TIBCO(R) Order Management - Long Running 5.0.1 HF-008 is now available

This hotfix can be downloaded from the TIBCO Support Web User Interface using your username and password for the TIBCO Support Web. Once logged in, you can find the hotfix under the Downloads Menu: "AvailableDownloads/ActiveFulfillment/5.0.1/LR-Hotfix008"

Files available for download: 

- TIB_om-lr_5.0.1_HF-008_readme.txt
- TIB_om-lr_5.0.1.md5
- TIB_om-lr_5.0.1-HF8.zip

Please take a look at the Readme file for the instructions on how to apply the hotfix.

================================================================================
Closed Issues in 5.0.1_HF-008 (This Release)

AF-20694
Duplicate plan items are created after an amendment.

AF-20662
On submitting an amendment, the acknowledgement is not logged.

AF-20607
In TIBCO Order Management version 5.0.1 HF-7, when a machine with multiple 
members crashes, the orders might get incorrectly balanced across backups.

AF-20462
In TIBCO Order Management version 5.0.1 HF6, the Orchestrator logs might 
incorrectly link values from different orders in "planItemExecuteRequest" 
entries.

AF-20414/AF-20347
After upgrading to TIBCO Order Management version 5.0.1 HF-7, amendments are 
withdrawn, and orders become stuck.

Note: If "CompensateRestartForNoEPMRChar" is enabled but the compensation action
is not defined, an "UNEXPECTED_ERROR" occurs after amendment.

AF-20373
When multiple order lines have the same product IDs, the "evaluationPriority" of
a shared variable is incorrect.

AF-19407
When the orchestrator restarts after a database switch, orders remain assigned 
to the last active cluster member.

Note:

1. Order Backup Behavior During Member Failover
       When Cluster Manager identifies a failed Orchestrator member through heartbeat 
       monitoring, a backup node is assigned to manage the workload of the affected 
       member.
       For example, if Member6 is identified as failed, Member2 is assigned as the 
       backup node and processes all orders that were previously managed by Member6.
       
       Ensure that you do not restart the failed member until the backup node 
       completes the backup process.
       
       To confirm backup completion, check either the Admin database or backup member logs.
       
       To confirm backup completion by checking the Admin database, perform the 
       following steps:
       1. Navigate to the "DOMAINMEMBERS" table in the Admin database.
       2. Locate the row for the failed member.
       3. Inspect the column "BACKUP_MEMBERID".
          If the "BACKUP_MEMBERID" column for the failed member shows a value (Member2), 
          the backup is in progress. 
          When the column is empty, the backup is complete.
          
       To confirm backup completion by checking the backup member logs, 
       perform the following steps:
       1. Monitor the logs of the assigned backup node.
       2. In the backup node logs, the start and successful completion of the 
          backup process can be confirmed in the following sequence of log entries:
          [ThreadID:340] [Tenant ID:TIBCO] ========== [ START: Backup Process ] ==========
          [ThreadID:340] [Tenant ID:TIBCO] This node with ID [Member2] received message to backup the failed node with ID [Member6].
          [ThreadID:340] [Tenant ID:TIBCO] Initiated processing backup by backup node [Member2] for failed node [Member6]
          [ThreadID:340] [Tenant ID:TIBCO] ========== [ END: Backup Process - COMPLETED ]
       
       Even after the backup completes, Orchestrator continues to process in-flight
       southbound messages for the failed member for up to two minutes, assigning
       them to the backup node to ensure recovery while maintaining order consistency.
       
2. Enabling Static Member Assignment in ORCH-DOMAIN
       To ensure predictable behavior and controlled member allocation in "ORCH-DOMAIN", 
       enable "static member assignment" for all Orchestrator nodes.
       
       As best practice, perform the following steps:
       1. In the Admin database, navigate to the "DOMAINMEMBERS" table.
       2. Locate each entry corresponding to a member in the "ORCH-DOMAIN."
       2. If not already configured, set the value of the "IS_STATIC" column to 
          "1" for each member.
          
       This configuration  enables static assignment, ensuring that each 
       Orchestrator instance retains a consistent identity across restarts and 
       deployments, which is essential for order ownership, backup, and failover.
       
       For more information on static assignment and how it impacts node discovery 
       and orchestration behavior, see the "Static Assignment" section in the 
       TIBCO® Order Management – Long Running Administration Guide.

================================================================================

TIBCO(R) Order Management - Long Running 5.0.1 HF-008 is now available