10.1. Outbound Interface Facility

Overview #

The SICS Outbound General Interface Facility (or Outbound Interface) handles the transfer of data from SICS to an external system.

The use of the Interface requires in-depth knowledge of SICS data structures. Therefore we recommend users to contact DXC before attempting to use the facility.

Only certain functional areas of SICS are adapted for use of the outbound interface. These are:

• Business Partner
• Business, Accounting
• Payment
• Balance Pairing,
• Claim (not for Life)
• and Insurable Object (not for Life).

The Interface operates in steps.

• First step: When data is entered into SICS, then depending on parameters and settings, some data will be inserted into the so-called Internal Interface tables.
• Second step: An Interface batch job, typically run at night, will process data from the Internal Interface tables, merge with data from SICS and place the result in the so-called External Interface tables.
• Last step: Processing of data in the External data tables is outside the scope of SICS, but may be used to load data from SICS into other systems.

How to Use the Interface #

General Interface Outbound Utilities icon

General Interface Outbound Setup icon

You access the Interface from the System Administration Utility by double-clicking the Outbound Interface folder, double-clicking the General Interface Outbound Setup folder and then clicking the General Interface Outbound Setup or the General Interface Outbound Utilities icon.

Setup Activities #

When you click the General Interface Outbound Setup icon in the Interface folder on the desktop, you see the General Interface Outbound Setup window. This is where you set which interfaces to use, define triggering rules and define the data you want to export.

Define which Interfaces to Use

The Settings tab on the General Interface Outbound Setup window is used to define which interfaces are in use.

For the Outbound Interface to be active, you need to have selected the Outbound Interface In Use check box.

There is additional check boxes for each supported interface type:

• Accounting Export
• Business Export
• Business Partner Export
• Claim Export (not for Life)
• Insurable Object Export (not for Life)
• Payment Export (remittances), and
• Pairing Export (pairing of balances in accounting).

In addition there are four additional parameters valid only for payment export.

Suppress Remittance Data After Triggering: If this check box is selected, remittances will not be transferred again after the original transfer, even if remittance data has been changed.

Reset trigger in Progress/Inactivate Status: If this check box is selected a remittance set to status In Progress or Inactivated, will be triggered (again) if it later ends up in a state defined in by the triggering rules (see below for more details). This is the case even if Suppress Remittance Data After Triggering has been selected.

Allow Update of Paid Remittance after Triggering: If this check box is selected a paid remittance in pending status may freely be updated after it has been triggered.

If this check box is not selected only two attributes of the remittance, Partner’s Reference and Notes may be updated after it has been triggered.

Allow Update of Received Remittance after Triggering: Similar to the above, but for Received Remittances.

Note! The Log Business Condition check box has nothing to with the interface, but is placed here for practical reasons.

Log Activity Settings #

There are two ways to register/ log the activities that takes place in SICS.

• Log Activities: When this option is selected, SICS logs changes done to business conditions, but not before there is at least one booking registered on the business.
• Log Business Conditions before Booking: When this option is selected, SICS logs changes done to the original version (the first entered version) in several parts of the system.

SICS can log changes made by an end user in the these part of the system:

• Only for P&C and Cede - Business:
  Business Conditions
  Business Properties
  Insured Period Properties
  Classifications
  Reporting Units
  Life Cycle Status
  Partners
  Business Groups
  Protection Assignment
  Cedent’s Program Linkages
  Excess of Loss Protection for Common Account Linkages
  

• Only for P&C- Claims:
  Claims
  Claim Group
  Headline Loss
  

• Business Partners:
  Business Partners
  Banks
  Business Partner Groups
  Third Party
  Third Party Group
  Mailgroups
  

• Accounting:
  Period Estimates (under Underwriter’s Estimates)

In addition, changes to the following functions can be logged:

• Document Production Maintenance
• Event Log
• Messages
• Security
• System Parameter Maintenance
• User Defined Field Administration Note! Logging all attributes in the areas mentioned above often creates a tremendous log.

To select the attributes you find useful to log:

1. Click the ‘Outbound Data Definition’ tab.
2. Select ‘Log Activity’ in the Interface Main Type drop-down list.
3. Select the ‘Class Name ‘and change Trigger to “‘Yes’”.

Define Triggering Rules

