> Using Integration Controls > MQSeries Control

Using Integration Controls

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

MQSeries Control

Example: Configuring SSL Within a Workflow

Note: The MQSeries control is available in BEA Workshop for WebLogic Platform only for licensed users of WebLogic Integration.

MQSeries is a middleware product from IBM that runs on multiple platforms. It enables message transfer between applications; the sending application PUTs a message on a Queue, and the receiving application GETs the message from the Queue. The sending and receiving applications do not have to be on the same platform, and can execute at different times. MQSeries manages all the storage, logging and communications details required to guarantee delivery of the message to the destination queue.

Disclaimer

Use of the MQSeries control and event generator with BEA WebLogic Integration in no manner confers or grants the right to use MQSeries control including "dynamic libraries". In order to use such IBM products, the user of the MQSeries control and event generator must obtain a valid license from IBM.

 

Topics Included in This Section

Overview: MQSeries Control

Describes the function of the MQSeries control within WebLogic Integration.

Prerequisites to Adding an MQSeries Control

Describes the pre-requisite tasks for creating a new MQSeries control.

Creating and Configuring a New Instance of the MQSeries Control

Describes how to create and configure a new MQSeries control.

Using the MQSeries Control Exit Implementation

Describes how to implement the MQSeries control Exit functionality.

Understanding Transaction Management

Describes the modes of transaction management supported by the MQSeries control.

Using Message Descriptors

Describes how to set and retrieve the message descriptor attributes of the message.

Sending and Receiving Messages

Describes the methods used to send and receive messages.

Working with MQSeries Message Descriptor Format

Describes the method used to send messages of built-in MQSeries formats.

Setting Dynamic Properties

Describes how to modify the MQSeries control properties at run time.

Configuring SSL In MQSeries Control

Describes how to configure server-side and client-side authentication using SSL, for the MQSeries control.

Migrating an MQSeries Control 8.1 SP3 JCX File

Describes how to migrate control files created using MQSeries control version 8.1 SP3, to version 9.2.

Using the MQSeries Event Generator

Describes the MQSeries Event Generator in brief, with a reference to more information.

Overview: MQSeries Control

The MQSeries control enables WebLogic Integration business processes to send and receive messages using MQSeries queues. Using the MQSeries control, you can send and receive Binary, XML, and String messages. You can specify MQSeries control properties while configuring the MQSeries control or dynamically at run time. You can also set the transaction boundaries for the MQSeries business operations.

The MQSeries control complements the other controls provided in WebLogic Integration, and can be used with other WebLogic Integration business processes.For information on how to add control instances to business processes, see Using Controls in Business Processes.

The MQSeries Event Generator can be used for polling specific MQSeries queues for incoming messages. For more information, see Using the MQSeries Event Generator.

Prerequisites to Adding an MQSeries Control

Before adding the MQSeries control to the BEA Workshop for WebLogic Platform, you must complete the following tasks:

  1. Install the WebSphere MQSeries client on your machine.
  2. Add the com.ibm.mq.jar file from the MQSeries client installation to the system environment CLASSPATH variable.
  3. Optionally, enable MQSeries control logging by adding the following code to the apacheLog4jCfg.xml file:

    4. <category name="com.bea.control.MQControl">
    <!-- NOTE: DO NOT CHANGE THIS PRIORITY LEVEL W/O WLI DEV APPROVAL -->
    <!-- Debug-level log information is frequently the only tool available to diagnose failures! -->
    <priority value="warn"/>
    <appender-ref ref="SYSLOGFILE"/>
    <appender-ref ref="SYSERRORLOGFILE" />
    </category>

    The MQSeries control uses the Workshop debugger for logging messages.

    Note: To change the log level, refer to the control documents..
  4. In BEA Workshop for WebLogic Platform, import the com.ibm.mq.jar file from the MQSeries client installation into the Libraries folder of the application where the MQSeries control is used.

Now you can add a new MQSeries control to send and receive messages.

Creating and Configuring a New Instance of the MQSeries Control

You can create and configure a new instance of the MQSeries control and add it to your business process. This topic includes the following sections:

To Add a New MQSeries Control

Describes how to add a new MQSeries control.

To Specify MQSeries Control General Settings

Describes how to configure the general settings for the MQSeries control, such as pool size, SSL, and so on.

To Specify MQSeries Control Connection Settings

Describes how to configure connection settings for the MQSeries control.

To Specify MQSeries Control Exits

Describes how to configure exits and how to use the MQSeries control exit implementation. For more information, see Using the MQSeries Control Exit Implementation.
To Add a New MQSeries Control

To add a new MQSeries control to WebLogic Integration, perform the following steps:

  1. In the Package Explorer pane, double-click the business process (Process.java file) to which you want to add the MQ Series control. The business process is displayed in the Design view.
  2. Click Example: Configuring SSL Within a Workflow on the Data Palette and from the drop-down list choose Integration Controls to display the list of controls used for integrating applications.
Note: If the Data Palette view is not visible in BEA Workshop for WebLogic Platform, click WindowArrow symbolShow ViewArrow symbolData Palette from the menu bar.
  1. Select MQSeries Control.

    2. The Insert Control - MQSeries dialog box is displayed.

Note: If you are creating the control for the first time, the Locate the MQ Series jar file dialog box will is displayed. Browse for the com.ibm.mq.jar file located at MQ series installation and click Open.
  1. In the Insert control: MQSeries dialog box enter the following details:
    • In the Field Name, type the variable name used to access the new MQSeries control instance from your business process. The name you enter must be a valid Java identifier.
    • In the Insertion point: from the drop-down list select the point where you want the field name to be inserted in the process file..
    • Decide whether you want to make this a control factory and select or clear the Make this a control factory that can create multiple instances at runtime check box. For more information about control factories, see Control Factories: Managing Collections of Controls.
    • Click Next.

      • The Create Control wizard is displayed.

  2. In the Create Control wizard enter the following details:
    • In the Name field, type the name of your new control extension file.
    • Decide whether you want to add comments as configured in the properties of the current project and select or clear the Generate comments check box.
    • Click Next.

      • The Insert control: MQSeries dialog-box is displayed.

  3. Configure the following settings in the Insert control: MQSeries dialog-box as mentioned below:
  4. Click Finish.
To Specify MQSeries Control General Settings

