Changing Message Processing When Universal Messaging Is the Messaging Provider
You can change the message processing after you create a webMethods messaging trigger. For example, capacity planning might indicate that a concurrent trigger should be changed to serial. Keep the following points in mind when changing the processing mode from serial to concurrent or vice versa for a webMethods messaging trigger that receives documents from Universal Messaging:
When you change the processing mode for a
webMethods messaging trigger that uses a
Universal Messaging connection alias that does not share a client prefix,
Integration Server deletes and recreates the durable subscription that corresponds to the trigger on
Universal Messaging. The trigger and its associated durable subscription on
Universal Messaging remain in sync.
Note:
A Universal Messaging connection alias does not share a client prefix if the Client Prefix Is Shared property for the connection alias is set to No.
When you change the processing mode for a
webMethods messaging trigger that uses a
Universal Messaging connection alias that shares a client prefix,
Integration Server does not delete and recreate the durable subscription that corresponds to the trigger on
Universal Messaging. As a result, the trigger on
Integration Server will be out of sync with the associated durable subscription on
Universal Messaging. If the same trigger exists on other
Integration Server, such as in a cluster or a non-clustered group of
Integration Server, the changed trigger will also be out of sync with the trigger on other
Integration Server. This affects document processing. One of the following situations occurs:
If you changed the processing mode from serial to concurrent, the corresponding durable subscription on
Universal Messaging remains a serial durable subscription. The trigger continues to process documents concurrently. However, if the trigger exists on more than one
Integration Server, such as in a cluster or a non-clustered group of
Integration Servers,
Universal Messaging distributes documents to only one trigger on the clustered or non-clustered group of
Integration Servers at a time.
Universal Messaging does not distribute documents in a way that allows for concurrent processing across the
Integration Servers.
If you changed the processing mode from concurrent to serial, the corresponding durable subscription on
Universal Messaging remains a shared durable subscription.
Integration Server does not change the durable subscription to be a serial durable subscription. Consequently, if the trigger exists on more than one
Integration Server, such as in a cluster or a non-clustered group of
Integration Servers,
Universal Messaging distributes documents to the trigger on each connected
Integration Server.
Universal Messaging does not distribute documents in a way that ensures that processing order matches publication order.
Note:
A Universal Messaging connection alias shares a client prefix if the Client Prefix Is Shared property for the connection alias is set to Yes.
Software AG does not recommend changing the processing mode for a trigger when more than one
Integration Server connects to the same durable subscription that corresponds to the trigger. For example, if the trigger is on an
Integration Server that is part of a cluster or a non-clustered group, more than one
Integration Server can share the same durable subscription.