For both inbound and outbound integration endpoints, 'transactional settings' specify how background processes will be generated, how the messages will be processed, and what will happen upon failure.
After configuring transactional settings on the integration endpoint, configuration for queue size and parallel are set in the sharedconfig.properties file as defined in the Background Processes and Queues topic in the System Setup documentation.
Inbound Integration Endpoints
In the IIEP wizard, background process and error handling are managed by three (3) elements: the selected Receiver (on the Choose Receiver step), the 'Transactional settings' parameter, and the 'Maximum number of waiting processes' parameter (both on the Configure Endpoint step). These elements also work together to determine what additional options are available in the wizard, as defined below.
For more information, refer to the IIEP - Configure Endpoint topic.
Outbound Integration Endpoints
While creating an outbound endpoint using the wizard, the Choose Data Source step determines if the transactional settings can be set in the wizard. As defined below, selecting a Select Objects data source provides several options for transactional settings; selecting an Event Queue data source requires the 'Strict' setting.
For Select Objects OIEPs, the transactional settings can be modified in the OIEP editor, on the Configuration tab. The 'Transactional settings' parameter and the 'Maximum number of waiting processes' parameter determine how background processes and errors are managed.
For more information on select objects OIEPs, refer to the OIEP - Select Objects - Configure Endpoint topic.
For details on the 'Transactional settings' and 'Maximum number of waiting processes' parameters, refer to the OIEP - Configuration Section topic.
For event-based OIEPs, only the 'Strict' transactional setting is allowed. 'Strict' ensures that an event in the STEP event queue is not removed until the endpoint has successfully delivered the result of the event to the external system. If event processing fails (i.e., the external system is not running and therefore does not accept any data), the endpoint is disabled but events are not removed from STEP. Once the error state is fixed by a user, the endpoint can be resumed; events waiting to be sent to the external system are processed, and the data history is retained.
For more information on event-based OIEPs, refer to the OIEP - Event Based - Configure Endpoint topic.
Transactional Settings Options
When available, the possible transactional settings are: Strict, Chain, and None.
Strict
Using the 'strict' transactional setting processes data in a strict order, using one background process at a time. When one background process completes successfully, the endpoint starts the next background process. If a background process fails with an error, or if it cannot deliver a file, the next process is not started, and the 'Failed' status is set. This is the most common setup, unless there is a reason to use Chain or None (for assets).
The queue size of a background process with strict transactional settings must be one (1). A strict transactional setting does not allow multiple background processes to work in parallel / concurrently regardless of the queue size. By definition, no new background processes can be generated while one is active.
Strict is allowed for all inbound receiver methods and for outbound select data endpoints but is required for outbound event-based endpoints.
Chain
Using the legacy 'chain' transactional setting processes data in batches of chained background processes. With this setting, a batch is generated each time the endpoint polls for data and finds more than one message or file that has not yet been processed.
Note: Generally, 'chain' is not recommended due to slower processing speeds compared to 'strict' with similar features for enforcing order of import files.
The Maximum number of waiting processes parameter allows you to specify the maximum number of background processes with the status 'Waiting' that are allowed. If a background process in a batch fails, the remaining background processes in the batch will also fail. However, the endpoint remains active with the status 'Running' and continues to process data in the next batch of chained background processes. A chain endpoint stops if a file cannot be delivered.
The queue size of a background process with chain transactional settings must be one (1). A chain transactional setting does not allow multiple background process to work in parallel / concurrently regardless of the queue size. By definition, no new background processes can be generated while a background process is active. The default 'Maximum number of waiting processes' is 1,000.
Although chain is allowed for all inbound receiver methods and for outbound select data endpoints, it is not recommended as it results in slower processing times.
None
Using the 'none' transactional setting processes data concurrently, without any transactional restrictions or data dependencies. This is useful, for example, when processing assets. The default queue size of a background process with transactional settings of 'none' is one (1). Data is not processed in a strict order and if one background process fails, the endpoint continues to process data in the next background process in the queue.
None is not allowed for the inbound 'Hotfolder Using File Sequence Receiver' or 'Hotfolder Using Meta Files Receiver' methods but can be set for other inbound endpoint receivers. It can also be set for outbound select objects endpoints.
Important: Switching the 'Transactional setting' parameter after an OIEP has been created will also change the 'Maximum number of waiting processes' parameter. If changing from Strict to Chain or None, the 'Maximum number of waiting processes' will stay at one (1). Users will need to go in and change that number to higher than one (1) in order to attain Chain or None processing. If the OIEP was set up with the Chain or None settings, then the 'Maximum number of waiting processes' will continue to display 1000 when changed to Strict until the workbench is refreshed.