Step | Description |
1 | A publishing service sends a document (the request) to the dispatcher. Integration Server populates the tag field in the document envelope with a unique identifier that will be used to match up the reply document with this request. The publishing service enters into a waiting state. The service will not resume execution until it receives a reply from a subscriber or the wait time elapses. Integration Server begins tracking the wait time as soon as it publishes the document. 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. The service unblocks, but with an exception. |
2 | The dispatcher sends the document to the webMethods messaging provider. Note: If the webMethods messaging provider is not available, the document is guaranteed, and use of the client side queue is configured, the dispatcher routes the document to the outbound document store. For more information, see Publishing Documents When the webMethods Messaging Provider Is Not Available. |
3 | The webMethods messaging provider examines the storage type for the document to determine how to store the document. If the document is volatile, the webMethods messaging provider stores the document in memory. If the document is guaranteed, the webMethods messaging provider stores the document in memory and on disk. |
4 | The webMethods messaging provider routes the document to subscribers by doing one of the following: If the document was published (broadcast), the webMethods messaging provider identifies subscribers and enqueues a copy of the document for each subscriber. If the document was delivered, the webMethods messaging provider enqueues the document for the destination specified in the delivery request. The Broker places documents in a queue for a subscriber. Universal Messaging places documents on a channel. A document remains enqueued on the webMethods messaging provider until it is picked up by the subscriber. If the time-to-live for the document elapses, the webMethods messaging provider discards the document. For more information about setting time-to-live for a publishable document type, see IBM webMethods Service Development Help. If there are no subscribers for the document and the messaging provider has been configured to handle dead letters (sometimes called dead events), the webMethods messaging provider routes the document to the dead letter queue or dead event store. For more information about configuring the messaging provider to handle documents for which there are no subscribers, refer to the documentation for the webMethods messaging provider that is in use. Note: If the Broker is the webMethods messaging provider and a deadletter subscription exists for the document, the Broker deposits the document in the queue containing the deadletter subscription. For more information about creating deadletter subscriptions, see IBM webMethods Service Development Help. |
5 | Subscribers retrieve and process the document. A subscriber uses the pub.publish:reply service to compose and publish a reply document. This service automatically populates the tag field of the reply document envelope with the same value used in the tag field of the request document envelope. The pub.publish:reply service also automatically specifies the requesting client as the recipient of the reply document. |
6 | One or more subscribers send reply documents to the webMethods messaging provider. The webMethods messaging provider stores the reply documents in memory. The webMethods messaging provider enqueues the reply documents in the request/reply queue or channel for the Integration Server that initiated the request. |
7 | The Integration Server that initiated the request retrieves the reply documents from the webMethods messaging provider. Integration Server uses the tag value of the reply document to match up the reply with the original request. |
8 | Integration Server places the reply document in the pipeline of the waiting service. The waiting service resumes execution. |