Page History

...

Message Responders can receive and respond with any content over one of the supported virtual asset protocol/API deployment options—namelyoptions, namely HTTP, JMS and WebSphere 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 assets, with different request/response use cases specified manually or via data sources, error conditions, delays, and so forth.

...

Message Responders are created and saved within .pva files.

The VirtualAssets project is the default and recommended location for .pva files. Any .pva files added to this project will be automatically deployed to the local Virtualize server. If a .pva is not in this project, it will not be deployed.

This project contains a VirtualAssets.xml file that stores the deployment configuration for each virtual asset—including asset, including the location of each virtual asset's .pva file, name and HTTP endpoint path, global reporting settings, and JMS and WebSphere MQ transport settings. This file is automatically updated when virtual asset deployment settings are modified.

...

If you ever want to change the message format that a Message Responder uses (e.g.for example, if you want to change from Fixed Length to Plain Text), just change the selected format.

...

The following general option is available at the top of the tool:

Data Source: Specifies the Data Source to be used for providing tool values. This menu is only available if a Data Source was added to the project (as described in Parameterizing Tools with Data Source Values, Variables, and Extracted Values).

XML Conversion Options

These options available only for formats that are converted to/from XML.

Format: Select the format for the response payload.
Respond with XML instead of [native format] when in Form Input or Form XML mode: If disabled (default), Virtualize will automatically convert the XML model into the native format before sending the message. In other words, Virtualize sends the native format to the server—so server, so that is what you will see in the Traffic Viewer.
- If this option is enabled, Virtualize will send the message you configured in the UI for the response. You You can create the message payload in the native format by using the Literal or Scripted views. If If you have this option disabled and you create XML in the UI (e.g.for example, using the Form Input view), then Virtualize will send that XML unmodified. You typically would not want to do this for the formats currently supported, but Virtualize makes this option available.

Schema for Modeling Request Payload Using Form Input

These options available only for formats that are converted to/from XML.

Message type:

Message type: Specifies the message type you want to use. This prompts Virtualize to populate the Form Input view.
Schema URL: Describes the Schema URL where this service can be accessed. You can either enter a value or click the Browse button. If you do not have a schema, you can leave this field empty.
Constrain to Schema: Determines whether certain tool parameters obtain their values from the Schema rather than from manual entry. If If this option is enabled, certain parameters are are disabled and get their values from the schema. If this option is disabled, the Refresh Schema button will also be disabled.

Definition Tab
Anchor
Definition Tab
Definition Tab

This tab is designed specifically for JSON, SOAP, and Plain XML Message Responders.

Specifying options in the Definition tab allows Virtualize to populate the Response tab with items that make it easier for you to specify the response message. You can specify the following settings related to the WSDL or schema that defines the expected request and outgoing response:

Service Definition: Specifies if the responder has an associated service definition (RAML, OpenAPI/Swagger, WSDL, or Schema). For plain XML, choose None. When a service definition is specified and the tool is constrained to WSDL or schema, the applicable form view will be automatically populated with appropriate field values and controls (e.g.such as, radio buttons for booleans, different controls for numbers vs. integers, drop-downs for enumerations). It will also prevent the entry of invalid messages (e.g.for example, messages missing required values, a value of the incorrect type, a method/resource/response code not specified in a schema, etc.and so on). Editing will be restricted to ensure that the message complies with the associated schema (e.g.for example, you will not be able to insert, delete, rename, copy, or paste tree nodes).
For RAML Service Definition Mode
- RAML URL: A specific RAML URL, or a variable referencing a RAML URL.
For OpenAPI/Swagger Service Definition Mode
- OpenAPI/Swagger URL: A specific OpenAPI/Swagger URL, or a variable referencing a OpenAPI/Swagger URL.
For WSDL Service Definition Mode
- WSDL URL: Describes the WSDL URL where this service can be accessed. You can either enter a value or click the Browse button. If you do not have a WSDL, you can leave this field empty.
- Constrain to WSDL: Determines whether certain tool parameters obtain their values from the WSDL rather than from manual entry. If If this option is enabled, certain parameters (e.g. like router endpoint, SOAP action, SOAP body and header parameters) are disabled and get their values from the WSDL. If this option is disabled, the Refresh WSDL button will also be disabled.
- WSDL Documentation: (Automatically completed if available): Describes the service at the given WSDL URI.
For Schema Service Definition Mode
- Schema URL: Describes the Schema URL where this service can be accessed. You can either enter a value or click the Browse button. If you do not have a schema, you can leave this field empty.
- Constrain to Schema: Determines whether certain tool parameters obtain their values from the Schema rather than from manual entry. If If this option is enabled, certain parameters are are disabled and get their values from the schema. If this option is disabled, the Refresh Schema button will also be disabled.
- XML Message Type: Determines whether the Response tab’s Form Input controls are geared for SOAP messages or plain XML messages. If Plain XML is selected, Form Input mode will directly represent the message. If SOAP is selected, the XML configured in Form Input will be wrapped with a SOAP Envelope and the view will provide a SOAP Header section that allows you to configure SOAP headers if desired.

