Skip to main content

I've encountered a problem and need some help understanding the workflow architecture, specifically when a workflow is invoked by an event. I'm focusing on synchronous workflow invocation only.
 

Diagram from documentation 


Problem: I've noticed a difference in behavior between using Error_SYS.Record_General() in an Execute Online SQL event action and IFS Failure in a workflow event action (in my experiment, both are exclusively called by the same event). It seems Error_SYS stops the process, while IFS Failure in the workflow doesn't stop the process, and I can see more activities (Server Trace) in the DevTool log. Additionally, some data are changed despite the validation error message appearing.

This issue is connected to the functionality: Report Picking of Pick List Lines -> Report Picking of one line with serial number. Report_Picking_Of_Pick_List_Lines_SVC.Do_Pick_Selected(...).


Context: For every event, a database trigger is created, and it invokes the workflow if I understand correctly. I imagine it is done in a similar way to other event actions like SQL actions, Emails, and so on.
 

Questions:

  1. How do we invoke the workflow from PL/SQL code? In the code Bpa_SYS.Append_Event, it looks like it is adding some workflow to the collection only. I do not see any direct invocation.
  2. If I do not see direct invocation of the Camunda Engine from PL/SQL, does it mean we use asynchronous communication in this case? How can we assure a single transaction? I have tried to read the documentation, but it doesn't answer my question.

 

I have the feeling that the workflow is being invoked with a delay (light async), but it should be run synchronously.

Understanding this would help me troubleshoot this and other issues.

 

Any insights or explanations, especially from the R&D team, would be greatly appreciated!

Additionally, I have conducted a simpler experiment in the Part Catalog (Master Part).


Here is what I can see in the log using Validation by Online SQL and Error_SYS:



And here is what I can see in the log using Validation by Workflow:

 

 Hi ​@Tomasz Grzebula,

These are the answers for your questions

  1. When an event trigger is fired, if the type is workflow, then the workflow and parameters are logged in the oracle session. In the same transaction, Odata checks the oracle session if there are any logged workflows. If there are any, these workflows are executed from OData side. That’s why you couldn’t find any execution logic in the PLSQL side.
  2. No. Executions are not asynchronous. They are synchronous,  in the same transaction of the Event triggering OData call. When OData receives an http call, it checks for projection before and after workflows. If found, they are executed first. Then OData checks for PLSQL side session for workflows that needs to be initiated because of an Event action. If found, they are executed next. Invoking transaction completes only when all of the above are completed successfully. If any of them gives an error, whole transaction will be rolled back.

Additionally, assume if the OData receives an HTTP call, which calls an action in PLSQL side, which calls other action chain as well. In this scenario, if the event is triggered by some db change in the first action, still the workflow will not start immediately. Workflow will start only after the initiating action chain is completed.

​@Buddhi Gunasekara , Thanks for your answer. Additionally, I have conducted some experiments. Please let me know if I understand them correctly.

Let's assume we have:

  • A call to the projection Package_SVC.Procedure().
  • Inside, there is an update tab1.
  • On tab1, there is an event with two actions:
    • SQL Event Action and
    • Workflow Event Action.
  • Additionally, we have a workflow type Workflow Projection Action 'After'.

As shown in the diagram below:
 


 

Please let me know if my understanding is correct:

  1. SQL Action Event is called just after update tab1
  2. Workflow Event Action is registered by a database trigger but is called later (still within a single transaction).
  3. This means Workflow Event Action is executed at a different moment than SQL Event Action.
  4. When we call Workflow Event Action, the state of the database may be different than just after the update tab1.
  5. Workflow Event Action is called after Workflow Projection Action 'After'.

 

 

1 - correct

2 - correct

3 - correct

4 - correct. After update tab 1, sql event action firing next might change the state or it might be any or all of pl/sql(1) or pl/sql(2). This concludes the base OData call. Then the after projection action workflow is run. This workflow again might/can change the db state. After all the above, workflow triggered by the event action is run. That workflow will be looking at a different db state again.

5 - correct

​@Buddhi Gunasekara, thank you very much for your comprehensive and detailed answer. I appreciate the effort you put into it. Unfortunately, in my opinion, this behavior goes against the principle of least surprise. As far as I know, all other synchronous Event Actions are called exactly at the moment of triggering. Please correct me if I'm wrong.

On the other hand, I understand that from an architectural point of view, this might have been the most obvious way to implement it. Therefore, I have a questions:

  • is it possible to change this behavior? This would be the ideal solution.
  • At the very least, this unexpected behavior should be described in detail in the documentation.

Thank you once again for your effort and assistance.

Reply


Terms & ConditionsCookie settings