...
Message Responders can receive and respond with any content over one of the supported virtual asset protocol/API deployment options, namely HTTP, JMS and WebSphere IBM MQ, or through a protocol/API that is handled by a custom extension (see Using Custom Transports, Message Formats, and Tools_Virt). By customizing Message Responder options, you can customize the behavior of the virtual assets, with different request/response use cases specified manually or via data sources, error conditions, delays, and so forth.
...
This project contains a VirtualAssets.xml file that stores the deployment configuration for each virtual asset, including the location of each virtual asset's .pva file, name and HTTP endpoint path, global reporting settings, and JMS and WebSphere MQ IBM MQ transport settings. This file is automatically updated when virtual asset deployment settings are modified.
...
In the case of HTTP, these header values will be appended to the standard HTTP headers that are generated in the responses. In the case of JMS, they are set as String message properties into the outgoing response messages. Or, if the provided header name matches one of the existing message property names, then it will be overwritten (example: JMSCorrelationID). In the case of WebSphere MQIBM MQ, there is a section for RFH2 headers that allows for configuring these as well.
...
- Solicit Response: Indicates that a response message body is returned. The default option.
- Notification Only: Indicates that the request message is merely acknowledged. In the case of HTTP, the response is just an HTTP header with no body content. In the case of JMS or WebSphere MQIBM MQ, the incoming request message is picked up from the request queue, but no response message is generated into a response.
...
| To achieve this... | Do this.... |
|---|---|
Execute a Data Bank before responder correlation in order to use a data banked request value as part of custom correlation. | Chain a Data Bank to the Pre-correlation Incoming Request of a Message Responder. Use the data banked values in custom correlation to determine if certain criteria is met. You may also reference the data banked values in other forms of correlation or in the response message payload. |
A responder triggers a database update action. For example: update/remote/add a row to a relational database or run a SELECT query. | Chain a Data Bank to the Incoming Request of a Message Responder. You may also chain an XML Data Bank to the XML output of the DB tool and reference these data bank values to in the Responder output in order to have them populate the response with values obtained from a relational database. |
Database data constructs a response message manually. For example: iterate over returned records to generate a desired XML response format. | Chain the DB tool to the outgoing response of a Message Responder and attach an XML Transformer, an XSLT Tool or an Extension tool to it. The output of these tools will replace the content configured in the Message Responder editor's Response tab. This provides flexibility to construct the message manually. If you want to use only certain select values from the database, chain the DB Tool to the Incoming Request as described above. |
| A responder invokes another service. | Chain a SOAP Client or Messaging Client to the Incoming Request of the Message Responder. Chaining a SOAP or Messaging Client to the Outgoing Response of a Message Responder is not supported. |
| A responder invokes another service and uses some of its output to populate response parameters. | Chain a SOAP/Messaging Client to the Incoming Request of the Message Responder and attach a Data Bank to the response of the client. These data bank values can be referenced within the Message Responder Form Input or Form XML views to construct a dynamic response message. If you need to invoke that service with parameters extracted from the request received by the responder, then chain an XML Data Bank to the Incoming Request of the Responder, then chain a SOAP/Messaging Client to the Incoming Request of the responder and parameterize its request with the data bank values you've extracted from the request. Note that order matters here: the data bank needs to be placed before the client in order for the client to be able to use its values. |
...