[ ML 497 ] IRS Aggregation - TSD

8/6/2019 [ ML 497 ] IRS Aggregation - TSD

http://slidepdf.com/reader/full/-ml-497-irs-aggregation-tsd 1/34

Fidelity Investments

Enterprise FSDM

IRS Aggregation

Version:

0.1

Project ID.

FILI10_FSY-DEV-PI-FILI10 IRS Aggregation

Publication Date:

June 7, 2011

Design Build and Test Transition

TSD TPD UPD SAT TRA PIR

FSDMLifecycle

Requirements Analysis

SRA PERAIP

Solution Definition

SDS PAI PSD

Project Initiation

PPI

Fidelity Internal Information



Fidelity InvestmentsTechnical

Systems Design

Enterprise FSDM FILI Systems Modernization

Version History Table

Version

number

Date Originator Reason for change Review Approval

0.1 02/08/2011 ART Initial version

TSD Technical Systems Design Template Version 2.0Copyright © 2006 FMR Corp. All rights reserved.

06/07/2011 Version 0.01 Fidelity Internal Information - ii -




Systems Design


Table of Contents

IRS Aggregation.......................................................1Version History Table...............................................iiTable of Contents...................................................iii

1 Project Background and References ............................. 11.1 Purpose ...................................................................................... 11.2 References .................................................................................. 1

2 Technical Framework .............................................. 32.1 Technical Environment Specifications ................................................... 32.2 Technical Constraints ...................................................................... 32.3 System Standards ........................................................................... 32.4 Security Classification ...................................................................... 3

3 System Framework ................................................. 43.1 Existing System Model...................................................................... 43.2 Proposed System Model.................................................................... 5

4 Development Package ............................................. 74.1 Implementation Unit Design ............................................................... 7

4.1.1 IRS Aggregation Inquiry screen ............................................................74.1.2 UpdateCostBasis transaction change ....................................................114.1.3 IRS Warning validation check ...........................................................134.1.4 Calculation engine ............................................................................144.1.5 CIL View .........................................................................................19

4.1.6 ODS table ........................................................................................194.1.7 Control-M job ...................................................................................194.1.8 IRS Aggregation Report ....................................................................20

4.2 Technical Data Design .................................................................... 224.3 Development and Integration Plans .................................................... 234.4 Training Support Requirements ......................................................... 23

5 Specifications for Operational Requirements ................. 245.1 Operations Specifications ................................................................ 245.2 Capacity Plan Impact ..................................................................... 255.3 Contingency Plan Impact ................................................................. 25

6 Unit Test Specifications .......................................... 266.1 Prototype Testing ......................................................................... 26

6.2 Unit Testing ................................................................................ 266.3 Integration Testing ....................................................................... 266.4 Test Procedure ............................................................................. 27

7 Conversion System Design ....................................... 288 Approvals ........................................................... 299 Appendices ......................................................... 30

9.1 Unit Test Case Specifications ............................................................ 30

06/07/2011 Fidelity Internal Information Version 1.00 - iii -




Systems Design


9.2 Roles and Responsibilities for TSD ...................................................... 30

06/07/2011 Fidelity Internal Information Version 1.00 - iv -




Systems Design


1 Project Background and

References1.1 Purpose

This document details the technical specification for the requested IRSAggregation functionality in ARK.

1.2 References

The functional requirements were taken from:

Non-Financials:

http://sharepoint.fmr.com/sites/FILI_BPR/AdminServer %20documentation/Platform%20BPRs/Reconciled%20BPRs/BPR_AllProducts_NonFinancials_Reconciled.doc

UpdateCostBasis:

http://sharepoint.fmr.com/sites/FILI_BPR/AdminServer %20documentation/Platform%20BPRs/Reconciled%20BPRs/BPR_NRRFPRAFGGIMGGI_UpdateCostBasis.DOC

Edits:

http://sharepoint.fmr.com/sites/FILI_BPR/AdminServer %20documentation/Platform%20BPRs/Reconciled%20BPRs/BPR_AllProducts_Edits_Reconciled.xls

Phone Inquiries:

http://sharepoint.fmr.com/sites/FILI_BPR/AdminServer%20documentation/Platform%20BPRs/Reconciled%20BPRs/BPR_AllProducts_PhoneInquiries_Reconciled.doc

IRS Aggregation Rules:

