Configuring and Running the Initial Load Service
You need to configure the Initial Load service (which is a TSA service) so that events can be triggered based on the existing Transact data.
About this task
The Initial Load service activates the following features in Integration Framework: selection of transactions to generate events and re-generation of events for flow changes, lost and / or erroneous events.
The service can be executed with the following options:
- Pick up data from a desired Transact application
- Execute the service for a specified time stamp window (e.g. the audit time stamp)
- Pass a data set which can be identified from a pre-built list, for consumption by the service
Follow the steps below to configure and run initial load service.
- Define a flow and an exit point for the application for which the event has to be triggered. For more information about exit points and flows, see Using Integration Designer.
- Configure the Initial Load service.
You can configure the TSA.SERVICE record for Initial Load service to execute in one of the following two ways:
- Option 1: Trigger events for all application records
This is the default behaviour. You can configure the company specific IF.INITIAL.LOAD.SERVICE record in BATCH as shown below.
The Transact routine IF.INITIAL.LOAD.SERVICE triggers events for the existing Transact records. You need to indicate the application name suffixed with the file type in the Data field. Events are triggered for the records in the applications listed in the multivalue Data field. The supported file types are Live, $HIS, $HIS$RO and $ARC. The format for Live file is Application Name.
- Option 2: Selectively trigger events based on a request or condition
The vanilla load service triggers events for all the records in the application. To make provision for selective triggering of events, configure the IF.INITIAL.LOAD.PARAMETER table as required.
The IF.INITIAL.LOAD.PARAMETER table accepts SYSTEM or any valid Company Code as Record ID. You might also input the company mnemonic, which will get converted to company ID automatically.
- Examples
System record
Company-specific record
For more information, see IF.INITIAL.LOAD.PARAMETER fields.
When a record is setup in the IF.INITIAL.LOAD.PARAMETER table and the INTIAL.LOAD.SERVICE is executed, the events will be triggered based on the parameter table configuration and the BATCH record configuration will be ignored. Also the company specific record will be used as the configuration to trigger events if both SYSTEM and Company Specific record is available.
- Examples
- Option 1: Trigger events for all application records
- Run the Initial Load service to trigger the events. After you have configured the BATCH record or IF.INITIAL.LOAD.PARAMETER, you need to start the BNK/INITIAL.LOAD.SERVICE.
On successful execution of the service, IF.EVENTS.INTERFACE.TABLE will be loaded with data for those applications that have an exit point and flow defined.
IF.INITIAL.LOAD.PARAMETER fields
This topic contains the mandatory and optional fields of the IF.INITIAL.LOAD.PARAMETER application.
- APPLICATION
Name of the application for which the Initial Load service is to be executed. The application name should be a valid Transact application.
- DATE.FIELD
This field is used to mention any IN2D field that needs to be considered to compare with the values provided in the TIME.AFTER, TIME.UNTIL and TIME.ASOF fields. By default, these three fields are compared with audit field DATE.TIME. There are applications without this field. For those applications, to perform partial initial load this option is introduced. When using this option the three date fields should hold a valid Transact date in the format YYYYMMDD.
- EXTENDED.ID.LIST
A new service IF.EXTENDED.INITIAL.LOAD.SERVICE is introduced to perform initial load for a set of records in various applications. This field holds the file name of the work that has the list of keys processed. This service deletes the keys from the work file once the event is triggered. The keys are to be stored in the format APPLICATION*RECORD_ID in the work file. For example:
- CUSTOMER*100113
- ACCOUNT$HIS*11001;5
- COUNTRY*AB
- CUSTOMER$HIS*100113;1
The configuration record can either have this EXTENDED.ID.LIST or usual fields configured and also both can be configured.
The value of this field is used by IF.EXTENDED.INITIAL.LOAD.SERVICE and the other field values are used by IF.INITIAL.LOAD.SERVICE. The fields used by a service are mutually exclusive and hence both services can co-exist.
- FILE.TYPE
Holds the types of files for which the events are generated. The valid values for this field are LIVE, $HIS, $HIS$RO and $ARC.
- ID.LIST
Optional: Holds the LIST FILE name for an already executed selection. If it is present, it will be used to get the initial set of keys. If the associated TIME.AFTER and TIME.UNTIL fields are present, they will be applied to filter the events.
- SERVICE.STATUS
A multi-value field to indicate the service status. The possible statuses are:
- ACTIVE – This status is for the service to trigger the event for the associated application.
- INACTIVE- Even if the TSA service is started, SELECT will detect this and stop the service. The status will be set to INACTIVE upon successful start of the service so that the service won’t be run accidentally causing generation of unwanted events.
When a record is set up in the IF.INITIAL.LOAD.PARAMETER table and the INTIAL.LOAD.SERVICE is executed, the events will be triggered based on the parameter table configuration and the BATCH record configuration will be ignored. Also, the company specific record will be used as the configuration to trigger events, if both SYSTEM and company-specific record is available.
- TIME.AFTER
Optional: Holds the minimum time stamp of the application records which will initiate events.
The format should be YYYYMMDD HH:MM.
- TIME.ASOF
Optional: Holds the minimum time stamp for the application history records which will be considered to raise the ‘previous state’ of the events. When provided, the format should be YYYYMMDD HH:MM.
- TIME.UNTIL
Optional: Holds the maximum time stamp of the application records which will initiate events. The required format is YYYYMMDD HH:MM.
- VERSION
Name of the version for which the initial load should be performed. The version name should be a valid Transact Version and should have Integration Flows defined to it.
- EVENT.TYPES
Name of the Integration Flows for which the Initial Load events should be triggered.
- WRITE.TO.MASS.TABLE
When this option is set to Yes, it writes the initial load events to IF.MASS.EVENTS.INTERFACE.TABLE instead of IF.EVENTS.INTERFACE.TABLE. It requires custom integration service to be configured to deliver the events using integration service. The integration service should be defined with the below rules:
- <COMPANY.CODE>-MASS (for example, GB0010001- MASS)
- <COMPANY.CODE>-<A number from 01 to 99>- MASS (for example, GB0010001-99- MASS)
- <SYSTEM >-<A number from 01 to 99>- MASS (for example, SYSTEM-99- MASS)
- <SYSTEM >-MASS (for example, SYSTEM-MASS)
Initial load is supported for Application, Version, TSA.SERVICE and on-demand exit points only. Initial load services generate events only for existing data. To deliver the event to the queue run integration service. Read Integration Service for more information on running integration service and setting up custom integration service.
In this topic