Building robust scalable business applications becomes more and more efficient since the Java Enterprise standard (Java EE) has reached a level where developers can concentrate on the business logic and not about all the backend stuff like database management or security issues.
So from this point it easy today to setup a new business application in short time with reasonable effort. The Java Persistence API (JPA) provides a natural way to map the business objects from the real world into a software system. The JAAS Standard makes it easy to add security. And with different connectors we can connect a business application also to existing applications to exchange any kind of data. So it seems that everything is prepared for developing big business applications. Why should we think about managing the business process? Isn’t it easy enough to add all the required information into our business objects as simple attributes?
Yes you can start this way. But you will run into problems as more information about the business process becomes relevant. Lets start with a typical scenario:
We are asked to build a new business application to manage a sale process for the sales department. The application deals with customer data (like the Email address and the postal address of a customer) and with the products the company sales (part number, price, amount, …). The business case seems to be easy enough. A sales person selects a customer form the customer database or creates a new one if the customer did not exist yet. Next the sales person select one or many products and add them into a shopping cart.
So fare we see the business process is simple enough to start.
But now think about the following new requests for our application form the management:
- What is the status of the current sale?
- Which sales person changed the sale last?
- How many different sale persons modified one sale?
- What was the price before the last change?
The problem with this kind of information is that it is not typical object related. First is looks easy to add an attribute for the current status of a sale and one attribute for the current sales person. But the things become more and more complex as more you have to deal with information in the past or the life-cycle of the sale. The list of all sales persons who have change the sale can be stored in a list related to our sale object. But what if you need to store the sate of a sale which was changed by a sales person in the past? And it will become really complicated when the new requirement sound like:
…we need to make sure that only sales persons from Group-A are able to change a sale which is in state ‘confirmed’, but this is not relevant for sales persons how are member of Group-B created a sale.
Since this is not a theoretical scenario, but the real-life of developing business applications the question comes out: how should we deal with this kind of complexity?
This is the moment where a workflow engine comes into the game. A workflow engine ore a BPM system has a total different view on our business application. For a workflow engine it is not relevant which data (customer, product, price) is managed. The focus of the workflow engine is the way the business data is handled. So you can say a workflow engine is not answering the question what data is stored but how it is stored.
HOW A WORKFLOW ENGINE WORKS:
So first a workflow engine know more about the business model itself. This is the way to describe the business process with a graphical tool. A typical way to describe a business process is the BPMN model. The model describes how the business process works, which persons are involved and which states are possible in different scenarios.
When the workflow model exists, the workflow engine can start the creation of a new process instance. A process instance maps our business data (customer, product, price) to a process model (sales process). The interesting part here is that the business application and the workflow engine can be decoupled from each other. So the only attribute which need to be stored in our business data object is the process instance ID given from the workflow engine. So the business application stores the data of our business process and the workflow engine will manage the state and the logic of our business process. And now we can ask the workflow engine about all the process data we need for our application. For example we can ask questions like:
- What is the current state of our process?
- Who is the process owner?
- Who was the last editor?
- What are the next steps in our process?
- Who is currently allowed to work in this process?
This are only a view examples which can be answered by the workflow engine. More important is the fact that we can change the behaviour of our business applications simply by changing the workflow model. This means that in most cases our main application is not affected from any changes in the business logic and we can manage the business application in a more flexible way.
So as you can see in this scenario of the development of a business application the need of a workflow engine is not always visible in the first phase of the development process. But as more complex a business application becomes as more important the usage of a workflow engine. The workflow engine can not replace the business application but extend the functionality into another layer.
So I recommend: the next time you add the attribute ‘status’ into one of your business data objects, stop working for a moment and ask yourself: wouldn’t it be easier to use a Workflow Engine….?