To specify connection settings for the MQSeries control, perform the following tasks:

  1. From the Connection Type drop-down list, select the type of connection that you want to establish; a Bindings or TCP type connection. Using the Bindings connection type, you can only get a connection to queue managers on the local system. Using the TCP connection type, you can also get connections to remote queue managers.
  2. In the MQ Pool Size text box, enter the number of MQSeries connections to be maintained in the MQSeries connection pool.
  3. In the Connection Time-out (Seconds) field, enter the number of seconds after which the connection should time out.
  4. From the Require MQ Authorization drop-down list, select either Yes or No. MQ authorization is applicable only in TCP mode. To get MQ authorization, you must enter the MQSeries user name and password in the Authorization tab.
  5. The Implicit Transaction Required option is selected by default. When selected, the MQSeries control handles transactions implicitly for each Put and Get individually, without having to set an explicit transaction boundary. When this option is not selected, you must explicitly set the transaction boundaries. For more information, see Understanding Transaction Management.
  6. In the Default Queue Name field, enter the default queue name to be used by the MQSeries control for sending and receiving messages.
  7. Select Require SSL Authentication if you want to enable server-side authentication using SSL (one way) for this instance of the MQSeries control.
  8. Select Require Two way SSL if you want to enable client-side authentication also using SSL (two way) for this instance of the MQSeries control.
To Specify MQSeries Control Connection Settings

To specify TCP/IP settings for the MQSeries control, perform the following tasks , in the Connection tab:

  1. In the Connection tab, in the Queue Manager Name field, enter the name of the Queue Manager for which the connection is being obtained.
Note: Specify TCP/IP settings only if you have set your connection type to TCP.
  1. In the Host field, enter the name of the host machine containing the queue manager to which you want to connect.
  2. In the Port field, enter the port number on which the queue manager is available for connection.
  3. In the Channel field, enter the MQSeries server connection channel configured in the queue manager.
  4. In the CCSID field, enter the Coded Character Set to be used when a connection is established. The CCSID is used mainly for internationalization support.
  5. Click the Test Connection button to validate the values entered, and to check that you can connect to the queue manager.
Note: The TCP Setting of Connection tab is enabled only when the TCP connection mode is selected
WARNING: Do not click the Test Connection button when selecting the SSL option for your control. Clicking this button will cause your connection to fail.
To Specify MQSeries Control Authorization Settings

To specify user name and password for MQ authorization, perform the following tasks:

  1. In the MQ User Name field, enter your MQ user name.
  2. In the MQ User Password field, enter your MQ password.
To Specify MQSeries Control Exits

To specify MQSeries control exits, perform the following tasks:

  1. In the Exits tab, in the Send Exit Class field, enter the fully qualified name of the class implementing the MQSeries MQSendExit interface.
  2. In the Receive Exit Class field, enter the fully qualified name of the class implementing the MQSeries MQReceiveExit interface.
  3. In the Security Exit Class field, enter the fully qualified name of the class implementing the MQSeries MQSecurityExit interface.

    4. For more information, see Using the MQSeries Control Exit Implementation.

    Note: The Exits tab is enabled only when TCP connection mode is selected. The fields in this tab are not mandatory.

The Control File for an MQSeries Control

When you create a new instance of the MQSeries control, you create a new Control file in your project. The following is a sample control file for an MQSeries control: 

package processes;
import com.bea.jpd.ProcessDefinition;
import com.bea.jpd.JpdContext;
import org.apache.beehive.controls.api.bean.Control;
@com.bea.wli.jpd.Process(process = 
"<process name=\"Process\">" + 
"  <clientRequest name=\"Client Request\" method=\"clientRequest\"/>" + 
"</process>")
public class Process implements ProcessDefinition {
	@com.bea.wli.jpd.Context
	JpdContext context;
	static final long serialVersionUID = 1;
	@Control
	private ServiceBrokerCntrl ServiceBrokerControl;
	@Control
	private MQSeriesCntrl MQControl;
	public void clientRequest() {
        // #START: CODE GENERATED - PROTECTED SECTION - you can safely add code above this comment in this method. #//
        // input transform
        // parameter assignment
        // #END  : CODE GENERATED - PROTECTED SECTION - you can safely add code below this comment in this method. #//
    }
}

The contents of the MQSeries control file depend on the selections made in the Insert MQSeries dialog. The example above was generated based on selecting a TCP connection type using one-way SSL.

Using the MQSeries Control Exit Implementation

The MQSeries control allows you to create your own send, receive, and security exits.

To implement an Exit, you must define a new Java class that implements the appropriate interface. Three exit interfaces are defined in the WebSphere MQ package:

Notes: User Exits are supported for TCP connections only; they are not supported for bindings connections.
Note: User Exits are used to modify the data that is transmitted between the MQSeries queue manager and the MQSeries client application. This data is in the form of MQSeries headers and does not involve the contents of the actual message being put and received from the queue.

Implementing MQSeries Exits

To implement MQSeries Exits, perform the following tasks:

  1. Create the Java class that implements the com.ibm.mq.MQSendExit, com.ibm.mq.MQReceiveExit, and com.ibm.mq.MQSecurity interfaces for the send, receive, and security exits, as shown in the following example:

    2. package com.bea.UserExit;
    import com.ibm.mq.*;
    public class MQUserExit implements MQSendExit, MQReceiveExit, MQSecurityExit {
    public MQUserExit()
    {
    }
    public byte[] sendExit(MQChannelExit channelExit,MQChannelDefinition channelDefnition,byte[] agentBuffer)
    {
    return agentBuffer;
    }
    public byte[] receiveExit(MQChannelExit channelExit,MQChannelDefinition channelDefnition,byte[] agentBuffer)
    {
    return agentBuffer;
    }
    public byte[] securityExit(MQChannelExit channelExit,MQChannelDefinition channelDefnition,byte[] agentBuffer)
    {
    return agentBuffer;
    }
    }

    You may implement these interfaces in a single class or in separate classes, as required.

    For an MQSendExit, the agentBuffer parameter contains the data to be sent. For an MQReceiveExit or an MQSecurityExit, the agentBuffer parameter contains the data just received.

    For the MQSendExit and the MQSecurityExit, your exit code should return the byte array that you want to send to the server. For a Receive exit, your exit code must return the modified data that you want WebSphere MQ Client for Java to interpret.

  2. Bundle the given class in a Jar file, for example, mquserexits.jar.
  3. Place the Jar file in the WebLogic classpath. Edit the setDomainEnv.cmd file located in the WebLogic domain directory to append the Jar file name to the CLASSPATH. To do this, find the following code in the setDomainEnv.cmd file:

    4. set Pre_CLASSPATH=

    and append the following line to it:

    ;%EXIT_DIR%\mquserexits.jar

    Before you append the code containing the Jar file name to the CLASSPATH, you can define the directory in which the Jar file resides, as follows:

    set EXIT_DIR=D:\UserExits