Response Tab

The Response tab allows you to configure the response values that you want the responder to deliver when correlated requests are received.

...

Notes

The form-based views allow you to build the response and parameterize values from a data source.
If an operation selector is enabled in the Form Input or Form JSON view, you can use it to select the operation for your response. When you select an operation, the Form Input/JSON view will be populated with appropriate values and UI controls (e.g.such as, radio buttons for booleans, different controls for numbers vs. integers, etc.and so on).
- In Form Input mode, the operation selector will show all operations for which the associated service definition 1A) defines the response as XML, and 2B) specifies an XML schema.
- In Form JSON mode, the operation selector will show all operations for which the associated service definition 1A) defines the response as JSON, and 2B) specifies a JSON schema.
In Multiple Responses mode, each possible response has its own correlation to the incoming request, static response message, and performance (time) options.

Anchor
Transport Header Tab
Transport Header Tab
Transport Header Tab

The Transport Header tab allows you to specify the HTTP, JMS, or MQ message header that will be returned with the response message. You can use table view or literal view.

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 MQ, there is a section for RFH2 headers that allows for configuring these as well.

For JMS, you can define any miscellaneous property values to be set into the javax.jms.Message object before it gets sent to a queue or published to a topic. For instance, you could define JMSPriority, JMSDeliveryMode, JMSExpiration, and other properties as follows:

...

Responder Correlation Tab
Anchor
Responder Correlation Tab
Responder Correlation Tab

The Responder Correlation tab allows you to specify which messages this Message Responder tool accepts and processes. Various messages sent to the virtual asset URL are routed to specific Message Responder tools (each of which handle different operations) based on the settings here. For example, one Message Responder tool might respond to customer registration messages, another might respond to payment messages, and another might function as a default "catch all" that is used when none of the others match.

You can specify which messages a Message Responder accepts by entering values in the following Responder Correlation tab areas:

Transport: Allows you to specify HTTP Headers, JMS message properties, or MQ message fields within the message that will determine whether or not the message is processed by this particular responder. See Transport Correlation for details.
Request Body: Allows you to specify XPaths within the message that will determine whether or not the message is processed. See Request Body Correlation for details.
HTTP URL Parameters (for RESTful services): Allows you to specify URL parameters that will determine whether or not the message is processed. You can configure the correlation to match all messages that include specific parameters (no matter what value they are set to), or only match messages where specific parameters are set to specific specific values). URL parameters can be repeated (you can have the same parameter set to different values). See URL Parameter Correlation for details.
HTTP URL Path: Allows you to specify URL paths that will determine whether or not the message is processed. See URL Path Correlation for details.
HTTP Methods: Allows you to specify HTTP methods that will determine whether or not the message is processed. See HTTP Method Correlation for details.
Custom: Allows you to specify a custom responder correlation that is based on the return value of a custom method written using Java or scripting languages. See Custom Correlation for details.

...

To configure a transport correlation:

Select the Enable Enable correlation check box..
Click the Add button. A new entry row displaysappears.
Enter the Header Name.
Do one of the following:
- If you want to match messages where this header is set a specific value: Enter that value under Value of Header.
- If you want to match all messages that include this header (no matter what value it is set to): Check Enable Correlate whenever the named header is present regardless of value.

...

To configure a request body correlation:

Select the Enable Enable correlation check box.
Click the Edit button. An Edit XPath Function dialog displaysopens.
Select an element from the Element tree, select a function from the Function drop-down menu, and click OK.
Do one of the following:
- If a tree representation of the incoming request message is displayed, then select an element from the tree and select a function from the Function drop-down menu.
- If a tree representation of the requests is not available—or if the tree does not fully display the elements or attributes that are of interest for extraction and evaluation—then provide an XPath expression manually. The XPath expressions supported by Virtualize for correlation purposes is based on the standard XPath 1.0 standard by W3C.
By default, XPath fields and values are case sensitive, but you can change case sensitivity by specifying the applicable system properties when starting Virtualize. See Case Sensitivity for details.
If you want to specify any additional XPaths, add them in the same manner.

...

To configure a URL parameter correlation:

Select the Enable Enable correlation check box.
If you want the correlation to be applied only if the request has the exact URL parameters specified in this table—no more and no less—check the table, enable Correlate only when the list of parameters matches exactly. Otherwise, any request that contains listed parameters as well as other parameters will correlate. Whether this option is enabled or disabled, a message that lacks one of the specified parameters will not match.
Click the Add button. A new entry row displaysappears.
Enter the Parameter Name.
Do one of the following:
- If you want to match messages where this parameter is set a specific value: Enter that value under Value.
- If you want to match all messages that include this parameter (no matter what value it is set to): Check Enable Correlate whenever the parameter name is present present regardless of valueof value.

For example, assume that an asset is deployed under the path http://myvirtserver:9080/MyAsset/MyPath and the following URL Parameters are specified in a responder:

...

URL path correlations apply to virtual assets that will be accessed over HTTP/HTTPS. Note that the matching strategy has changed since Virtualize 9.7; existing virtual assets will automatically be reconfigured to use the current paradigm when they are modified.

To configure a URL path correlation:

Select the Enable Enable correlation check box.
Specify the path you want to use for correlation.

...

To configure an HTTP method correlation:

Select the Enable Enable correlation check box.
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 HTTP requests with CONNECT, DELETE, HEAD, etc. and so on will not match.

Anchor
Custom Correlation
Custom Correlation
Custom Correlation

...

The method must take 0 or 1 arguments.
The optional argument is of type com.parasoft.api.ScriptingContext.
The method can access the transport headers, URL parameters, and message contents of the incoming message using the ScriptingContext object.

More information can be found at Parasoft> Help> Extensibility API> For more information, go to Parasoft > Help or Help > Help Contents (depending on your installation) and choose Extensibility API > CorrelationScriptingHookConstants.

...

For text/plain, a string is returned.
For text/xml, a javax.xml.transform.stream.StreamSource.StreamSource is returned.
For all other types a java.io.InputStream is returned.

For example, if you wanted to correlate on an attachment (here, a string with the word "Attachment"), you might use:

...

Anchor
Data Source Correlation Tab
Data Source Correlation Tab
Data Source Correlation Tab

The Data Source Correlation tab allows you to specify which data source row values to use in virtual asset responses. When an incoming message matches the responder correlation settings, Virtualize performs a data lookup in the data source based on the data source correlation settings to find a row of data. The row is then used to populate the response (as defined in the Response tab) with parameterized values from the data source.

For example, the following configures a correlation between the loanAmount value in incoming messages messages and the Amount column within the ApprovalLists data source:

...

With the following settings in the Response tab, the approved value will be parameterized with values from the corresponding value in the Decision data source column... :

and the The message value will be parameterized with values from the corresponding value in the Message data source column.

...

Another way to configure virtual assets to dynamically respond with the desired message is to use data sources. You You can easily fill out data source tables (like Excel, etc.) where each row contains values in the incoming message (typically, just the leaf node values) that you want the virtual asset to respond to, then another column that specifies how you want the virtual asset to respond when the specified conditions are met (see Using Existing Data Sources or Rapidly Creating Data Sources for Responses for details). After that, you can configure the mapping between the request and response message values and the columns within the data source.

