FarmCraft - July Update

It's about time for another monthly FarmCraft update! The beginning of July started out a bit slow due to working through some other projects, but things picked up again in the second half. Let's take a look.

Supplier Management​

The first actual feature for FarmCraft, supplier management, was wrapped up this month. Supplier management allows a farm to enter not only suppliers, but products that be purchased from the supplier.

Though adding suppliers and products doesn't seem to do much at the moment, this will play a large part during the order management workflow. Suppliers will determine who you can place an order with, and which products are "available" to purchase.

Order Managment​

Next on the feature list is order management. The only thing accomplished in relation to orders for the month of July has been the data model, but in future work, orders will play a large part in both inventory and traceability.

Initially, there will be a purchase order area from which you can place orders and track them. You'll also be able to "receive" an order which will populate inventory inside of FarmCraft.

Later on, I'll also be adding a sales order area from which you can manage all client-related purchases from your farm.

Refactoring​

A large amount of work this month went into refactoring and better organizing the code. One of the other "projects" I worked on this month was an Akka bootcamp, which goes into additional detail about how to use Actors and the Actor System. Completing that caused me to go back and re-think some of the logic that my actors were handling.

Actor Hierarchy​

One change that took place was a re-organization of the core actor system.

Originally, most of the work being done was forwarded to an actor that was created on demand and then killed off. I decided to change this into a few root "system managers" who are responsible for system-level events and managing their own workers.

I also put the business logic behind both a tenant manager and tenant supervisors. The reason for this was to isolate work within a tenant and to reduce the scope of errors. If one tenant starts to have a problem, it won't effect the operation of any other tenants.

Concurrent Database Requests​

When I first built the system, I decided to create DbContexts within a scope in each actor. Due to how this was setup, I was limited to doing a single database operation at a time. In many cases; however, multiple requests needed to be completed which didn't rely on one another.

To resolve this, I did some refactoring and utilized the DbContextFactory, which allows me to speed things up by performing multiple database operations concurrently.

Standardization​

Finally, I spent some time standardizing the API endpoints and actor messages. This helps with keeping things organized and makes it easy to figure out what's going on, regardless of which controller or endpoint you're working with.

Demo​

If you'd like to take a look at this month's demo, you can find it on YouTube.