Understanding Transaction Management

Two modes of transaction management are supported by the MQSeries control. They both use the underlying MQSeries syncpoint feature. The two transaction management modes are:

Implicit Transaction Management

Implicit transaction management is selected by default. When this mode is on, the MQSeries control handles the transaction for each MQSeries Get or Put function. The following diagram describes how an implicit transaction is handled by the MQSeries control.

Example: Configuring SSL Within a Workflow

Using implicit transaction management prevents you from grouping several Get and Put functions together as a part of a transactional unit. Each Get and Put are handled individually within a transaction boundary.

Explicit Transaction Management

Explicit transaction management is enabled when you choose not to use implicit transaction management while configuring the MQSeries control. In the explicit transaction mode, you must set the transaction boundaries explicitly, using the Begin and Commit (or Rollback) MQSeries control functions.

The following diagram describes the process of creating a workflow using explicit transaction management.

Example: Configuring SSL Within a Workflow

Using Message Descriptors

A Message Descriptor is an attribute representing a property of the message that is either being sent or received. Message properties can be the type of message, the message ID, and the message priority. For a detailed list of all the message descriptors supported by the MQSeries control, see Table 10-1, Elements of the MQMDHeaders XML document.

Using the MQSeries control you can set Message Descriptors for each message while sending the message using the putMessage function. You can also get the message descriptors of the messages retrieved from the queue. This facility is supported using the MQMDHeaders document which is provided as an input to the putMessage and getMessage functions. The MQMDHeaders document is represented using an XMLBean that conforms to the MQMDHeaders schema present in the MQSchemas.jar file.

The following elements of the MQMDHeaders XML document can be set as part of the MQMD parameters:

Table 10-1 Elements of the MQMDHeaders XML document 
Element Name
Description
Permissible Values
Relevance
MessageType
Type of message
8-Datagram
1-Request
2-Reply
Other positive integers are also accepted if they are within the Application or System defined ranges specified by MQSeries.
Put Request, Put Response, Get Response
MessageId
Id of message
Hexadecimal string
Put Request, Put Response, Get Request, Get Response
CorrelationId
Correlation Id of the message
Hexadecimal string
Put Request, Put Response, Get Request, Get Response
GroupMessage
This element is required to send and receive group messages.
 
Put Request, Put Response, Get Request, Get Response
GroupId
Group Id of the message
Hexadecimal string
Put Request, Put Response, Get Request, Get Response
Priority
Message priority
0-9
Put Request, Put Response, Get Response
Format
Message format
String values representing valid built-in MQSeries formats or user-defined formats. The string values are present in MQC.MQFMT_*.
Put Request, Put Response, Get Response
CharacterSet
Character Set of the message
Valid MQSeries Character set
Put Request, Put Response, Get Response
Persistence
Persistence property of the message
0- non-persistent message.
1-persistent message
Put Request, Put Response, Get Response
Segmentation
Segmentation property of the message
0- segmentation not allowed.
1- segmentation allowed.
Put Request
Expiry
Message expiration
A positive integer or -1 (for unlimited expiration)
Get Request, Put Response, Get Response
UserId
User Id of the message
A string
Put Request, Put Response, Get Response
MessageSequenceNumber
Message Sequence Number of the message
A positive integer, not 0
Put Request, Put Response, Get Request, Get Response
GroupOptions
use this element in the Put Request only if the message being Put is a group message. In the Get Response, this element appears only if the message retrieved is a group message.
 
Put Request, Get Response
IsLastMessage
Identifies the last message of a group message. This element accepts boolean values.
True or False
Put Request, Get Response
ReportOptions
Identifies the report options to be set while sending a message.
 
Put Request
COA
Confirmation on Arrival.
COA Report options
COA - the COA report without any original message data.
COAWithData-the COA report with the first 100 bytes of the original message.
COAWithFullData - the COA report with all the original message data.
COA, COAWithData, COAWithFullData, None
Put Request
COD
Confirmation of Delivery
COD Report options
COD - the COD report without any data of the original message.
CODWithData - the COD report with the first 100 bytes of the original message.
CODWithFullData - the COD report with all the original message data.
COD, CODWithData, CODWithFullData, None
Put Request
Exception
Exception Report options
Exception - the Exception report without any original message data.
ExceptionWithData - the Exception report with the first 100 bytes of the original message.
ExceptionWithFullData - the Exception report with all the original message data.
Exception, ExceptionWithData, ExceptionWithFullData, None
Put Request
Expiration
Expiration Report options
Expiration - the Expiration report without any original message data.
ExpirationWithData - the Expiration report with the first 100 bytes of the original message.
ExpirationWithFullData - The expiration report with all the original message data.
Expiration, ExpirationWithData, ExpirationWithFullData, None
Put Request
Feedback
Message feedback
A positive integer
Put Request, Put Response, Get Response
ReplyToQueueName
The queue to which the reports or the reply (used only for a request message) should be sent.
String representing a valid queue name
Put Request, Put Response, Get Response
ReplyToQueueManager
The queue manager containing the reply to queue.
String representing a valid queue manager name
Put Request, Put Response, Get Response
WaitInterval
The lapse time (in milliseconds) before receiving a message.
A positive integer. -1 for unlimited wait interval
Get Request
ApplicationIdData
 
String value
Put Request, Put Response and Get Response.
ApplicationOriginData
 
String value
Put Request, Put Response and Get Response.
PutApplType
Put application type of the message
Positive integer value
Put Request, Put Response and Get Response.
PutApplName
Put application name of the message
String value
Put Request, Put Response and Get Response.
PutDateTime
Put date and time of the message
String value
Put Response and Get Response
AccountingToken
Accounting information for the message
Byte array
Put Request, Put Response and Get Response.
Version
Version information of the message descriptor
2 or 1
Put Request, Put Response and Get Response.
MessageConsumption
Message consumption option for the getMessage function.
Browse - Retrieve the message from the queue (without deleting the message).
Delete - Delete the message from the queue after retrieving it.
Browse, Delete
Get Request
MQGMO_CONVERT
Specifies whether data conversion is required for the message during a Get operation.
This element must be set to True to retrieve messages of the EBCDIC characterset.
True or False
Get Request

Table 10-2 Attributes of the MQMDHeaders document
Attribute Name
Under Element
Description
Values
Relevance
waitForAllMsgs
GroupMessage
Used while retrieving group messages to specify that no message of the group should be retrieved until all the messages of the group are available in the queue. This attribute is normally specified only while retrieving the first message of the group.
True or False
Get Request and Get Response
logicalOrder
GroupMessage
Used while retrieving group messages to specify that the messages of the group should be retrieved in the order of their Message Sequence Number irrespective of the order in the queue. This option is specified while retrieving all the messages of the group.
True or False
Get Request and Get Response

