============================================================================== ============================================================================== Licensed materials - Property of IBM 5724-D96 (C) Copyright IBM Corp. 2002, 2011 All Rights Reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. ============================================================================== ============================================================================== README for IBM(R) WebSphere(R) Business Integration for Financial Networks for Multiplatforms V3.1.1 Messaging Services for SWIFTNet InterAct and FileAct PTF UK72302 for APAR PM52045 = Date 2011-11-30 = ============================================================================== ============================================================================== ============================================================================== Table of contents ----------------- A About this document B Summary of changes C Planning D Preparation E Activating F APAR details G Other changes A. About this document ---------------------- If you install this PTF as part of the migration from WebSphere BI for FN Version 3.1.0 to Version 3.1.1 then do not follow the steps in this readme, but those described in the Migration Information document. Only the online version of this readme document is current. Before you install the corresponding PTF, download the latest version from: http://www.ibm.com/software/integration/wbifn/support Download the latest version of the WebSphere BI for FN product documentation from: http://www.ibm.com/software/integration/wbifn/library The structure of WebSphere BI for FN readme documents is identical for all PTFs. Sections that are not applicable are left blank. If you install more than one PTF at a time, combine the readme documents by merging the contents of each section. The installation of this PTF is done in two phases: 1. Preparation - During this phase your system can continue to process messages as usual. 2. Activation - During this phase your system cannot process messages. This readme document uses the following variables: The installation directory of WebSphere BI for FN. The directory /opt/IBM is used in examples. The customization directory. The directory /var/dniv311/cus is used in examples. The deployment directory. The directory /var/dniv311/cus/depdata is used in examples. The name of the WebSphere BI for FN instance. The name INST1 is used in examples. The name of the organizational unit. Depending on the context, this might be SYSOU, DNFSYSOU, or the name of a business OU. The names of users, groups, files, and directories are the same as those used in WebSphere BI for FN for Multiplatforms Planning, Installation, and Customization. If you use different names, use those names instead of the names shown here. B. Summary of changes --------------------- APARs addressed by this PTF: PM48227 MSIF AN ERRONEOUS REQUEST MESSAGE SHOULD NOT LEAD TO A CIN STOP IN MSIF PM48501 MSIF INCLUDE RM IN THE MESSAGE TEXT OF DNFL9430E Note: This APAR addresses message changes in MSIF and Base. PM49622 MSIF MSIF: FILE SIZE OF THE UNCOMPRESSED FILE MUST NOT BE LIMITED PM49500 MSIF THE DNFO1048E EVENT SHOULD BE AN INFORMATIONAL EVENT RATHER THAN AN ERROR EVENT. PM34077 MSIF MSIF MUST ACCEPT INCOMING SNF TRANSFERS DIRECTLY AFTER A QUEUE IS ACQUIRED Note: This is an APAR initially opened for EFAS V2.2.0 for z/OS PM07900 MSIF MSIF DOES NOT ALLOW TO SPECIFY MULTI-SERVER Note: This is an APAR initially opened for MSIF V3.1.0 PM45255 MSIF IMPROVEMENT OF DNF03463E FOR MORE DETAILED INFORMATION PM49791 MSIF MSIF INTERACT AND MX APPHDR: COUNTERPART DOES NOT SUPPORT NAMESPACE PREFIX AH PM50793 MSIF MSIF CIN STOP, WHEN A 2ND PDM IS RECEIVED FOR IA SNF TRANSFERS PM49781 MSIF MSIF INTERACT AND SIGNATURELIST: DIGESTREF "SW.IAREQUESTHEADER" CAUSES ERRORS AT COUNTERPARTS USING SAG 6.0 PM50999 MSIF MSIF: DELIVERY NOTIFICATIONS FOR SNF TRANSFERS CANNOT BE PROCESSED WHEN SAG 6.1 IS USED PM52045 MSIF MSIF PROCESSING WITH AUTORECOVERY FOR OUTOFSEQUEUCE MESSAGES CAN RESULT IN DUPLICATE FILES BEING TRANSFERRED Additional functional changes: - none Documentation updates: - Messages and Codes - System Administration - Application Programming The following modules have been changed: /dnfv311/run/jplugin/dnfco.jar /dnfv311/run/msg/dnfcomsg.cat /dnfv311/run/res/dnfcomsg.xml /dnfv311/run/flows/DNF_O_FT.bar /dnfv311/admin/data/DNFEFAS.xml /dnfv311/admin/data/dnfcocmo.cli C. Planning ----------- Before installing a new PTF, ensure that: - All previously prepared deployment instructions have been carried out. - All previous CDD changes have been implemented using the CDP. - All configuration administration changes have been deployed. To check this, enter the following commands: dnicli -s DNI_SYSADM -ou SYSOU > list -ou % -qo amorz > list -cos % -qo amorz > list -ct % -qo amorz Each list command should result in 'No [OU/COS/CT] match search criteria'. - All security administration changes have been approved. To check this, enter the following commands for each OU: dnicli -s DNI_SECADM -ou > list -ro % -qo mor [only for SYSOU] > list -user % -qo mor Each list command should result in 'No roles found that match specified criteria'. Customization changes other than those described in a PTF readme document are not allowed during PTF installation. Prerequisite and supersede information: This PTF requires the following PTFs: - UK68724 for APAR PM45244 (HANDLING OF DELIVERY NOTIFICATIONS RECEIVED OUT OF SEQUENCE) - UK71716 for APAR PM44564 (DELETE ACTION DOESN'T WORK WITH THE IMPORT RELATIONSHIP IN RMA) This PTF supersedes the following PTFs: - none Roles involved: The activities in this PTF involve the following roles: - Installer (root) - Customizer (ucust1) - WebSphere MB administrator (uwmba1) - First WebSphere BI for FN system configuration administrator (sa1) D. Preparation -------------- D1. Installation ---------------- 1. Stop all sessions and services, for example: - Stop all applications that send requests to WebSphere BI for FN. - Log out SIPN FIN LTs. - Close MSIF SnF input and output channels. - Release SWIFTNet SnF queues. - Stop the MSIF Message Transfer service. - Stop the Enhanced InterAct service. - Close all dnicli sessions. 2. Stop all WebSphere BI for FN message brokers. 3. Install this PTF using IAW based on the chapter "Installing WebSphere BI for FN" in WebSphere BI for FN for Multiplatforms Planning, Installation, and Customization, SH12-6942. Please be aware of the directory containing the installation data for this PTF has changed compared to the directory documented in this chapter, use the path Disk1/InstData/NoVM instead of Disk1/InstData/VM. 4. Share the files in the /dnfv311/admin directory with your customization system. 5. Ensure that the group ownership of the /dnfv311/admin directory and all of its subdirectories and files, is set to group dniadmin. To do this, enter the following command in AIX shell: chgrp -R dniadmin /dnfv311/admin 6. Share the files in the /dnfv311/run directory with your runtime systems. These files are already needed during the preparation phase and do not influence normal operation. 7. Set the group ownership of these directories and files to group dnilpp. To do this, enter the following command in AIX shell: chgrp -R dnilpp /dnfv311/run D2. Steps on a customization system ----------------------------------- To update your current definition directory and the customized administrative scripts, and to create deployment instructions and vehicles: 1. Log on to AIX on the customization system as a customizer (ucust1). 2. Change to the customization directory: cd 3. Run your customization profile: . ./dnicus_ 4. Start the CDP in migration mode and use the following commands to migrate customization data: dnicdpm -i > export cdd/_PM52045.cdd > import cdd/_PM52045.cdd 5. Implement the customization definition data to activate the delivered service bundle and quit the CDP session: > implement When the message "DNIZ9013I: Current Definition file already exists." is displayed enter 'y' to continue. > quit D3. Generating configuration data migration scripts --------------------------------------------------- NOT APPLICABLE. D4. Manually customize updated BAR files when not using the BAP to deploy them ------------------------------------------------------------------------------ If you use the BAP (dniczbap) to deploy the updated broker archive (BAR) files, the BAR files will be automatically customized during deployment, so you can skip this step. If you do not use the BAP to deploy the updated BAR files, which of the following procedures you must follow depends on whether there is a connection to the configuration manager: - If so, follow the procedure described in D5.1 - If not, follow the procedure described in D5.2 Note: Ensure that configuration manager is running and no flows or execution groups are stopped during the deployment of updated BAR files. Otherwise it may happen that old flow levels are not deleted during the BAP update operation (-cmd prepare -update new). To verify that the update was successful you can use the BAP list command. There should be no flows running with the same name but a different version. D4.1. Customize BAR files without connection to the configuration manager - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carry out the following steps when there is no connection to the configuration manager, for example, because the configuration manager runs on Windows. The BAP customizes all BAR files that it processed earlier, for example, during installation of WebSphere BI for FN. You then select which files are to be updated for the current PTF. 1. On the runtime system, log on to AIX as the system configuration administrator, for example, sa1, or as the WebSphere MB administrator, for example uwmba1, and run the profile for your runtime environment by entering: . /var/dni_03_01/run/dniprofile 2. Create a temporary directory where dniczbap stores the customized BAR files. You will need up to 35 MB free space in this directory. 3. Issue the following command: dniczbap -cmd prepare -all -dir where represents the directory created in the previous step. Each of the customized BAR files has a name of the form: ...bar where The name of the broker to which the BAR file is to be deployed. The name of the execution group to which the BAR file is to be deployed. The name of the BAR file as provided by WebSphere BI for FN. 4. Identify the BAR files that are listed in section 'B. Summary of changes' and delete all other BAR files in the temporary output directory. 5. Transfer, in binary mode, the customized BAR files to the Toolkit or to the system on which you will issue the mqsideploy command. 6. If you want to deploy using the Toolkit, import the customized BAR files. D4.2. Customize BAR files with connection to the configuration manager - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carry out the following steps when there is a connection to the configuration manager. The connection enables the configuration manager to automatically detect updated BAR files. 1. Ensure that the configuration manager is started. 2. On the runtime system on which the configuration manager runs, log on to AIX as the WebSphere MB administrator, for example, uwmba1, and run the profile for your runtime environment by entering: . /var/dni_03_01/run/dniprofile 3. Create a temporary directory where dniczbap stores the customized BAR files. You will need up to 35 MB free space in this directory. 4. Issue the following command: dniczbap -cmd prepare -update new -dir where represents the directory created in the previous step. Each of the customized BAR files has a name of the form: ...bar where The name of the broker to which the BAR file is to be deployed. The name of the execution group to which the BAR file is to be deployed. The name of the BAR file as provided by WebSphere BI for FN. *-----------------------------------------------------------------------------* * End of Preparation * *-----------------------------------------------------------------------------* E. Activating ------------- E1. Stopping all sessions and services you use ---------------------------------------------- Stop all sessions and services, for example: - Stop all applications that send requests to WebSphere BI for FN. - Log out SIPN FIN LTs. - Close MSIF SnF input and output channels. - Release SWIFTNet SnF queues. - Stop the MSIF Message Transfer service. - Stop the Enhanced InterAct service. - Close all dnicli sessions. For further information, see "Administering and operating components, sessons, and services" in "WebSphere BI for FN for Multiplatforms: System Administration", SH12-6943. E2. Stopping all application servers ------------------------------------ NOT APPLICABLE. E3. Stopping all WebSphere BI for FN message brokers ---------------------------------------------------- Stop all WebSphere BI for FN message brokers. E4. Sharing the runtime directory structure ------------------------------------------- 1. Share the files in the /dnfv311/run directory with the runtime systems. 2. Set the group ownership of these directories and files to group dnilpp. To do this, enter the following command in AIX shell: chgrp -R dnilpp /dnfv311/run E5. Backing up configuration and security data in image copies -------------------------------------------------------------- NOT APPLICABLE. E6. Following the deployment instructions created in step D2.4 -------------------------------------------------------------- NOT APPLICABLE E7. Additional activities ------------------------- E7.1. DB2 related activities - - - - - - - - - - - - - - NOT APPLICABLE. E7.2. WebSphere MB related activities - - - - - - - - - - - - - - - - - - - NOT APPLICABLE. E8. Restarting all WebSphere BI for FN message brokers ------------------------------------------------------ Restart all WebSphere BI for FN message brokers. E9. Redeploy updated BAR files ------------------------------ To customize and deploy the updated WebSphere BI for FN BAR files, you must have the access rights of the WebSphere MB administrator (uwmba1). To redeploy updated BAR files: 1. Ensure that the configuration manager is running. 2. If you already have prepared the customized BAR files as described in step D5 proceed with step E9.1; otherwise, proceed with step E9.2. Note: Ensure that configuration manager is running and no flows or execution groups are stopped during the deployment of updated BAR files. Otherwise it may happen that old flow levels are not deleted during the BAP update operation (-cmd prepare -update new). To verify that the update was successful you can use the BAP list command. There should be no flows running with the same name but a different version. E9.1. Deploying the BAR files customized in step D4 - - - - - - - - - - - - - - - - - - - - - - - - - - Use the Toolkit or the mqsideploy command to deploy the BAR files. Remove the old versions of the flows which have been updated by this PTF as otherwise two different versions of the flows are running. You can list the flows running in the broker to identify the names including their version suffix. You can also refer to the Planning, Installation, and Customization manual for a list of flows contained in each BAR file. E9.2. Updating BAR files when step D5 has not been performed - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Use these steps when your configuration manager runs on AIX and you want to deploy directly using the BAP (dniczbap). To customize and deploy the BAR files: 1. On the runtime system on which the configuration manager runs, log on to AIX as the WebSphere MB administrator, for example, uwmba1, and run the profile for your runtime environment by entering: . /var/dni_03_01/run/dniprofile 2. Ensure that you have sufficient free space in the current directory. To deploy all message flows requires about 35 MB of free space. 3. Issue the following command: dniczbap -cmd prepare -update new -deploy E9.3. Activating WebSphere BI for FN accounting - - - - - - - - - - - - - - - - - - - - - - - - NOT APPLICABLE. E10. Migrating configuration data --------------------------------- NOT APPLICABLE. E11. Updating the WebSphere BI for FN enterprise application ------------------------------------------------------------ NOT APPLICABLE. E12. Restarting all sessions and services ----------------------------------------- 1. Restart all of the sessions and services that you use. How to do this depends on which WebSphere BI for FN features you use. For example: - Log in SIPN FIN LTs. - Subscribe MSIF to SAGs to enable file transfer and session monitoring. - Start the MSIF Message Transfer service. - Start the Enhanced InterAct service. - Acquire SWIFTNet SnF queues. - Open MSIF SnF input and output channels. - Start the applications that send requests to WebSphere BI for FN. For further information, see "Administering and operating components, sessions, and services" in "WebSphere BI for FN for Multiplatforms: System Administration", SH12-6943. 2. A subscription to receive FileAct events is needed for each SAG that the MSIF Transfer Service uses to conduct file transfers. Because one of the previous steps erased all subscriptions from the WebSphere BI for FN database, for each SAG that the MSIF Transfer Service is to use to conduct file transfers, resubscribe manually by issuing the "subscribe" command. E13. Updating the Toolkit development environment ------------------------------------------------- NOT APPLICABLE. *------------------------------------------------------------------------------* * End of Activating * *------------------------------------------------------------------------------* F. APAR details --------------- Fixes for the following APARs are contained in this PTF: PM48227 MSIF AN ERRONEOUS REQUEST MESSAGE SHOULD NOT LEAD TO A CIN STOP IN MSIF Formerly, the ControlledInputNode (CIN) stopped to read messages from the MSIF input queues due to permanent errors that cause a flow rollback, such as data exceptions, DB2 or MQ errors. The necessity to definitely stop processing is only seen for situations, where problems in DB2 or MQ environment occur. In the past, however, most situations which caused the CIN to stop were related to data exceptions, caused by code or migration problems. Mostly, only one single request message was affected, the following messages could have been processed successfully. However, due to the CIN behaviour, the processing was interrupted (production down) until the input queue was cleaned up. Even if the problems were caused by e.g. cleanup, the processing of FileAct transfers (the normal operation) was interrupted. With MSIF covering FileAct and InterAct processing, a problem within InterAct did also affect FileAct and vice verse. Now, requests which cannot be processed due to data exceptions or any other problems, which only affect this single request, are backed out and processing continues with the next request. The CIN provides new operation commands to operate backed out messages using the DNI_SYSOP service. PM48501 MSIF INCLUDE RM IN THE MESSAGE TEXT OF DNFL9430E For WebSphere BI for FN V3.1.1 the message DNFL9430E was reworked to include the new parameters, and the keyword "RM" was removed from the message text. For usability reasons, it was suggested that including the keyword "RM" again will help end users to directly determine, that they need to check the RM data store rather than guessing, which kind of authorisation might be wrong. Note: This APAR addresses message changes in MSIF and Base. PM49622 MSIF MSIF: FILE SIZE OF THE UNCOMPRESSED FILE MUST NOT BE LIMITED Formerly, when MSIF received a zipped file and the target was a dataset where the size of the uncompressed dataset exceeded 250 MB, the file transfer was in Error and the file was not delivered to the application. In addition, the list result for this transfer showed a file size of 250 MB for the uncompressed dataset. However, the file size of the uncompressed file or dataset must not be limited. Now, the limitation has been removed. PM49500 MSIF THE DNFO1048E EVENT SHOULD BE AN INFORMATIONAL EVENT RATHER THAN AN ERROR EVENT. Formerly, when the MSIF transfer service issued a local file transfer (LFT) DELETE command to delete a file from the SAG that was no longer needed, and the SAG did not respond to the DELETE command within the timeout period, event DNFO1048E was raised. As the MSIF transfer service automatically re-issues the DELETE command later, event raised should not be an error event (DNFO1048E), but an informational event (DNFO1048I). Now, error event DNFO1048E has been changed to information event DNFO1048I. The user action has been adapted. PM45255 MSIF IMPROVEMENT OF DNFO3463E FOR MORE DETAILED INFORMATION Formerly, it was difficult to analyze errors that caused a rollback of the message processing leaving the the message on the input queue. Although, the error message DNFO3463E was complete, it was not sufficient to determine the root cause of the error because the originating DB2 error did not contain detailed information about affected tables or columns. Now, error analysis is easier because the trace behavior has been changed. If an error causes now the rollback of the message processing and the message processing is retried, MSIF activates tracing with level DEBUG for the components DNFO and DNPA. This generates a detailed trace of the error situation, if the error reoccurs during the message retry. For other components the configured trace levels are used. When the retry of the message processing is finished (successfully or not), MSIF switches back the trace levels for the components DNFO and DNPA to their configured values. PM49791 MSIF MSIF INTERACT AND MX APPHDR: COUNTERPART DOES NOT SUPPORT NAMESPACE PREFIX AH Formerly, when using an InterAct message with an MX Application Header, an application had to specify all values by means of dedicated fields in the API request message. MSIF then created the MX Application Header, and added a namespace prefix "Ah:" to each tag. Now, as an alternative, an application can fully control the structure of an MX Application Header by providing it as a single XML subtree. MSIF will then send the Application Header "as-is" to the counterpart. Regardless of whether the Application Header was provided as dedicated values or as XML subtree, MSIF updates MWH_AH_MSGREF and MWH_PD_INDICATION accordingly if Message Warehouse is enabled. This applies to SendMsg scenarios, and MsgReceived scenarios in RT mode in flexible mode when the application is creating a reply message. PM50793 MSIF MSIF CIN STOP, WHEN A 2ND PDM IS RECEIVED FOR IA SNF TRANSFERS Formerly, in the following circumstances, the MSIF transfer service sometimes issued the event DNFO3466E and stopped the controlled input node (CIN): - Several instances of DNF_O_FT run simultaneously in different execution groups. - Two of these instances of DNF_O_FT both received InterAct requests from an SnF queue. - One of the InterAct requests was a PDM for a MsgReceived scenario for which a PDM had already been received. Now, the MSIF transfer service processes the InterAct PDMs correctly, does not issue an event, and does not stop the CIN. PM49781 MSIF MSIF INTERACT AND SIGNATURELIST: DIGESTREF "SW.IAREQUESTHEADER" CAUSES ERRORS AT COUNTERPARTS USING SAG 6.0 Formerly, when InterAct messages were sent or received using the automatic signature mode (which means signed with a signature list and no SignatureOptions are configured or provided), the digestRefs with the names 'Sw.IARequestHeader' and 'Sw.IAResponseHeader' were automatically added to the signature list. However, those digestRefs are unknown for SAG 6.0 installations. These digestRefs were introduced with SAG 7.0 and will therefore cause an error on the correspondent side if the correspondent has a SAG 6.0. Now, MSIF checks if the InterAct message is using a service with copy (T-Copy or Y-Copy). On the sending side this is also based on the content of the ASP for the used service. If a copy service is used, the new digestRefs 'Sw.IARequestHeader' and 'Sw.IAResponseHeader' are chosen. If no copy service is used, the older digestRefs 'Sw.RequestHeader and RequestPayload' and 'Sw.ResponseHeader and ResponsePayload' are used. If MIMode is set to 'SWIFTNet6', MSIF will always use the older digestRefs which are compatible with SAG 6.0. PM50999 MSIF MSIF: DELIVERY NOTIFICATIONS FOR SNF TRANSFERS CANNOT BE PROCESSED WHEN SAG 6.1 IS USED Formerly, when an SAG 6.1 was used, the SIPN provides delivery notifications as SNL primitives, even if MSIF requested to receive delivery notifications as system message. The MSIF implementation on level UK71891 could not handle this. The delivery notification was not processed and the corresponding SnF queue was closed by SWIFT. Now, MSIF has been changed to allow that SAG 6.1 behavior. PM52045 MSIF MSIF PROCESSING WITH AUTORECOVERY FOR OUTOFSEQUEUCE MESSAGES CAN RESULT IN DUPLICATE FILES BEING TRANSFERRED Formerly, MSIF processing with AutoRecovery for OutofSequeuce Messages could result in duplicate files being transferred. When during a MSIF transfer an error was encountered by the SAG or SWIFTNet, and MSIF had already set some FileAct events as out-of-order messages, during the recovery of the transfer, the out-of-order FileAct events might be processed again and caused duplicate files to be sent. That resulted in two files being transferred. Now, MSIF removes the out-of-order messages when an error is encountered. In addition, the handling of local references in the history table is enhanced to improve the detection of duplicate send file requests. This prevents MSIF to send a file twice. Fixes for the following WebSphere BI for FN for z/OS V2.2.0 APARs are now added to WebSphere BI for FN V3.1.1: PM34077 MSIF MSIF MUST ACCEPT INCOMING SNF TRANSFERS DIRECTLY AFTER A QUEUE IS ACQUIRED Formerly, when an SnF queue was acquired or an output channel was opened, it could happen that incoming transfers were rejected because MSIF did not previously receive the response from the SAG, that the acquire or open had been performed successfully. This caused files or messages, which were already available on the SnF queue to be rejected, and only subsequent receive requests (with PDM indication) were processed successfully, as soon as the queue or channel status was updated in the WebSphere BI for FN database. Now, the MSIF implementation has been improved to accept incoming transfers from an SnF queue or output channel even if the SnF queue status in the WebSphere BI for FN internal database is still 'Acquiring' or the output channel status is still 'Opening'. Fixes for the following WebSphere BI for FN V3.1.0 APARs are now added to WebSphere BI for FN V3.1.1: PM07900 MSIF MSIF DOES NOT ALLOW TO SPECIFY MULTI-SERVER Formerly, when you tried to assign the Service Bundle DNFEFAS to more than one server the CDP stops with an error. Now, this behavior has been corrected. Note: This is an APAR initially opened for EFAS V2.2.0 G. Other changes ---------------- - Documentation APAR PM46596 * besides the description addition in the System Administration a comment has also been added to the cli file: dnfcocmo.cli - Message updates: * Changed event messages: DNFO1048E becomes DNFO1048I ++++ End +++ End +++ End +++ End +++ End +++ End +++ End +++ End +++ End ++++