Description:
TIBCO BusinessConnect EDI Protocol 5.2.0 hotfix 4 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/EDI/5.2.0/hotfix-04/

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

======================================================================
Closed Issues in 5.2.0-hotfix4 (This Release)

CR:1-8KLODH

When receiving synchronous requests from a Trading Partner, there are intermediate
processing files with extension xdata.map are left in the sub-directories of the
location pointed by shared location in the deployment. This problem over time
causes a lot of accumulation of files and degrades performance. This is fixed.

CR:1-8KLOGH

When a synchronous response is not sent out, the socket does not timeout in the time
specified in the configuration. This issue is fixed with properly sending a
hibernation alert to DMZ and audit logging as an ERROR CONFIGURATION. For this to
work, users must make the hibernation interval in the System Settings-&gtBusinessConnect Server
to less than a minute in the configuration GUI. Currently the default is 75 seconds
(Entry is bc.hibernation.pollingInterval).

CR:1-8KLOHH

The following performance issue is addressed only when Inbound large file is
processed along with synchronous transactions. When processing large files on inbound,
the synchronous transaction response time gets slower and ultimately starts timing
out. This issue is resolved.

CR:1-8KLOBW

When a synchronous requests fails in validation and the ISA14 value is not
requesting for an rejecting acknowledgement, but the Ack creation for ISA14 field
is set to disable, the HTTP socket in the DMZ does not get closed. This causes a lot
of open connections to be left out. This is fixed with sending a 502 error along
with the failure report.

CR:1-8KLO9P

When a synchronous response is sent after a engine failure and restart, the response
job waits after the timeout. The sync response should have timed out immediately.
This is fixed.

CR:1-8KVDKM

When large batches are trying to go out with multiple engines and if the collated
batch is picked up by another engine that is not the same engine that collated, then
there is an exception thrown since the file is created in local temporary location
rather than shared temporary location.

======================================================================
Closed Issues in 5.2.0-hotfix3 (This Release)

1-8GARYL

When receiving EDI messages which contain multiple groups with multiple
transactions in each group, the audit log for each transaction is inconsistent
and gets combined with other transactions. This issue is fixed. Each transaction
would have its own summary row.

1-8GRLTP

This issue is caused when Allow all operations is disabled and proper operation
bindings exist in the BusinessAgreement. This is only for EDI-X12 protocol.
When receiving a synchronous transaction from the Trading Partner, if the incoming
synchronous request fails because of txn validation, then instead of sending the
Transaction level Acknowledgement (997) as the synchronous response, a TA1 interchange
level acknowledgement was sent. This issue is fixed.

1-8EZ6K4

When receiving a message through Inbound FILE poller from the Trading Partner,
earlier version (EDI 2.8.0) had put the actual file name in the audit log
description. This was not available for users in EDI 5.2.0. This problem
has been fixed and users can see the actual source file name in the audit log.

1-8CJ9L1

When receiving a synchronous request from a Trading Partner, if the Trading
Partner has been configured to batch based on the BusinessAgreement, then
the synchronous response was getting generated with improper control numbers
and the audit logs show the control numbers as batch. This has been fixed.
The fix is to disregard the scheduled transmission for synchronous request
and response as well as fixing the audit logs to show the appropriate control
numbers.

1-8F7SW3

Audit logs for synchronous responses had the operation ID same as the
synchronous request, except that the hostInitiates was set to true. This
causes problem for users who would not be able to differentiate between
a synchronous request going out versus a synchronous response sent to the
Partner. This has been fixed. The fix is to put the correct synchronous
response operation ID so that it is searchable as well.

======================================================================
Closed Issues in 5.2.0-hotfix2 (This Release)

1-8A77XQ

When a EDI document is received from a Trading Partner and is configured to
send a Business level Acknowledgement through a EDI-Gateway Participant,
BusinessConnect EDI protocol sends the outbound Business Acknowledgement
document generated via EDI-X12 or EDI-EDIFACT Trading partner without the
honoring the packaging conditions configured under EDI-Gateway. This problem
occurs only when the primary transport for the EDI-X12 or EDI-EDIFACT Participant
is of a different type than the EDI-Gateway Participant. This problem is fixed.

1-88QJFP

When receiving a large EDI document with multiple interchanges from the Trading
Partner, BusinessConnect EDI Protocol would coredump when processing a smaller
interchange if the previous interchange is a large interchange and has been processed
on a memory-saving mode and that large interchange size is greater than the threshold
set in the "Host Participant->&ltProtocol>-&gtAdvanced-&gtThreshold to enable Memory-saving
mode During EDI to XML Conversion" option. This problem is fixed.

======================================================================
Closed Issues in 5.2.0-hotfix1 (This Release)

1-70IDUF

If the Business Acknowledgements are exclusively batched, the
Acknowledgements was not getting added to the resend queue. This issue is
fixed and is possible only if the Acknowledgements are exclusively
batched. A Miscellaneous Message "TransactionAckToTradingPartner" is published
on the private process transport to indicate that the Batch has been
scheduled.

If the Acknowledgements are batched with no exclusive batching,
then the transactions can be with some regular transactions and
for this scenario the user has to go to EDI-Gateway REQUEST_FOR_BATCH
to resend that batch.

1-7YUIYG
When receiving a response through EDI-Gateway, the response cannot
be captured by Receive Response Activity since the operation was
reported as EDI/Outbound/Interchange. This is fixed. Users can now
receive response for the message that was sent out since the operation
is reported as EDI/&ltProtocol> where Protocol can be X12, EDIFACT or TEXT.

1-81BHVI
When using JMS as private process transport, Resend for REQUEST_FOR_BATCH
state under EDI-Gateway did not return any record when searching.
This issue is fixed.

Users can also see the Raw EDI Logging location in the Audit Description
when it is enabled in the Outbound Participant settings.

1-831YFS
BusinessConnect after receiving the MDN for the outbound or
Acknowledgement EDI Transaction initiated, marks the transaction
status as "Pending" even though the state is displayed as
"RECEIPT_VERIFIED" when synchronous receipt is requested. This is fixed.

1-830MB7
When sending Outbound Transactions routed via a Gateway Participant
with no batching, the Outbound Transactions never gets reconciled.
This is fixed.

1-82YGYR
When sending an XML from BW Palette, if there is an outbound
validation error, the response activity throws an error in the
Palette and cannot continue. This is fixed.

1-7YTUXN
When Outbound transactions are sent out with ack expected option as "None",
the Audit Log in BusinessConnect EDI Protocol does not go to COMPLETED status.
This is fixed.