Schema of the MQMDHeaders Document 

<?xml version="1.0"?>
<xs:schema targetNamespace="http://www.bea.com/wli/control/MQMDHeaders"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns="http://www.bea.com/wli/control/MQMDHeaders" elementFormDefault="qualified">
<xs:element name="MQMDHeaders">
     <xs:complexType>
          <xs:sequence>
<xs:element name="MessageType" type="xs:string" minOccurs="0"
maxOccurs="1"/>
<xs:element name="MessageId" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="CorrelationId" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="GroupMessage" minOccurs="0" maxOccurs="1"> <xs:complexType>
     <xs:sequence>
<xs:element name="GroupId" type="xs:string" minOccurs="1" maxOccurs="1"/>
          </xs:sequence>
<xs:attribute name="waitForAllMsgs" type="xs:boolean" use="optional"/>
<xs:attribute name="logicalOrder" type="xs:boolean" use="optional"/>
     </xs:complexType>
          </xs:element>
<xs:element name="Priority" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="Format" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="CharacterSet" type="xs:string" minOccurs="0"
maxOccurs="1"/>
<xs:element name="Persistence" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="Segmentation" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="Expiry" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="UserId" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="MessageSequenceNumber" type="xs:string" minOccurs="0"
maxOccurs="1"/>
<xs:element name="GroupOptions" minOccurs="0" maxOccurs="1">
     <xs:complexType>
          <xs:sequence>
               <xs:element name="IsLastMessage" type="xs:boolean" minOccurs="1" maxOccurs="1"/>
          </xs:sequence>
     </xs:complexType>
</xs:element>
<xs:element name="ReportOptions" minOccurs="0" maxOccurs="1">
     <xs:complexType>
     <xs:sequence>
     <xs:element name="COA" type="xs:string" minOccurs="0" maxOccurs="1"/>
     <xs:element name="COD" type="xs:string" minOccurs="0" maxOccurs="1"/>
     <xs:element name="Exception" type="xs:string" minOccurs="0" maxOccurs="1"/>
     <xs:element name="Expiration" type="xs:string" minOccurs="0" maxOccurs="1"/>
     </xs:sequence>
     </xs:complexType>
     </xs:element>
<xs:element name="Feedback" type="xs:int" minOccurs="0" maxOccurs="1"/> <xs:element name="ReplyToQueueName" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="ReplyToQueueManager" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="WaitInterval" type="xs:string" minOccurs="0" maxOccurs="1"/> 
<xs:element name="ApplicationIdData" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="ApplicationOriginData" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="PutApplType" type="xs:int" minOccurs="0" maxOccurs="1"/>
<xs:element name="PutApplName" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="PutDateTime" type="xs:string" minOccurs="0" maxOccurs="1"/> 
<xs:element name="AccountingToken" type="xs:base64Binary" minOccurs="0" maxOccurs="1"/> 
<xs:element name="Version" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="MessageConsumption" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="MQGMO_CONVERT" type="xs:boolean" minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>

Sample of an MQMDHeaders Document

The following is a sample MQMDHeaders document that contains most of the message descriptors you can set using the MQSeries control: 

<?xml version="1.0"?>
<even:MQMDHeaders xmlns:even="http://www.bea.com/wli/control/MQMDHeaders">
<even:MessageType>8</even:MessageType>
<even:MessageId>1111</even:MessageId> <even:CorrelationId>2222</even:CorrelationId>
<even:GroupMessage>
     <even:GroupId>3333</even:GroupId>
</even:GroupMessage>
<even:Priority>9</even:Priority>
<even:Format>MQSTR</even:Format> <even:CharacterSet>819</even:CharacterSet> <even:Persistence>1</even:Persistence> <even:Segmentation>1</even:Segmentation>
<even:Expiry>5000</even:Expiry>
<even:UserId>WebLogic</even:UserId> <even:MessageSequenceNumber>1</even:MessageSequenceNumber> <even:GroupOptions>
     <even:IsLastMessage>true</even:IsLastMessage>
</even:GroupOptions>
<even:ReportOptions>
     <even:COA>COAWithFullData</even:COA>
     <even:COD>CODWithFullData</even:COD>
     <even:Exception>ExceptionWithFullData</even:Exception>
     <even:Expiration>ExpirationWithFullData</even:Expiration> </even:ReportOptions>
<even:Feedback>1</even:Feedback>
<even:ReplyToQueueName>trial</even:ReplyToQueueName> <even:ReplyToQueueManager>QM_itpl_025051</even:ReplyToQueueManager> <even:ApplicationIdData>App_ID_025051</even:ApplicationIdData> <even:ApplicationOriginData>Windows_app_025051</even:ApplicationOriginData> <even:PutApplType>1</even:PutApplType> <even:PutApplName>MQSeriesClient</even:PutApplName> <even:Version>2</even:Version>
</even:MQMDHeaders>

Using XML Beans to Set the MQMDHeader Element Values

The MQSeries control MQMDHeaders document element values can be set, and the return values can be retrieved, programmatically, using XML beans. The following is an example of setting the MQMDHeader element values prior to calling the putMessage function: 

headers = com.bea.wli.control.mqmdHeaders.MQMDHeadersDocument.Factory.newInstance();com.bea.wli.control.mqmdHeaders.MQMDHeadersDocument.MQMDHeaders header = headers.addNewMQMDHeaders();
header.setMessageType(MQC.MQMT_DATAGRAM);
header.setPriority(8);
header.setExpiry(5000);
header.setPersistence(MQC.MQPER_PERSISTENT);
header.getReportOptions().setCOA("COA"); header.setReplyToQueueName("ReportQueue"); header.setApplicationIdData("Testing"); header.setApplicationOriginData("AAAA");
header.setPutApplName("Websphere MQ 2"); header.setPutApplType(MQC.MQAT_JAVA);

Sending and Receiving Messages

You can send and receive messages with the MQSeries control using the Put and Get functions. Messages can be of the form Bytes, String, or XML data.

Sending Messages

To send a message, select a putMessage function based on the data type of the message that you want to send:

The first parameter that is passed to the function is the message to be put into the queue. The possible types for this parameter are byte[], XmlObject and String for sending Binary, XML and plain text messages respectively.

The second parameter that is passed to the function is the queue to which the message is sent. If a value is not provided at runtime, that is, if the value is null, the default queue name mentioned in the control property is used.