...

Ensure that you have a data source configured in Virtualize and available for the Message Responder.
Click the Add button in the appropriate part of the Data Source Correlation tab, provide an XPath, URL parameter, URL path and/or criteria expression and select the appropriate column name. When the deployed virtual asset is exercised, Virtualize will extract the specified values from the request, then search the named column for a match that corresponds to the extracted value. If a match is found, the data in the corresponding data source row will be used to populate the response:
- If you specify the same column name multiple times (e.g.for example, in URL Parameters and URL Paths), only one value will be set; the previous value(s) will be overwritten.
- If a WSDL was provided, the XPath can be generated using the by clicking Edit button. That dialog validates the XPath expression and the column name in real time.
- Virtualize validates the XPath syntax while you type/edit these XPath expressions—if expressions if you choose to customize them instead of using the visual Edit option.
- Wildcards can be used in the data source column.
- Expressions (e.g.for example, [> "55"], [like "alpha?beta*"], [like "*b*" or like "*a*" and like "*z*"]) can can be used as described in Criteria Expressions for Matching Values with the Message Responder.
- See Data Source Correlation Options below for details on the available configuration options.
Parameterize the Response area of the Message Responder by referencing other data source columns within that same data source (i.e.that is, Form Input, Form XML, etc.and so on). You can add several XPaths or URL parameters to column name mappings.

...

If multiple columns are used for the correlation, the values for each column row must all be either decoded or encoded. If all values are encoded, they must all be encoded in the same way—using way, using either the plus sign or “%20” for spaces, but not both.

...

Info

title	Matching on Absent/Empty Fields and Parameters

Data source correlations can correlate on the absence of a field in the request. For example, assume you have a responder responder that’s configured with data source correlation on a text value of an XML element on the Request Body—but Body, but that element is optional. You You can use the same data source to populate the response with parameterized values when the field is absent. To do this, you would set the value of the corresponding field in the data source row as the empty string. Because of the property of XPath function, the empty string would match the case when the XML element is absent and when the XML element is empty. This is also the case for data source correlation for URL Paths: to match the absence of the field in the request, you can use the empty string as the value for the corresponding field in the data source row.

URL parameter data correlation works somewhat differently (in order to handle cases where the parameter value is the empty string and where the parameter is altogether absent):

To match the case where the URL parameter is present, but its value is the empty string, use the empty string as the value for the corresponding field in the data source row.
To match the case where the parameter is absent in the request URL, right-click the the corresponding field in the data source row (in the data repository editor) and choose Set field to exclude.

...

If you want to match a dynamic value from the URL URL http://myvirtserver:9080/MyAsset/MyPath/A/[somedynamicvalue]/C, then use the path index value 3.

...

If multiple columns are used for the correlation, the values for each column row must all be either decoded or encoded. If all values are encoded, they must all be encoded in the same way—using way, using either the plus sign or “%20” for spaces, but not both.

...

Anchor
Attachment Tab
Attachment Tab
Attachment Tab

The Attachment 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 the Add button. An XML Attachment entry displays in the Attachment table.
Double-click the XML Attachment entry. An Edit Attachments Edit Attachments dialog displaysopens.
In the Edit Attachments dialog, select choose either XML or Binary from the Mode drop-down menuMode menu.
Configure the attachment.
- The following option is available for XML Mode:
  - Views: Select the desired view from the drop-down 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 the Browse button. Check the Enable Persist as Relative Path option 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 the Edit Headers button if if you want to add, modify, or delete attachment headers.

Options Tab

The Options tab allows you to configure how the message is processed. The following options are available:

...

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 dropdown menu. To specify a date-time, enter it in the field. If left blank, no offset will be calculated.

...

Allows you to specify an XML-format template that will be used to automatically populate the expected XML response when XPath parameters (e.g. for example, in the message request XPath dialogs for data source correlation and responder correlation or in the multiple response XPath dialog).

