1

I'm looking at jBPM specifically, but I think this applies with other systems too.

As I understand it..

When placing an item into a workflow, one does not generally put a reference to that item, one puts the whole serialized item or document into the workflow. This means that the state of the workflow and the item undergoing workflow can all be kept in the workflow systems database, making it easy to make atomic updates.

At the end of a workflow, or sometimes in explicit steps along the way, calls can be made to downstream services, and these may make changes to the state of their databases. How does one handle this?

Is it:

  1. The workflow and services should all be deployed in a single application server container, and a transaction manager used to keep everything consistent?

  2. You call a service, then the workflow state is updated, but not in a transaction. Failure and restart of the workflow may cause duplicate calls to be made, if the state update failed.

  3. You decouple them using a transactional JMS queue. Then downstream systems can read from that queue in their own transaction. Updates happen transactionally and in the correct order.

Or something else, or whatever combination of the above that you like.

I should add, where I work we have micro-services (whatever that means). It means we do not have an application server, so global transactions accross service end-points are not possible (no ws-tx either, the services are REST/json). Is the JMS solution the only one that is open to us?

1

Not being a Java guy my answer may be disappointing.

"When placing an item into a workflow, one does not generally put a reference to that item, one puts the whole serialized item or document into the workflow"

I think the word "generally" is key here. The decision about placing the a reference or the whole item should be case by case. If the object is constant across workflow instances and the workflow needs to know when it changes, do not place it on the workflow. Use a reference instead. It's easier than creating a mechanism to notify instances abut the change. Registry data is my prime example.

How you update the database from the workflow instance is also a case by case decision. Some updates should be atomic (the workflows should not be allowed to continue to order fulfillment if the database transaction updating the client balance fails).Even if not in a transaction the workflow can be modeled around it.

Other times the workflow can continue even if database fails to update with just a warning to the user("We were unable to update your address in our registry at this time, but your order will be delivered to the new address" ). You can also queue the update.

So, use transactions when you must, fail gracefully when you need to and queue things that are not time sensitive.

No silver bullet. Sorry.

  • Not a disappointing answer at all. In fact I enjoyed hearing from a non-Java guy, since you are not drinking the Java cool-aid, and have given an answer that focusses more on ways of achieving the desired outcome, rather than what dogma or a particular tech stack dictates. – user2800708 May 21 '15 at 14:37

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.