IBM Support

V4.0.3 Release Information for Financial Transaction Manager for Red Hat OpenShift

Fix Readme


Abstract

This document contains release information for Financial Transaction Manager for Red Hat OpenShift 4.0.3.

Content

Financial Transaction Manager for Red Hat OpenShift 4.0.3 Release Information
 

 
 

Contents

  

When you upgrade a fix pack or interim fix (iFix), in addition to the changes in the level that is being upgraded to, be sure to review the changes in the intermediate fix packs or interim fixes (iFixes). 

Examples:

  • Currently at level fix pack 1 and upgrading to level fix pack 3, review the changes in fix pack 2 and fix pack 3.
  • Currently at fix pack 1 / iFix 1 and upgrading to fix pack 1 / iFix 3, review the changes in fix pack 1 / iFix 2 and fix pack 1 / iFix 3.

Back to top
Common Across Releases
 
 

Feature changes

Fix list and new feature summary

For a list of fixes, see V4.0.3 Fix List for Financial Transaction Manager for Red Hat OpenShift.

Database migration
For database migration instructions, refer to the migration instructions in {Install location}\shared\vnnn\pfs\Database\db2\{os}\doc
Refer to Entitled Documentation for the document.

Entitled Documentation
Entitled documentation can be downloaded from Fix Central at:

Documentation fix pack for FTM (base)

General Instructions

Deployment

Refer to the FTM online documentation for deployment instructions.
For more information about the specific 4.0.3.0 interim fix 1 deployment instructions, see
Back to top
4.0.3.0 interim fix 1 release
 
Known Issues
For known issues, refer to V4.0.3 Release Information for Financial Transaction Manager for Interac e-Transfers for Red Hat OpenShift under section 4.0.3.0 interim fix 1 release
Back to top
4.0.3.0 release
 
 
This release contains all features and known issues from 3.2.6.  Refer to the 3.2.6 Release Information document for Financial Transaction Manager.
Known Issues

High Availability

Additional resiliency is needed in some scenarios to improve the handling of error detection / auto recovery. This issue is addressed in the delivery of the interim fix.

 
Feature changes
 

Enhanced software upgrade capabilities and process management

Improved flexibility and scaling capabilities for the IBM App Connect Enterprise and IBM MQ containers
FTM split the combined containers into separate IBM App Connect Enterprise and IBM MQ containers.

The IBM MQ container is now a separate container that is running IBM MQ 9.2. IBM App Connect Enterprise 11.0.0.11 is running in separate IBM App Connect Enterprise containers.
Benefits of the split:
- Ability to deploy IBM App Connect Enterprise and IBM MQ separately
- Ability to have IBM App Connect Enterprise connect to a remote queue manager
- Ability to customize the IBM App Connect Enterprise deployment topology as required
- Ability to have multiple IBM App Connect Enterprise containers.
- Ability to set resources (CPU and memory) for the IBM App Connect Enterprise and IBM MQ containers separately
- Provide features of both auto and manual scaling for IBM App Connect Enterprise containers

 

Improved security of communication between FTM components
FTM communication between components is now more secure with TLS encryption.
IBM MQ and Db2 communications are running over TLS.
The J2EE, J2SE, and IBM App Connect Enterprise client applications connect over a TLS protocol.
The procedure to generate (if self-signed certificates) and configure TLS certificates used by all the FTM components is documented by FTM. The default CipherSuite/CipherSpec used by IBM MQ and all the clients is SSL_RSA_WITH_AES_128_CBC_SHA256/TLS_RSA_WITH_AES_128_CBC_SHA256. This default can be customized during deployment with the Operator Instance YAML.

LTPA keys by default
No customization is required. LTPA keys are managed by the individual J2EE Liberty server instances. The default configuration is used and LTPA keys are created when the application pod starts.

Readiness and Liveness health check probes and prestop pod lifecycle event
FTM now comes with health check probes (readiness and liveness) and prestop pod lifecycle events implemented.
Readiness and liveness probes: During the rolling upgrades, the new version pod gets created and when it becomes ready, then OpenShift deletes the old pod. OpenShift runs the readiness probe to decide whether the pod is ready or not. Unless the probe returns success, it does not mark the new pod in ready state.
Liveness probes are run periodically like readiness probe. If liveness probe fails, OpenShift restarts the container.
Prestop pod lifecycle event: OpenShift allows adding the PreStop hook to be run inside the container before OpenShift deletes the container. This script is called by OpenShift before it deletes the container.

Allow customization of config files and server.xml files by using configMap
FTM operator now supports ConfigMap-based approach to let user provide custom server.xml or other configuration files in addition to the persistent volume-based approach. There are separate ConfigMaps created for each FTM component and the customer can place all the customized files in those ConfigMaps. This method is useful for the customers who do not use persistent volumes (PV) or do not have easy access to the PVs from outside. This method is supported for JSE and Java EE components.

Usage count metering differentiates between production and non-production environments
The FTM metering application, which is in the OAC pod, now differentiates between production and non-production usage counts. The differentiation is made based on the "Environment type" variable under "License" category of IBM FTM Base operator.
- Customers should set this variable to "Production" or "NonProduction" based on the type of environment they are building during the operator installation.
- Regardless of "Environment type" value, all usage counts are calculated and stored in the database.
- Only production mode usage counts are reported to the IBM License Server, which is in the "ibm-common-services" namespace and is shared across all projects.

Ability to override transaction states

FTM Base supports a new feature that allows State properties to be overridden.
If the product models define a state S_State1 to have Amber image, with a Retry constraint and no Alert stereotype, the customer can now redefine it in their model. For example, they could choose to define S_State1 to have Red image, with an extra Cancel constraint and with an Alert stereotype.
To override state properties, do the following steps.
- Create an FSM and use a name that does not clash with an existing one.
- Add the state S_State1.
- Set the properties you want as normal. 
- Select the 'Definition' check box (found on the FTM properties tab).
This definition should now override for both validation and extraction.

[{"Line of Business":{"code":"LOB10","label":"Data and AI"},"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSPKQ5","label":"IBM Financial Transaction Manager"},"ARM Category":[{"code":"a8m50000000ClaTAAS","label":"Product Documentation"},{"code":"a8m50000000ClaTAAS","label":"Product Documentation"},{"code":"a8m50000000ClaTAAS","label":"Product Documentation"}],"ARM Case Number":"","Platform":[{"code":"PF016","label":"Linux"}],"Version":"4.0.3"}]

Document Information

Modified date:
13 September 2021

UID

ibm16433523

Page Feedback