Signal Intermediate Boundary Event at normal Service-Task with Retry-Pattern

[shp]

Hello,
I think, I missunderstood something and just to be sure (as tests don’t succeed)…

That task has a retry pattern (R4/PT15M) as the service maybe blocked. To reduce waiting time (and not increase polling), my idea was to add that signal, that was meant to interrupt the waiting-time for the next retry.

In my tests, as couldn’t find any event-subscription while waiting for retry.

Can please anybody tell my what’s wrong - my code or my idea?

[WilliamR.Alves]

Hello my friend!

The signal event works correctly, but maybe it’s not the best solution… but I don’t quite understand the idea…

Let me understand better… you will have several instances running in the Webservice Call service task… and when one of the instances “Exits” from this service task, you want to trigger the event so that all instances exit their execution and start her again?

The Signal event works like this: It has a global scope in your application, that is, all instances that are locally waiting for the signal… when they receive this signal, they will follow the flow defined by this event.

Notice this image below:
I have 4 instances running in the “Webservice Call”… however when one of them finishes execution, and reaches the Signal End Event, the other 3 instances that were running are thrown out of this task through the Signal Boundary Event.

Here you can see that one instance finished execution via the happy path, and triggered the signal end event, and the other 3 instances returned to the previous step, as they all received the signal event.

If the idea is this… when the first instance finishes, it means that the others that are executing the task, or waiting for retries… will be triggered to restart the process and call the service again, “skipping” the step of retry.

However, this seems like a bad solution to me… because imagine that, in a perfect scenario where everything is running well… imagine you have 100 instances in the WebService Call, and it’s just taking a while to execute, but it hasn’t triggered any retry , because there was no error… when any instance of yours finishes the process, it will trigger the event and make all your instances restart the process from scratch again without need… entering a loop and probably crashing your application in a short time.

Or maybe I didn’t understand the idea hehehehe…

But I remain at your disposal and hope I helped.

William Robert Alves

[shp]

I have to read the full answer again on monday.
But I can give some background.

First of all: In our case it is a Service-Task, not Usertask!
The Sericetask is a WS-Call to the backend, which may answer a locked-error from time to time (because of data beeing in use).
This is, why we use a retry-pattern.

There are two reasons, why a quicker retry may be successfull:

• new instance starts (because of backend-changes)
• an other instance end (the one, that may have blocked the backend - it a bit more complicated).
  This is why the bpmn implements two send-signal-events (that use a specialised signal-name to just push the relevant instances).

Short:
The Service-Task gets an error, because of the retry-pattern, it doesn’t end in an incident after the first try.

As I told, in my Tests, I was not able to find any event-subscription when waiting for retry after an error-response from backend.

[WilliamR.Alves]

Yes, I understand that your case is a service task, I used user task just to model my example… hehehehehe …

Maybe I still haven’t understood the need very well… and that’s why I can’t think of a solution right now…

But instead of starting an instance for each update, couldn’t this be done in an external task? doing the retries and validations inside the worker’s own code?

William Robert Alves

[shp]

I appreciate your input, I just need it in the right direction

The professional process is a well as it is. There is a need for every started instance anyway and there is also a need for the backend locking the service from time to time.
So we have situation, in which have have to handle mutliple instances at the time. The retry-signal-solution would have been an optimization.

As my different tests could not prove, that it would actually work (no event-subscription), I asked here.

I am sure, that a usertask behaves totally different, as it has other waitstates and not implements no rety-pattern.
So if you really tested with a service-task as you answered…

The signal event works correctly, but maybe it’s not the best solution… but I don’t quite understand the idea…

…I would really be happy to see your test-code.

Thanks anyway!