...
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.
...
- Enable Enable correlation.
- Specify the HTTP methods you want to use for correlation.
For example, if GET, POST, and PUT are checked, the responder will match HTTP requests with the method GET, POST, or PUT. HTTP requests with CONNECT, DELETE, HEAD, and so on will not match.
...
For more details on processing, see Criteria Expressions for Matching Values with the Message Responder.
...
Options Tab
...
The Attachment The Options tab allows you to send either Binary or XML HTTP attachments to the response message.
When you are using MTOM, you do NOT need to add anything to the Attachment tab. The MTOM option will cause it to automatically create the MIME_boundaries with the optimized (non-encoded) SOAP Envelope xsd:base64Binary content. The Attachment tab applies only to MIME/DIME options.
To send an attachment, perform the following from the Attachment tab:
- Click Add. An XML Attachment entry displays in the Attachment table.
- Double-click the XML Attachment entry. An Edit Attachments dialog opens.
- In the Edit Attachments dialog, choose either XML or Binary from the Mode menu.
- Configure the attachment.
- The following option is available for XML Mode:
- Views: Select the desired view from the menu and configure accordingly.
- The following options are available for Binary Mode:
- Base 64 Encoding: Enables Base 64 Encoding to encode the binary value.
- Data Source Column: Select to send values from a data source column.
- File: Select to send values from a file. Choose the desired file by clicking Browse. Enable Persist as Relative Path if you want the path to this file to be saved as a path that is relative to the current configuration file.
- Text: Select to send a text value.
- Content type: Specify the content type. Click Edit Headers if you want to add, modify, or delete attachment headers.
- The following option is available for XML Mode:
Options Tab
The Options tab allows you to configure how the message is processed. The following options are available:
...
configure how the message is processed. The following options are available:
Request Template
Anchor | ||||
---|---|---|---|---|
|
Request Date
The request date template is used to calculate offsets for dates when generating inline expressions when
...
Request Date
The request date template is used to calculate offsets for dates when generating inline expressions when no match occurs, such as when no dates are present in the request message template or the request URL template. To use the current date/time, choose [Current Date/Time] from the menu. To specify a date-time, enter it in the field. If left blank, no offset will be calculated.
...
- 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.
...
Specifies whether to use the Default or Custom encapsulation format. The Default option specifies whatever is chosen as the Attachment Encapsulation Format in the Preferences panel. The Custom option allows you to choose MIME, DIMENone, MTOM Alwaysalways, or MTOM Optionaloptional. For details, see Working with Attachments.
...
- Enter a WSDL in the WSDL URL field of the Message Responder tool.
- Right-click the Message Responder node and choose Add Output. The Add Output wizard opens.
- From the Add Output wizard, choose Incoming Request from the left pane and XML Data Bank from the right pane and click Finish.
- Double-click the Incoming Request > XML Data Bank node beneath the Message Responder node. The XML Data Bank configuration panel displays in the right GUI panel.
- In the right GUI panel, add the XPath of the value you want to access in your script.
- Double-click the Message Responder node. The Message Responder configuration panel displays in the right GUI panel.
- In the Response tab, choose the Scripted view.
Specify your logic. The following is the basic template for accessing data source and data bank values:
Code Block def customLogic(context): # Retrieve the data source value. "Data Source Name" should be replaced # with the name of your data source and "Column Name" should be the column # that your value is coming from. You can access many columns from the same # data source within this script. For Data Bank values, the table is always # named "Generated Data Source" so you only need to replace "Data Bank Column Name" dataSourceValue = context.getValue("Data Source Name", "Column Name") dataBankValue = context.getValue("Generated Data Source", "Data Bank Column Name") # add custom logic that uses value from data source # The following method tells what data source you will be using in this script. # "Data Source Name" should be replaced with the name of your data source def addDataSources(context): return "Data Source Name"
- Select the correct method from the Method menu. The method you select should be your entry point. In the above example, the method would be customLogic().
...
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. |
...
When sending responses with character data such as XML, CSV, fixed-length, or plain text, the "format", the MQ header type must be set to the value of the MQFMT_STRING constant, which is "MQSTR". This format header should be configured in the Message Responder’s Transport Header tab (in the MQ Headers table, add an entry with format
set to MQSTR
).
The response message will be encoded based on the MQ "characterSet" header field. By default, Virtualize automatically sets the characterSet field on the outgoing (response) MQ message to the same value as the incoming (request) MQ message. However, this character set can also be explicitly configured by adding a "characterSet" header in the Message Responder’s Transport Header tab.
...
- 850 - ASCII
- 819 - ISO standard ASCII
- 37 - American EBCDIC
- 1200 - Unicode
- 1208 - UTF-8