The third parameter that is passed to the function is the XML bean representing the MQMDHeadersDocument provided as an XML document during runtime, which conforms to the MQMDHeaders schema. The values provided in this document are used for setting the MQMD attributes of the message being sent. If the MQMDHeadersDocument parameter is not provided, or if the parameter is null, the message is put into the queue with the default values for the message descriptors.

The return value of the function is the MQMDHeadersDocument representing the MQMD attributes of the message sent to the queue.

Using the putMessage Function In a Business Process

The following procedure describes how to add any MQSeries control putMessage function to a business process.

  1. Open the Client Request node.
  2. In the General Settings tab, enter a name for the new method.
  3. Click Add, then select MQMDHeadersDocument from the XML Types list. Enter a name for the variable in the Name field. Click OK to add your selection to the Client Request node. This represents the input MQMDHeaders document for the putMessage function.
  4. Click Add again, then select String from the Java datatype list. Enter a name for the variable in the Name field. Click OK to add your selection to the Client Request node. This represents the queue name for the putMessage function.
  5. Click Add again, then select String from the Java datatype list. Enter a name for the variable in the Name field. Click OK to add your selection to the Client Request node. This represents the message for the putMessage function.
  6. In the Receive Data tab, create a new variable for each of the three parameters that you created in the General Settings tab of the Client Request node. You must provide variable names for all three variables. The variable type is pre-defined, based on the parameters to which you are assigning the variable.
  7. Close the Client Request node.
  8. Drag and drop the putMessageAsString function from the Controls tab in the Data Palette into your business process, just below the Client Request node.
  9. Open the Send Data tab of the putMessageAsString function node. From the Select variables to assign drop-down list, assign the variables that you created in the Receive Data tab of the Client Request node, to the corresponding parameter of the putMessageAsString function listed in the Control Expects column.
  10. Open the Receive Data tab of the putMessageAsString function node. From the Select variables to assign drop-down list, create a new variable in which to store the output of the putMessageAsString function, the MQMDHeaders document, which represents the attributes of the message that was sent.

You can use similar steps to send messages using the putMessageAsBytes or the putMessageAsXml functions.

Sending Messages To a Remote Queue Manager

Using the MQSeries control you can add messages to a remote queue managed by a remote queue manager. To do this, you must configure a transmission queue in the queue manager to which the MQSeries control is connected. For more information on how to configure a transmission queue, see the MQSeries documentation on http://www.IBM.com.

To add a message to a remote queue (managed by a remote queue manager) you must drag and drop the following function, before the putMessage call in the workflow:

void setRemoteQueueManager(java.lang.String remoteQueueManager);

The parameter to this function is the name of the remote queue manager. To set the value for this parameter, in the Design View, open the remoteQueueManager node. In the Send Data tab, select or create a string variable, then enter the name of your remote queue manager as the default value.

Once you've configured the remote queue manager, the putMessage functions following the setRemoteQueueManager function add messages to the remote queue manager.

To revert to the default (local) queue manager to which your control is connected, in the Design View you must drag and drop the setRemoteQueueManager again in your workflow. On doing this, a default value, null, is passed as the parameter to this function. This null value or empty string reverts control back to the default queue manager. messages are now automatically added to the local queue.

Receiving Messages

To receive a message, select a get Message function based on the data type of the message that you want to receive:

The first parameter of the function, java.lang.String queue, is the name of the queue from which the message is to be received. If a value is not provided at runtime (the value is null) the default queue name mentioned in the control property is used.

The second parameter of the function, MQMDHeadersDocument, is an XML bean. This represents the MQMDHeadersDocument provided as an XML document at runtime, which conforms to the MQMDHeaders schema. The values provided in this document are used to retrieve the message corresponding to the MQMD attributes specified in the document. If the MQMDHeadersDocument parameter is not provided, or if the parameter is null, the first message present in the queue is retrieved. If the MQMDHeadersDocument parameter is not null, the MQMD attributes of the message obtained from the queue are updated in this XML bean object itself.

Note: If the MQMDHeadersDocument parameter to the getMessage function is null, you must use the getMQMDHeaders function after the getMessage function in the workflow, to get the MQMD attributes of the message retrieved from the queue. Also, if the MQMDHeadersDocument parameter to the getMessage function is null, Delete is used as the default MessageConsumption option.

The return value of the function is the message obtained from the queue. The data type of the message depends on the getMessage function added. The values may be byte[], XmlObject, or String, depending on whether the message obtained is to be processed as a Binary, XML, or plain text message.

Using the getMessage Function In a Business Process

The following procedure describes how to add a MQSeries control getMessage function to a business process.

  1. Open the Client Request node.
  2. In the General Settings tab, enter a name for the new method.
  3. Click Add, then select MQMDHeadersDocument from the XML Types list. Enter a name for the variable in the Name field. Click OK to add your selection to the Client Request node. This represents the input MQMDHeaders document for the getMessage function.
  4. Click Add again, then select String from the Java datatype list. Enter a name for the variable in the Name field. Click OK to add your selection to the Client Request node. This represents the queue name for the getMessage function.
  5. In the Receive Data tab, create a new variable for each of the two parameters that you created in the General Settings tab of the Client Request node. You must enter variable names for the two variables. The variable type is pre-defined based on the parameters to which they are assigned.
  6. Close the Client Request node.
  7. Drag and drop the getMessageAsString function from the Controls tab in the Data Palette into your business process, just below the Client Request node.
  8. Open the Send Data tab of the getMessageAsString function node. From the Select variables to assign drop-down list, assign the variables that you created (in the Receive Data tab of the Client Request node) to the corresponding parameter of the getMessageAsString function listed in the Control Expects column.
  9. Open the Receive Data tab of the getMessageAsString function node. From the Select variables to assign drop-down list, create a new variable in which to store the output of the getMessageAsString function. The output is a string representing the message that was retrieved from the queue.

    10. The Message Descriptor attributes of the message retrieved from the queue are updated in the MQMDHeaders document. This document was provided as input to the getMessageAsString function.

You can use a similar procedure to retrieve messages using the getMessageAsBytes or the getMessageAsXml functions.

Sending Group messages

You can send group messages using the MQSeries control putMessage function within a loop. The loop can be created using one of the following process nodes: While Do, Do while, and For Each.

Provide the GroupOptions element in the MQMDHeadersDocument. You only provide this element in the input MQMDHeaders XML document if a group message is to be sent.

In the MQMDHeaders document, set the IsLastMessage element within GroupOptions to False, for all messages except the last message. For the last message, the IsLastMessage element must be set to True.

