In concurrent processing, Integration Server processes the documents received by a webMethods messaging trigger in parallel. Integration Server processes as many documents in the webMethods messaging trigger queue as it can at the same time. Integration Server does not wait for the service specified in the webMethods messaging trigger condition to finish executing before it begins processing the next document in the trigger queue. You can specify the maximum number of documents Integration Server can process concurrently.

Concurrent processing provides faster performance than serial processing. The Integration Server process the documents in the trigger queue more quickly because the Integration Server can process more than one document at a time. However, the more documents Integration Server processes concurrently, the more server threads Integration Server dispatches, and the more memory the document processing consumes.

Additionally, for concurrent webMethods messaging triggers, Integration Server does not guarantee that documents are processed in the order in which they are received.

Concurrent document processing is equivalent to the Shared Document Order mode of “None” on the webMethods Broker.

When receiving messages from Universal Messaging, the Universal Messaging window size limits the number of documents that can be processed at one time by an individual trigger. By default, the window size of a client queue for a concurrent trigger is set to the sum of the Capacity and Max execution threads properties plus 5. For example, if the Capacity property is set to 10 and Max execution threads is set to 5, the client queue window size is 20. The window size set for a trigger overrides the default value specified in Universal Messaging.