When a Message Responder is created from traffic logs, the Request Message Template is generated automatically. The largest request message identified in the Traffic Log is used for this purpose.
When a Message Responder is NOT created from traffic logs, the template will be empty. In this case, you can manually modify the Request Message Template through the Tree or Literal views (e.g.for example, by copying in a sample request message that correlates with the response message you’re configuring).
The completed Request Message Template is used to populate the Tree/Literal/Element views in the Edit XPath Function dialogs available from the Message Responder. The XML Data Bank and XML Transformer output will also use the template if it is attached to the Message Responder as a Request output.

...

Select Solicit Response or Notification Only.

Solicit Response is the default option. It indicates : Indicates that a response message body is returned. The default option.
Notification Only indicates : 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 MQ, the incoming request message is picked up from the request queue, but no response message is generated into a response.

...

Allows you to specify how the message is returned—for returned, for instance, to emulate working or faulty services. To use the default value of 200 OK, select the enable Use Default Return Status check box. If this option is not selected, the following options are available:

Return Status: Enter the custom return status value. If a data source is available, you can also parameterize this value.
Return Message: Enter the custom return message. If a data source is available, you can also parameterize this value.
Skip message proxy failover: When enabled, internally routed error messages bypass the message proxy's failover setting (as set in the HTTP Reverse Proxy or HTTP Forward Proxy) and allows sending the custom return status and payload configured in the Responder.

...

Select Allow incoming request tools to modify the message before applying data source or multiple response correlations if if you want to chain a tool that alters the request message before the data source or multiple response correlation criteria execute on that message. However, if you are chaining a tool that might alter the request—but do not want such alterations to impact the message that is passed to the data source and multiple response correlation criteria—then leave that option unselected. This is important when the XML must be altered to make it suitable for correlation—or correlation, or if the message is not XML at all and requires some transformation before the virtual asset sends the original caller a suitable response for the request.

Select Skip incoming request tools if data sources correlations fail if if you want to prevent chained request tools from being executed if the incoming message is not succesfully successfully correlated to data source columns.

...

Convert incoming request to XML before applying responder correlation ensures ensures that XML conversion occurs before correlations are run. If this is enabled, correlations will be based on the converted XML.

Info

title	Impact on Message Modelling

With Convert incoming request to XML before applying responder correlation enabled, you can paste sample native-format traffic into Literal tabs (in the Request Message Template as well as the XPath areas of the Responder Correlation and Data Source Correlation controls) and the Tree/Element tabs will render that message using the structure designated for that message format. For example, if you paste a JSON message into a Literal Literal tab within a JSON responder, then open the Tree tab, the message will be rendered in Form JSON structure.

If you want to paste a message that is in a different format than the response, be sure to enable the Convert incoming request to XML using different message format than response option and specify the desired message format.

Convert incoming request to XML using different message format than response lets lets you configure the Message Responder to receive messages in a different format than the one it is configured to respond with. For example, if you wanted to receive an EDI message and respond with a Fixed Length message, you would create a Fixed Length Message Responder, then configure it to convert incoming requests as EDI.

Performance

Allows you to set the following options related to the execution time of the Message Responder:

Performance group: If you’re using performance profiles, you can set or change this responder’s performance group using this control. For details on performance profiles, see Working with Performance Profiles.
Think time: Enter the amount of time (in milliseconds) for the message delay you want to emulate (e.g.for example, to emulate a slow service). This time will be added to aA) the execution time, which is calculated from the time that the server finishes receiving the request to the time that the sending of the response begins, and bB) any any additional time specified via performance profiles, which are described in in Working with Performance Profiles. If a data source is available, you may also parameterize this value.

...

These options allow you to select the body style and encoding of the message:

Body Style: Enable either document or rpc.
Use: Enable either encoded or literal.
Encoding Style URI: (Automatically completed if available) Lists the encoding style URI used to send requests.
Target Object URI: Specifies the target object URI.

...

These options enable you to specify a character encoding for the outgoing message that's different than the request message encoding.

