Peoplesoft (FBT Project) and Indus Passport (Portal Project) Integration Risk and Control Analysis (RACA) Version 4.0

Transcription

1 EAI Financial Integration Project FINAL Peoplesoft (FBT Project) and Indus Passport (Portal Project) Integration Risk and Control Analysis (RACA) Version 4.0 May Reference:EAI FI_RACA_v4.0 Final.doc

2 REVISION RECORD SECTION Version Author Status Date Description of Change 1-2 David Priestley Draft 19 February 2003 Initial Draft 1-3 David Priestley Draft 5 March nd Draft following comments from Stan Krogh 1-4 David Priestley Draft 19 March rd Draft 2.0 David Priestley Draft 09 May 2003 Incorporate minor factual updates from FBT project. Not Circulated for comment 3.0 M.Wynne Draft March 2003 Updated IPP diagram and additional comments 4.0 David Priestley Draft May Final draft version for comment before Project closure. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 2 of 24

3 CONTENTS 1 BACKGROUND SCOPE OF CONTROLS ARCHITECTURAL DESIGN CONTROLS CONTROL DATA SYNCHRONISATION ERROR HANDLING INFRASTRUCTURE FAILURE CONTROLS...14 APPENDIX A INDUS-SEEBEYOND-PEOPLESOFT APPLICATION INTEGATION SCHEMATIC...18 APPENDIX B: EAI TOUCHPOINT DATA SYNCHRONIZATION...19 APPENDIX C: NON-EAI (MANUAL) DATA SYSNCHRONIZATION...23 Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 3 of 24

4 1 BACKGROUND The Enterprise AppIication Integration (EAI) Financial Integration (FI) Project was re-initiated in July 2001 to design, build and deploy a series of 22 interfaces (Touchpoints) between the Indus Passport work management and supply chain system and the Peoplesoft HR and Financial suites using the Seebeyond Enterprise Application Integration product. The three application components are part of the BC Hydro Integrated Package Program (IPP) launch planned for April SCOPE OF CONTROLS Integration does not represent a business process however the effective and correct operation of the interfaces is a key enabler of integrated business processes and data between the Indus and Peoplesoft business applications. The interfaces or touchpoints are required to facilitate the transfer of control and transaction data. A diagrammatic representation of the interfaces and the data components passing between the two business applications is contained in Appendix 1. The categories below represent the areas where controls are in place to ensure availability, completeness, accuracy and timeliness of data. The areas covered in this Risk and Control Assessment address the components of integration that have not been included within the scope of the RACA documentation for either the Peoplesoft or Indus Passport business applications. This covers Peoplesoft messaging API s. Passport s Financial Integration APIs written in Oracle Stored Procedures feeding the Indus database EAI Touchpoints built using the Seebeyond application. The majority of data controls have been built into the overall architecture of the interfaces and specifically been built into the common error-handling framework (EHF). These control types are generic to all Touchpoints and are enabled through the architectural framework for the interface covering: Control data synchronization - code tables such as employee, vendor etc. Error handling controls validations within the EAI Touchpoints. Infrastructure failure controls fail over and recovery for gateways, e-ways or the network components. In parallel, the two API layers for each application contain their own process controls to ensure that only transactions that are valid for that application are passed through to the API to the interface layer. 3 ARCHITECTURAL DESIGN CONTROLS The Mitigating Actions Column describes the action taken by each of the three application interface components in this order: (a) Seebeyond EAI, (b) Passport, (c) Peoplesoft. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 4 of 24

5 3.1 CONTROL DATA SYNCHRONISATION I. Inconsistencies between PeopleSoft and Passport reference tables cause messages to fail at reception into either application covering: a. EAI: Each interface has a mapping spreadsheet, which confirms the translation of data from Passport to PeopleSoft. Due to the technical complexities of EAI, the stored procedures and interfaces, and the time constraints involved, the audit review focussed on review of the testing strategy, the Enterprise Application Integration Error Handling: Framework and Implementation, and the End-to-End (E2E) testing conducted and its documentation. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 5 of 24

