7 Replies Latest reply on Sep 16, 2014 12:17 PM by Maciej Swiderski

    Unexpected behaviour using interrupting message boundary event at a custom task

    Thomas F Newbie

      Hi all,

       

      We are using custom tasks to execute asynchronous service calls to external systems.

      The asynch response can result in different processings (simplified):

      - positive response -> call 'completeWorkItem' and go with the process (LOG AFTER, ...)

      - negative response --> redo the custom task by sending a message which is processed by the interrupting boundary message event and loop back into the custom task

       

      redo_message_boundary.PNG

      Our expectation is:

      - The custom task is cancelled/aborted (without traversing the process flow further to LOG AFTER, ...)

      - Loop back to the custom task again so that the service call is triggered again.

      --> Only one thread exists and that is the one for the looping (MessageReceive -> LOG FIRST --> XOR -> FIRST_CALL)

       

      What happens:

      - One token traverses down the process (LOG AFTER, ...)

      - One token loops back to the custom task again so that the service call is triggered again.

      --> So there are "logically" two threads of execution in the process exist (1. MessageReceive -> LOG FIRST --> XOR -> FIRST_CALL | 2. LOG AFTER ...)

       

      Is that a desired behaviour?

      If so, do are there best practices etc. how to solve our use case/expectation?

       

       

      Thanks in advance

      Thomas