Control flow execution of external application

Hello.

I want to know if with a camunda bpm it’s possible to design a flow for a completely external application.

  1. An external application should start a bpmn model and retrieve some results after the first interruption/suspension of the process itself.
  2. After that the external application, through workers, will Fetch and Lock on a specific External Task and Topic, and will wait to proceed further.
  3. After the worker has locked succesfully the task, it will process the data and in the end it will send a ‘complete’ command to to externaltask.

The points 2 and 3 can be repeated again to continue the flow.

I know this is not an usual worker that accept every task with some topic, and instead it must find only the specific waiting external task. Right now the ‘FetchAndLock’ rest method does not allow to filter through specific process instances or other parameters except than the topics name.

Any idea ?

I’m interested why it would matter what external task you would get?
Usually if you’re designing a system which implements external tasks it doesn’t matter which task is picked up any task that subscribes to a given topic should be able to do that same work irrelevant of the specific instance.

Hello Niall.
Thanks for the answer. I perfectly know that.
I wanted to know if the external task is the right to do what I want, but probably is not designed for that.

I’ll try to explain with an example:
External Application Flow:
User Logins ----> User completes form 1 -----> User completes form 2 ----> END
Camunda Process Flow (described through rest api calls):

  1. START - Process is started after user login and tells the external application what form should be used as form1 (using the parameter ‘withVariablesInReturn’ inside the rest call). The process will suspend itself (with any useful suspending task/event)
  2. TASK COMPLETE(or another command that indicates that FORM 1 is completed) : the process in camunda continues till the next step (another suspension of the process) and returns to the external application what form will be used as form 2.
  3. … repeating (2) for other steps if needed.

In other words the process will act as a router based on some (but not necessarily all) of the variables filled in the external form. The form will activate until it reaches the next suspension, giving to external application the next page/form to show to the user and waiting for the next activation from the external form, and so on. The two flows are connected.

To do that the external application will either get the results for the next step from rest call (if possible) or with a polling on the state of the process in camunda (and this why I thought about the fetchAndLock call of the external task rest api).

Maybe I have to take a completely different approach.