book
Article ID: KB0102793
calendar_today
Updated On:
Description
Description:
The hotfix can be downloaded from the TIBCO Support ftp server, mft.tibco.com. Please use your eSupport username and password to access the server. After connecting, go to /AvailableDownloads/ActiveFulfillment/2.0.1/hotfix-06/ to download the hotfix.
HF6 md5: 3e6cec59c7fc1e6ad88d56eae3799a55 TIB_af_2.0.1_HF-006.zip
Instructions on how to apply the hotfix are provided in the TIB_af_2.0.1_HF-006_readme.txt file.
================================================================================
Closed Issues in 2.0.1_HF-006 (This Release)
AF-5314
Random circular dependencies between milestones were observed for some orders,
which resulted in incorrect execution plans. The issue has been fixed.
AF-5276
The JMS message for amendment plan, sent by BE Orchestrator, was processed by OMS
in a different way. The amendment plan message was lost from
"tibco.aff.orchestrator.plan.oms.set" queue if an exception was thrown during the
original attempt of OrderAmendmentNotification processing
(possibly due to DB deadlock). During the subsequent retries, OMS did not get the
amendment plan and threw an exception
"com.tibco.aff.oms.server.domain.exception.DataException : No amended plan for
order {} was received". The amendment plan message was lost since the
corresponding camel listener wasn't transacted. The issue was fixed and the JMS
message will now be processed during the processing of OrderAmendmentNotification
message during the status change from AMENDING to COMPLETE.
AF-5136
The TDS migration script, that helps migration to Fulfillment Order Management
2.0.1, was running very slowly. The issue was fixed.
AF-4103
FOM 2.0.1 was not resilient to network glitches due to an older version of
TIBCO BusinessEvents. The issue was fixed by upgrading to TIBCO
BusinessEvents 5.1.4. The users now have the ability to change new parameters
using following values:
- AS_MEMBER_TIMEOUT("be.engine.cluster.as.member.timeout")
The MEMBER_TIMEOUT parameter specifies how many milliseconds ActiveSpaces
waits for a member to reconnect if it loses connection to the metaspace. The
default value is 30 milliseconds.
EXAMPLE: <property name="be.engine.cluster.as.member.timeout" value="300000"/>
- AS_CLUSTER_SUSPEND_THRESHOLD("be.engine.cluster.as.suspend.threshold")
The CLUSTER_SUSPEND_THRESHOLD parameter specifies the number of host connections
that can be lost before the cluster goes into a suspended state. If connectivity
is lost for a seeder member of a space, doing a read or write for that space
might cause a protocol timeout. The default value is -1.
NOTE: Never suspend membership operations.
EXAMPLE: <property name="be.engine.cluster.as.suspend.threshold" value="-1"/>
Issue/Introduction
TIBCO FOM 2.0.1 Hotfix06 is available