http://sharepoint.fmr.com/sites/RS11Q1/FILI%20IRS%20Aggregation/Shared%20Documents/FSDM/01%20-%20PPI%20(Business%20Documents)/AA%20-%20Charter%20and%20Requirements/Revised_All-in-one_AGGREGATION%20in%20Business%20Terms_092508.doc

IRS Aggregation MS Excel Utility ( Actuary tool ):

06/07/2011 Fidelity Internal Information Version 1.00 - 1 -

http://sharepoint.fmr.com/sites/FILI_BPR/AdminServer%20documentation/Platform%20BPRs/Reconciled%20BPRs/BPR_AllProducts_NonFinancials_Reconciled.doc



http://sharepoint.fmr.com/sites/FILI_BPR/AdminServer%20documentation/Platform%20BPRs/Reconciled%20BPRs/BPR_NRRFPRAFGGIMGGI_UpdateCostBasis.DOC



http://sharepoint.fmr.com/sites/FILI_BPR/AdminServer%20documentation/Platform%20BPRs/Reconciled%20BPRs/BPR_AllProducts_Edits_Reconciled.xls




























Systems Design


http://sharepoint.fmr.com/sites/RS11Q1/FILI%20IRS%20Aggregation/Shared%20Documents/FSDM/01%20-%20PPI%20(Business%20Documents)/AA%20-%20Charter%20and%20Requirements/Aggregation%20v6.0.xls

http://sharepoint.fmr.com/sites/RS11Q1/FILI%20IRS%20Aggregation/Shared

%20Documents/FSDM/01%20-%20PPI%20(Business%20Documents)/AA%20-%20Charter%20and%20Requirements/Aggregation%20v6.7.xls

IRS Aggregation Test Cases:

http://sharepoint.fmr.com/sites/RS11Q1/FILI%20IRS%20Aggregation/Shared%20Documents/FSDM/01%20-%20PPI%20(Business%20Documents)/AA%20-%20Charter%20and%20Requirements/Examples%20with%20tax%20form%20information_070809_v5.xls

IRS Aggregation Report Layout:

http://sharepoint.fmr.com/sites/RS11Q1/FILI%20IRS%20Aggregation/Shared%20Documents/FSDM/01%20-%20PPI%20(Business%20Documents)/AA%20-%20Charter%20and%20Requirements/IRS%20Aggreg%20Report%20Requirements.xls

http://sharepoint.fmr.com/sites/RS11Q1/FILI%20IRS%20Aggregation/Shared%20Documents/FSDM/01%20-%20PPI%20(Business%20Documents)/AA%20-%20Charter%20and%20Requirements/IRS%20Aggregation%20Feeds_Reports%20Requirements.xls






































Systems Design


2 Technical Framework

2.1 Technical Environment SpecificationsThis effort shall be packaged as part of the ARK Maintenance release,R11.02.00.

R11.02.00’s development and testing environments shall be used for thiseffort.

2.2 Technical ConstraintsThe constraints on this design are as follows:

o ARK configuration has limited flexibility with screen interface designs.

o Hyperion reporting is normally sourced from ODS. The requirement for

this effort demands for using a single calculation engine for both reportand screen interface. In this case, ARK screens are maintained in theprimary AdminServer/recordkeeping management system database.

o Inquiry screen information are typically hypothetical data. The design

of this component shall rely on the last known information about theunderlying assets of a policy.

2.3 System StandardsLinks to Informatica, Brio and Control-M standards are specified by thecommon SRA for all batch cycle jobs.

2.4 Security ClassificationBatch jobs are responsible for applying Fidelity’s SP2I standards to any feedsand reports.





Systems Design


3 System Framework

The business interface component of the IRS Aggregation functionality shallcomprised of changes in the screen interfaces and validation checks in ARKand an introduction of a new Hyperion report.

3.1 Existing System ModelAssessment of IRS aggregation based implications and cost-basis adjustmentsare typically aided by custom applications such as the MS Excel applicationutility provided by Actuaries, Aggregation v6.0.xls.

Processed withdrawal related activities of annuity contracts that are eligible forIRS aggregation are re-processed with applicable cost-basis adjustments. Thisis done via the UpdateCostBasis transaction interface as shown below.

Figure 1 – Update cost basis interface








Systems Design


3.2 Proposed System Model

The solution design is governed by the illustrated technical framework below.

CIL

ADMINSRV

Ark Config interface calls toGeneric Aggregation Engine

