Software AG Products 10.7 | Integrating On-Premises and Cloud Applications | Integration Server Built-In Services | Publish Folder | Summary of Elements in this Folder | pub.publish:reply
 
pub.publish:reply
WmPublic. Delivers a reply document to the requesting client.
Input Parameters
receivedDocumentEnvelope
Document Optional. The envelope of the document to which you are replying. By default receivedDocumentEnvelope specifies the envelope of the document that triggered this service. In case of a join, receivedDocumentEnvelope will specify the last document that satisfied the join condition. However, you may specify the envelope of any published document to which you want to reply.
documentTypeName
String Fully qualified name of the publishable document type for the document that you are sending as a reply. Keep in mind that the publisher of the requesting document might be expecting a reply document that conforms to specific publishable document type.
document
Document The reply IData object. This document must conform to the publishable document type specified in documentTypeName.
delayUntilServiceSuccess
String Optional. Flag indicating whether Integration Server should publish the document when the pub.publish:reply service executes or after the top-level service successfully completes. If the top-level service fails, Integration Server will not publish the document.
Set to:
*true to delay publishing until after the top-level service executes successfully.
*false to publish the document when the publish service executes. This is the default.
Output Parameters
None.
Usage Notes
You can use the pub.publish:reply service to publish a document to Universal Messaging, Broker, or locally within Integration Server.
All reply documents are volatile documents. If the requesting Integration Server shuts down before processing the reply document, the reply document is lost.
Integration Server always encodes reply messages as IData.
If the replyTo envelope parameter is set in the request document, the reply document is delivered to that destination; otherwise, the reply document is sent to the publisher specified in the pubId parameter in the envelope of the request document.
This service correctly maps the required fields from the request document to the reply document.
A reply document can be a simple acknowledgment, or it can contain information asked for by the publisher of the request document.
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.
If you are building a service to reply to documents that meet join conditions, keep the following in mind:
*All (AND) join conditions. If the replying service executes because two or more documents satisfied an All (AND) join condition, Integration Server uses the envelope of the last document that satisfied the join condition to determine where to send the reply document. If you want Integration Server to use the envelope of a different document, link the envelope of that document to receivedDocumentEnvelope. If you want to reply to all documents received as part of an All (AND) join, invoke pub.publish:reply once for each document received and map the envelope from the received document to receivedDocumentEnvelope for each call.
*Any (OR) or Only one (XOR) join conditions. If the replying service executes because a document satisfied an Any (OR) or Only one (XOR) join condition, do not map or assign a value to receivedDocumentEnvelope. It is impossible to know which document in the Any (OR) or Only one (XOR) join will be received first. For example, suppose that an Only one (XOR) join condition specified document types A and B. Integration Server uses the envelope of the document it received first as the receivedDocumentEnvelope value. If you map the envelope of document A to receivedDocumentEnvelope, but Integration Server receives document B first, your replying service will fail.
Services that publish or deliver a document and wait for a reply can specify a publishable document type to which reply documents must conform. If the reply document is not of the type specified in the receiveDocumentTypeName parameter of the pub.publish:publishAndWait or pub.publish:deliverAndWait service, the publishing service will wait forever for a reply. Work closely with the developer of the publishing service to make sure that your reply document is an instance of the correct publishable document type.
For more information about building a reply service, see the Publish-Subscribe Developer’s Guide.
See Also
pub.publish:deliverAndWait
pub.publish:publishAndWait
pub.publish:envelope