10.2. Inbound Interface Facility

Overview #

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

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

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

• Payment
• Exchange Rates
• Business Partner
• Index data
• Reporting Unit
• and Global Event (headline loss, not for Life).

The interface operates in two steps:

• First step: Insert data into the so-called External Interface tables.

This step requires writing of client specific programs not delivered as part of SICS.

• Second step: An Interface batch job, typically run at night, will process data in the External Interface tables and insert data into the regular SICS tables.

How to Use the Interface #

General Interface Inbound Utilities icon

General Interface Inbound Setup icon

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

Setup Activities #

When you click the General Interface Inbound Setup icon in the Interface folder on the desktop, you see the Inbound Data Definitions tab and the Settings tab.

The Settings tab in holds only one attribute, Use Replace for Collections.

Inbound Data Definitions #

When you click the General Interface Inbound Setup icon in the Interface folder on the desktop, you see the Inbound Data Definitions tab.

The Inbound tab does not allow any user changes. It provides the user with information on which objects and attributes are relevant for the given inbound interfaces.

To view the objects and attributes:

1. Select the interface main type, the interface type, and the class name from the drop-down lists at the top of the window.
2. Select View Attributes from the pop-up menu of the Objects display list. You see the attributes belonging to the selected object(s).
3. The first time you have selected an object, double-click the object in the Objects display list to see the attributes. If you select another object, its attributes will automatically be displayed in the Attributes display list.

Create Data in the External Interface Tables #

Data to be received by SICS must first be placed into the External Interface tables. A client specific program will typically perform this step. Such programs may be run using the Job scheduler of SICS.

Utility Functions #

You initialise the Interface from the Initialize tab. To access the Interface tab, double-click the Outbound Interface folder on the desktop, double-click the General Outbound Interface folder and then click the General Interface Outbound Utilities icon.

Click the Edit button and then the Initialize Interface button to 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 does not do any harm.)

Run the Interface Job

Data from the External tables will be processed, and the result will be placed into the regular data tables of SICS. 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.

This tab provides a means of manually testing the inbound interfaces without using the job scheduler.

Clicking the Activate Testing check box while in browse (non-edit) mode enables the feature: Process Inbound Interface.

Clicking the Edit button followed by the Activate Testing check box enables the feature: Clear Interface Database Tables.

View Data in the Interface Data Tables #

The External Data tab provides a readable view of interface data.

It is 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 inbound 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 Inbound Interface #

Interface Types #

The interface type describes the particular function within the interface main type. These functions normally describe the creation(C) or updating (U) of an object within this functional area.

The interface type must be given in a record on the INF_HEADER table on the interface database and must be one of the available types for that interface main type.

The interface main types are visible on the inbound tab of the Interface window.

For example, in the Index interface, the possible interface types are:

Index Table (C_INDEX_TABLE)

Index Row (C_INDEX_ROW, U_INDEX_ROW)

Index Point (C_INDEX_POINT, U_INDEX_POINT)

In some cases a function may not be available for business reasons (e.g. U_INDEX_TABLE).

For the interface main types Business Partner, Exchange Rates and Global Event, SICS looks for an existing record with the key attributes provided. If one is found, an update (U) is assumed, otherwise a create (C) is assumed.

Interface Objects #

Each interface type is associated with a certain number of objects that are placed as records on the INF_OBJECT database table.

What Is the Update Object?

For any given interface type for inbound, there is always one and only one object which is designated the update object, which is the object where changes have been made or should be made

Key Attribute Lookup Objects

For each interface type and its update object, there may also be a number of lookup objects that are key attributes required to identify the update object uniquely.

They function like other key attributes except that object change attributes must be linked to the update object. For further information, refer to Linking Objects.

From the Attribute Selection tab of the Interface window, you can see which objects are key attributes for the update object.

Key attribute objects are valid for both inbound and outbound interfaces, but the object linking is different.

Multiple-key attribute object linking may be required in some circumstances.

Example: SicsCountryIndexPoint

• SicsCountryIndexRow (key attribute for the point)
• SicsCountryIndexTable (key attribute for the row) Attribute Change Objects

For each interface type and its update object, there may be attribute-change objects that are valid for that interface type.

Attribute-change objects are considered as attributes to be changed like other non-key attributes in the given update object. However, the attribute-change object itself is not changed, rather the link between it and the update object. For further information, refer to Object Linking.

From the Attribute Selection tab of the Interface window, you can see which objects are given as attributes for the update object.

Not all attribute objects can be assigned or unassigned from an update object in this way. Objects that cannot be assigned or unassigned as attributes are marked as Change Barred in the attribute properties list.

Change Barred attributes may, however, be changeable as an update object.

Example: U_ADDRESS in the business partner interface main type.

Linking Objects #

The database fields used for linking on the inbound interface are different from those on the outbound interface. However the linking principle is the same in both cases.

A linked object is always an attribute of the parent object, usually the update object.

In this parent or update object the ATTRIBUTE_VALUE field holds the link.

For the outbound interface, the SICS_OBJECT_ID field of the linked object must hold the same value.

For the inbound interface, the REFERENCE_ID field of the linked object must hold the same value.

The value is defined as a string, but for outbound holds a SICS object identification. The value for inbound is provided by the external system.

The ‘index row’ update object has a key attribute ‘indexTableRelation’ which is a linked object. The attribute value for the table is given as ’table1’ in the ATTRIBUTE_VALUE field.

There is a lookup object record in the INF_OBJECT table that represents the required index table. The REFERENCE_ID value of this lookup object must also be ’table1’ so that the link to the attribute of the update object is established.

Interface Attributes #

Attributes are the individual values associated with any given object. They are placed on the interface database as records in the INF_ATTRIBUTE table.

These attributes can be of many different data types including links to other objects, or links to collections of objects. The required record format for each attribute type is described below.

Types of attribute and their format (INF_ATTRIBUTE)

Properties of attributes

Change Non-Key Attributes via Inbound Interface #

The correct interface main type and interface type must be set in the INF_HEADER record.

The object associated with interface type must be set in the INF_OBJECT record.

The key attributes of that object must be given in the INF_ATTRIBUTE records.

The non-key attribute must have the new value to which it should be changed.

The IS_KEY_ATTRIBUTE field in the INF_ATTRIBUTE record must be set to ‘NO’.

Change Key Attributes via Inbound Interface #

Key attributes that are being changed need to have two INF_ATTRIBUTE records within the same update object. The occurrence that contains the new value must have a later time-stamp.

The first occurrence of the attribute is required to uniquely identify the update object because it is a key attribute.

The current value of the key attribute on the database must be given.

The IS_KEY_ATTRIBUTE field in the INF_ATTRIBUTE record must be set to ‘YES’.

The second occurrence of the attribute must give the new value to which it should be changed.

The IS_KEY_ATTRIBUTE field in the INF_ATTRIBUTE record must be set to ‘NO’.

If There Are Data Errors on Inbound Interface #

There are syntax checks and business validation checks on the inbound data. If an error is found, an error message is written to the INF_ERROR database table, where the administrator can get the details of the error. The record where the error is found will not be converted into SICS data, nor will any subsequent records that depend on the existence of that record.