PKG_IRS_AGGR

Hyperion Report Jobs

Tuesday, A

High Level Implementation

ARK

Cost BasisTaxable Amount

request

response

invoke

Report Table/s

1) Execute

Control-M job/s

Refresh Load

2) Generate

Procedure toPre-Load to cil tables

Invoke and Access

1) Read From

BQY/Pdf/xlsReport

2) Generate

At a high-level, the implementation shall comprise of the followingcomponents:

i. Calculation engine which retrieves prevailing cost basis informationfrom all IRS aggregation relevant contracts and accepts two types of inputs:

o hypothetical withdrawal information; and,

o processed withdrawal information, which includes consideration to

surrender charges.

ii. A new policy based Inquiry Screen interface that:

o captures user entries for hypothetical withdrawal;

o identify and display relevant contracts, along with their cost basisinformation, to the IRS aggregation rule ( see implementationunits for specific details derived from the BRD );

o report cost basis adjust adjustment and taxable amount

information based on user keyed-in data.

iii. A new CIL database object view that :o Invokes the calculation engine with IRS aggregation relevant

policies that were recently processed for a withdrawal; and,o Provide a result set for batch reads.





Systems Design


iv. A new ODS database table object that :

o Allows for a persistent storage of IRS aggregation records; and,

o Serve as source repository for reporting.

v. A new control-M job component that :

o Reads result set information from the new CIL view; and,

o Copies them to the new ODS table.

vi. A new reporting component that :

o Runs on a nightly cycle basis; and

o Gathers processed transactions that are subject to IRS

aggregation along with their required data adjustments,particularly cost basis information.





Systems Design


4 Development Package

4.1 Implementation Unit Design

This effort shall introduce the following functional components.

4.1.1 IRS Aggregation Inquiry screen

This new screen interface, basically, shall replicate the features of the MSExcel application for hypothetical IRS Aggregation calculation. Shown below isthe proposed screen layout.





Systems Design


Figure 2 – IRS Aggregation Inquiry screen

Basic Course of Events:

a. From within a screen policy context, user shall open the

IRS Aggregation screen by selecting Inquiry IRSAggregation menu item.

b. Upon opening the IRS aggregation screen, the screen shall





Systems Design


default to displaying:

i. valuation date field as system date;ii. five (5) contract information placeholders;iii. contract 1 fields shall be sourced from the current

policy context;

iv. succeeding contracts fields shall be filled for up toanother four (4) contracts as sorted by their issuedate in ascending order. These contracts shall:

+ have the same primary owner SSN ( regardlessof client type ),+ are issued in the same calendar year,+ are issued by the same company:

- NRR, FPRA, FGGI- ENRR, PRA, FGGI NY- MGGI- MGGI NY

+ are in Active status+ not have any of the following substatuses:

-5 yr. Option- Annuitize- Continue- Continue Annuitant- Continue Beneficiary- Continue-Pending Conversion- Death Claim Pending- DIVCON-Pending Conversion- DIVCP-Pending Conversion- Divorce- Divorce Continue- DTHCP-Pending Conversion

- Lump Sum- Met Annuitization- Open Unsettled- OpnUn-Pending Conversion- Period Certain

v. each contract shall display the following read-onlyinformation:

+ contract number+ account value+ pre TEFRA gain

+ Unknown Amount+ pre TEFRA basis

+ post TEFRA basis+ post TEFRA gain

* these values are as of the indicated Valuationdate.

vi. each contracts shall have a modifiable field forWithdrawal Amount $.





Systems Design


c. the result portion of the screen shall display the followingby default:

+ contract number – as current policy in context+ policy issue date – issue date of the policy+ pre TEFRA basis - $0.00

+ pre TEFRA gain - $0.00+ post TEFRA basis - $ 0.00+ post TEFRA gain - $ 0.00+ Unknown Amount - $ 0.00+ taxable Amount - $ 0.00

d. Upon entering a withdrawal amount, user shall be able toclick the OK button to display the calculated Cost Basisadjustments, including the resulting taxable amount in thebottom part of the screen. The bottom or result screen shallallow for displaying maximum line entries from 5 to 100.

The result screen shall itemized the following calculated

information:

+ contract number+ policy issue date+ pre TEFRA basis+ pre TEFRA gain+ post TEFRA basis+ post TEFRA gain+ Unknown Amount+ taxable Amount