6 Country / Province Currency Code UOM (Purchasing) Employee Type LBR-SAL PP Project Type PP Work Order Type PP Vendor Type Group Id to GL BU Sex Location to Location PCE/SCE/DCE to RSC type Buyer Ids b. Passport: The PP FI API validates inbound message data before posting to the appropriate PP table. If control (reference) data is not recognised, an error is recorded against the transaction and this is sent as an error return message through EAI back to PeopleSoft for correction. The message is not accepted into Passport. Messages that passes PP FI validation will be processed and the PP tables updated including the timestamps to indicate when it was updated or created. The E2E testing was designed to test the most common business scenarios that required a flow through of data through the various touchpoints between Passport and PeopleSoft. However, due to limited project time and resources, several scenarios were not completely tested E2E. Those scenarios that were not tested were omitted because a common functionality or interface was successfully tested in other scenarios. The rationale for limiting the testing and the scenarios chosen (not tested) was reasonable, but such limitations in testing can be risky. Therefore, after golive, the Sustainment Team should be prepared to have to deal with possible errors involved with those scenarios. The planned E2E testing was well carried out. Outstanding testing or control issues are being tracked and monitored. Any significant concerns are identified on the issues list appended to the EAI Control Advisory Report. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 6 of 24

7 c. PeopleSoft: Has no inbound message validation in the PS messaging. A record with incorrect or invalid data will pass through the EAI layer to the PeopleSoft messaging layer. On receipt into the appropriate module an error will be thrown if the data is invalid. Refer also to the PeopleSoft Application Messaging RACA_v1.document. Refer also to the PeopleSoft Application Messaging RACA_v1.document. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 7 of 24

8 3.2 ERROR HANDLING The primary goal of the EAI Error Handling strategy was to arrive at an extensible, modular design to be able to trap, edit and resend error messages to the destination systems in a consistent manner, maintaining the sequential nature of the messages. The Error handling architecture implemented provides the means to: Consistently identify when errors have occurred and provide adequate auditing/logging. Easily correct errors and resubmit corrected messages. Queue messages, maintaining any dependencies and sequencing Process in parallel (i.e. the existence of one erroneous message in error should not stop all other subsequent messages) Provide Notification ( s/alerts) either using the e*gate product itself or by interfacing with third party system software like BMC Patrol. The detailed specification for the EAI Error Handling Framework is in the document EAI Error Handling_v0.6_2002_12_08.doc. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 8 of 24

9 I. Data element errors are passed into the production system for Real-time inbound and outbound events includes: Duplicate records Corrupt Data Invalid / In Error Data Resent messages (after correction) See Batch processing process for detailed steps (process is the same). a. EAI: Based on the validations within each application, the data mappings, error handling framework and the publish/receive validations on the PS messaging and PP Stored Procedures, the EAI Error Handling Framework will identify, trap and sent notification on all incoming or outgoing errors according to the Touchpoint specifications and for each error, will record all key elements required for fault diagnosis, prioritisation and correction including: Identifying the action required when the error occurs (e.g. Resend). Error message as returned by the target application. Unique error number and time stamp for correction tracking Error Severity to prompt the appropriate corrective response. Force-Fail flag to identify if the message was failed in order to maintain the sequential nature of the messages. Interface Id denoting the source and target applications affected Message Detail Message Modified by Flag to identify the individual who modified or corrected the message. No of resends and timestamps Source and target systems ids Touchpoint number Unique key to identify the individual message. See Audit Comments in Section 3.1 covering the general approach in reviewing integration controls. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 9 of 24

10 b. Passport: The PP FI API validates inbound message data before posting to Passport. If the Stored Procedure fails or the collaboration fails due to missing, invalid or out of date Passport or PeopleSoft data then: the PP FI API sends an appropriate error code and description of the error to the Passport e*way EAI s error handling component will store the PeopleSoft message that failed the Passport e*way calls or paging e*way to send or page with error message/information to designated support personnel resolving the data problem may involve updating data in Passport, changing the XML message Outbound messages created by the PP FI API are kept for reference until they are purged from the online system. This enables PP FI API to track the detail of outbound messages and resend them from PP FI. The message passing mechanism designed between EAI and PP API ensures that only complete messages will be sent to PS. See Audit Comments in Section 3.1 covering the general approach in reviewing integration controls. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 10 of 24

