FTM Payment Feature Services. Parallel Migration. 21 May FTM_PFS_Parallel_migration.doc Page 1 of 8

Transcription

1 FTM Payment Feature Services Parallel Migration 21 May 2016 FTM_PFS_Parallel_migration.doc Page 1 of 8

2 Contents 1. Overview Purpose Runtime deployment scenarios Gateway Server considerations Duplicate checking Business Rules Process Server and Distribution Manager considerations Duplicate Detect component consideration Distribution component considerations Transaction Server considerations Additional Check specific considerations Deployment Scenarios details Scenario 1: Run the prior system in parallel with the new system Scenario 2: Inbound Gateway Duplicate Checking variation Scenario 3: Inbound Duplicate Detect component variation Runtime flow summary... 8 FTM_PFS_Parallel_migration.doc Page 2 of 8

3 1. Overview 1.1 Purpose This document enumerates the steps to migrate from a prior FTM Payment Feature Services product set (ACH, Check, and CPS) release to a newer release by running the products in parallel, phasing over to the new system The general approaches are: Determine new deployment scenarios and migration approach. Determine phases for shifting partners to the new system. QA system for testing. Contains both the prior system and new system for testing. Migrate configuration data and configure components. Document all of the necessary steps and procedures for setting up the production systems. Test processing partners. Will usually keep processing existing partners in the prior production system but also duplicate partner input to the QA new system. This will help discover anything not accounted for. New system. Migrate configuration data and configure components. Test processing partners. Will usually keep processing existing partners in the prior production system but also duplicate partner input to the new system. Direct partners away from the prior production system to the new production system. Note: depending on your situation you will either change production from the prior system to the new system at one time or in phases. If at one time, such as over a weekend, you will shut down your prior system and start up new system. If done in phases then the Runtime deployment scenarios will apply. Additional information on the FTM PFS components can be found in the Financial Transaction Manager documentation ( FTM_PFS_Parallel_migration.doc Page 3 of 8

4 2. Runtime deployment scenarios There are several variations that you may have depending on what prior FTM PFS components you have deployed and your business requirements. The types of runtime deployment scenarios that you may have are: 1. Inbound into prior system and outbound from prior systme with no other variations. This is the most basic deployment scenario. 2. There may be additional deployment variations depending on your operation. 1. Basic scenario with inbound Gateway Duplicate Checking variation. 2. Basic scenario with inbound Duplicate Detect product variation. In the above deployment scenarios, you can choose to run the prior system and the new system in parallel during a transition period. Section 2Deployment Scenarios details describes parallel deployment in more detail. For the scenario you have you will need to configure the new system installation for the partner configurations and the runtime configurations. Depending on your partner configuration complexity you may want to use the Data Setup Utility for exporting data from your prior system into your new system. The types of configuration information include: Partners Endpoints Business Rules work flows 1.1 Gateway Server considerations Duplicate checking That Gateway Server has the ability to detect for duplicate files, cash letters and bundles (segments). The Gateway Server has the ability to detect duplicate files, batchs/cash letters (ICL) and ICL bundles (segments). If you are concerned with duplicates either with prior processed files or during the cross over period, then the duplicate data from the prior system will need to be migrated to the new system. If you will also be running both the prior system and new systems in parallel then you can share the same duplicate data between the two systems by configuring the prior system Gateway to use the new system. Note that duplicate data is kept by the Gateway per the dupkeepdays configuration parameter, so if you do not share the data this is the amount of time for missing potential duplicates. FTM_PFS_Parallel_migration.doc Page 4 of 8

5 1.2 Business Rules Process Server and Distribution Manager considerations There are no special considerations. The prior products that interact with the Business Rules products, such as the Gateway or Payment Repair, will still only interact with the prior system and the new system will only interact with the new system. 1.3 Duplicate Detect component consideration If you are using the Duplicate Detect component on both the prior and new system and you are concerned with duplicates during the cross over period then you will need to share the new Duplicate Detect component between both systems. The following changes will be required: The prior Transaction Server will need to now be configured to send event messages to the new Duplicate Detect component. Note: If the same input queue is used for the new Duplicate Detect component then no configuration changes are required. The new Transaction Server will need to be configured to also obtain items from the prior Transaction Server. First the new Transaction Server will try to retrieve the information from the new installation and if the item is not found, the prior Transaction Server will be queried. 1.4 Distribution component considerations There are no special considerations. The prior Distribution component will only interact with the prior system and the new Distribution product will only interact with the new system. 1.5 Transaction Server considerations There may be situations requiring the FTM for Check Transaction Server to interact with the IPD Transaction Server for: Duplicate Detect If these situations apply then configure the new Transaction Server to interact with the old Transaction Server. Business Day requests will be forwarded to the IPD Transaction Server. For item retrieval requests the new Transaction Server will first check the new installation. If the item is not found, the prior Transaction Server will be queried. Refer to the Knowledge Center for the Transaction Server migration properties. FTM_PFS_Parallel_migration.doc Page 5 of 8

6 1.6 Additional Check specific considerations There are additional FTM for Check specific considerations for Archive Server and CPCS. Refer to the Financial Transaction Management for Check from Payments Director Migration Guide for additional information form these scenarios. FTM_PFS_Parallel_migration.doc Page 6 of 8

7 2 Deployment Scenarios details This section describes common deployment scenarios for running the prior system and the new system in parallel while you transition work from the prior system to the new system. 2.1 Scenario 1: Run the prior system in parallel with the new system This is the basic scenario for running the prior system in parallel with the new system. Note: Deploying both the prior system and the new system into the same WebSphere Application Server cell as the prior system is not supported. Depending on your specific prior system deployment scenario there will be variations in the components and configurations required. During the migration process the prior system will be running in parallel with the new system. Each will be processing work independent of the other. Your up front application will decide how partner data is distributed between the two systems. Although not required, processing different partners on each system allows to more effectively manage cross over. Actively processing work on both systems concurrently allows moving partners in phases to the new system until the prior system is no longer required. Most customers will probably use this approach. Depending on the additional deployment scenarios there will be some variations that build on this approach. 2.2 Scenario 2: Inbound Gateway Duplicate Checking variation This scenario is when the Gateway is configured to perform duplicate checking when ingesting files. Only required when duplicates are a concern during cut over period. You will be sharing the duplicate checking data. Migrate the Duplicate checking data from the prior system to the new system. Configure the prior system to use the data in new system. This allows sharing the same data for duplicate checking. 2.3 Scenario 3: Inbound Duplicate Detect component variation Scenario 3 is when you are also using the Duplicate Detect component to check for duplicates on ingested files. Note: this is not the Gateway duplicate checking. You will be using the Scenario 1 approach. However, only the new Duplicate Detect component will be used. Duplicate Detect has its own database whose tables are defined by your deployment. Using the new Duplicate Detect component will allow sharing the same Duplicate Detect database for both the prior system and the new system. FTM_PFS_Parallel_migration.doc Page 7 of 8

8 No data migration is required. Prior Gateway or prior Transaction Server simply needs to be configured to point to the new Duplicate Detect component. 2.4 Runtime flow summary Here is an overview of the runtime flow for scenarios 1, 2, and Start up the prior system and the new system for processing work. 2. Your application puts files into either the prior system or new system based on your defined criteria. 3. Each Gateway will process the files as normal. If duplicate detect is being used the prior system Gateway will be using the new system Gateways duplicate detect database tables so both Gateways can verify potential duplicates against the same set of data. 4. If the Duplicate Detect component is being used, the Transaction Server, per the scheduler event configuration, will interact with the Duplicate Detect component as normal. 5. If the Distribution product is being used, files will be processed as normal with each system independent of the other. 1. Note: If Distribution is being used on both the prior system and new systems and inbound files for the same partner and business day are going to both systems, then the receiving partner may receive more files than they normally expect because both systems will be release files independent of the other system. 6. To end a business day, the administrator will have to check both the prior system and the new system for the business day. Note that this also applies to the Outbound flows. 7. After all business days have been ended and the prior system is no longer required: 1. Shut down the prior system. 2. Remove the migration configuration from the new Transaction Server. 3. Configure your application to only send work to the new system. 8. Only use the new system. FTM_PFS_Parallel_migration.doc Page 8 of 8