AlternativePaths:

User shall be able to close the screen by hitting the Closebutton.

Exception Paths: A ( 1 ). If the number of contracts exceeds 5, then promptfor an informational message specifying the screen limit.

[ Placeholder ]. Do not allow calculation to occur.

b ( 1 ). If the valuation date is entered in the past, thenprompt the user for an invalid date entry.

d ( 1 ). If no withdrawal amount is entered in any of thecontract, then display the result portion with defaultinformation.

d ( 2 ). if a negative amount is keyed-in for withdrawal, thenprompt the user for an invalid entry message:

Assumptions: None

Pre Conditions: IRS Aggregation screen shall be available from within a Policycontext.





Systems Design


Post Conditions: The new inquiry screen shall be able to provide hypotheticalcost basis and taxable amount information as a product of IRS aggregation consideration.

AffectedapplicationcomponentInventory:

1. IRS Aggregation ScreenType: ARK Inquiry screen rule configurationStatus: New

2. PKG_IRS_AGGRType: ARK Oracle package/stored procedureStatus: New

3. PKG_INQUIRY_SCREENType: ARK Oracle package/stored procedureStatus: Existing

Source Inventory( Config ):

IRS AggregationInquiry Screen.xml

4.1.2 UpdateCostBasis transaction change

Add ‘Aggregation’ as new entry in the drop-down selection box control forspecifying “Change Reason”, as shown below.





Systems Design


Figure 3 – UpdateCostBasis drop down change


a. user shall access the screen as a transaction selection inARK’s Activity detail screen.

b. use shall select the appropriate change reason entry

Alternative

Paths:

Exception Paths:Assumptions:

Pre Conditions:

Post Conditions:

AffectedapplicationcomponentInventory:

1. CopyBook-UpdateCostBasisType: ARK copybook rule configurationStatus: Existing

Source Inventory( DML ):

asrules_adminsrv_stup_dml_R11.02.00.





Systems Design


4.1.3 IRS Warning validation check

Enforce a warning validation check on partial withdrawal based transactions toindicate if the contract may be subject to IRS aggregation.

Figure 4 – New validation edit

Basic Course of

Events:

a. Note: memo code need to be considered to determine if

activity/w/d is eligible for IRS aggregation i.e. 1035.

AlternativePaths:

Exception Paths:

Assumptions:

Pre Conditions:

Post Conditions:

Affectedapplicationcomponent

Inventory:

Products:- NRR, FPRA, FGGI- ENRR, PRA, FGGI NY

- MGGI- MGGI NY

ValidationExpressions and transaction/copyBooks for:o Withdrawal

o WithdrawalMax

o Surrender

Type: ARK copybook rule configurationStatus: Existing





Systems Design


Source Inventory( Config ):

CopyBook-Withdraal.xml

NRR WithdrawalValidateExpression.

CopyBook-WithdraalMax.xml

NRR WithdrawalMaValidateExpression.

CopyBook-FullSurreder.xml

NRR SurrenderValidateExpression.

GGI Transaction-Withdra

GGI WithdrawalValidateExpression.

GGI Transaction-Withdra

GGI WithdrawalMaxValidateExpression.

GGI Transaction-Surrend

GGI SurrenderValidateExpression.

4.1.4 Calculation engine

The calculation engine shall be hosted in the ADMINSRV database andimplemented as an Oracle stored procedure package. The following interfacesshall be made available from the engine:

PKG_IRS_AGGR :

o fnc_is_irs_aggr_po_substatus – to determine if a given

contract qualifies for IRS Aggregation based solely on policy substatus

Basic Course of

Events:

a. list other contract

which:+ are issued by the company:

- NRR, FPRA, FGGI- ENRR, PRA, FGGI NY- MGGI- MGGI NY

+ are in Active status+ do not have any of the following substatuses:

-5 yr. Option

- Annuitize- Continue- Continue Annuitant

- Continue Beneficiary- Continue-Pending Conversion- Death Claim Pending- DIVCON-Pending Conversion- DIVCP-Pending Conversion- Divorce- Divorce Continue- DTHCP-Pending Conversion- Lump Sum- Met Annuitization





Systems Design


- Open Unsettled- OpnUn-Pending Conversion- Period Certain

b. if count of contracts in step b is greater than zero (0) then return

TRUEd. Disbursement code needs to be regular disbursement.

AlternativePaths:

a. if there is no active owner then return FALSE.

Exception Paths: If a processing / system error is encountered, then returnFALSE.

Assumptions: Valid policy identifier is provided from calling system i.e.front-end.

Pre Conditions: This module requires the following inputs:a. policy GUID

Post Conditions: Returns TRUE if a given contract with a specified activityeffective date is subject to IRS aggregation.

Returns FALSE if a given contract with a specified activityeffective date is NOT subject to IRS aggregation.

o FNC_GET_MATH_VALUES – identify a policy’s most recent

ASACTIVITYMATH.MATHVALUE entry based on a given mathname andeffective date.


N/A

AlternativePaths:

Exception Paths: If data cannot be found, return NULL.

Assumptions:

Pre Conditions: Unique Activity GUIDAsActivityMath.MathName

Post Conditions: AsActivityMath.MathValue

o fnc_get_irs_pol_num_by_pos – primarily used by the ARK inquiry

screen front-end to display a specific contract based on issue date





Systems Design


based ranking position given an owner client guid, transaction effectivedate, current contract in context and a position number.


a. identify IRS aggregation eligible contracts other than thegiven policynumber owned by the client.

b. Order and assign a rank number for each contract based

on issue date sortingc. Return contract number which match the given position

number

AlternativePaths:

a. return an empty string.b. return an empty string.c. return an empty string.

Exception Paths: If a processing / system error is encountered, then returnFALSE.

Assumptions:

Pre Conditions:

Post Conditions: Return an IRS eligible contract number owned by a givenclient.

o prc_sort_wd_list – module to sort a given list of contract

withdrawals based on policy issue date. This is primarily used by thecost basis adjustment calculation engine.

Basic Course of

Events:

AlternativePaths:

Exception Paths:Assumptions:Withdrawals happened on the same day.

Pre Conditions:

Post Conditions:

o prc_set_on_top_of_list – module to place a specified contract at

the topmost or as first element of the withdrawal contract list. This isprimarily used by the cost basis adjustment calculation engine.


AlternativePaths:

Exception Paths:

Assumptions:Withdrawals happened on the same day.

Pre Conditions:





Systems Design


Post Conditions:

o fnc_parse – module specifically implemented to handle the list of

withdrawals passed from the Inquiry Screen. This parses the elementsfrom the front-end’s passed string as delimited by a ‘|’ and ‘;’ .


AlternativePaths:

Exception Paths:


Pre Conditions:

Post Conditions:

o fnc_get_cb_info – module to retrieve the cost basis information of

a policy given the effective date.


AlternativePaths:

Exception Paths:


Pre Conditions:

Post Conditions:

o fnc_calc_inquiry_screen – module specifically designed for the

ARK inquiry screen front-end that returns the taxable amount and theadjusted cost basis based on the IRS Aggregation computation.


Alternative

Paths:Exception Paths:


Pre Conditions:

Post Conditions:





Systems Design


o fnc_calc_report – module specifically designed for the controlM

job which populates a persistent table for Hyperion reporting usage.


AlternativePaths:

Exception Paths:


Pre Conditions:

Post Conditions:

o fnc_calc_report – module specifically designed for the controlM

job which populates a persistent table for Hyperion reporting usage.This specifies specific column names to match the target persistenttable.


AlternativePaths:

Exception Paths:


Pre Conditions:

Post Conditions:

o fnc_calc_irs_aggr – core module which executes the cIRS

Aggregation calculation. This is based on the Aggregation v7.0MS

Excel program that Actuary provided.


AlternativePaths:

Exception Paths:

Assumptions:

Pre Conditions:

Post Conditions:





Systems Design


4.1.5 CIL View

4.1.6 ODS table

4.1.7 Control-M job





Systems Design


Identification: FO_

Description: This job runs the.

Job Schedule FO_AS_LOAD_ DLY is the predecessor job.

FO_AS_ _DLY is the successor job.

Input: Variable File / Parameter Comment

$ENV_FILE environment variables Defined in *_variables

$ENV_PKG utility package Defined in *_variables

Output: Variable File / Parameter Comment

$JOB_MSG_LOG Job message log Deleted on job success

$NC_ECO_LOG_FILE eco_adminserver.log Server’s eco log

$UTL_SUCCESS,

$UTL_FAILURE

Job return value via $UTL_JOB_IS_SICK

or $UTL_JOB_IS_WELL

