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 Delivered Documents When Using webMethods Broker
 
The Subscribe Path for Delivered Documents When Using webMethods Broker
A publishing service can deliver a document by specifying the destination of the document. That is, the publishing service specifies the Broker client that is to receive the document. When the Broker receives a delivered document, it places a copy of the document in the queue for the specified client only.
Typically, documents are delivered to the default client. The default client is the Broker client created for Integration Server when Integration Server first configures its connection to the Broker.
Note:
If a publishing service specifies an individual trigger as the destination of the document (the publishing service specifies a trigger client ID as the destination ID), the subscribe path the document follows is the same as the path followed by a published document.
The following diagram illustrates the subscription path for a document delivered to the default client when Broker is the messaging provider.
Subscribe path for documents delivered to the default client when using Broker
Step
Description
1
The dispatcher on Integration Server requests documents from the default client’s queue on the Broker.
Note:
The default client is the Broker client created for Integration Server. Broker places documents in the default client’s Broker queue only if the publisher delivered the document to Integration Server’s client ID.
2
The thread retrieves documents delivered to the default client in batches.
The number of documents the thread retrieves at one time is determined by the capacity and refill level of the default document store and the number of documents available for the default client on the Broker. For more information about configuring the default document store, see the section Configuring the Default Document Store in the webMethods Integration Server Administrator’s Guide. Configuring the Default Document Store.
3
The dispatcher places a copy of the documents in memory in the default document store.
4
The dispatcher identifies subscribers to the document and routes a copy of the document to each subscriber’s trigger queue.
In the case of delivered documents, Integration Server saves the documents to a trigger queue. The trigger queue is located within a trigger document store that is saved on disk.
5
Integration Server removes the copy of the document from the default document store and, if the document is guaranteed, returns an acknowledgement to the Broker. The Broker removes the document from the default client’s queue.
6
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, the 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.
7
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, 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. Integration Server also generates a journal log message stating that the document did not match a condition.
8
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 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, returns the server thread to the thread pool, and sends an error document to indicate that an error has occurred. If the document is guaranteed, Integration Server returns an acknowledgement to the trigger queue. The trigger queue removes its copy of the guaranteed document from storage.
*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:
*Integration Server saves delivered documents in a trigger document store located on disk. Integration Server saves published documents in a trigger document store located in memory.
*If Integration Server shuts down before processing a guaranteed document saved in a trigger document store on disk, Integration Server recovers the document from the trigger document store when it restarts. Volatile documents are saved in memory and are not recovered up restart.
*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.
*If a transient error occurs during document retrieval or storage, the audit subsystem logs the document and assigns it a status of FAILED. 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.