B98ORCH Design Considerations

When you configure B98ORCH to call an orchestration or notification from an EnterpriseOne event, there are many factors to consider to ensure that the process completes successfully with little or no impact to performance. Some of the considerations listed here are no different than if you were designing a business function for a custom application.

Understand the action that the orchestration or notification performs

Is the notification set to Run as Subscriber? If so, be aware of impacts when calling a notification that is set to "Run as Subscriber." See Planning for "Run As Subscriber" and "Allowing Subscriber Overrides" in the JD Edwards EnterpriseOne Tools Notifications Guide.

Is the orchestration performing updates or deletes? Is it calling a UBE and waiting for it to complete? These operations take time and have the potential to lock database records.

Consider the event from where you call an orchestration or notification

If you call an orchestration or notification from an event rule, consider how many times the event is executed. Do you want to call the orchestration or notification every time or do you need to condition the call?

If called from a table trigger, to avoid recursion and locking, it is recommended that you run it asynchronously. Recursion and locking can happen on update or delete operations on existing records if the trigger on a table calls an orchestration that attempts to update the same record in the table.

Consider the performance impact of a UBE designed to invoke an orchestration repeatedly. For example, if you have a UBE configured to invoke an orchestration hundreds of times to update hundreds of records, expect a marginally longer processing time. The time the system takes to complete each transaction is no different, but the overhead for each orchestration invocation (100 milliseconds per invocation at a minimum) should be considered. You should determine the actual runtime of your orchestration to understand the impact of calling the orchestration repeatedly during the report execution.

Orchestrations invoked from a UBE always runs synchronously, regardless of whether the B98ORCH parameter is set for synchronous or asynchronous processing.

Design considerations for avoiding time-outs

If a trigger on a table calls B98ORCH configured for synchronous processing, the table operation may time out, which will cause the operation to fail, and potentially roll back the transaction.

Important: If a transaction times out or fails, it is important to note that even though the transaction might be rolled back, the operation performed by the orchestration is not rolled back.

If an orchestration launches a UBE, it has to wait for the UBE to complete before proceeding to the next step. Because of the time it can take for a UBE to process, it is likely that the session between the calling client and the AIS Server or the session between the AIS Server and HTML Server will time out. Therefore, the recommendation is to call an orchestration asynchronously, especially if the orchestration is designed to launch a UBE.

Make sure that the recommended timeout settings for the servers in an EnterpriseOne with AIS Server architecture are set properly. See "Timeout Settings" in the JD Edwards EnterpriseOne Tools Security Administration Guide for details.