Some Interface types (Business Export, Accounting Export, Payment Export (remittances) require triggering rules, that is definition of predefined statuses of certain objects in SICS. Without such rules defined, no data will be transferred.

Rules can be defined, altered and deleted on the Triggering tab in the General Interface Outbound Setup window.

In the trigger configuration is also possible to choose between Changed Set and Full Set for each trigger for Business Export and Claim Export.

If Changed Set is selected, the behaviour of the export is unchanged, i.e. only exporting data from the current edit bubble.

If Full Set is selected, all attributes and objects of all parent and children edit bubbles of the updated edit bubble are exported in addition to the updated edit bubble itself.

For Business Export the triggering status is defined as a combination of level of business, type of business, and agreement basic status.

For Payment the triggering status is defined as a combination of remittance status, remittance type, and base company (all companies possible).

For Accounting Export the triggering status is defined as a combination of worksheet status, origin of worksheets, level of business, and type of business. The user should ensure that all required triggering rules are inserted before going into production. The maintenance of triggering rules after production may have unpredictable results (DXC should be contacted).

Define the Data to be Exported

You define the data to be exported on the Outbound Data Definitions tab in the General Interface Outbound Setup window.

Specify the classes and attributes, which you want to export.

This tab shows all relevant objects and attributes for the selected outbound interface, in addition to a parent relationship tree for the selected object.

The administrator should examine all the interface main types, domain classes and attributes where notification of SICS changes is required.

Objects and attributes where changes should be notified must be specified.

Classes for which objects should be delivered must be specified with Yes in the Deliver column.

An attribute of a deliverable class will be delivered if at least one of the following conditions is fulfilled:

Attribute for Trigger objects where Trigger column is set to Yes.

Attribute where the Lookup and Update column is specified as Yes

A specification of Yes for Lookup and Update and No for Trigger will not be accepted by the system.

Initialise the Interface #

You initilise the interface on the Initialize Interface tab. You open the Initialize Interface tab by clicking the General Interface Outbound Utilities icon in the General Interface Outbound folder.

Click the Edit button followed by the Initialize Interface button. This initialises the data attribute information for both inbound and outbound.

Note! This procedure is necessary the first time the interface is used, and also when upgrading SICS with a new release or patch. (Clicking the button at other times causes no harm.)

Enter Data into SICS #

When all the above activities have been finished, the interface is ready for use.

For certain types of input (e.g. normal manual input) a set of data will be populated in the internal data tables according to interface settings and triggering rules.

Utility functions started from the System Administration Utility system will not trigger the interface (examples: General Inbound Interface, Migration Toolkit)

Run the Outbound Interface job #

Data from the Internal tables will be processed, merged with data from SICS and the result will be placed in the External data tables.

In a normal production environment this will be done by running a scheduled job with a job step ‘General Interface’ and parameters indicating the type(s) of interface that should be processed.

For testing purposes the interface can also be tested from the Testing tab.

The Testing tab provides a means of manually testing the inbound and outbound interfaces without using the job scheduler.

Clicking the Activate Testing check box while in browse (non-edit) mode enables the Generate Outbound Interface features:

Enables manual generation of outbound external datafrom the internal data, without using the job scheduler.

A single interface type or <none> can be selected

Clicking the Edit button followed by the Activate Testing check box enables two features: Clear Interface Database Tables and Set All Attributes Deliverable.

View Data in the Interface Data Tables #

The Internal Data tab and the External Data tab provide a readable view of interface data. You open the Internal Data and External tabs by clicking the General Interface Outbound Utilities icon in the General Interface Outbound folder.

They are primarily used for testing or maintenance purposes. Accessing during production may result in long response times.

The External tab provides a readable view of data on the external interface database tables.

The upper display list shows the outbound transactions.

On selecting one of these transactions, the left display list shows the objects linked to that transaction.

On selecting one of these objects, the middle-right display list shows the attributes linked to that object.

The lower-right display list shows the SICS logical links to the selected object. By double-clicking the mouse in the right-hand display lists, the SICS logical links can be followed.

After clicking the Edit button, the user has the possibility to change the status of a transaction for testing or maintenance purposes.

Technical Information #

To understand the reminder of this document, DXC recommends you to first read the technical information described in the SICS/Interface Facility-Technical Information document.

Using the Outbound Interface #

How Data is Generated on the Outbound Interface #

There are three basic types of outbound interface data:

• Incremental data
• Triggering data
• Lookup data

Incremental data corresponds exactly to the data the user changes in SICS during one edit procedure.

Triggering data is a one-off generation of all required data for a predefined trigger object (e.g. Business)

A ’trigger’ is a definition of the predefined status for generating the trigger object on the database, and may consist of several conditions.

A ’trigger object’ is a SICS object that has a predefined or user-defined trigger.

A ‘root’ object is defined as the last object in the ‘bottom-up’ chain of upward attributes for incremental data. This is normally also a trigger object, although a trigger object may not be a root object (e.g. life cycle phase in business).

Lookup data is data additional to the incremental or trigger data. This data was not changed but may be required by the customer, or may be necessary to identify the context of the incremental changes.

How Incremental Data, Triggering Data and Lookup Data Correspond

Before triggering, any incremental database changes do not reach the interface database.

Triggering occurs when the trigger object reaches a predefined or user-defined status.

At triggering, all the necessary data for a trigger object are reconstructed and placed on the interface database. After triggering, the trigger object is flagged as triggered and is not triggered again.

After triggering, only incremental data are placed on the interface database

Lookup data is additional data provided to the external system in both the triggering and the incremental transactions. It can be essential or non-essential information depending on the context.

Incremental Data (Create, Update, Delete) #

Interface incremental data is generated from low-level database software in SICS. The user can see this generated data as U (Update), I (insert) or D (Delete) objects on the ‘Internal’ tab of the interface GUI in the system parameters.

SICS Technical Implementation of Incremental Data

Before any SICS changes are committed to the SICS database, an interface function checks if these changes are required for the interface. If so, these changes are converted into records on the internal interface database.

At interface data generation by the batch job scheduler, the interface software first copies the incremental data from the internal transitional tables into the external interface database tables. The objects thus copied keep their object usage ‘I’, ‘U’ or ‘D’.

Incremental data requires all basic defining (key) data to uniquely define the context of the changes. For example, if the limit condition of a business is changed, the interface user will need to know the relevant business, insured period and section etc. for this business condition in order to identify the business condition change uniquely. This key data was almost certainly not part of the incremental change itself and must therefore be generated as ‘Lookup data’. In the unusual case that key attribute data was changed, the outbound interface generates the old values with key attribute=YES and the new values with key attribute=NO.

The generation of these key objects for incremental data is achieved with a ‘bottom-up’ search of relational links, normally back to the root object for any outbound interface main type.

These objects will be generated as L (lookup objects) on the external interface database tables.

These ‘bottom-up’ links (upward attributes) are hard-coded in the interface software and cannot be accessed by the user. However, the user could override these links by defining the whole object as not deliverable. This is not recommended.

User Control of Incremental Data

In the ‘Miscellaneous’tab, the user can define which interfaces he requires from those available.

In the ‘Outbound’tab, the user can define which objects and attributes he requires for a given interface.

The ‘upward paths’ of related objects from the incremental objects are system-defined and cannot be changed by the user. However, the user could override these links by defining the whole object as not deliverable. This is not recommended

Triggering Data (Trigger) #

In many cases the client wishes to see data only when it reaches a specific status. For example, in assumed business, it may be that the client only wishes to see the business data when that business life cycle has reached ‘definite’ status.

SICS Technical Implementation of Triggering Data

Technically, triggering is a ’top-down’ generation of data, as opposed to the ‘bottom-up’ generation for the incremental data.

The top object in this case is the basic trigger object, which is the only object generated on the internal database table

At interface data generation by the batch job scheduler, the interface software follows all object relational links downwards from the trigger object, placing them on the external tables, until no more links exist or until the objects are not relevant or required for the given interface.

‘Triggering data’ on the interface internal and external tables shall always have an object usage of ‘T’.

User Control of Triggering

The trigger objects themselves are system-defined and cannot be changed by the user.

The ’triggering paths’ of related objects from the trigger object are system-defined and cannot be changed by the user. However, the user could override these links by defining the whole object as not deliverable. This is not recommended

Triggering is a fixed functionality (cannot be deselected) in SICS for:

• Accounting
• Claims

For Claims, the triggering criterion is the claim creation.

Triggering is also a fixed functionality for Business, Payment and Accounting outbound, but the user can define the point of triggering via the triggering tab in the System Parameters.

All other outbound interfaces function without triggering, that is, with data creation and incremental changes

Advantages of Triggering

The user receives all the data for a trigger object altogether at a convenient time.

SICS system performance is not affected by a triggering, because only the trigger object is placed on the internal database. The user can generate the external interface data at a convenient time on another server.

Redundancy in Trigger and Incremental Data

The subsequent generation of external data from a trigger object is obviously not real-time.

The data-generation phase will therefore reflect the state of the database at the time of generation and not at the time the trigger object was placed on the internal table. This has consequences for the external system, because incremental changes to the database may have occurred between triggering and database generation. These changes are effectively redundant, because the generation of the trigger object data will show the latest state of these changed objects. Redundant incremental transactions are recognised from the header_lock_ids, and the relevant timestamps of the trigger and incremental transactions. The handling of this redundant data is left to the client.

Data Relevant to More than One Trigger Object

When two different trigger objects are interdependent, this can lead to inconsistencies in the triggering mechanism if there is data relevant to both trigger objects.

An interbusiness relationship is, for example, a relationship between two businesses, both of which are potential trigger objects. If the interbusiness relationship data is triggered for one of these businesses, data for the other business may appear on the interface, whether or not it has been triggered.

Lookup Data #

Lookup objects are not themselves changed data, like triggering or incremental data, but rather additional information which the user has requested, or may be necessary to identify the generated data uniquely.

Using the interface tabs in the System Parameter Maintenance, users have full control over the delivering of data for lookup objects and their attributes on the interface. They can suppress some attributes or the complete object if the data is not required.