Advanced interface table polling
You can perform advanced configuration of the interface table polling process to improve its performance when reading data from interface tables. The system provider performs this configuration on behalf of tenants.
If you send inbound messages through the continuous JMS queue and do not require messages to be maintained in first-in-first-out sequence, you can improve the performance of interface table polling.
Multiple cron tasks
The interface table polling process uses instances of the IFACETABLECONSUMER cron task to read all messages from all interface tables for all external systems that write to the tables. To improve performance, you can introduce multithreaded polling by configuring multiple instances of the IFACETABLECONSUMER cron task in the Cron Task Setup application.
For each instance, you define selectors by assigning values to the EXTSYSNAME and ENTERPRISESERVICE parameters, for example, EXTSYSNAME=EXTSYSNAME1 and ENTERPRISESERVER=MXPERSONInterface. All selectors must be mutually exclusive among the multiple instances to avoid processing a message more than once.
The performance benefit of multithreaded polling can be further realized in a clustered
configuration. The IFACETABLECONSUMER instances can run on different servers to balance the load. To
designate an instance of the IFACETABLECONSUMER cron task to run on a specific application server,
set the TARGETENABLED parameter to 1 and, on the application server, set
-DIFACETBCONSUMER..<instance name>=1
.
If you configure multiple instances of a cron task the selectors must be mutually exclusive, so that messages are not processed multiple times. Selectors must retrieve all the enterprise service transactions that you use, so that no messages are left unprocessed.
Multiple queues
You can improve performance by setting up multiple interface queue tables. For example, you can write each interface to a separate queue table and define separate cron tasks to process the queue tables independently of one another. You also can set up separate queue tables for each external system and, within each queue table, define selectors for each interface. Depending upon the complexity of your integration, you can use multiple queue tables instead of multiple selectors. To set up multiple queue tables, create the queue tables in the same database as the interface tables, and include all the columns that are in the MXIN_INTER_TRANS queue table. You must design the external system to write to the appropriate queue tables. Ensure that the external system does not insert an interface table message into more than one queue table so that the message is not processed multiple times.