If you specify a GroupID for the first message, then the MQSeries control assigns this ID to the group message. If you do not specify a GroupID for the first message, the MQSeries queue manager assigns a group ID to the first message. This ID is returned in the output MQMDHeaders document of the putMessage function.

The Group Id assigned to the first message must be used for all the subsequent messages of the group. The MessageSequenceNumber of the first message of the group should be 1; the MessageSequenceNumber of the second message should be 2, and so on.

Retrieving Group Messages

You can retrieve group Messages using the MQSeries control getMessage function within a loop. The loop can be created using one of the following process nodes: While Do, Do while, and For Each.

Setting the logicalorder Attribute

You can retrieve group messages using the MQSeries control in a logical order. To configure the MQSeries control to retrieve group messages in a logical order, set the logicalOrder attribute of the GroupMessage element to True.

You can retrieve messages in a logical order only when you use explicit transaction mode. The following figure depicts a sample workflow for retrieving group messages in logical order:

Example: Configuring SSL Within a Workflow

The loop executes until the IsLastMessage element within the GroupOptions element is set to True in the response MQMDHeaders document of the getMessage function.

Note: The GroupOptions element does not appear in the Get Response MQMDHeaders document if the retrieved message is not a part of a group.

The logicalOrder attribute must be set to True in each call of the Get service, to retrieve the messages of the group in their logical order (by message sequence number, beginning at one for the first message).

Changing the logicalOrder attribute from True to False while getting group messages, when its value was True in the previous Get service call, changes the logical ordering.

Setting the logicalOrder attribute to False or not providing this attribute in the Get request document means that the control gets the first message of the group as it appears on the queue irrespective of its message sequence number.

The following is an example of a Get Request MQMDHeaders document for retrieving group messages in logical order, and also waits for all messages in the group: 

<?xml version="1.0"?>
<even:MQMDHeaders xmlns:even="http://www.bea.com/wli/control/MQMDHeaders"> <even:GroupMessage waitForAllMsgs="true" logicalOrder="true"> 	<even:GroupId></even:GroupId>
</even:GroupMessage>
<even:MessageConsumption>Delete</even:MessageConsumption>
</even:MQMDHeaders>

Setting the waitForAllMsgs Attribute

You can configure the MQSeries control to wait for all messages of the group to be present in the queue before retrieving any message within the group. To configure the MQSeries control to wait for all messages, set the waitForAllMsgs attribute of the GroupMessage element to True.

Note: The waitForAllMsgs and the logicalOrder attribute are optional and can be set to either True or False.

You can set the waitForAllMsgs to True while retrieving the first message of the group. After you retrieve the first message in the group, you can set this attribute to True again, for retrieving the other messages of the group, provided that you have also set the logicalOrder attribute to True.

Setting the waitForAllMsgs attribute to False, or not providing this attribute in the Get Request document means that the control can still get group messages from the queue even when not all of the messages of the group are present in the queue.

Setting the GroupId element

GroupId is an optional element within the GroupMessage element. Its value may not be provided if the hexadecimal group ID of the group message is not known. When there are multiple group messages present in the queue, the first group message in the queue is retrieved. The GroupId value may be specified, if known. If specified and there are multiple group messages in the queue, the group message matching the group ID is retrieved.

Setting the MessageSequenceNumber Element

Group Messages can also be retrieved by specifying the MessageSequenceNumber element and the GroupId. Messages can be retrieved in this way only if the logicalOrder attribute value is False or is not provided. When the MessageSequenceNumber and the GroupId are provided, the message of the group matching the MessageSequenceNumber is retrieved. The group messages can still be retrieved in a loop by providing the GroupId and incrementing the MessageSequenceNumber by one in each Get function call in the loop, the MessageSequenceNumber of the first message being one.

Working with MQSeries Message Descriptor Format

Format is a message descriptor attribute. Messages of a particular Format conform to a specific structure which depends on the Format type. For example, CICS, IMS, MQRFH2, and so on. The structure for each built-in MQSeries Format is different and is defined by MQSeries. For more information on MQSeries Formats, see the online MQSeries documentation at the following URL:

http://www.ibm.com

Using the MQSeries control you can send messages that correspond to built-in MQSeries formats and user-defined formats. This can only be done using the putMessageAsBytes function.

To send a message that conforms to an MQSeries Format, you must add Java code to the process JPD file. This is shown in the following examples.

Example: Sending a message that conforms to the CICS Format (using the putMessage function)
  1. Declare a variable, for example, putin, in your application process JPD file, as follows:
    2. public com.bea.wli.control.mqmdHeaders.MQMDHeadersDocument putin;

    This variable represents the input MQMDHeaders document XMLBean variable for the putMessage function.

  2. Drag and drop the Perform node from the Palette into the business process, just below the Client Request node.
  3. Open the Perform node in the Source View and add the following code.
    4. public void perform() throws Exception
    {
    putin.getMQMDHeaders().setFormat(MQC.MQFMT_CICS);
    bytmsg = getCICSHeader();
    }
    public byte[] getCICSHeader() throws Exception    {
    ByteArrayOutputStream bstream = new ByteArrayOutputStream();
    DataOutputStream ostream = new DataOutputStream (bstream); ostream.writeChars("CIH "); // Struct id
    ostream.writeInt(1);      // Version 
    ostream.writeInt(164);    // StrucLength
    ostream.writeInt(273);    // Encoding 
    ostream.writeInt(819);    // CodedCharSetId
    ostream.writeChars("        "); // Format
    ostream.writeInt(0);      //Flags
    ostream.writeInt(0);      //ReturnCode
    ostream.writeInt(0);      //CompCode
    ostream.writeInt(0);      //Reason
    ostream.writeInt(273);    //UOWControl
    ostream.writeInt(-2);     //GetWaitInterval
    ostream.writeInt(1);      //LinkType
    ostream.writeInt(-1);     //OutputDataLength
    ostream.writeInt(0);      //FacilityKeepTime
    ostream.writeInt(0);      //ADSDescriptor
    ostream.writeInt(0);      //ConversationalTask
    ostream.writeInt(0);      //TaskEndStatus
    ostream.writeBytes("\0\0\0\0\0\0\0\0");   //Facility
    ostream.writeChars("    ");   //Function
    ostream.writeChars("    ");   //AbendCode
    ostream.writeChars("        ");   //Authenticator
    ostream.writeChars("        ");   //Reserved1
    ostream.writeChars("        ");   //ReplyToFormat
    ostream.writeChars("    ");  //RemoteSysId
    ostream.writeChars("    ");  //RemoteTransId
    ostream.writeChars("    ");  //TransactionId
    ostream.writeChars("    ");  //FacilityLike
    ostream.writeChars("    ");  //AttentionId
    ostream.writeChars("    ");  //StartCode
    ostream.writeChars("    ");  //CancelCode
    ostream.writeChars("    ");  //NextTransactionId
    ostream.writeChars("        "); //Reserved2
    ostream.writeChars("        ");  //Reserved3
    ostream.writeChars("HelloWorld");
    ostream.flush();
    byte[] bArr = bstream.toByteArray();
    return bArr;
    }

    This code sets the Format element in the input MQMD Headers document of the putMessage function to MQC.MQFMT_CICS, represented by the String "MQCICS".

    The getCICSHeader function writes the fields present in the CICS header to a byte array output stream and returns an array of bytes. The field values given in this example can be modified as required. The actual message can be appended to the end of this byte array and can be Put into the MQSeries queue. The byte array can be provided as the first parameter to the putMessageAsBytes function, which is added to the process JPD file after the Perform node. For more information on the putMessage function, see Sending and Receiving Messages.