11 c. PeopleSoft: PeopleSoft currently has no mechanism for identifying and preventing the transmission of duplicate records. Data from source is validated against CTF Data brought into the interface must pass the component interface validation or will be held with an error status Mapped data is based on tables validated and maintained by The PeopleSoft systems and the Passport System. Data brought into the interface table is validated by the component interface to check for duplicate key values Query of Project and Activity interface table that totals number of rows received by interface ID, system source. Interface message log that counts number of rows received in PS by interface. Control total report of lines extracted from legacy mainframe system. Refer also to the PeopleSoft Application Messaging RACA_v1.document. Refer also to the PeopleSoft Application Messaging RACA_v1.document. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 11 of 24

12 II. Data element errors are passed into the production system for Batch inbound and outbound events includes: Duplicate records Corrupt Data Invalid / In Error Data Resent messages (after correction) a. EAI: On entry into the e*way, the message is checked to determine if it is an original or a RESEND event. IF NOT A RESEND, the message sequence is checked. If there are no prior dependent messages in the queue, normal event processing applies. If there are dependent messages in the queue, a Force Fail Exception is generated and a USER EXCEPTION is thrown requiring manual intervention to correct the record in the IQ Error Stack. IF A RESEND, the message payload (content) is extracted, time-stamped, validated and checked for its sequence in the batch. If there are no prior dependent messages in the queue, normal event processing applies. IF a RESEND error occurs, the error is checked for USER exceptions (data validation failures) or UNMARSHAL (system validation failures). In both cases the result is sent to the IQ Error Stack for manual intervention and correction. b. Passport: (Staging Table INSERT). If the call to insert data into the Staging Table fails or the collaboration fails due to missing, invalid or out of date Passport or PeopleSoft data then: the PP FI API sends an appropriate error code and description of the error to the Passport e*way EAI s error handling component will store the PeopleSoft message that failed the Passport e*way calls or paging e*way to send or page with error message/information to designated support personnel See Audit Comments in Section 3.1 covering the general approach in reviewing integration controls. See Audit Comments in Section 3.1 covering the general approach in reviewing integration controls. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 12 of 24

13 resolving the data problem may involve updating data in Passport, changing the XML message batch data received from PS will be kept online for a predetermined period of time until they are archived off. unique indexes are created in the staging table to catch duplicate messages received from EAI (Staging Table PROCESSING). If the call to the stored procedure fails due to missing, invalid or out-of-date Passport or PeopleSoft data then: The stored procedure will mark the event as INVALID PP FI API returns an appropriate error code and description to notify the Passport e*way that one or more of the messages were not processed. The Passport e*way calls or paging e*way to send or page with error message/information to designated support personnel Control totals are created on a log that identifies the number of records processed and the logs are kept for a predetermined period of time until they are archived off the server. The timestamps for the rows updated or created by PP FI API are updated. c. PeopleSoft: Refer also to the PeopleSoft Application Messaging RACA_v1.document. Refer also to the PeopleSoft Application Messaging RACA_v1.document. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 13 of 24

14 3.3 INFRASTRUCTURE FAILURE CONTROLS I. EAI system down for a period of time, and the other applications unable to access it. a. EAI Application messages will queue up on the application side, or within egate. No application messages will be lost. All critical errors will be sent to NCS 24X7 Operations Centre via call out, to be addressed per operational procedures (restart, call-out, etc.). The disk space for EAI IQ is sized to handle data volumes for downtime of up to 7 days. b. Passport On recognition that the E-way is not available, all PP messages remain within the Passport Oracle database until polled (called for) by the E-way once it is restored. Data storage within the Oracle database is unrestricted and can easily store messages for 7 days. c. PeopleSoft The PS application will poll every 20 seconds for 3 consecutive attempts to connect to the PS E-way after which time it will time out and the message remains unsent within the PS database (unrestricted capacity). An notification is automatically sent to NCS Support requiring the reason for the time out to be determined. Once determined and the E-way is restored, the queued messages will require a manual restart to resend them. Due to technical complexities of this area, these controls were not tested. However, the proposed actions appear reasonable. Due to technical complexities of this area, these controls were not tested. However, the proposed actions appear reasonable. Due to technical complexities of this area, some of these controls were not tested (e.g. E Way). However, the proposed actions appear reasonable. See Application Messaging RACA_V1 Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 14 of 24

