Hi,
in most cases external ‘workers’ read and complete tasks. I understand that is preferred solution because of the simplicity, performance and errors handling.
But what if camunda tasks initiate API calls? This works but is not recommended? If that’s OK what is prefered; situation when service task do ‘http-connector’ and parse response OR call API with service task and move to ‘receive task’ where API should reply?
How to handle communications failure, errors? Boundary timer event for service task or else?
Anyway what’s the proper camunda naming for both scenarios (task is called, task calls)?
Regards,
G.
Hi @mkelton,
it is totally OK that a service task calls a REST API. (I don’t know a special term for this, I talk about delegation code in this situation). For Java developers it is an easy task as they can control the complete lifecycle of the call and use all features from the library they like.
If you use Connectors for this, be aware of the limits here: communication failure and timeout. Boundary timers didn’t work for connectors or Java delegates: Transactions in Processes | docs.camunda.org.
But they can used in external tasks. If you have long running calls, external tasks can make your life easier here.
Hope this helps, Ingo
Thank you Ingo - it helped me much to understand how Camudna works.
Boundary timers for connectors seemed to me so natural that I would never thought this is not possible…
I tried “Java Delegate”. Everywhere we can find information that this is class. I think this is rather application or at least package not class - requires separate build on web server. So I had another surprise that I cannot just point to some class from BPM definition but I have to build deployment containing ‘delegate’ code and BPM diagram - all combined together.
Anyway, I tried bu build one but despite lot of tries I failed. There must be something with the Camunda code or I simply do not know the trick (I followed strictly the manual). I will open another ticket - maybe some good soul will help.