Custom application request/response with bpm

Sorry, I am new to the BPM world and Camunda. I have been poking through the examples and am wondering the best way to do something. In all the examples it seems like a process is just started and no real response goes to the invoking user besides stating that the process has been started.

So say for example we look at the bank account opening example

Now, say the flow changes that instead of the user submitting an order and human checking documents, some of this can be automated. If certain things are met based on the user, then the account will automatically be created, otherwise it may go to a human to evaluate.

If the account is auto created, then the response to the user would include his account number. If the account is not auto created, the response would state that the account creation is in process and he would be notified when it is available.

How are the multiple responses handled from the custom application?

In this case, I would expect the application to submit to the BPM the order as it does now. Does the BPM model need an additional flow to send response to the user and the custom app would have to listen for a response on a different REST endpoint?

This is something I think a lot of use have to deal with and I am no expert. My own company has the need for such functionality. So, I’ll “hold forth” a little bit on what I know, which may not be much.

The problem you are describing has a couple of different aspects to it. If you have some external client invoking a process, you must decide if it is appropriate for the client to wait for X amount of time for the process to complete and return any output, or if you want the client “released” immediately after invocation. Both of these choices are complicated by the question of what interactions the client must have with the process during its lifetime.

Like most things, there are a bunch of different ways to do this. For example, you could have your client maintain a “session” with the process during its entire lifetime. However, during this session, you only have one opportunity to receive a response from the process via the initial REST call. When that response is received in the lifecycle of the process is up to you.

I have a process that uses the “Asynchronous Before” option very early. This means the process ID/status code is sent back to the client almost immediately, even though the process could run for a considerable time thereafter. In this scenario, there are two (or probably more) ways for the client and process to “communicate”. One way is for the client to store the process ID and periodically poll (or pull from) Camunda for status on the relevant element (e.g. process variable) in the process. The other way is for the process to send (or push to) a message to the client via some interface. Either method generally requires your client, which is not an integral part of Camunda, to modify its behavior.

There are no doubt other, and possibly more sophisticated, methods of communication such as the Java API which may allow for direct incorporation of some form of messaging “channel” between the client and Camunda (i.e. a Java library). That’s beyond the scope of my experience.

One other way potentially to do this is to have your process write relevant “state” information (e.g. the current value of process variables) to an external database. Then your client (or other applications requiring this information) could access that. However, this information is generally available via the REST API, so it might not make sense. However, should you have correlation requirements that fall outside of what Camunda can provide, this may be applicable in those use cases.

In the end, this is really a matter of having your client’s behavior modify itself to accommodate how Camunda works. The REST API is a stateless connection, so it’s always going to require some form of request/response interaction. The JAVA API may offer more “real time” communications options, but I’ve never used it directly.

I hope this helps.