Replying to a Published or Delivered Document
You can create a service that sends a reply document in response to a published or delivered request document. The reply document might be a simple acknowledgement or might contain information requested by the publisher.
You can build services that send reply documents in response to one or more received documents. For example, if receiving documentA and documentB satisfies an All (AND) join condition, you might create a service that sends a reply document to the publisher of documentA and the same reply document to the publisher of documentB.
To send a reply document in response to a document that you receive, you create a service that invokes the pub.publish:reply service.
Keep the following details in mind when creating a service that sends a reply document in response to a received request.
All reply documents are treated as volatile documents even if the publishable document type used for the reply document has a storage type of guaranteed. Volatile documents are stored in memory. If the resource on which the reply document is stored shuts down before processing the reply document, the reply document is lost. The resource will not recover it upon restart.
Integration Server always encodes reply messages as IData.
Integration Server sends the reply document using the same connection that the trigger used to retrieve the request document.
Integration Server ignores the messaging connection alias assigned to the publishable document type in
documentTypeName.
Because
Integration Server sends the reply document using the same connection that the trigger used to retrieve the request document, when
Universal Messaging is the messaging provider, the publishable document types to which the trigger subscribes must be associated with a
Universal Messaging connection alias for which the
Enable Request/Reply Channel and Listener check box is selected.