n/a $JOB_NAME”.LOG*” Created via control-m/nohup

DetailedSpecification:

Logic

specify korn shell and set options to echo all outputif $ENV_FILE does not exist, then exit with failure status

UtlHandleEvent $UTL_JOB_STARTUP # start job (eco logging)

Initialize cycle application parametersRun cycle application

if [[ $? -eq $UTL_SUCCESS ]]; then # if cycle is okUtlLogMsg $UTL_MSG_GENERIC $UTL_SEV4 "Cycle returned zero"UtlHandleEvent $UTL_JOB_IS_WELL # end job

else # else

UtlLogMsg $UTL_MSG_GENERIC $UTL_SEV2 "Cycle returned non-zero" "Call AS cycleexpert"

UtlHandleEvent $UTL_JOB_PM_PAGE # page nowUtlHandleEvent $UTL_JOB_IS_SICK # end job

fi # endif

ProcessingFunctions:

Function Name Logic

UtlHandleEvent() See the Utilities TSD

UtlLogMsg() See the Utilities TSD

Event Handling /Message Logging:

Event/Message Id Severity Message / Action

$UTL_JOB_STARTUP INFO Start eco logging

$UTL_JOB_PM_PAGE FATAL Specify page now

$UTL_JOB_IS_SICK FATAL End eco logging

Keep job msg logExit (failure)

$UTL_JOB_IS_WELL INFO End eco loggingDelete job msg logExit (success)

4.1.8 IRS Aggregation Report





Systems Design


Provide a daily report of IRS Aggregation eligible contracts that has recentlyundergone successful withdrawal transactions. This report shall incorporateinformation of corresponding cost basis adjustment computation.

Figure 5 – Proposed screen layout





Systems Design


4.2 Technical Data DesignError: Reference source not found specifies the table queried for the batchstatistics. The ODS database design may also contain this information.

T_ARXY

Column Name Datatype Null Option Comment


http://opt/scribd/conversion/ODS/Old/ODS%20Logical%20Modelv1.1.zip

http://opt/scribd/conversion/ODS/Old/ODS%20Logical%20Modelv1.1.zip




Systems Design


4.3 Development and Integration Plans

For the schedule of different phases of the project refer to the link below:\\filimmk002nts\ssg\Project Management\Platform Project Plans\Feeds and Reports.mpp

4.4 Training Support RequirementsIf requested, a presentation can be scheduled to provide developers with anoverview of the job template and utility package.


http://smb//filimmk002nts/ssg/Project%20Management/Platform%20Project%20Plans/Feeds%20and%20Reports.mpp







Systems Design


5 Specifications for Operational

Requirements5.1 Operations Specifications

The job template and common utility package illustrate how to satisfy therequirements, standards & conventions, and processes & procedures for theFILI batch jobs that run in Control-M. These requirements, co-authored byFILI S&T Operations and FILI S&T Development, are documented in:http://sharepoint.fmr.com/sites/FILISDA/SRA%20SDS/Feeds%20and%20Reports/FnR%20SRA_SDSs/1%20-%20Initial%20SRA%20for%20Feeds/(ML000)%20FILI%20Batch%20Cycle%20Standards%20SRA.doc

Help FileThe following link is an example of a help file to be created for each job andinstalled onto the production server to help FILI S&T Operations andDevelopment to make decision in case of job failures.http://sharepoint.fmr.com/sites/FILIPlatform/Systems%20%20Technology/Interfaces%20(Reports%20and%20Feeds)/Templates%20and%20Standards/FSDM%20FILI%20Templates/Feeds%20and%20Reports_Help_File_%20ML128%20.doc

Install documentA PACE ticket will reference an install document that will include thedeployment of this Implementation Unit.

Archiving processThe feed information will be stored as follows:

Component Onsite

HyperionPortal

Daily & on secondary storage for abouta year

Solaris 45 days

Windows(ftp’d file)

18 months

The feed information will be kept offsite for about 7 years.

Escalation List:

Communication to external groups will be carried through PACE and internalcommunication will be made to FACET group.

Group Contact

FILIOPERATIONS

FACET

FILIDEVELOPMENT

FILIDEV


http://sharepoint.fmr.com/sites/FILISDA/SRA%20SDS/Feeds%20and%20Reports/FnR%20SRA_SDSs/1%20-%20Initial%20SRA%20for%20Feeds/(ML000)%20FILI%20Batch%20Cycle%20Standards%20SRA.doc



