Description:
TIBCO BusinessConnect ebXML Protocol 6.0.1 hotfix 2 has been released.

You can download this Hot Fix from the TIBCO Product Support FTP server using your eSupport username and password, at

           ftp://support-ftp.tibco.com

Once you have successfully logged into the server, you will find the hotfix packages under

           available_downloads/ActiveExchange/ebXML/6.0.1/hotfix-02/

Listed below is a summary of updates included. Please refer to the associated readme document for any additional information.

Closed Issues in 6.0.1_HF-002 (This Release)

CR: EBMS-1161

For ebMS3 protocol, the resend functionality is disabled for "PUSH_MESSAGE_FROM_PP"
state if there is no "body" field populated in the received INITIATOR.REQUEST message.

This has been fixed.

CR: EBMS-1163

For ebMS2 synchronized response, if the response message contains a &ltSyncReply>
element which indicates the initiator to send back a reply in synchronized mode,
this was considered to be conflicting with the standard; our consistency
checking on initiator side rejects this response; however this makes one of
the customer not able to process the response.

This consistency check is relaxed by introducing a system property:

ebxml.syncresponse.syncreply.check.relaxed

When this property is set to true, this consistency check will not take effect
on initiator side when receiving a synchronized response.

To turn on this feature, complete the following steps to add this property and
set it to "true":
   - In TIBCO Administrator, choose BusinessConnect > System Settings >
     Activated Protocol Plug-ins and Properties > ebXML > Add
   - Input "ebxml.syncresponse.syncreply.check.relaxed" for "Property Name",
     choose "boolean" for "Property Type", and click "Save".
   - Select the check box labeled as "ebxml.syncresponse.syncreply.check.relaxed",
     click "Save" and click "Done".

   Note: The default value of this property is "false" if not configured.

CR: EBMS-1170

For ebMS3 protocol, when an inbound pull request explicitly uses the default
MPC name ("http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC")
to pull from the default MPC channel, it will be rejected even though there
are messages available in the default MPC channel.

This has been fixed.

CR: EBMS-1172

For ebMS3 protocol, if synchronized receipt is expected for an outbound push
message however there is no content in HTTP response, no error is generated
and reported.

This has been fixed.

CR: EBMS-1182

For ebMS3 protocol synchronized receipt mode, if the receipt relevant to an
outbound request is not received, the outbound request retries are executed
however the retry intervals don't honor the "Time to Wait for MSH Receipt"
property configured for this transaction.

There are two scenarios for this issue. The first is the outbound HTTP connection
is not established successfully, in which case the HTTP connection retries would
occur first, then after all the HTTP connection retries are exhausted the ebMS3
retries would occur immediately, not honoring the "Time to Wait for MSH Receipt";

This has been fixed so that the ebMS3 retry intervals will follow the "Time
to Wait for MSH Receipt"; However since the HTTP connection retries will still
be conducted (this cannot be changed even the ebMS3 retries are set), in order
to avoid the interfering between the HTTP retries and the ebMS3 retries, the
best practice is to set the ebMS3 "Time to Wait for MSH Receipt" longer than
the multiplication of HTTP "Retry Interval" by "Retry Count".

The second scenario is the outbound HTTP connection is established and the
request message has been sent out, but the receipt is not received within the
"Socket Timeout" (configured in HTTP transport), or due to any error occurring
on the receiver side. In this case there will not be any HTTP connection retries,
however the ebMS3 retries would occur immediately after the "Socket Timeout" or
the server error is detected, not honoring the "Time to Wait for MSH Receipt";

This is also fixed so the ebMS3 retry intervals will follow the "Time to Wait
for MSH Receipt" settings. To avoid the interfering of the HTTP socket timeout
error or the HTTP server error to the resend action, it is recommended that
the "Time to Wait for MSH Receipt" is set a little longer than the "Socket
Timeout".