Dear friends,
My use case is:
At a specific step in flowable bpmn workflow, we need to call an API of another system for approval. Because there are some manual activities in that system so it will call back to my system some days later.
How I can model it ?
Thanks
I play this game. The way I have come up with to handle this is with a User Task that’s completed programmatically when the “green light” condition is met. The Flowable APIs will let you do this, you just have to decide upon how you establish the green light condition. I’ve had 2 different approaches to it over the years.
Approach A uses a database table read on a schedule. When the external system finishes its work successfully, it updates a row in that table. The scheduler runs code that checks that table for the update and when it finds it, executes the logic to complete the task and advance the workflow. The downside of this approach is that it requires the external system to reach directly into your database, and many IT security postures are moving against this practice because having a database directly talk with another database creates problems. In fact, this is the “Old” way I did my first external integration and I’ve since had to rework it because of that.
Approach B, which is more recent, uses a custom web API call. The external system calls back to me using this API and the payload of that call contains the “Approved” status. Inside my code, I read through that payload to find items that were “Approved” and complete the corresponding tasks for them to advance the workflow along. This approach requires two very important things. First, the external system has to be able to invoke your web API. If it can’t (for whatever reason), this approach is never going to work. Second, your API has to be a secure endpoint. You don’t want just anyone being able to complete your tasks, you want to ensure that only the target system can. That means setting up a security mechanism (like a service account) for that system to authenticate and be authorized to interact with your API.
thank you @jeff.gehly
I just find a solution for this. It quite similars to your appoach B.
My solution is:
It works but I don’t know if it is the best approach or not
Thanks
Whether that is the best approach or not depends on your particular system and your security, logging, and audit requirements. For me, my Flowable engine is embedded into my server-side code and I use the User Tasks so that I can report on the exact steps a workflow is on at any point in time and who completed which steps and when. That’s because I have requirements that demanded that level of detail from me and User Tasks were a nice way to accomplish it with minimal fuss.
If your solution works for the requirements and needs you have, then it doesn’t really matter. If you do need to do auditing of your system task it’s possible, it just requires more work on your part. User Tasks have dedicated APIs (one for running workflows, one for task history) that you can query against. System Tasks are lumped into the activity history API set, and then you’d have to drill down within that query to find only your system tasks (activity history is the entire workflow history including start/end nodes, sequence flows, decision gateways, sub processes, user tasks, etc. It’s all in there).
That’s probably the nicest thing about Flowable. There isn’t a “right” solution. If it works, and it’s not murdering your system performance then it’s a viable solution. (You should not, under any circumstances, try to invoke the Flowable APIs within a loop that contains potentially hundreds of records. You will blow up the JDBC).