15 II. The other receiving applications down for a period of time, with EAI messages remaining unprocessed in their queues. III. Batch Interface Scheduling Failure a. EAI (only applicable application) The EAI error-handling framework retains the sequence and dependencies of messages within the sending IQ to ensure correct sequence processing when the receiving application is restored. These records are held within the EAI error IQ and When the PS gateway is down a notification is received by the EAI PS e*way and on notification of this error, the e*way is shut down and the message that was attempted to be sent is stored in the error database. All other inbound messages are stored in the e*way IQ. Once the connection is restored, notification is required from the systems administrator that the application is restored and a manual intervention is required by the Support team to re-start the e*way and re-send the messages stored in the Error Database. With PP messages, when the PP application is down, an attempt will be made to re-connect and if the application is still down, the message will be sent to the error database. As the e*way is not shut down, once the application is restored, the inbound messages stored in the error database will require the Support team to re-start the e*way and re-send the messages stored in the Error Database. An automated batch-scheduling tool (ESP) has been implemented for the integrated batch net for the PeopleSoft, Indus Passport and Seebeyond batch routines along with the application and server routine back-ups. Manual oversight is maintained as part of the ABS ITI 24x7 operations and operator intervention is available should the net run into processing difficulties. Due to technical complexities of this area, these controls were not tested. However, the proposed actions appear reasonable. No Audit testing of permanent solution. However, the proposed actions appear reasonable. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 15 of 24

16 Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 16 of 24

17 IV. EAI System failure or memory loss Two servers are run in a clustered configuration providing real-time fail-over recovery. The two servers each have 7Gb of memory and the current peak load during testing (including the use of the Load Runner performance monitoring tool) has been 3 GB giving over 100% peak capacity available. In the event of memory leaks and the entire 7Gb on one server is consumed, the second server will cut in as a failover and the memory loss will be eliminated on this second server. Daily back-ups are retained for 30 days allowing recovery for almost a Calendar month of transactions. Due to technical complexities of this area, these controls were not tested. However, the proposed actions appear reasonable. Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 17 of 24

18 Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 18 of 24 APPENDIX A INDUS-SEEBEYOND-PEOPLESOFT APPLICATION INTEGATION SCHEMATIC

19 APPENDIX B: EAI TOUCHPOINT DATA SYNCHRONIZATION TP No 1 Account PS General Ledger parent accounts 2 Activity PS General Ledger product. Interface Data From Data To Synchronization Impact Timing Complexity 3 Cost Center PS General Ledger department 5 Project PS Projects and Activities 6 Vendor PS Accounts Payable Vendors 7 Employee PS Pay / Human Resource employees and their job codes 8 Labour Rate PS Pay / Human Resource hourly labour rate by employee PP System Administration account. PP System Administration activity PP System Administration cost centre. PP Data Project and User Def. PP Data Module Vendors PP Data Module personnel data and their job class (also known as resource code in PP). PP Data Module hourly rate by personnel. Real Time Low Real Time Real Time Real Time Real Time Real Time Real Time Low Low Medium Medium Medium Medium Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 19 of 24