Enable the Use different encoding from request option to activate the Encoding options. When the Encoding options are active, you can choose Custom from the drop-down menu and choose an encoding option from the the drop-down menu. You can also choose Default to use the encoding set in the responder suite.

Conversion Options Tab

The Options tab allows you to configure how the message is processed. These options are available only for message formats that are converted to XML, and the available options vary from format to format. For details on a specific tool’s conversion options, see the relevant topic:

...

Use the procedure described in Generating a Data Source Template for Populating Message Elements to create a CSV file from the Form Input view of the Message Responder tool. A data source will be generated and added to the responder suite. This generated data source will contain columns for responses. The Message Responder tool’s Form Input view will be parameterized automatically.
Add a new data source column (e.g.for example, using Excel, OpenOffice or a similar spreadsheet application) for each request parameter that should be used to determine the response. Wildcards can be used.
Configure the Message Responder’s data source mapping with the new request columns you added. See Data Source Correlation Tab for details.
Add new rows to the data source (e.g.for example, using Excel, OpenOffice or a similar spreadsheet application) in order to specify values for request parameters and the desired corresponding response parameters.

...

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 displaysopens.
From the Add Output wizard, select choose Incoming Request from the left pane and XML Data Bank from the right pane and click Finish.
Double-click the Incoming Request> 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 combo box menu. The method you select should be your entry point. In the above example, the method would be customLogic().

...

Select the Message Responder node and click the Add responder or output button. The Add Output wizard displaysopens.
From the Add Output wizard, select choose Incoming Attachment from the left pane and Attachment Handler from the right pane and click Finish.
Double-click the AttachmentHandler node, then configure the tool in the tool configuration panel.
(Optional) Select the Attachment Handler node beneath the Message Responder node and click the Add Responder or Output button. The Add Output wizard displays opens from which you can add a Write File tool to write the attachment out as a binary file.

...

The Message Forward tool can be attached to a Message Responder tool in order to forward messages to another endpoint (e.g.for example, the actual resource). The response returned from the endpoint will be used as the response returned by the Message Responder.

...

To achieve this...	Do this....
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 DB Tool 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 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 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 form 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.

...

The response message will be encoded based on the MQ "characterSet" header field. By 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.

The value can be one of the supported coded character set number (CCSID) values:

...

Page tree

Versions Compared

Old Version 1

New Version Current

Key

XML Conversion Options

Schema for Modeling Request Payload Using Form Input

Definition Tab
Anchor
Definition Tab
Definition Tab

Response Tab

Anchor
Transport Header Tab
Transport Header Tab
Transport Header Tab

Responder Correlation Tab
Anchor
Responder Correlation Tab
Responder Correlation Tab

Anchor
Custom Correlation
Custom Correlation
Custom Correlation

Anchor
Data Source Correlation Tab
Data Source Correlation Tab
Data Source Correlation Tab

Anchor
Attachment Tab
Attachment Tab
Attachment Tab

Options Tab

Performance

Conversion Options Tab

Page tree

Page History

Versions Compared

Old Version 1

New Version Current

Key

XML Conversion Options

Schema for Modeling Request Payload Using Form Input

Definition Tab AnchorDefinition TabDefinition Tab

Response Tab

AnchorTransport Header TabTransport Header TabTransport Header Tab

Responder Correlation Tab AnchorResponder Correlation TabResponder Correlation Tab

AnchorCustom CorrelationCustom CorrelationCustom Correlation

AnchorData Source Correlation TabData Source Correlation TabData Source Correlation Tab

AnchorAttachment TabAttachment TabAttachment Tab

Options Tab

Performance

Conversion Options Tab

Definition Tab
Anchor
Definition Tab
Definition Tab

Anchor
Transport Header Tab
Transport Header Tab
Transport Header Tab

Responder Correlation Tab
Anchor
Responder Correlation Tab
Responder Correlation Tab

Anchor
Custom Correlation
Custom Correlation
Custom Correlation

Anchor
Data Source Correlation Tab
Data Source Correlation Tab
Data Source Correlation Tab

Anchor
Attachment Tab
Attachment Tab
Attachment Tab