Question

Potential infinite recursion detected in cascading BPAs

  • 29 January 2024
  • 2 replies
  • 139 views

Badge +1

Hi All,
I have a question about Business Process Automation and workflow.

A workflow has been created, which is triggered by an event action when changing the status of the Purchase Requisition line from Planned to Released.
Neither the workflow nor the function called in the workflow modifies the data (no insert or update). The result may only be a message informing about errors in the data.
For the Purchase Requisition case with the number of lines greater than 20, when changing the status from the Requisition header, an error message appears:
Errortext:
(BPA_EXECUTION_EXCEPTION Error): Potential infinite recursion detected in cascading BPAs.
In Log Window:
ERROR - Command error: (BPA_EXECUTION_EXCEPTION) - Potential infinite recursion detected in cascading BPAs., details: "4" undefined
DEBUG - CMD(1): Error: Potential infinite recursion detected in cascading BPAs.
DEBUG - CMD(1): Done Form_ReleaseCommand.

Performing a status change from the header level will, of course, change the status of all lines (in one transaction).
Changing the status from the Purchase Requisition lines (e.g. after selecting all lines) does not cause an error.

Is there any limit (e.g. within the system configuration) to the number of possible Workflow runs (probably up to 20) within one Oracle transaction?

regards
Witold


2 replies

Userlevel 5
Badge +14

Good question. 
Based on the standard, the status might change more than one time. I once had a setup where I checked the status update and it happened that I received more than 10 times or something like that where the status had been updated.

 

Not sure which mechanism is running here to check the possible counts of it. 

 

Userlevel 3
Badge +5

Yes. This is the default max number of cascading workflows allowed for a transaction. This reply elaborates on how to change that and the caveats of increasing that number. 
 

If you only need data validation for header level, you can consider short circuiting wf in the subsequent executions that occur after header change. This techdocs example discusses on how to detect recursion and exit the unintended wf executions.
https://docs.ifs.com/techdocs/23r2/040_tailoring/500_business_process_automation/080_workflow_examples/#detect_recursion_example
 

Also you can try a projection action(state change bound action) instead of an event to trigger the workflow ,if it suites your use case. Hopefully projection action will trigger the workflow only once. So you don’t have to worry about the cascade limit.

Reply