We are interested to know if there are some examples that explain or show how to make business flows watch for certain database changes. When a watched change happens, a process would start.
The changes are outside of a workflow instance, like a person updating an address or certain core data fields, and based upon “seeing” that change, a business flow could be triggered.
Paul are you using embedded engine or shared engine?
Deployed through Docker on AWS in our environment.
Would you consider that embedded?
Sounds like shared.
So your app (built in what?) is doing something and you want to execute a process what xyz happens? If so, this sounds like “events”. Take a look at the /messages rest API and the message start event in bpmn. You can post a message to camunda when xyz event occurs in your app and camunda will start the process.
Will take a look along those lines.
We were hoping to “register” a business flow that “watches” or acts like a trigger to catch when the condition(s) are met and then start the business flow instead of having to create another messaging system in our application to trigger a message to have a Camunda business flow start.
How can your app be accessed? API, direct to DB? Can you poll your DB for specific changes?
What is available for camunda to monitor your app?
Direct DB is option
We could also expose API to make requests.
This is a brand new application for us, so all are possible.
But the MVP ( proof of concept ) is probably direct DB polling.
Not sure what is the most efficient yet - the DB is Postgre
My recommendation is to write some simple DB procs to do your logic of “changed data” or whatever queries you need to rerun/poll on and build a simple rest Endpoint to call.
Look at this polling pattern: Pattern Feedback: Timer Cycle Checking of external systems State/Status.
Create a process that polls and when there is a change that you want to execute on, your polling process calls a subprocess with a call activity.
But given this is a MVP and a new app, it would be way simpler for you to just call the camunda message API whenever a change occurs in your app.
For a proof of concept, have you considered use of a DB trigger? For example create a post update trigger on a table to initiate a script to call a REST API to start a process.
Theres a few things to be aware of. You may have a distributed transaction without a transaction manager (what happens if REST API fails?).
In addition, Im not a fan of the approach. Consider this, the DB was updated due to an activity in a process. For example assume the trigger is on a customer address. Hence there is a change customer address process happening which caused the update to the DB. If this were to trigger more processing, I wonder if the entire change customer address process should not be externalized from the application…