Example: Sending a message that conforms to the IMS Format (using the putMessage function)
  1. Declare a variable, for example, putin, in the application process JPD file, as follows:
    2. public com.bea.wli.control.mqmdHeaders.MQMDHeadersDocument putin;

    This variable represents the input MQMDHeaders document XMLBean variable for the putMessage function.

  2. Drag and drop the Perform node from the Palette into the business process, just below the Client Request node.
  3. Open the Perform node in the Source View and add the following code.
    4. public void perform() throws Exception
    {
    putin.getMQMDHeaders().setFormat(MQC.MQFMT_IMS);
    bytmsg = getIMSHeader();
    }
    public byte[] getIMSHeader() throws Exception    {
    ByteArrayOutputStream bstream = new ByteArrayOutputStream();
    DataOutputStream ostream = new DataOutputStream (bstream);
    ostream.writeBytes("IIH "); // Struct id
    ostream.writeInt(1);      // Version 
    ostream.writeInt(84);     // Length
    ostream.writeInt(0);      // Encoding
    ostream.writeInt(0);      // CodedCharacterSet
    ostream.writeBytes("        "); // Format (8 characters)
    ostream.writeInt(0);      // Flags
    ostream.writeBytes("        "); // LTermOverride
    ostream.writeBytes("        "); // MFSMapName
    ostream.writeBytes("        "); // ReplyToFormat
    ostream.writeBytes("        "); // Authenticator
    ostream.writeBytes("\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0");  // TransInstanceId
    ostream.writeBytes(" ");  //Transtate
    ostream.writeBytes("1");  // CommitMode
    ostream.writeBytes("F");  // Security Scope
    ostream.writeBytes(" ");  // Resrved 
    ostream.writeChars("HelloWorld");
    ostream.flush();
    byte[] bArr = bstream.toByteArray();
    return bArr;
    }

    The previous lines of code set the Format element in the input MQMD Headers document of the putMessage function to MQC.MQFMT_IMS, represented by the String "MQIMS ".

    The getIMSHeader function writes the fields present in the IMS header structure to a byte array output stream and returns an array of bytes. The values of the fields given in this example can be modified as required. The actual message can be appended to the end of the byte array and can be Put into the MQSeries queue. The byte array can be provided as the first parameter to the putMessageAsBytes function, which is added to the process JPD file after the Perform node. For more information on the putMessage function, see Sending and Receiving Messages.

Example: Sending a message that conforms to the MQRFH2 Format (using the putMessage function)
  1. Declare a variable, for example, putin, in the JPD file of your process project in the application, as follows:
    2. public com.bea.wli.control.mqmdHeaders.MQMDHeadersDocument putin;

    This variable represents the input MQMDHeaders document XMLBean variable for the putMessage function.

  2. Drag and drop the Perform node from the Palette into the business process, just below the Client Request node.
  3. Open the Perform node in the Source View and add the following code.
    4. public void perform() throws Exception
    {
    putin.getMQMDHeaders().setFormat(MQC.MQFMT_RF_HEADER_2);
    bytmsg = getMQRFH2Header();
    }
    public byte[] getMQRFH2Header() throws Exception    { ByteArrayOutputStream bstream = new ByteArrayOutputStream(); DataOutputStream ostream = new DataOutputStream (bstream);
    String strVariableData = "<mcd><Msd>jms_text</Msd></mcd><jms><Dst>someplace</Dst></jms>";
    int iStrucLength = MQC.MQRFH_STRUC_LENGTH_FIXED_2 + strVariableData.getBytes().length;
    			while(iStrucLength % 4 != 0)
    {
    strVariableData  = strVariableData  + " ";
    iStrucLength = MQC.MQRFH_STRUC_LENGTH_FIXED_2 + strVariableData.getBytes().length;
    }
    ostream.writeChars(MQC.MQRFH_STRUC_ID);//StrucID ostream.writeInt(MQC.MQRFH_VERSION_2);//Version ostream.writeInt(iStrucLength );//StrucLength ostream.writeInt(273);//Encoding ostream.writeInt(1208);//CodedCharSetID ostream.writeChars(MQSTR);//Format ostream.writeInt(MQC.MQRFH_NO_FLAGS);//Flags ostream.writeInt(1208);//NameValueCCSID ostream.writeInt(strVariableData.getBytes().length);//NameValueLength ostream.writeChars(strVariableData ); //NameValueData ostream.writeChars("HelloWorld");
    ostream.flush();
    byte[] bArr = bstream.toByteArray();
    return bArr;
    }

    The previous code sets the Format element in the input MQMD Headers document of the putMessage function to MQC.MQFMT_RF_HEADER_2,represented by the String "MQHRF2 ".

    The getMQRFH2Header function writes the fields present in the MQRFH2 header structure to a byte array output stream and returns an array of bytes. The values of the fields given in this example can be modified as required. The actual message can be appended to the end of the byte array and can be Put into the MQSeries queue. The byte array can be provided as the first parameter to the putMessageAsBytes function, which is added to the process JPD file after the Perform node. For more information on the putMessage function, see Sending and Receiving Messages.

Setting Dynamic Properties

You can change the MQSeries control properties dynamically at runtime. The MQSeries control properties that you can modify are specified in the MQDynamicProperties document. This document conforms to the MQDynamicProperties schema which is available in the MQSchemas.jar file.

