Interface tables are an option for integration with systems that use database tables to exchange data. This integration option applies only to enterprise services and publish channels and is always processed asynchronously, by using JMS queues.
Within an external system, there can be one or more publish channels and enterprise services that are being used for integration with interface tables. Any channel or service that is using an interface table must be associated with an object structure that is configured to support flat files and all alias conflicts must be resolved.
The endpoint definition for an external system or a publish channel points to the database where its interface tables are stored. The database can be the local application database or a remote database. The predefined content includes the MXIFACETABLE interface table endpoint which points to the application database. You can add additional endpoints for remote databases.
The integration framework registers interface table names to an enterprise service or a publish channel. Default names for interface tables are not provided. Apply the following guidelines when naming interface tables:
The interface queue tables identify the sequence in which a receiving system processes the records in the respective interface tables. Two queue tables exist, one for inbound transactions and the other for outbound transactions. Some transactions depend on the successful processing of a previous transaction, for example you must create a user before you can add that user to a security group. The receiving system must process the records in the same sequence in which the sending system created the records.
| Interface queue table | Direction |
|---|---|
| MXOUT_INTER_TRANS | Outbound |
| MXIN_INTER_TRANS | Inbound |
External applications that pull data for outbound messages can use the outbound interface queue table (mxout_inter_trans). However, the external applications can also choose to use other methods of consuming outbound messages that meet their integration requirements.
All inbound and outbound transactions must have a record that is inserted into the corresponding inbound or outbound queue table. This record contains a TRANSID value, a unique identifier that identifies the interface table to which the transaction data is written. The corresponding interface table uses the TRANSID value to identify the record or records that are associated with the transaction. You can identify the contents of a transaction by looking up all the records with a given TRANSID value in the corresponding interface table.
The sequence of TRANSID identifies the sequence in which records are processed by the integration framework. For example, when users and security groups are entered into the system, the TRANSID values for the user record must be lower than the TRANSID values for the security group records that reference that user.
The difference between the MXIN_INTER_TRANS and MXOUT_INTER_TRANS queue tables is the direction of the interface table records that they track. The external system must write to the MXIN_INTER_TRANS queue table, and the integration framework must read from it. The integration framework writes to the MXOUT_INTER_TRANS queue table, and the external system reads from it.
The external system can use the MXOUT_INTER_TRANS table or retrieve outbound records from interface tables. The interface queue tables are generated the first time that you create interface tables for an endpoint. Each endpoint has its own interface queue tables and a counter for maintaining the outbound TRANSID value.