webMethods Messaging Trigger Properties

General Properties for webMethods Messaging Triggers

In the Properties view, under General, you can enable/disable the webMethods Messaging Trigger, configure join expiration, enable priority message handling, and assign permissions to the trigger.

Property	Description
Enabled	Specifies whether the webMethods Messaging Trigger is enabled or disabled.
	Select...	To...
	True	Enable the webMethods Messaging Trigger. An enabled webMethods Messaging Trigger contains one or more valid conditions.
	False	Disable the webMethods Messaging Trigger. A disabled webMethods Messaging Trigger can contain valid or invalid conditions. A disabled webMethods Messaging Trigger does not have any subscriptions registered on the Integration Server or the messaging provider.
Join expires	Indicates whether the join expires after the time period specified in Expire after.
	Select...	To...
	True	Indicate Integration Server should stop waiting for the remaining documents in a join condition after the time specified in Expire after elapses.
	False	Indicate that the join should not expire. That is, Integration Server should wait indefinitely for the remaining documents in a join condition.
	Note: webMethods Messaging Triggers that receive documents from Universal Messaging do not use joins. Designer ignores the value of the Join expires property if the trigger subscribes to publishable document types that can be published to Universal Messaging.
Expire after	Specifies how long Integration Server waits for the remaining documents in the join condition. The default join time-out period is 1 day. Note: webMethods Messaging Triggers that receive documents from Universal Messaging do not use joins. Designer ignores the value of the Expire after property if the trigger subscribes to publishable document types that can be published to Universal Messaging.
Priority enabled	Specifies whether priority messaging is enabled or disabled for the webMethods Messaging Trigger. This property applies to webMethods Messaging Triggers that receive documents from Broker only. webMethods Messaging Triggers that receive documents from Universal Messaging always receive higher priority documents in an expedited fashion. Additionally, priority messaging does not apply to locally published documents received by the webMethods Messaging Trigger. At run time, Integration Server ignores the value of the Priority enabled property if the trigger receives a locally published document.
	Select...	To...
	True	Enable priority messaging for the webMethods Messaging Trigger. Note: If priority messaging is enabled on an existing trigger, the Broker connection is dropped and the client is deleted. The client gets recreated when the Broker connection is re-established. This may result in loss of documents for that trigger.
	False	Disable priority messaging for the trigger.
Execution user	Specifies the name of the user account whose credentials Integration Server uses to execute a service associated with the webMethods Messaging Trigger. You can specify a locally defined user account or a user account defined in a central or external directory. Note: The Execution user property only applies to webMethods Messaging Triggers that receive documents from Universal Messaging. The publishable document type to which a trigger subscribes determine the messaging provider from which the trigger receives messages. At run time, Integration Server ignores the value of the Execution user property if a webMethods Messaging Trigger receives locally published documents or documents from Broker
Permissions	Click to assign or view ACL permissions to a webMethods Messaging Trigger.
Reuse	Specifies whether this element can be dragged from the CentraSite Registry Explorer view to a BPM process or CAF project. When this property is set to public, you can drag the asset to a BPM process or CAF project. When this property is set to private (the default), you cannot drag the asset to a BPM process or CAF project. All published assets are available for Impact Analysis, whether they are public or private. Although changing the public/private status will immediately change whether or not you can drag an element to a BPM process or CAF project, the element's status in CentraSite will not change until the next publication of assets to CentraSite.

Trigger Queue Properties

In the Properties view, under Trigger queue, you can specify the capacity and refill levels of the trigger queue on Integration Server. You can also specify how many messages Integration Server should acknowledge at one time.

Property	Description
Capacity	Specifies the maximum number of unprocessed documents that can exist for this trigger in the trigger document store. (Each trigger has its own queue in the trigger document store on Integration Server.) The default is 10 documents.
Refill level	Specifies the number of unprocessed documents that must remain in this trigger queue before the Integration Server retrieves more documents for the trigger. The default is 4 documents. Note: The Refill level does not apply to webMethods Messaging Triggers that receive documents from Universal Messaging. At run time, Integration Server ignores the value of the Refill level property if a webMethods Messaging Trigger receives documents from Universal Messaging.
Acknowledgement queue size	Specifies the maximum number of pending document acknowledgements for this trigger. A server thread places acknowledgements in the acknowledgement queue after it finishes executing the trigger service. Acknowledgements collect in the queue until the server returns them as a group to the sending resource. If the acknowledgement queue fills to capacity, the server blocks any server threads that attempt to add an acknowledgement to the queue. The blocked threads resume execution only after Integration Server empties the queue by returning the acknowledgements. The default is 1 acknowledgement.

Message Processing Properties

In the Properties view, under Message processing, you can specify whether the trigger processes messages serially or concurrently.

Property	Description
Processing mode	Specifies how Integration Server processes the documents in the trigger queue.
	Select...	To...
	Serial	Specify that Integration Server should process documents in the trigger queue one after the other, in the same order that they were received.
	Concurrent	Specifies that Integration Server should process as many documents in the trigger queue as it can at one time. The maximum number of documents the server can process at one time is determined by the Max execution threads property.
Max execution threads	Specifies the maximum number of server threads that can process documents for this trigger concurrently. Integration Server uses one server thread to process each document in the trigger queue. The default is 1 server thread.