To change properties dynamically, perform the following tasks

  1. Open the Client Request node. In the General Settings tab, add a variable of type MQDynamicProperties document.
  2. In the Receive Data tab, create a new variable for the parameter that you created in the General Settings tab of the Client Request node by entering a name for the variable. The variable type is already pre-defined based on the parameter to which you are assigning the variable.
  3. Drag and drop the setDynamicProperties function from the Controls tab of the Data Palette, into your business process.
  4. Open the Send Data tab of the setDynamicProperties function node. From the Select variables to assign drop-down list, assign the variable that you created in the Receive Data tab of the Client Request node to the corresponding parameter of the setDynamicProperties function listed in the Control Expects column. All MQSeries Get and Put operations following the setDynamicProperties function in the business process use the properties that you specify in the MQDynamicProperties document.
  5. While executing your business process at runtime, provide the MQDynamicProperties document as input.
Caution: When you use Explicit Transaction mode, always call the setDynamicProperties function before the Begin function or after the Commit or the Rollback functions. If this sequence is not followed, the business process will throw an exception at runtime.

Schema of MQDynamicProperties 

<?xml version="1.0"?>
<xs:schema xmlns="http://www.bea.com/wli/control/MQDynamicProperties" xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.bea.com/wli/control/MQDynamicProperties" elementFormDefault="qualified" attributeFormDefault="unqualified">	<xs:element name="MQDynamicProperties">
<xs:complexType>
<xs:sequence>
<xs:element name="connectionType" type="connType" minOccurs="0" maxOccurs="1"/>
<xs:element name="queueManager" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="requireAuthorization" type="authType" minOccurs="0" maxOccurs="1"/>
<xs:element name="host" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="port" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="channel" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="ccsid" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="user" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="password" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="sendExit" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="receiveExit" type="xs:string" minOccurs="0" maxOccurs="1"/>
<xs:element name="securityExit" type="xs:string" minOccurs="0"
maxOccurs="1"/>
<xs:element name="defaultQueueName" type="xs:string" minOccurs="0"
maxOccurs="1"/>
<xs:element name="implicitTransactionRequired" type="transType"
minOccurs="0" maxOccurs="1"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:simpleType name="connType">
<xs:restriction base="xs:string">
<xs:enumeration value="Bindings"></xs:enumeration>
<xs:enumeration value="TCP"></xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="authType">
<xs:restriction base="xs:string">
<xs:enumeration value="Yes"></xs:enumeration>
<xs:enumeration value="No"></xs:enumeration>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="transType">
<xs:restriction base="xs:string">
<xs:enumeration value="true"></xs:enumeration>
<xs:enumeration value="false"></xs:enumeration>
</xs:restriction>
</xs:simpleType>	
</xs:schema>

Sample MQDynamicProperties Document

The following is a sample MQDynamicProperties document. You must provide this document at runtime when you execute your business process: 

<?xml version="1.0"?>
<even:MQDynamicProperties
xmlns:even="http://www.bea.com/wli/control/MQDynamicProperties">
<even:connectionType>TCP</even:connectionType>
<even:queueManager>newqm</even:queueManager>
<even:requireAuthorization>Yes</even:requireAuthorization>
<even:host>localhost</even:host>
<even:port>1869</even:port>
<even:channel>chn</even:channel>
<even:ccsid>437</even:ccsid>
<even:user>WebLogic</even:user>
<even:password>WebLogic</even:password>
<even:defaultQueueName>errqueue</even:defaultQueueName>
</even:MQDynamicProperties>

Configuring SSL In MQSeries Control

SSL functionality is available only if you selected TCP Connection mode while configuring an MQSeries control. For more information on configuration options for the MQSeries control, see Creating and Configuring a New Instance of the MQSeries Control.

This topic includes the following sections:

Setting the SSL Cipher Suite

Setting Server-side SSL Properties

Setting Client-side SSL Properties

Example: Configuring SSL Within a Workflow

Setting the SSL Cipher Suite

The cipher suite algorithm is used to encrypt and decrypt message communication between the MQSeries server and the MQSeries client. If you selected either of the two SSL options while creating a new MQSeries control, you must set the SSL cipher suite before you put or get messages from the queue. This can be done using the following function:

void setSSLCipherSuite(java.lang.String cipherSuite);

The parameter to this function is the string representing the selected SSL cipher suite. You can get the different values for the cipher suites from the final static variables of the MQControlConstants class.

Setting Server-side SSL Properties

After enabling either of the SSL options for your MQSeries control, you must set server-side SSL properties before you put or get messages from the queue. You can do this using the following function:

void setServerSideSSL(java.lang.String trustStoreLocation, java.lang.String trustStoreType, java.lang.String trustStorePassword) throws com.bea.control.ControlException;

The parameters to this function are:

Setting Client-side SSL Properties

After enabling two-way SSL for your MQSeries control, you must set server-side and client-side SSL properties before you put or get messages from the queue. To set the client-side SSL properties, use the following function:

void setClientSideSSL(java.lang.String keyStoreLocation, java.lang.String keyStoreType, java.lang.String keyStorePassword, java.lang.String keyPassword);

The parameters to this function are:

Example: Configuring SSL Within a Workflow

After selecting either of the two SSL options while creating a new MQSeries control, your workflow must adhere to the order of MQSeries control function calls represented in the following figure.

Figure 10-1 Example: Configuring SSL Within a Workflow

Example: Configuring SSL Within a Workflow

WARNING: If the sequence represented in Figure 10-1 is not followed in the workflow when SSL authentication is required, the MQSeries Control will throw an exception at runtime.

For information on how to set up the Queue Manager for SSL connections, refer to the MQSeries Product documentation at http://www.IBM.com. SSL support is available only from WebSphere MQ version 5.3 onwards.

Migrating an MQSeries Control 8.1 SP3 JCX File

When you migrate a workflow containing the MQSeries control version 8.1 SP3 to a workflow containing the MQSeries control version 8.1 SP4, you must make the following changes to your workshop application:

Using the MQSeries Event Generator

The MQSeries event generator polls the MQSeries queue for messages and publishes them to WebLogic Message Broker channels. The MQSeries event generator supports three different data types — Bytes, String, and XML.

You can configure event generator channels for different data types using a Message Broker channel name, which instructs that any message coming into the specified MQSeries queue will be published to that message broker channel.

Similar to the MQSeries control, the MQSeries event generator also provides two modes of connections — TCP-IP and Bindings. You can also implement content-filters to filter messages based on the specific content that you want. By doing this, you can ensure that you generate events only for the messages that you require.

The MQSeries event generator can also spawn multiple threads of events. Each thread can separately poll the MQSeries queue. You can configure the number of messages to be picked by the event generator thread in each poll.

To learn more, see Using Integration Event Generators.


  Back to Top       Previous  Next