Integration Server 10.15 | Publish-Subscribe Developer’s Guide | Overview of Publishing and Subscribing | Overview of Subscribing from webMethods Messaging Provider | The Subscribe Path for Published Documents
 
The Subscribe Path for Published Documents
When a document is published or broadcast, the webMethods messaging provider enqueues a copy of the document for each subscriber.
The following diagram illustrates the path of a document to a subscriber (webMethods messaging trigger) on Integration Server.
Subscribe path for published documents
Step
Description
1
Integration Server retrieves documents for a webMethods messaging trigger from the webMethods messaging provider. Integration Server places the documents in the trigger’s queue.
2
Integration Server pulls a 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 that has already been processed by the trigger. Integration Server continues processing the document only if the document is new.
3
If the document matches a trigger condition, Integration Server executes the trigger service associated with that condition.
If the document does not match a trigger condition, Integration Server discards the document and returns an acknowledgement to the webMethods messaging provider. Integration Server also generates a journal log message stating that the document did not match a condition.
4
After the trigger service executes to completion (success or error), one of the following occurs:
*If the trigger service executed successfully, Integration Server returns an acknowledgement to the webMethods messaging provider.
*If a service exception occurs, the trigger service ends in error and Integration Server rejects the document. If the document is guaranteed, Integration Server returns an acknowledgement to the webMethods messaging provider. Integration Server sends an error document to indicate that an error has occurred.
*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.
Notes:
*After receiving an acknowledgement, the webMethods messaging provider removes its copy of the document from guaranteed storage. Integration Server returns an acknowledgement for guaranteed documents only.
*If Integration Server shuts down or reconnects to the webMethods messaging provider before acknowledging a guaranteed document, Integration Server recovers the document from the webMethods messaging provider when the Integration Server restarts or the connection is re‑established. That is, the documents are redelivered. For more information about guaranteed documents, see webMethods Service Development Help.
*If a trigger 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 satisfy more than one condition in a trigger. However, Integration Server executes only the service associated with the first satisfied 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.
*If a transient error occurs during document retrieval or storage, the audit subsystem logs the document and assigns it a status of FAILED. A transient error is an error that arises from a condition that might be resolved later, such as the unavailability of a resource due to network issues or failure to connect to a database. You can use webMethods Monitor to find and resubmit documents with a FAILED status if the document was published locally or received from Broker. For more information about using webMethods Monitor, see the webMethods Monitor documentation.
*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.