When the Broker connection alias is assigned to the publishable document type and the service that publishes the document specifies that the document should be published locally.When the Broker connection alias is assigned to the publishable document type and the service that publishes the document specifies that the document should be published locally.When the messaging connection alias assigned to the publishable document type is set to IS_LOCAL_CONNECTION.The default messaging connection alias is IS_LOCAL_CONNECTION.
Step | Description |
1 | A publishing service publishes a document, sending the document to the dispatcher. If validation is configured for the publishable document type, Integration Server validates the document against its publishable document type before sending the document to the dispatcher. If the document is not valid, the service returns an exception specifying the validation error. |
2 | The dispatcher does one of the following: The dispatcher determines which triggers subscribe to the document and places a copy of the document in each subscriber’s trigger queue. The dispatcher saves locally published documents in a trigger document store located on disk.If there are no subscribers for the document, the dispatcher discards the document. |
3 | The dispatcher obtains a thread from the server thread pool, pulls the document from the trigger queue, and evaluates the document against the conditions in the trigger. Note: If exactly-once processing is configured for the trigger, Integration Server first determines whether the document is a duplicate of one already processed by the trigger. Integration Server continues processing the document only if the document is new. |
4 | If the document matches a trigger condition, the dispatcher executes the trigger service associated with that condition. If the document does not match a trigger condition, Integration Server sends an acknowledgement to the trigger queue, discards the document (removes it from the trigger queue), and returns the server thread to the server thread pool. |
5 | After the trigger service executes to completion (success or error), one of the following occurs: If the trigger service executed successfully, Integration Server sends an acknowledgement to the trigger queue (if this is a guaranteed document), removes the document from the trigger queue, and returns the server thread to the thread pool.If a service exception occurs, the trigger service ends in error and Integration Server rejects the document, removes the document from the trigger queue, and returns the server thread to the thread pool. If the document is guaranteed, Integration Server sends an acknowledgement to the trigger queue.If a transient error occurs during trigger service execution and the service catches the error, wraps it and re-throws it as an ISRuntimeException, then Integration Server waits for the length of the retry interval and re‑executes the service using the original document as input. If Integration Server reaches the maximum number of retries and the trigger service still fails because of a transient error, Integration Server treats the last failure as a service error. For more information about retrying a trigger service, see webMethods Service Development Help. |
You can configure publishable document types and Integration Server so that Integration Server does not validate documents when they are published. For more information about validating publishable document types, see webMethods Service Development Help.Integration Server saves locally published documents in a trigger document store located on disk. If Integration Server shuts down before processing a locally published guaranteed document, Integration Server recovers the document from the trigger document store when it restarts. Integration Server does not recover volatile documents when it restarts.If a subscribing trigger queue reaches its maximum capacity, you can configure Integration Server to reject locally published documents for that trigger queue. For more information about this feature, see the description of the watt.server.publish.local.rejectOOS parameter in webMethods Integration Server Administrator’s Guide.If a service generates audit data on error and includes a copy of the input pipeline in the service log, you can use webMethods Monitor to re-invoke the trigger service at a later time. For more information about configuring services to generate audit data, see webMethods Service Development Help.It is possible that a document could match more than one condition in a trigger. However, Integration Server executes only the service associated with the first matched condition.The processing mode for a trigger determines whether Integration Server processes documents in a trigger queue serially or concurrently. In serial processing, Integration Server processes the documents one at a time in the order in which the documents were placed in the trigger queue. In concurrent processing, Integration Server processes as many documents as it can at one time, but not necessarily in the same order in which the documents were placed in the queue. For more information about document processing, see webMethods Service Development Help.You can configure a trigger to suspend and retry at a later time if retry failure occurs. Retry failure occurs when Integration Server makes the maximum number of retry attempts and the trigger service still fails because of an ISRuntimeException. For more information about handling retry failure, see webMethods Service Development Help.You can configure Integration Server to strictly enforce a locally published document’s time-to-live and discard the document before processing it if the document has expired. For more information about this feature, see the description of the watt.server.trigger.local.checkTTL parameter in webMethods Integration Server Administrator’s Guide.