Fatal Error Handling Properties

In the Properties view, under Fatal error handling, you can specify how Integration Server responds when a trigger service ends because of a fatal error.

Property	Description
Suspend on error	Specifies that Integration Server suspends document retrieval and document processing when an exception occurs during trigger service execution. This property is only available for serial triggers.
	Select...	To...
	True	Suspend document processing and document retrieval for the trigger when a trigger service ends with an error.
	False	Indicate that document processing and document retrieval should not be suspended if a trigger service ends with an error.

Transient Error Handling Properties

In the Properties view, under Transient error handling, you can specify how Integration Server responds when a trigger service ends because of a transient error.

Property	Description
Retry until	Specifies the maximum number of times that Integration Server will attempt to execute the trigger service if an ISRuntimeException occurs during the trigger service execution. An ISRuntimeException occurs when the trigger service catches a transient error, wraps the error, and re-throws it as an exception. (A transient error is an error that arises from a condition that might be resolved quickly, such as the unavailability of a resource due to network issues or failure to connect to a database.)
	Select...	To...
	Max attempts reached	Indicate that Integration Server re-executes the trigger service up to the number of times specified in the Max attempts property. The server stops re-executing the trigger service when the service succeeds or when the server reaches the maximum number of retries.
	Successful	Indicate that Integration Server re-executes the trigger service until the service executes to completion.
Max retry attempts	Specifies the maximum number of times the Integration Server should re-execute the trigger service if an ISRuntimeException occurs during service execution. The default is 0 attempts, which indicates that Integration Server does not retry the trigger service.
Retry interval	Specifies the length of time Integration Server waits between attempts to execute the trigger service. The default is 10 seconds.
On retry failure	Indicates how Integration Server handles a retry failure for a trigger. A retry failure occurs when Integration Server reaches the maximum number of retry attempts and the trigger service still fails because of an ISRuntimeException. This property also determines how Integration Server handles a transient error that occurs during trigger preprocessing.
	Select...	To...
	Throw exception	Indicate that Integration Server throws a service exception when the last allowed retry attempt ends because of an ISRuntimeException. This is the default.
	Suspend and retry later	Indicate that Integration Server suspends the trigger when the last allowed retry attempt ends because of a run-time exception. Integration Server retries the trigger service at a later time when the resources needed by the trigger service become available. When On Retry failure is set to Suspend and retry later, a transient error that occurs during trigger preprocessing causes Integration Server to suspend the trigger and resume it when the resources, specifically the document history database, are available.
Resource monitoring service	Specifies the service that Integration Server executes to determine whether the resources needed by the trigger are available and if the trigger can be resumed. Integration Server schedules a system task to execute the resource monitoring service when one of the following occurs: The trigger service ends because of a retry failure and the On retry failure property is set to Suspend and retry later. The document resolver service used for exactly-once processing ends because of a run-time exception and the watt.server.trigger.preprocess.suspendAndRetryOnError is set to true. Note: A resource monitoring service must use the pub.trigger:resourceMonitoringSpec as the service signature.

Exactly Once Properties

In the Properties view, under Exactly once, configure exactly-once processing for a trigger. Exactly-once processing ensures that a trigger processes a guaranteed document once and only once. Integration Server provides exactly-once processing by determining whether a document is a copy of one previously processed by the trigger. Designer provides three duplicate detection methods: redelivery count, document history, and a document resolver service.

Property	Description
Detect duplicates	Enables exactly-once processing for the trigger and instructs the server to check a document’s redelivery count to determine whether the trigger has received the document before.
	Select...	To...
	True	Specify that exactly-once processing is provided for documents received by this trigger and instructs the server to check a document’s redelivery count to determine whether the trigger received the document previously. The redelivery count indicates the number of times the routing resource has redelivered a document to the trigger.
	False	Specify that exactly-once processing is not provided for documents received by this trigger.
Use history	Indicates whether a document history database will be maintained and used to determine whether a document is a duplicate.
	Select...	To...
	True	Indicate that Integration Server maintains a history of documents processed by the trigger. When the trigger receives a document, Integration Server compares the document’s universally unique identifier (UUID) to the UUIDs of documents processed by the trigger. If there is a match, the Integration Server either determines the second document is a duplicate and discards it or, if the first document has not finished processing, marks the second document’s status as In Doubt.
	False	Indicate that Integration Server does not maintain a document history database. The Integration Server will not use document history to determine whether a document is a duplicate of one already processed by the trigger.
	Note: To perform duplicate detection using a document history database, the audit subsystem must be stored in a relational database and Integration Server Administrator must define a JDBC connection pool for the Integration Server to use to connect to the document history database.
History time to live	Specifies the length of time the document history database maintains an entry for a document processed by the trigger. During this time period, Integration Server discards any documents with the same universally unique identifier (UUID) as an existing document history entry for the trigger. When a document history entry expires, Integration Server removes it from the document history database. If the trigger subsequently receives a document with same UUID as the expired and removed entry, the server considers the copy to be new because the entry for the previous document has been removed from the database.
Document resolver service	Specifies the service that you created to determine whether message’s status is New, Duplicate, or In Doubt. Click to select a service from a list. The document resolver service must use the pub.publish:documentResolverSpec to define the service signature.