This section describes how to set SOAtest up for accessing IBM MQ. Access to IBM MQ is achieved by configuring Parasoft tools.Sections include: IBM MQ Java API versus the standard JMS API This section refers to testing services over the IBM MQ Java API, not the standard JMS API. If you intend to send and receive messages from IBM MQ using the JMS API, select the JMS transport option and refer to JMS. To use IBM MQ you must provide the required client jars: To add the jar files to SOAtest's or Virtualize's classpath, complete the following for each: The IBM Java Runtime uses different CipherSuite names than the Java Runtime included with SOAtest. To use the Java installed with the product, set the following JVM property: Alternatively, you can use the IBM JDK. IBM Java is available at https://www.ibm.com/developerworks/java/jdk/.If you configure SOAtest to use the IBM JDK, see Configuring Java Runtime for details. After selecting IBM MQ from the Transport menu within the Transport tab of an appropriate tool, the following options are shown in the left panel: When specifying MQ connection settings, you can choose between the following modes: If you are using Default mode, complete the following fields: Option Description If you are using CCDT mode, complete the following fields: Option Description If you are using Bindings mode, complete the following fields: Option Description Enable Perform Authentication and enter the Username and Password to authenticate the request. If the correct username and password are not used, the request will not be authenticated. Enable Keep-Alive connection to cause the test to keep the connection to the queue manager alive, which allows the use of an MQ browse cursor across subsequent tests. When disabled, the connection to the queue manager will be closed after this test is run; any subsequent tests will open a new connection. Enabled by default. The following options are available for Message Exchange Pattern: Expect Synchronous Response: Specifies whether or not SOAtest or Virtualize receives a response. If Expect Synchronous Response is selected, SOAtest or Virtualize sends a message and receives a response. If Expect Synchronous Response is not selected, SOAtest or Virtualize sends a one-way message and does not receive a response. This section allows you to configure the MQRFH2 header, which is used to pass messages to and from a message broker that belongs to IBM MQ Message Broker. See the IBM documentation for more information: https://www.ibm.com/docs/ibm-mq/. In the MQRFH2 Header area, you can configure different parts of the request message header, then SOAtest or Virtualize will create header "folders" based on the specified settings. Publish/Subscribe Command: This panel lets you configure the See the IBM documentation for more information about the content of JMS messages: https://www.ibm.com/docs/ibm-mq/. MQRFH2 Get Messages Options: This panel allows you to control the Transform MQRFH2 Header to XML format for Get Messages option. If this option is enabled, the response message’s MQRFH2 header will be transformed into readable XML format. This allows you to apply XML output tools (for example, XML Data Bank, XML Transformer). Without this option enabled, the response message’s MQRFH2 header may contain characters which are not viewable. The following options are available for Put Messages: MQOO_PASS_IDENTITY_CONTEXT: This allows the MQPMO_PASS_IDENTITY_CONTEXT option to be specified in the PutMsgOpts parameter when a message is put on a queue. This gives the message the identity context information from an input queue that was opened with the MQOO_SAVE_ALL_CONTEXT option. The MQOO_OUTPUT option must be specified. MQOO_SET_IDENTITY_CONTEXT: This allows the MQPMO_SET_IDENTITY_CONTEXT option to be specified in the PutMsgOpts parameter when a message is put on a queue. This gives the message the identity context information contained in the MsgDesc parameter specified on the MQPUT() or MQPUT1 call. This option implies MQOO_PASS_IDENTITY_CONTEXT, which need not therefore be specified. The MQOO_OUTPUT option must be specified. MQMD.report: A report message about another message. This field enables SOAtest & Virtualize sending the original message to specify which report or response messages are required, whether the application message data is to be included in them, and also how the message and correlation ID in the report or reply are to be set. It comprises one or more constants from the MQC class. You may select one type from each of the following: MQRO_EXCEPTION_WITH_DATA: This is the same as MQRO_EXCEPTION, except that the first 100 bytes of the application message data from the original message are included in the report message. If the original message contains one or more MQ header structures, they are included in the report message, in addition to the 100 bytes of application data. MQRO_EXPIRATION_WITH_DATA: This is the same as MQRO_EXPIRATION, except that the first 100 bytes of the application message data from the original message are included in the report message. If the original message contains one or more MQ header structures, they are included in the report message, in addition to the 100 bytes of application data. MQRO_EXPIRATION_WITH_FULL_DATA: This is the same as MQRO_EXPIRATION, except that all the application message data from the original message is included in the report message. The following options are available for Get Messages: MQGetMessageOptions.options: Options which control the action of MQQueue.get() that is internally invoked by SOAtest & Virtualize. Any or none of the following values can be specified. MQGMO_WAIT: SOAtest or Virtualize waits until a suitable message arrives. The maximum waiting time is specified in WaitInterval. MQGMO_NO_WAIT: SOAtest or Virtualize does not wait if no suitable message is available. This is the opposite of the MQGMO_WAIT option and is defined to aid program documentation. MQGMO_BROWSE_FIRST: When a queue is opened with the MQOO_BROWSE option, a browse cursor is established, positioned logically before the first message on the queue. You can then use MQGET calls specifying the MQGMO_BROWSE_FIRST, MQGMO_BROWSE_NEXT, or MQGMO_BROWSE_MSG_UNDER_CURSOR option to retrieve messages from the queue nondestructively. The browse cursor marks the position, within the messages on the queue, from which the next MQGET call with MQGMO_BROWSE_NEXT searches for a suitable message. MQGMO_BROWSE_NEXT: Advance the browse cursor to the next message on the queue that satisfies the selection criteria specified on the MQGET call. The message is returned to SOAtest or Virtualize, but remains on the queue. After a queue has been opened for browse, the first browse call using the handle has the same effect whether it specifies the MQGMO_BROWSE_FIRST or MQGMO_BROWSE_NEXT option. MQGMO_MSG_UNDER_CURSOR: Retrieve the message pointed to by the browse cursor, regardless of the MQMO_* options specified in the MatchOptions field in MQGMO. The message is removed from the queue. The message pointed to by the browse cursor is the one that was last retrieved using either the MQGMO_BROWSE_FIRST or the MQGMO_BROWSE_NEXT option. MQGMO_UNLOCK: Unlock a message. The message to be unlocked must have been previously locked by an MQGET call with the MQGMO_LOCK option. If there is no message locked for this handle, the call completes with MQRC_NO_MSG_LOCKED. MQGMO_CONVERT: Requests SOAtest or Virtualize data to be converted. The conversion conforms to the characterSet and encoding attributes of MQMessage, before the data is copied into the message buffer. MQOO_BROWSE: Open the queue to browse messages. The queue is opened for use with subsequent MQGET calls with one of the following options: MQGMO_BROWSE_FIRST, MQGMO_BROWSE_NEXT and MQGMO_BROWSE_MSG_UNDER_CURSOR. This is allowed even if the queue is currently open for MQOO_INPUT_EXCLUSIVE. An MQOPEN call with the MQOO_BROWSE option establishes a browse cursor, and positions it logically before the first message on the queue. MQOO_ALTERNATE_USER_AUTHORITY: The AlternateUserId field in the ObjDesc parameter contains a user identifier to use to validate this MQOPEN call. The call can succeed only if this AlternateUserId is authorized to open the object with the specified access options, regardless of whether the user identifier under which SOAtest or Virtualize is running is authorized to do so. The following options are available for Queue Manager Options: MQCNO_FASTPATH_BINDING: This option causes SOAtest or Virtualize and the local-queue-manager agent to be part of the same unit of execution. This is in contrast to the normal method of binding, where SOAtest or Virtualize and the local-queue-manager agent run in separate units of execution. MQCNO_STANDARD_BINDING: This connection option causes SOAtest or Virtualize and the local-queue-manager agent (the component that manages queuing operations) to run in separate units of execution (generally, in separate processes). This arrangement maintains the integrity of the queue manager, that is, it protects the queue manager from errant programs. MQCNO_SHARED_BINDING: This connection option causes SOAtest or Virtualize and the local-queue-manager agent (the component that manages queuing operations) to run in separate units of execution (generally, in separate processes). This arrangement maintains the integrity of the queue manager. That is, it protects the queue manager from errant programs. However, some resources are shared between SOAtest or Virtualize and the local-queue-manager agent. MQCNO_ISOLATED_BINDING: This option causes SOAtest or Virtualize and the local-queue-manager agent (the component that manages queuing operations) to run in separate units of execution (generally, in separate processes). This arrangement maintains the integrity of the queue manager, that is, it protects the queue manager from errant programs. SOAtest or Virtualize process and the local-queue-manager agent are isolated from each other in that they do not share resources. The following option is available for MQ Queue Manager Properties: MQC.CCSID_PROPERTY: This configures the CCSID used by the client. It does not apply when connecting directly to IBM MQ in bindings mode. You can configure the following SSL settings. The CipherSuite is used for the SSL connection on the specified MQ channel. Refer to the IBM MQ documentation to determine which CipherSuite to select based on the CipherSpec. You can specify a fixed CipherSuite from the drop-down menu or enter a parameterized variable to specify a CipherSuite based on traffic. (Optional) Specify a peer name to verify that the certificate presented by the Queue Manager matches the criteria specified with the peer name parameter. A server certificate will match this parameter with the Distinguished Name (DN) of the certificate presented by the Queue Manager. You can specify a fixed peer name or enter a parameterized variable to specify a peer name based on traffic. This setting specifies the Key Store to be used for Client-Side SSL (authentication of the client by the Queue Manager). You can configure tools to use either the key store configuration for all projects under Parasoft > Preferences (see Security Settings) or you can add a suite-level global settings property and configure key store settings available to all tools in the suite. See Adding Global Test Suite Properties for additional details. If the MQ Channel does not require the client to authenticate itself, then the Key Store does not need to be provided. Specifies the Trust Store to be used for Server-Side SSL (authentication of the Queue Manager by the client). You can either configure tools to use the trust store configuration for all projects under Parasoft > Preferences (see Security Settings) or you can add a suite-level global settings property and configure trust store settings available to all tools in the suite. See Adding Global Test Suite Properties for additional details.Once an SSL connection is attempted by specifying a CipherSuite and running the tool, the trust store, key store, and key store passwords cannot be changed. If they are changed, SOAtest or Virtualize needs to be restarted before changes will take effect. If using Key Stores, you will need to download and install the Unlimited Strength Java Cryptography Extension. For details, see JCE Prerequisite. The Scripting Hook options allow you to customize MQ Properties by using scripting language such as Jython, Java, Groovy, and JavaScript. If you need more information on using the scripting utility, please refer to the Scripting section of the tutorial. For a list of scripting APIs, go to Help > Help Contents or Parasoft > Help (depending on your installation), then look for the book titled "Parasoft SOAtest Extensibility API" (for SOAtest) or "Parasoft Virtualize Extensibility API" (for Virtualize). The following are scripting access keys: For example, if you like to change the Expiry time for put message to 999: Once you are done running the tool with the above script, note the Expiry field in the Traffic header has changed to 999. Note: Any options set in the Add MQ Hook tab overrides and takes precedence over any options set in the other tabs. When a failure occurs, MQ returns a reason code for a failure. SOAtest & Virtualize error messages report these same reason codes in order for users to interpret them. See the IBM documentation for more information about MQ reason codes and their meaning: https://www.ibm.com/docs/ibm-mq/. The following are best practices for sending and receiving character data with client tools (for example, SOAP Client, REST Client, Messaging Client, and so on). When sending character data such as XML, CSV, fixed-length, or plain text, the format type must be set to the value of the MQFMT_STRING constant which is MQSTR. For the SOAP client tool, the character set used to encode the request is specified using the tool’s Outgoing Message Encoding option on the Misc tab. Other applicable tools (for example, REST Client, Messaging Client) use the character encoding configured in the product’s Misc preferences. The applicable options are: If you specify a different encoding, then the character set of the MQ messages will be defaulted to MQCCSI_Q_MGR, which means "Character data in the message is in the queue manager’s character set." The MQGMO_CONVERT box should be enabled under the client tool’s MQGetMessageOptions (in the Transport tab). This will instruct the queue manager to convert the message to the client tool's character set. This is important if the message's original characterSet is not one of those supported by the client (IBM_037, IBM_437, and so on). The character set used to perform the conversion is configured the same as for put messages (described above).Adding Necessary Jar Files to the Classpath
com.ibm.mq.allclient.jar
(download from Maven Central here)json.jar
(download from Maven Central here)Java Runtime
-J-Dcom.ibm.mq.cfg.useIBMCipherMappings=false
Configuring MQ Options
MQ Address
Host Specifies the name of the host running IBM MQ. Port Specifies the port where IBM MQ is running (default is 1414). Channel Specifies the name of the server-defined channel. Queue manager Specifies the queue manager’s name. Put queue Specifies the queue that the message is sent to. Get queue Specifies the queue that the message is retrieved from. CCDT file Specifies the location of the CCDT file (with a .tab extension). Queue manager Specifies the queue manager’s name. Put queue Specifies the queue that the message is sent to. Get queue Specifies the queue that the message is retrieved from. Queue manager Specifies the queue manager’s name. Put queue Specifies the queue that the message is sent to. Get queue Specifies the queue that the message is retrieved from. Authentication
Optional Parameters
Message Exchange Pattern
MQRFH2 Header
<mcd>
(Message content descriptor) folder. The <mcd>
folder can contain elements that describe the structure of the message data in an IBM MQ message. They are all character strings and are case-sensitive.<psc>
(Publish/subscribe command) folder. The <psc>
folder is used to convey publish/subscribe command messages to the broker. Only one psc folder is allowed in the NameValueData field. See the IBM documentation for more information: https://www.ibm.com/docs/ibm-mq/.<usr>
(Application [user] defined properties) folder. The content model of the <usr>
folder has the following characteristics.Put Messages
MQQueue.put()
. Any or none of the following values can be specified.
You can specify how the message ID is generated for the report or reply message:
You can specify one of the following to control how to set the correlation ID of the report or reply message:
You can specify one of the following to control the disposition of the original message when it cannot be delivered to the destination queue:Get Messages
Queue Manager Options
MQ Queue Manager Properties
Changing this value affects the way that the queue manager you connect to translates information in the IBM MQ headers. All data in IBM MQ headers is drawn from the invariant part of the ASCII codeset, except for the data in the MQMessage.applicationIdData and MQMessage.putApplicationName fields.
If you avoid using characters from the variant part of the ASCII codeset for these two fields, then the CCSID can be changed from 819 to any other ASCII codeset. If you change the client CCSID to be the same as that of the queue manager to which you are connecting, you gain a performance benefit at the queue manager because it does not attempt to translate the message headers. If no value is provided in the CCSID field, SOAtest or Virtualize will provide a default value of 1208 (UTF-8).SSL
CipherSuite
Peer Name
Key Store
Trust Store
Scripting Hook
from com.ibm.mq import *
def changeExpiry(context):
putMessage = context.get("mqPutMessage")
putMessage.expiry = 999
Interpreting IBM MQ Error Messages
Sending and Receiving Data - Best Practices
Put Messages
Get Messages
Overview
Content Tools