Implementing concurrent processing of event-triggered flows

You can configure collaboration objects and connector controllers to process multiple event-triggered flows at the same time. This can significantly improve the performance for event-triggered interfaces.

Concurrent event-triggered flow processing in Collaborations

Collaborations can be configured to process multiple event-triggered flows concurrently. System throughput and response time to event processing improve when concurrent event processing is properly used (see tip below). By default, a collaboration processes one event-triggered flow at a time.

When a collaboration is processing concurrent event-triggered flows, the collaboration identifies dependencies among those flows and processes them in the order that they were sent from the connector controller. Concurrent processing of event-triggered flows is performed on flows that do not have data conflicts, while flows with data conflicts are processed in the order received.

To configure a collaboration to handle multiple event-triggered flows, see Maximum number of concurrent events.

Tip:
Concurrent processing of event-triggered flows in collaborations requires additional system resources. To maximize performance, ensure that system resources used to handle concurrent events are not idle. For example, do not set the value for the Maximum number of concurrent events to 10 if the number of events in the collaboration queue never reaches 10.

If a collaboration's inbound ports are bound only to receive external calls through the Server Access Interface, and are not bound to any connectors, you can improve performance by setting the value of Maximum number of concurrent events to zero. But do not set this value to zero if the collaboration is being used for bidirectional exchanges with connectors.

Concurrent event-triggered flow processing in collaboration-object groups

Each collaboration in a collaboration-object group can be configured independently for processing a number of concurrent event-triggered flows. It is recommended that you set the same value for the number of concurrent event-triggered flows for all of the collaborations in a group, so that a collaboration with a low concurrency rate does not become a bottleneck.

Concurrent event-triggered flow processing in connector controllers

Connector controllers can be configured to process multiple event-triggered flows concurrently.

Event-flow processing performance improves when a connector is configured to process triggered event flows concurrently. This is because multiple business objects can be transformed in mapping at the same time.

To configure concurrent event-triggered flow processing for connector controllers, you set the ConcurrentEventTriggeredFlows property to the maximum number of flows you want processed at the same time. For more information on this property, see ConcurrentEventTriggeredFlows. For more information on using Connector Configurator to set connector properties, see in Configuring connectors general.

Tip:
If the ConcurrentEventTriggeredFlows property is configured to a value greater than 1, the connector controller maintains the same order of events that it received from the application. Concurrent processing of event-triggered flows in connectors requires additional system resources. To maximize performance, ensure that the system resources that handle concurrent events are not idle. For example, do not set the ConcurrentEventTriggeredFlows property to a value of 10 if the number of events arriving at InterChange Server Express for the connector never reaches 10. Use the server statistics window to determine the number of events that are in connector's queue by monitoring the MQ queue depth for the connector. Monitoring this statistic can help you set the value for the ConcurrentEventTriggeredFlows property.

If a connector is being used only as a destination, you can improve performance by setting the value of ConcurrentEventTriggeredFlows to zero. But do not set this value to zero if the connector is being used in bidirectional exchanges with a collaboration.

Copyright IBM Corp. 2004