http://sharepoint.fmr.com/sites/FILIPlatform/Systems%20%20Technology/Interfaces%20(Reports%20and%20Feeds)/Templates%20and%20Standards/FSDM%20FILI%20Templates/Feeds%20and%20Reports_Help_File_%20ML128%20.doc













Systems Design


5.2 Capacity Plan ImpactN/A

5.3 Contingency Plan ImpactN/A





Systems Design


6 Unit Test Specifications

6.1 Prototype TestingPrototype testing demonstrated the feasibility of the design proposed for the job template and utility package in this TSD.

6.2 Unit TestingUnit testing of the utility package occurs during the unit testing of new and

modified jobs.

Features to be tested:Starting job

Logging messageTransferring filesSending mailInvoking Oracle sql scriptStopping job

Testing Approach:Setup the Control-M job components.Prepare the environment (Databases, ETL, Hyperion, Filesystem, testdata/files) for the testing.Test the job script by executing it from the server’s command-line,redirecting the job output into a log file as Control-m would do.nohup ./FO_<JOB_NAME> > FO_<JOB_NAME>.LOG_<date>Review the log files to validate negative and positive test case results:

FO_<JOB_NAME>.LOG*FO_<JOB_NAME>.log.* (exists if fatal/error message logged)FO_<JOB_NAME>.ftp.* (exists if ftp function called)

Verify any other expected output files (e.g. feeds, reports, transferred file,published files) were generated, if the job ran successfully.Compare the data with the expected test result.

Expected Test Results:To be defined for each job.

Pass/Fail Criteria:If the actual log files and output file contain the expected test results, then the

unit test case passed, else the unit test case failed.

6.3 Integration TestingIntegration testing of the utility package will occur in a Control-menvironment.





Systems Design


Features to be tested (depending on job requirements):Starting jobLogging messageTransferring filesSending mailInvoking Oracle sql script

Stopping job

Testing Approach:Define and schedule the Control-M jobs. (work with FILI S&T Operations)Install the Control-M job components.Prepare the environment (Databases, ETL, Hyperion, Filesystem, testdata/files) for the testing.Schedule the Control-M job and monitor the process flow through all thecomponents.Review the log files to validate test case results:

FO_<JOB_NAME>.LOG*FO_<JOB_NAME>.log.* (exists if fatal/error message logged)FO_<JOB_NAME>.ftp.* (exists if ftp function called)

Verify any other expected output files (e.g. feeds, reports, transferred file,published files) were generated, if the job ran successfully.Compare the data with the expected test result.Compare the Control-M run statistics from the new system with that of thecurrent system.

Expected Test Results:To be defined for each job.

Pass/Fail Criteria:If the actual log files and output file contain the expected test results, then the

unit test case passed, else the unit test case failed.

6.4 Test ProcedurePositive Test Case:Verify that the job generates the correct output per the job’s SRA.

Negative Test Case:Create conditions (incorrect path, user, password, etc.) to force the job tocomplete unsuccessfully. Well-designed jobs will be easy to break byreplacing correct variable values with incorrect ones (*_variables.<env>).The system is supposed to respond in the same way as the existing systemwould perform in such scenarios.Verify the logged messages should comply with what the existing system

would do, with the expectation that the message logging has been updated inaccordance with new standards imposed (switching from 3 to 4 severitylevels).





Systems Design


7 Conversion System Design

N/A





Systems Design


8 Approvals

This list of approvers may be customized as needed.

Table 1—Technical Systems Design Approvers

Role Team Member

S&T Systems Analyst Lead: Feeds and Reports

S&T Development Manager

S&T QA

S&T Architecture: Feeds and Reports

S&T Security

S&T Operations

S&T Operations Environment Support





Systems Design


9 Appendices

9.1 Unit Test Case SpecificationsNA

9.2 Roles and Responsibilities for TSD

Table 1—Reviewers

Role Team Member

S&T Architecture: Feeds and Reports

S&T Development

S&T Systems Analyst Lead: Feeds andReports

S&T Systems Analyst

Table 2— Contributors

Role Team Member

S&T Development Lead: Feeds andReports

S&T Development: Feeds and Reports

S&T Operations

Date post:	07-Apr-2018
Category:	Documents
Upload:	udaytiwari
View:	221 times
Download:	0 times