One o f the key requirements of Operational Risk Management systems is the ability to import or interface data from external sources to enrich the data collected within the organisation and also to export or extract data from the system for use by external systems, e.g. modelling tools.
Optial has been architected to specifically cover this requirement and there are a number of ways in which data can be consumed & published within Optial.
Data Import
Data can be imported via XML, XML Schema generated from the customer’s model described within the Optial repository is used to define and validate the form of XML used. Optial provides a tool to import (add, update, delete) objects within the system using the given xml file.
Additionally Optial can import from a excel file in defined structure, a technique that is typically used during go live for import from historical systems. This can operate in 2 main modes, one that requires strict validation before importing from Excel and therefore requires any data cleansing whilst in Excel, or another mode that actually allows data to be loaded in an intermediate state into Optial, where it can be cleansed and reviewed.
System operations such as data import and data load activities are audited, in this case the user is identified as an internal application user (data load for example). A full audit history is therefore available for all changes; those made by users and automated jobs for full traceability.
Data Export
Data can be exported in a number of formats including, CSV, XML, ORX, PDF, Excel and other Microsoft Office tools driven by user initiated actions – e.g. ability to export to Excel via link to on list page.
In addition OBI provides an abstraction layer that sits above the low level Optial OLTP tables. This layer is constructed to allow tools such as reporting and modelling engines access to SQL views that are at the granularity similar to the business objects that are defined in the logical business data model.
Data Interchange
Optial typically uses published XML schema for relevant data class/web services approach. XML messages are defined by an XML schema generated from the Optial repository which describes the primary data elements specified within the customer’s system (e.g. Loss Event, Organisational Unit).
Integration can be broadly categorised into 2 classes, Periodic and dynamic.
Periodic (or one off) data interchange
XML
In this case XML files are specified using the relevant XML Schema corresponding to the data type(s) being loaded. Files are stored in a secure location typically produced by an external system. The files can then be transformed from their original format, enriched if necessary and translated to Optial’s expected schema for loading.
Web Service
Optial can also easily pull or push data to/from external systems using web service calls.
Examples in current production use are:
- Optial periodically pull’s data from an external customer complaints system, and use it to add business items within Optial
- Items in Optial of a certain type and workflow state are periodically pushed to an external ‘journal’ system for the particular portion of the business.
Dynamic ‘on demand’ data interchange
Another category of interchange is dynamic interchange, where data is exchanged on demand. For example:
- Retrieve and display information from web services and combine them on an object view page, to present a seamless consolidated view to the user
- Use an external system to validate data entered within an object edit page