20 TP No 9 Accounts Payable Actuals EAI FINANCIAL INTEGRATION PROJECT Interface Data From Data To Synchronization Impact Timing Complexity PS Accounts Payable Actuals back PP to support the supply chain management process and average unit price adjustments. 10 Contracts PP Contract data PS to support supply chain processes by passing trigger data to the purchase order interface. 11 Purchase Order PP Purchasing Purchase Order information 12 General Ledger Transactions 13 Project Accounting Transactions 14 Property Unit In- Service and As Built PP source system transactions PP source system transactions PP Work Management Property Unit information related to work order tasks PS GL and Accounts Payable PS General Ledger. PS Project Costing PS Project Costing. Unit of Measure impacts AP (TP9), Contracts (TP10), & PO (TP11) Batch Real Time Real Time Batch Batch Real Time High Medium Medium High High Medium Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 20 of 24

21 TP No 15 Work Order / Task EAI FINANCIAL INTEGRATION PROJECT Interface Data From Data To Synchronization Impact Timing Complexity 19 PP Job Type and PS Activity Type 20 PP Vendor Type and PS Vendor Class 21 PP Catalogue Id and PS Inv Item Id PP Work Management work order, work order status (summarised), work order task and work order task status (summarised) and work order task estimates by detailed cost element. PP System Administration job type (must contain the same values as ) PP System Administration vendor type must contain the same values as ) PP Data Module catalogue-ids 23 Client Ids PS Customer and related information PS Project Costing project, project status (summarised), project activity and project activity status (summarised) and creates project resource rows for each estimate by resource subcategory. PS Project Costing activity type. PS Project Costing vendor class. PS Items Ids must contain the same values. If these are not synchronised, work order tasks passed from PP to PS will not be available for use in PS Project Costing. If these are not synchronised, vendors passed from PP to PS will not be available for use in PS Accounts Payable. If these are not synchronised, catalogue-ids passed from PP to PS will not be available for use in PS. This will impact both PS Accounts Payable and PS Project Costing (proj_resource table). Real Time Manual Manual Real Time Medium PP client Ids Synchronises revisions. Real Time Medium Low Low Low Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 21 of 24

22 TP No Interface Data From Data To Synchronization Impact Timing Complexity 26 MR PP commitment PS Project Batch High Commitments information. Costing. 30 Labour Hours and Dollars Batch High 33 PS Currency- Code to PP Currency Code 36 PR, PO, CR and CO commitments from PBOOK PS Labour hours and labour billings recorded in Projects PS currency codes and rates To pass commitment lines that relate to PR and CR to PeopleSoft PP PBOOK to support PP repair versus replace functionality and viewing labour hours in PP. PP Labour Hours This interface will pass labour hour transactions to the PP PBOOK (Accounting Transaction Table). Once in PBOOK the information will be available to support delivered PP processes and panels. PP must use the same currency codes and rates as PS. Real Time Batch Low Medium Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 22 of 24

23 APPENDIX C: NON-EAI (MANUAL) DATA SYSNCHRONIZATION Ref. Interface Data From Data To Synchronisation Impact Timing Complexity 16 PP Cost Elements & PS Resource Codes 17 PP Project Type and PS Project Type 18 PP Work Order Type and PS Project Type 19 PP Job Type and PS Activity Type 20 PP Vendor Type and PS Vendor Class PP System Administration Module detail, secondary and primary cost elements must contain the same values as PP System Administration project type (must contain the same values as ) PP System Administration work order type (must contain the same values as ) PP System Administration job type (must contain the same values as ) PP System Administration vendor type must contain the same values as ) PS Project Costing resource sub-category. category and type PS Project Costing project type. PS Project Costing project type. PS Project Costing activity type. PS Project Costing vendor class. If these are not synchronized, projects passed from PS to PP will not be available for use in PP for reference on work orders and thus the work order / task interface will not be supported. If these are not synchronized, work orders passed from PP to PS will not be available for use in PS Project Costing. If these are not synchronised, work order tasks passed from PP to PS will not be available for use in PS Project Costing. If these are not synchronised, vendors passed from PP to PS will not be available for use in PS Accounts Payable. Manual Manual Manual Manual Manual Low Low Low Low Low Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 23 of 24

24 4 Property Unit / Profile PS Asset Management Profile ID PP Data Module Property Unit NA Low Prepared by: David Priestley Last Saved: 06/03/03 9:49 AM Page 24 of 24