The patch notes contain the following sections:
Following are new and revised features of the 1.4.1 version of the connector for MQSeries:
|
Available as of Connector Version |
Feature | Description |
| 1.4.1 | Enables the user to configure how the feedback code of a response message is interpreted by the MQSeries connector. | Currently the mapping between feedback codes and CrossWorlds status values is hard-coded such that some MQSeries feedback value 'x' always corresponds to SUCCESS, some value 'y' corresponds to FAIL, etc. This enhancement allows the user to customize how feedback codes are mapped to CrossWorlds status values. |
| 1.4.1 | Support for Binary response messages | An enhancement to a previous version of the Connector for MQSeries provided support for binary messages. The connector will now issue binary response messages for any request messages that the connector is configured to process as binary. |
This patch contains fixes for the following CRs based on customer-reported cases.
| CR Number | As of Version | Problem |
|---|---|---|
| 11581 | 1.4.1 | Support for customizable feedback code mappings |
| 12248 | 1.4.1 | Support for binary response messages |
| 12679 | 1.4.1 | Support for MQFB_NONE in the feedback code mappings |
To perform an upgrade to this version of the connector:
Add, replace, or remove the following files and directories as indicated:
| For Connector Version | Platform [WIN; UNIX] | Add / Replace / Remove | File (Starting from %CROSSWORLDS%/$CROSSWORLDS) |
| 1.4.1 | WIN;UNIX | Replace | CWMQSeries.jar |
| 1.4.1 | WIN;UNIX | Replace | CWJMSCommon.jar |
Add or remove the following connector properties using CSM:
| For Connector Version | Platform | Add / Remove | Property (Case-Sensitive) |
| 1.4.1 | WIN;UNIX | none |
CR11581
To support customizable interpretation of feedback codes, the connector now supports configuration property "FeedbackCodeMappingMO". Specification of this property is completely optional and existing implementations of the connector, which do not specify a value for this property, will not be impacted by the enhancement.
If a user wants to override the default interpretation of feedback codes, he must create a new meta-object (MO) in which attribute names specify the MQSeries feedback constant to be recognized and default attribute values specify the CrossWorlds return status value to be passed up to the ICS. In this manner, the user can map specific feedback codes to CrossWorlds-specific return status values. Once the MO is created, the user must specify the name of this MO in connector configuration property "FeedbackCodeMappingMO".
In the MO, the connector recognizes the following attribute names corresponding to MQSeries feedback codes: MQFB_PAN, MQFB_NAN, MQFB_APPL_FIRST and MQFB_APPL_FIRST_OFFSET_X where X is an integer (interpreted as the value of "MQFB_APPL_FIRST + X").
In the MO, the connector recognizes the following attribute values corresponding to CrossWorlds-specific status codes: SUCCESS, FAIL, VALDUPES, APP_RESPONSE_TIMEOUT, BO_DOES_NOT_EXIST, MULTIPLE_HITS, RETRIEVE_BY_CONTENT_FAILED, UNABLE_TO_LOGIN, VALCHANGE, and VALDUPES.
Figure 1 Sample Feedback MO
| Attribute Name | Default Attribute Value |
| MQFB_APPL_FIRST | SUCCESS |
| MQFB_APPL_FIRST_OFFSET_1 | FAIL |
| MQFB_PAN | VALCHANGE |
If you created a MO like that shown in Figure 1 and specified it for property "FeedbackCodeMappingMO", the connector behavior would be as follows:
If the connector received a response message with a feedback code of MQFB_APPL_FIRST (currently 65536), the connector would return SUCCESS to the ICS. If instead, the connector received a response with a feedback code of MQFB_APPL_FIRST+1 (currently 65537), the connector would return FAIL to the ICS. Finally, if the connector received a response message with a feedback code of MQFB_PAN, the connector would return VALCHANGE to the ICS. Furthermore, unless a given feedback code is explicitly overridden by specifying it in the MO, the connector will interpret the value using the default mappings.
CR12248
Previously, the MQSeries connector always converted all message bodies to text and invoked only methods getStringFromBO and getBO( String text ... ) of the configured DataHandler instance. With CR9731, the connector could be configured to convert binary data to a business object and vice-versa directly through the DataHandler methods getStreamFromBO and getBO( InputStream stream ...) without any intermediate conversion to text. However, this functionality was only added for request messages--either those picked up during event retrieval or those posted during request processing. CR12258 adds identical behavior for response message handling.
If the customer intends to send binary messages, he can configure it using the configuration property 'DataEncoding'. This property can be specified in the static meta-object on a per BO/Verb combination, or in the dynamic meta-object on a per-BO basis. If the property is set in both the static and dynamic MO, the dynamic MO value will take the precedence.
The following example indicates how a static MO might look if a customer wanted to send business object 'Customer' as binary messages.
Figure 1. Static MO Example
| Attribute Name | App-Text Value |
| Customer_Create | InputFormat=CUSTOMER; DataEncoding=Binary; |
For more information on the format of the static MO, see the MQSeries connector documentation.
If the customer intends to configure the encoding on per business object basis he should specify the 'DataEncoding' property in the dynamic MO.
Figure 2. Dynamic MO Example
| Attribute Name | Attribute Value |
| DataEncoding | Binary |
For more information on the format of the dynamic MO, see the MQSeries connector documentation.
CR12679
With CR11581, users gained the ability to customize how the MQSeries connector mapped MQSeries feedback codes to CrossWorlds return constants. One limitation is that the connector can only map feedback constants if the "Feedback" property is specified in the response message. We've added MQFB_NONE to the list of recognized feedback codes the connector recognizes as attribute names in the feedback MO.
For example, if the user adds attribute name "MQFB_NONE" to the MO and specifies a default value of "VALCHANGE", the connector will report VALCHANGE to the ICS every time it receives a response message that has no MQSeries feedback code specified.
January 17, 2002 06:32 PM
© 2001 CrossWorlds Software, Inc. Proprietary and Confidential. All Rights Reserved.