Development Process

FSR

Project: Document: Subject:

Prepared by: Date: Version:

FSR KT – Understanding document Development Process

Balaji Gangadhar B Jun2007-06-13 Draft 0.1

FSR

Version History: Version

Date

By

Changes

0.1

13 Jun

Balaji Gangadhar B Initial version

Contributors: Name

Santhosh Eturi Uthranarayani

Role

Location

Remarks

FSR

CONTENTS

FSR

1 Overview This document explains about the development process involved in the FSR Framework.

2 Taxonomy FSR Framework uses database driven change control mechanism, wherein business users enter the request on set of predefined tables and raise a change request via share point, which will be communicated to ETL Team. Upon receiving the communication and approval of change request, CR coordinator analyse the requirement and perform synchronization of the requirement from work area to live area, then notify the ETL development team about the new request. Prerequisite: • •

Share point access Access to the FEED_D.GII_OWNER schema

3 Current Implementation The current implementation is segregated into the following segments. ETL 1 Processing The FSR framework process begins once the run for the individual feed is completed and the data is available in the corresponding GFIS table in the ETL environment. The value ‘Y’ in DATA_PRESENCE_FLAG column in the T_GW_STP_STARTUP table indicates that the data is available in the corresponding GFIS table and it is ready for further processing. This source data from GFIS table is taken and it is directly loaded in the T_GW_TMP_PROCESSED_DATA table in the GII environment with a STAGE_NO value ‘0’. Every row that is populated in this T_GW_TMP_PROCESSED_DATA table will acquire a unique RECORD_ID. The records with STAGE_NO ‘0’ are taken for a particular PRC_PROCESS_ID and FEED_ID and are allowed to traverse through the various engines present in the framework. There are 9 processing engines in which each engine comprises of many components. The input record is propelled through each component and the respective output record is also stored in the same T_GW_TMP_PROCESSED_DATA table, with the STAGE_NO increased by 1 for every stage. In this process the PRC_PROCESS_ID, RECORD_ID and FEED_ID remains the same for a particular record. On completion of the first 8 processing engines the ‘Target Load Entry’ engine, which is the final engine in FSR starts processing. This Target Load Entry engine selects the records with the maximum STAGE_NO for a particular PRC_PROCESS_ID and FEED_ID and makes it

FSR available for generating the target file. The target file is then generated for the respective target systems depending on the requisite file format. The generated target file is send to the SAP R/3 server. ETL2 Processing The source data is taken from SAP R/3, and is loaded in the T_GW_TMP_PROCESSED_DATA table with stage_no ‘0’. The reference data is loaded from the SAP RDM tables to the GFIS reference data tables with a unique feed_id of 10021. This data will be processed as per the rules declared in the taxonomy table. The records with STAGE_NO ‘0’ are taken for a particular PRC_PROCESS_ID and FEED_ID and are allowed to traverse through the various engines present in the framework. The input record is propelled through each component and the respective output record is also stored in the same T_GW_TMP_PROCESSED_DATA table, with the STAGE_NO increased by 1 for every stage. In this process the PRC_PROCESS_ID, RECORD_ID and FEED_ID remains the same for a particular record. On completion of the initial processing engines the ‘Target Load Entry’ engine, which is the final engine in FSR starts processing. This Target Load Entry engine selects the records with the maximum STAGE_NO for a particular PRC_PROCESS_ID and FEED_ID and makes it available for generating the target file.The target file is then generated for the respective target systems depending on the requisite file format. The generated target file is send to the SAP BW server. Portal Processing The error records detected in ETL1 processing is sent to portal for manual correction. The corrected records are sent back to ETL environment from validation. Once the file containing the corrected records is ready for validation the Portal server publishes a JMS message to the ETL server. The ETL server subscribes this JMS message from Portal, which contains the corrected file details. The JMS message contains the processing type information (MAN, FLA, NFI) and the action type also (Validate, Post). These input records are loaded in the T_GW_TMP_PROCESSED_DATA, where the data validation is done. If no errors are detected then the corrected file is uploaded to the SAP server. If any errors are detected during validation, the error file is again sent to Portal for correction.

FSR

4 New CR Process flow

1. Receive approved CR or Bug from SharePoint

DEVELOPERS Saving updated Informatica objects in CVS and including in Daily Delivery

2. Make changes/corrections in Informatica PC_DEV environment

3. Add CR or Bug SharePoint id in Metadata Extension (on Mapping, Mapplet or Workflow level):

Add new Bug or CR number at the end of existing Metadata Extension

Bug Fixes: 123, 133, 177 Change Requests: 65, 71,72

4. Go to CVS directory on your local PC: \db_cvs\dbFeeds\dev\Informatica\ GII_Gateway

5. Connect to DEV repository: connect_dev.cmd (not needed if you already connected to DEV)

6. Export changed workflow from Informatica:

Export workflows from GW_APAC_1 folder, as this folder is used for baselining versions from UAT

export_workflow.cmd GW_APAC_1 wf_<engine name> (i.e export _workflow.cmd GW_APAC_1 wf_B9_4_APAC _ALL )

“CVS Header” and “CVS Revision” Metadata Extensions are updated here by CVS internally 7. Go to WinCVS and commit changed files, adding as a comment latest CR or Bug number: Bug Fixes: 177 Change Requests: 71,72

Write only new Bug or CR numbers in CVS “log message”

8. Update Daily Delivery file with your xml-file: Z:\A-ETL\80-Feeds\GII_Gateway\Global\Build\UAT_delivery version_objects.txt Add new line: w.GW_APAC_1.wf_<engine name> (i.e. w.GW_APAC _1.wf_B9_4_APAC_ALL)

This file will be used by Release Manager for preparing Daily Delivery

FSR