This is a repost of an article from my old blog about CodaServer. It’s being published here for posterity.
Most software developers work in the trenches, the corporate IT departments, writing code to help automate a company’s various processes. While the Googles get the glory and Facebooks find the fame, our intrepid warriors make life better for one knowledge worker at a time.
One problem corporate developers have is that business processes, once in code, are difficult to change. This is compounded when multiple languages or development platforms are in use, as the changes need to happen at the same time in multiple places.
The Old Way
Let’s start with an example taken from a simple warehousing operation.
- Pallets are delivered by UPS or Federal Express to the receiving department.
- They are then inspected for damage by the staff.
- If there is damage, they are rejected and sent back to the supplier.
- If they are good, they are “broken down” and the boxes on them are stocked in the warehouse.
Using a traditional SQL database, there may be a table for “pallets” with a column called “status” having each of the highlighted words above as possible values. (There would be other stuff in there too, but I’m keeping it simple.) There would also be a (say) PHP class called “Pallet” with methods corresponding to each of these actions, as well as business logic handling the validation of various fields and making sure that the specified pallet was in the right state to have the action performed. Then there is a web tool that let users record this stuff online, and it would also do some form validation as the user tried to do various things. There is also a Java-based reporting engine that runs against the database, and it needs to know about all of the statuses for some of its ad hoc querying capabilities.
Now, say management decided to change this. They add a staging status between delivery and inspection, since the warehouse is receiving so many shipments and the staff can’t inspect them quickly enough. The staging area will act as a short-term storage area, and the status will give management greater visibility into where their boxes are. What needs to change?
Well, the database is simple. “Staging” becomes a new status field value. Just gotta make sure to add it to all of the environments. The Pallet class gets a new method, and most of the other methods may need to change too to make sure they are checking for the new status. The front end has some new conditional logic to take care of, and it needs a new button and status made available. And the Java reporting system needs to know about staging.
The CodaServer Way
CodaServer handles “tables with status” using its FORM entity. Instead of making status a data value in a table, it lets developers define the state diagram for the entity. This is done by defining a series of “leads to” relationships:
- Delivered leads to Inspected.
- Inspected leads to Rejected or Broken.
- Rejected leads to Nothing.
- Broken leads to Nothing.
To add a new status to the list involves simply declaring the new status through an ALTER FORM command and rewiring Delivered to point to it via another ALTER FORM.
CodaServer lets you specify both an adjective and a verb for each status.
- Delivered/Deliver
- Inspected/Inspect
- Rejected/Reject
- Broken/Break
These verbs are what happens to the object to make it enter the adjective state. Incidently, these verbs replace the traditional INSERT, UPDATE and DELETE operations in SQL databases, although you can still use UPDATE to modify an object without changing its state.
UPDATE pallets SET status = 'Inspected',
inspection_date = CURRENT_TIMESTAMP WHERE id = 4;
is replaced by
INSPECT pallets SET delivery_date = CURRENT_TIMESTAMP WHERE id = '4';
CodaServer handles all of the busy work of determining if Pallet 4 is in the Delivered status, without your having to do anything. It also fires off the BEFORE INSPECT and AFTER INSPECT triggers if you have them specified to handle any validation or cleanup that needs to be done.
What’s more:
All of this is discoverable through metadata commands.
Applications can be written in such a way that they know about your business entities, their statuses, actions, and workflow without you needing to write any additional application code. Think about this, because it’s a pretty big deal. All application metadata is available through a cross-platform web services API, a business rules engine enforces your workflow and data integrity, and your workflow can change without you having to write more application code.
That’s developing smarter.
Til next time.
