Description:
TIBCO BusinessConnect RosettaNet Protocol 5.1.0 hot fix 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/RosettaNet/5.1.0/hotfix-2/


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

Closed Issues in 5.1.0-hotfix2 (This Release)

1-7AJAXQ
When the "Use Digital Signature Where Required" property is used and
Non-Repudiation in the PIP definition is disabled, outbound PIPs would
fail at the trading partner because the digital signature is not
added with this configuration. This behavior is different from that in
the previous software version.

To revert to behavior similar to the previous version, the issue has
been fixed such that, if the "Non Repudiation Logging" property is
enabled in the Business Agreement and "Use Digital Signature Where
Required" per TP level is enabled, the digital signature will be
added into the outbound message.

1-7AGSVV
Backslash characters in inbound RosettaNet documents were causing PIP
failures. Now, if the new "bcrn.support.malformed.schemaLocationURI"
plug-in property is enabled, the software supports backslash
characters in both inbound and outbound RosettaNet documents.

To enable the "bcrn.support.malformed.schemaLocationURI," property,
navigate to this location in the BusinessConnect console:

System Settings&gtInstalled Protocol&gtRosettaNet>
                              bcrn.support.malformed.schemaLocationURI

1-7AH2HB
When the RNIF version was missing from the private process message,
the software used the default RNIF version of 1.1. A new property
in the operation bindings for the PIP definition, "Override Default
RNIFVersion," resolves this issue. To configure the new property,
navigate to the following location in the BusinessConnect console:

Operations Editor&gtPIP Definition&gtBusiness Agreement>
                                   Protocol Binding&gtOperation Binding

The software uses the value stored in this property to override the
RNIFVersion sent from the Private Process. The software uses this
logic to determine the RNIFVersion:

1. If the operation-binding was overridden, use the default
RNIFVersion unless that value is "Both," in which case continue to 2.

2. If the RNIFVersion from the private process has a valid value,
use it. If it is invalid, continue to 3.

3. Use the version defined in the PIP definition. if this value is
"Both", use "1.1" for the RNIFVersion.

1-7A0TKW
There was no explanation in the audit log for PIP termination when the
PIP was terminated due to expired certificates. This is fixed.

1-78KHV4
An incorrect DOCTYPE schema identity was used in the public
message. This caused invalid message at the Trading Partner side.
This is fixed.

1-793NFX
Proprietary Document ID was not populated correctly on Auditing.
This is fixed.

1-7A44V9
BusinessConnect, after receiving outbound Transactions from the private
process, tried to perform the "Best Match" process among the available
PIP Versions. During this process, if the versions were similar (a
difference in minor versions), BusinessConnect failed to process the
transaction and returned a "NOT-MATCHED-TRANSACTION" error.
This is fixed.

======================================================================
Closed Issues in 5.1.0-hotfix1

1-768G70
When an incoming message contained invalid data and the private process
had an invalid value such as rnifVersion, DUNS, the software's audit
trail didn't save the message; it returned a null pointer exception.
This has been fixed.

1-77DOH3
When the RECEIPT contained wrong data, the message was not saved in the RECEIVED_TP_RECEIPT state. It went to the PIP_TERMINATED state. This is
fixed and the RECEIPT is being saved into Audit.

1-77DOHO
When DUNS is blank in INITIATOR.REQUEST, a nullpointer exception occurs
and is logged in the Audit. This is fixed; a proper error message is
written to the Audit log.