Integration Server 10.3 | Publish-Subscribe Developer’s Guide | Publishing Documents | Delivering a Document and Waiting for a Reply
 
Delivering a Document and Waiting for a Reply
 
How to Deliver a Document and Wait for a Reply
You can initiate and continue a private conversation between two clients by creating a service that delivers a document and waits for a reply. This is a variation of the request/reply model. The publishing client executes a service that delivers a document requesting information to a specific client. The subscribing client processes the document and sends the publisher a reply document that contains the requested information.
A service can implement a synchronous or asynchronous request/reply.
*In a synchronous request/reply, the publishing service stops executing while it waits for a response to a published request. The publishing service resumes execution when a reply document is received or the specified waiting time elapses.
*In an asynchronous request/reply, the publishing service continues to execute after publishing the request document. The publishing service must invoke another service to wait for and retrieve the reply document.
If you plan to build a service that publishes multiple requests and retrieves multiple replies, consider making the requests asynchronous. You can construct the service to publish all the requests first and then collect the replies. This approach can be more efficient than publishing a request, waiting for a reply, and then publishing the next request.
You can use the pub.publish:deliverAndWait service to build a service that performs a synchronous or an asynchronous request/reply. This service delivers the request document to a specific client. If multiple clients can supply the requested information, consider using the pub.publish:publishAndWait service instead. For more information about using the pub.publish:publishAndWait service, see Publishing a Document and Waiting for a Reply.
The messaging connection alias assigned to the publishable document type determines which messaging provider receives and routes the document. Integration Server publishes the document using the messaging connection alias specified in the Connection alias name property of the publishable document type.
Note:
Instances of publishable document types that use the IS_LOCAL_CONNECTION messaging connection alias cannot be delivered.
If the publishable document type in documentTypeName is associated with a Universal Messaging connection alias, the Enable Request/Reply Channel and Listener check box must be selected for the alias. When this check box is selected, Integration Server ensures that a request/reply channel exists for the Universal Messaging connection alias on the Universal Messaging server and that Integration Server has a listener that subscribes to the alias-specific request/reply channel. If the check box is cleared, there will be no channel in which Universal Messaging can collect replies and no listener with which Integration Server can retrieve replies. The pub.publish:deliverAndWait service will end with a ServiceException if the Enable Request/Reply Channel and Listener check box is not selected for the Universal Messaging connection alias.
Note:
For considerations regarding debugging an asynchronous request/reply when Universal Messaging is the messaging provider, see Debugging a Flow Service that Performs an Asynchronous Request/Reply with Universal Messaging .