Non-Blocking Process Execution with Asynchronous Service and Retry Mechanism

[initshdb]

I’m working on a process where I need to send a message to a JMS queue as part of the flow. However, I want this task to behave in a non-blocking manner - meaning:

1. While the service task sending the message to the Queue should happen asynchronously should not stop the process execution and should immediately continue to the next task
2. If the message sending to the Queue fails, the service task should retry for a finite amount of time based on number retry attempt defined, and if it still fails, it should log an incident, but not abort the process execution.

I’ve explored Asynchronous Service Invocation however, I’ve hit some roadblocks:

• The process execution is still blocking. When the execute() method of the service task returns, the process engine halts execution and waits for a signal() call. I don’t want the process to wait for the service task to complete.
• signal() can’t create an incident if an error occurred while running the Business Logic.

What I’m trying to achieve:

• A service task that kicks off an async JMS message sending operation.
• The process execution continues immediately to the next task after invoking the send task.
• If the message sending task fails, it handles the retries, logging an incident if it fails completely without aborting or rolling back the process execution.

Has anyone implemented this before? Is there a recommended approach or workaround to get this behavior or have my design.
Or am I possibly approaching the design incorrectly, and if this should be handled in a different way?

Any guidance would be really appreciated!

[claudio_rio]

You can try the whole message handling as another process and not rely on implementation details (you probably can reach this asynchronous behavior using Java, though).

Something like this:

The main process would send the message to the Message Handler and proceed to the next task.
A new instance of the process Message Handler would be created to handle the delivery to the JMS queue. And you can add the retry logic in there and even resubmit messages by re-executing a specific instance.

[GotnOGuts]

This is exactly the same thought I had

[initshdb]

Thanks for the hint

Do you think it would also be a good approach to use a parallel gateway, that creates two tokens - one path leading to Some Other Task, and the other sending the message to the JMS queue via a Service Task marked as async? This would allow retries in case of failure, and otherwise complete successfully, while the first token continues through the user tasks to completion.

Could this be another approach, or are there any downsides to consider?

[claudio_rio]

Yes, this is an option. The difference is the life-cycle.

In this option the process terminates only when both branches reach the end event. If the task that sends JMS fails the process will not terminate successfully.

In the other option, both branches are completely decoupled.

It pretty much depends on your requirements.

[initshdb]

Right, I see it now. With the decoupled approach the main process will complete with a normal flow even if the JMS flow fails, while in the coupled one the main process will only complete once both the parallel flows have been completed.
It’s a matter of what should happen if the JMS fails, on which I need to decide between either of the approaches.

Thanks for the explaining and showing the way