Integration Service Parameter Table
The Integration Service parameter table provides system level parameter data for the Integration Service.
- Table:
IF.INTEGRATION.SERVICE.PARAM - Key:
The valid values are:
- SYSTEM,
- or company ID,
- or system followed by -nn,
- or company ID followed by -nn.
For more information, see Defining a Custom Integration Service.
When a company mnemonic is entered, it is changed into the relevant company ID. The event delivery parameters are read from the company specific record of parameter table, if it is available.
If the company specific record is not available, the SYSTEM record values are used as parameters for event delivery. This could lead to unexpected event delivery behaviour. Hence the recommendation is to have company specific configuration records. Also company specific configuration record provides flexibility and control on event delivery.
Fields in IF.INTEGRATION.SERVICE.PARAM
This section provides the list of fields available in IF.INTEGRATION.SERVICE.PARAM and the descriptions of these fields.
- EVENTS.BATCH.SIZE
This field holds the number of events to be bulked for delivery. For example, if set to 100, the INTEGRATION.SERVICE will batch 100 events together to be delivered within a single transaction.
- DESTINATION.STATIC
For TAFJ event delivery, DESTINATION.STATIC must hold the queue name to which the event has to be delivered and the connection factory. For example: queue/t24IFInboundQueue#connectionFactory or just the queue name (queue/t24IFInboundQueue). The queue name could be a physical or a logical queue. The screen capture shows a physical queue.
- DESTINATION.PROP
Events can be delivered to a queue based on the value of a particular field in the event. Apart from specifying the value, you need to define the end point activation in the MDB that processes and delivers the event to the third-party system.
For more information about delivering messages to a queue based on DESTINATION.PROP, see the Delivering Events section.
- MSG.DELIVERY.MODE
This field specifies the way to batch the events during event delivery process. It can be any one of the following values:
- NO.BATCH – Records are not allowed to batch and deliver.
- NO.BATCH.SORTED - Records are not allowed to batch, deliver and sort based on creation time of the event.
- NO.BATCH.NO.PRIORITY – This is similar to NO.BATCH, but the events are not sorted based on the event priority.
- NO.BATCH.SORTED.NO.PRIORITY - This is similar to NO.BATCH.SORTED, but the events are not sorted based on the event priority
- BATCH.EVENT.TYPE – The records are batched based on the event type and then the event delivery service processes the event delivery as batches.
- BATCH.EVENT.TYPE.SORTED – The records are batched based on the event type and then sorted based on the CREATION.TIME field value of the event and then the event delivery service processes the event delivery as batches. This mode allows the events to be processed in the first come, first served basis. It is advisable to use only one tSA to deliver the messages, while using this mode.
- INITIAL.LOAD – This is a special mode, to deliver the events, used specifically during initial load of events. This mode selects the events to deliver without any conditions and filters. It deletes the event record once delivered.
When the message delivery mode is BATCH.EVENT.TYPE or BATCH.EVENT.TYPE.SORTED, the event delivered to the queue as batches conforms to the batch schema structure generated while publishing the flow. The message delivery mode BATCH.ALL is no longer supported from Transact 201606 release. - MSG.BATCH.XML
This property is used to specify whether the events that are delivered into the JMS queue should be in a group as ‘n’ number of events, where n is the value for the field EVENT.BATCH.SIZE.
- MSG.PROP.NAME
This field is a multi-value field. You can specify which information from the event has to appear in the JMS header. The value for the field can be any string, but the event could hold the value for these fields in the JMS header based on the following conditions:
- The value specified here should be an element name that appears in the flow schema.
- The event that got generated should carry a value for the fields mentioned here.
This is used only for the configuration where events are delivered to a Message-Driven Bean through CALLJEE.
- FILTER.TYPE and EVENT.TYPE.LIST
It is possible to filter or deliver events when using INTEGRATION.SERVICE. This functionality allows INTEGRATION.SERVICE and adapters to coexist. The fields FILTER.TYPE and EVENT.TYPE.LIST are used for configuring filters.
FILTER.TYPE - This is a single value field that specifies the type of filter that is to be applied. This field can take any of the following values:
- None - In this case the INTEGRATION.SERVICE selects all the events and delivers them to the queue. This is the default option and it ensures that the INTEGRATION.SERVICE is backward compatible.
- BLACK.LIST - When this option is selected, then all the events mentioned in the EVENT.TYPE.LIST will not be selected for event delivery using INTEGRATION.SERVICE.
- WHITE.LIST - When this option is selected, then only the events mentioned in EVENT.TYPE.LIST will be selected for event delivery using INTEGRATION.SERVICE.
- EVENT.TYPE.LIST - This is a multi-value field that specifies the list of events that need to be delivered or not delivered by INTEGRATION.SERVICE based on the FILTER.TYPE configured.
- EVENT.TYPE.DEST and EVENT.DEST
The following two fields are associated multi value fields that allow the events of specific type to be delivered to a specific queue.
- The EVENT.TYPE.DEST field holds the event type.
- The EVENT.DEST field holds the destination (queue name) where the events of EVENT.TYPE.DEST are to be delivered.
Integration service delivers an event to the specific queue if it is configured. If this value is not configured, then the destination is determined by the values the field mentioned in the DESTINATION.PROP can have. If both options are not configured then the selected events will be delivered to the default destination mentioned in DESTINATION.STATIC.POST.DELIVERY.ACTThis field value specifies what to do with the event after the event has been delivered to the queue. This field can take three values:
- None – On successful delivery of the message the EVENT.TIMESTAMP field gets updated to denote the event is delivered.
- DELETE.EVENT – On successful delivery of the message the event gets deleted from IF.EVENTS.INTERFACE.TABLE.
- ARCHIVE.TO.FILE – On successful delivery of the message, it allows the user to write the IF.EVENTS.INTERFACE.TABLE record into a separate table mentioned in the MAIN.FILE field of ARCHIVE record. It is useful for those who use Data Lifecycle Management (DLM) to run purge service to redirect the record from IF.EVENTS.INTERFACE.TABLE to Read only Database (RODB). The purge service does not require to run online in parallel with integration service.
- ARCHIVE.EVENT - On successful delivery of the message the EVENT.TIMESTAMP field gets updated to denote the event is delivered and the record is stored in the archive file IF.EVENTS.INTERFACE.TABLE$ARC. The event record will be deleted from IF.EVENTS.INTERFACE.TABLE. You can set up a custom configured ARCHIVE record. Here is an example of ARCHIVE record:
Integration Framework uses the values in the fields ARC.FILENAME, FILE.TYPE and MODULUS.
By default, Delivery events are not archived or deleted when processed regardless of the POST.DELIVERY.ACT configuration. User can refer to IF.DELIVERY.EVENTS.TABLE to which the processed delivery events are moved since R22. Integration Framework refrains the maintenance option for this table and hence the clients need to make sure that this table is cleaned up periodically. - COMPANIES.LIST
IF.EVENTS.INTERFACE.TABLE is the lead company, specific table and by default the integration service selects events from the IF.EVENTS.INTERFACE.TABLE table of the company for which the integration service is executed. This new field allows you to configure integration service to select events from multiple files based on the provided IDs of the lead companies.
For example, when running BNK/INTEGRATION.SERVICE, integration service would select events from the BNK company for event delivery by default. But if the COMPANIES.LIST is configured with the company ID of BNK and, for example CO1, then the events from both lead companies would be selected for delivery.
This configuration allows to run Integration Service for multiple companies and can be used to rationalize the number of services running in parallel on a given Transact instance.
Integration Framework does not validate the COMPANIES.LIST field value with other records available in IF.INTEGRATION.SERVICE.PARAM.
The ALL value in this field allows a single INTEGRATION.SERVICE to deliver events from all lead companies.
- ON.LOC.TRANS.ERR
Integration Framework allows custom transformation of the event XML file before it gets delivered to the queue. This feature is available only for integration events delivered on behalf of the Transact Delivery module. The ON.LOC.TRANS.ERROR field allows the user to configure how integration service is to handle this scenario.
When this field is set to DELIVER.ORIGINAL.XML or NONE, then the XML generated by Integration Framework without local transformation will be delivered to the destination. The other option DONT.DELIVER.ORIGINAL.XML prevents delivering the event to the destination when there is an issue with local transformation.
- RETRY.INTERVAL and RETRY.COUNT
When these two fields are configured and the event delivery fails, for example for connectivity reasons, integration service will wait for RETRY.INTERVAL and will retry the event delivery.
If the RETRY.COUNT is reached and the integration service fails to deliver the event, the integration service will stop its execution.
RETRY.INTERVAL is expressed in seconds.
- SAMPLE.SIZE
-
SELECT.EVENT.TYPES
Indicates to compute the event types for which the events are available for delivery . It is applicable when BLACK.LIST or WHITE.LIST is configured or MSG.DELIVERY.MODE is BATCH.EVENT.TYPE or BATCH.EVENT.TYPE.SORTED.
When set to N, integration framework performs a select in IF.EVENTS.INTERFACE.TABLE for each flow and indicates the number of selects are equal to IF.INTEGRATION.FLOW.CATALOG records. It is recommended to use this option when all the flow holds the events for processing.
When set to Y or left empty, integration framework performs a select in IF.EVENTS.INTERFACE.TABLE to identify the event types that has events for delivery. For these event types, the events are selected for delivery and indicates that there should be a minimum of 1 to N+1 selects, where N is the number of records in IF.INTEGRATION.FLOW.CATALOG. It is recommended to use this option when only from flow has events for delivery.
-
This field hold values between two to thirty one to compute the archival file name which is in the format “F<companyMnemonic>.IF.EVENTS.INTERFACE.TABLE<MODULO$ARC ” where MODULO is calculated as the Day of the year % NO.OF.ARCHIVE.FILE. If the value in this field is left empty or is marked as zero or one, the event record is archived under the default file name IF.EVENTS.INTERFACE.TABLE$ARC.
Indicates the number of records selected by a select statement. When BLACK.LIST or WHITE.LIST is configured or MSG.DELIVERY.MODE is BATCH.EVENT.TYPE or BATCH.EVENT.TYPE.SORTED, then for each event type the number of events selected will be less than or equal to SAMPLE.SIZE. For the rest of the event delivery options, it indicates the total number of records to be selected for event delivery.
In this topic