1. ITAS Risk Reporting Integration to an ERP
Business Requirements and Limitations
The Solution
Issues Faced
Evolution
Business Benefits
POWERED BY HIVEDOME

2. Business Requirements
SOLUTION
ISSUES FACED
BUS. BENEFITS
EVOLUTION
Business Requirements
Risk Reporting
Capture data generated through ITAS reporting processes for a wider audience
Problems to solve:
Having to perform manual extracts to excel which is time consuming and prone to errors
Needing further information not available to reports
Volume of detail not suited to spreadsheet or printing
Require both scheduled and on-demand requests (jobs)
Flat data structure in repository to match output generated by desktop users
Changes applied to desktop application must flow through without additional work/updates
Repository to be easily query-able, handle historical data, be segregated at Trading Entity and request (job) levels

3. Overview of the solution provided
REQUIREMENTS
SOLUTION
ISSUES FACED
BUS. BENEFITS
EVOLUTION
Risk Reporting
Overview of the solution provided
Convert GPLRPT to allow the 2 report styles to be exposed to batch style processing
Included standardising parameter capture (command-line)
SSIS script built to:
Call GPLRPT for each report
Read excel data extracted, transform and store in target Database (RD)
Run additional SQL to build list on trades, use ITASPL to calculate values and store in target Database
Send notification to nominated Topic including Job ID
API endpoint introduced to accept requests for on-demand extract
External User
Request manual extract
Create Job
Manage schedule
Trigger SSIS activation
SSIS Scheduler
Build report data using SQL and Heritage functions
Push data into dedicated reporting database tables
Generate notification to dedicated Topic
SSIS Job
Reason for the solution provided
Notify relevant people job complete
To create a re-usable model based on existing Reporting Database infrastructure
Client wanted data available outside of ITAS in DB so that data could be extracted to their corporate data warehouse
By allowing API call for on-demand extract, users outside of ITAS could request data and extract directly from the Reporting Database on receipt of a notification all through their own middle tier
Parallel project to enhance the reporting data provided by one of the GPLREP reports, no re-working for extract process
Middle Tier
Reporter

4. Issues faced in Phase 1 Issues faced in Phase 2 Risk Reporting
REQUIREMENTS
SOLUTION
ISSUES FACED
BUS. BENEFITS
EVOLUTION
Issues faced in Phase 1
Risk Reporting
Reporting logic built into desktop application (GPLREP)
Front-end required user intervention, parameter selections
Scheduled jobs managed through Data Export feature in Trader Desktop but needed on-demand option
Additional Trading data required by risk team to compliment Reporting data
Issues faced in Phase 2
Needed to ensure changes applied to GPLREP reports automatically available to this process
Potentially further reports would be needed for same process
Output via file (CSV) requires physical location, so potential setup/security issues
Needed to expose these reports to other consumers, alternate outputs such as data stream

5. Corporate Risk Reporting Evolution
REQUIREMENTS
SOLUTION
ISSUES FACED
BUS. BENEFITS
EVOLUTION
Risk Reporting
Corporate Risk Reporting Evolution
Phase 1 - In order to consumer GPLREP output the application was converted using standard methods
Move reporting logic to public module (BAS)
Handle call through batch method (Sub Main->Command)
Desktop activation changed to use public module, logic
Part of Reporting Database infrastructure
SSIS scripts can be version-controlled at client level, bespoke and separated from normal generic stars
Client wanted flat table structure as opposed to star for simplicity of reading as ultimate target was corporate Database
Improved public access to reporting logic by moving to dedicated class
Single point-of-reference for any report through RF, knowledge of class names, parameters and expected responses
Standardised output options to single function based on Ar() data format meaning new methods immediately available to all converted reports, ability to pass data stream/dictionary directly back to consumer
Phase 1 - To allow simple customisation of the overall process (workflow) SSIS was a natural choice
Phase 2 - To address the issue of building a re-usable model we introduced ReportFactory

6. Defining the User Journey
REQUIREMENTS
SOLUTION
ISSUES FACED
BUS. BENEFITS
EVOLUTION
Defining the User Journey
Risk Reporting
Requirement
Solution
Replace manual process of extracting reporting data from GPLREP via Advanced Print to Excel
Provide public access to reporting logic, ReportFactory to ensure consistency in usage and return raw report data
Schedule an automated process, allow different times for different groups of Trading Entities
Reports Admin in Trader Desktop provides UI for managing schedule, identification of Trading Entities as standard
Provide an on-demand facility
ITAS API endpoint, accepts parameters for filtering and generates new Job request for standard Data Extract function, triggered by middle tier process
Allow identification of data by time and/or id
Job ID generated by script and stored against each record, also TimeStamped
Inform user when new data available
Notification raised using Alerts process, includes Job ID, middle tier subscriber can then redirect to any end-user and/or process
Extract to file not always appropriate, data to be stored in Reporting Database
SSIS script to consume reports directly to generate raw report data and then push to bespoke, dedicated tables in RD
Future changes to desktop report need to be mirrored in automated process
ReportFactory model provides single point of contact irrespective of consumer; desktop, API or SSIS all referencing same report logic