IFS Connectivity Technical Details

Connectivity is a system for transferring messages asynchronously between applications over the Connectivity Out Message Box and In Message Box. The transfer can take place between an Out Message Box and an In Message Box in the same database or an Out Message Box and an In Message Box in different databases. Messages in the Out Message Box can also be transferred over the file system or by some third party tool.  Read more about Connectivity Concept.

Contents

• Background Services
• Message dependency
• Process InMessageBox
• Process OutMessageBox
• Receiving Data
• Performance Considerations

Background Services

Several background processes are needed to be running for connectivity functionality. Find about those in here.

Message dependency

The process Connectivity_SYS.Process_Inbox__ monitors the In Message Box and executes processes for each arriving message. Incoming messages are processed sequentially by Connectivity. This doesn’t mean that the processing of a message is delayed until a previous message has finished processing. Depending on the queue configuration several processes may be running in parallel. If more then one process is allowed to be executing a later arriving message may finish processing before an earlier arriving message although the processing of the first arriving message has started first. This can happen when different messages have different processing time. If messages are depending on each other then they have to be directed to a queue where only one process is allowed at any time.

Two messages arrive, one with a new order and the second with a change of the same order. Processing of the first message containing the new order always starts first. If the message containing the order change is allowed to start before the first message has finished, processing the order change might fail because the new order is not committed to the database yet. Even if the two messages are created at different times, they may arrive at the same time depending on the configuration of the Connectivity_SYS.Process_Outbox__ on the sending site.

The background processes are not executing continuously. The time interval may be short but there is always a possibility that several messages are transported in the same transaction. They will always be inserted in the In Message Box on the receiving side in the correct order but processing might overlap as explained above. A proper configuration of the executing queues will guarantee that messages are processed correctly.

Receiving data

When messages are placed in the In Message Box they are in state Posted. When the transfer process starts it changes the state to Processing and when the registered method for receiving the message is invoked the state is changed to Transferred. When the receiving method has processed the message the receiving method is responsible for changing the state to Accepted, Failed or Rejected depending on the outcome of the process.

If an error occurs during start of the registered method the message under transfer will be placed in state Incomplete and an error message can be found in the In Message attribute Error Message. When the error is corrected the message can be Reactivated and a new transfer will take place.

In some cases a message can remain in the state Transferred. This occurs most likely when a registered method doesn't exist. The transfer process cannot see that the registered method is missing and a background job is started. The background job will of course fail but there is no way to change the state of the transferred message. This kind of error can be detected in the Foundation1 Administration – Runtime Monitoring – Background Jobs. When the error is corrected the message can be Reprocessed and a new transfer will take place.

The method Connectivity_SYS.Process_Inbox__ is used to activate methods registered for receiving messages from the In Message Box. A process executing the method can be configured and started by the system administrator. This is done in the Foundation 1 Adminstration – Configuration – Parameters form.

When the process is running it will check the In Message Box at a regular interval for messages belonging to message classes with attribute Receive set to ON. Whenever a message is found the registered method is invoked to handle the message. If there are several messages a process is invoked for each message.

Performance considerations

The two processes Connectivity_SYS.Process_Inbox__ and Connectivity_SYS.Process_Outbox__ should not cause any problem because the load on them is light.

The process Out_Message_Util_API.Transfer_Data__ is executing in the system default batch queue. If there is a lot of other background jobs executing in the default queue this may cause the transfer of data to be waiting for resources in the queue. This can be avoided in one of two ways.

By increasing the number of simultaneously running processes in the queue the transfer process is more likely to be given resources but in some cases a few long running processes can block the queue.

The transfer process can be placed in a queue of its own. The number of simultaneously running processes in the queue can be set to the number of receivers of messages. This will give the transfer processes all the resources they need and the fastest transfer.

The processes executing the receiving methods are by default executing in the default batch queue. The same considerations as for the transfer process mentioned above can be made.

If a method is placed in another queue than the default queue and there still is performance problems the queue has to be examined considering how many methods are associated with the queue and how many simultaneously running processes is allowed. If there is no other methods associated with the queue then increasing the number of simultaneously running processes should be sufficient. If there is many other methods associated with the queue then a better approach is to divide them into two or more queues.

Process InMessageBox

A message is stored in two tables, In_Message_TAB containing header information used by Connectivity and the receiving application and In_Message_Line_TAB containing the actual message data.

In_Message_TAB

The columns in bold are used by Connectivity. The other columns can be used by the receiving application. If the message has been transferred by SQL*Net from an OutMessageBox on another site the SENDER_ID column contains the MESSAGE_ID in the OutMessageBox from where the message was sent. The column VERSION can be used by the receiving application to identify different versions of the same message type, CLASS_ID. The column CONNECTIVITY_VERSION is for internal use but is not used presently.

In_Message_Line_TAB

The columns in bold are used by Connectivity. The other columns can be used by the receiving application.

Process OutMessageBox

Data is stored in two tables, Out_Message_TAB containing header information used by Connectivity and Out_Message_Line_TAB containing the actual message data.

Out_Message_TAB

The columns in bold are used by Connectivity. The other columns can be used by the receiving application. The column VERSION can be used by the receiving application to identify different versions of the same message type, CLASS_ID. The columns MEDIA_CODE, FORMAT_CODE and CONNECTIVITY_VERSION is for internal use but is not used presently.

Out_Message_Line_TAB

The columns in bold are used by Connectivity. The other columns can be used by the receiving application.

Fetch messages

Select a message from Out_Message_TAB for Receiver/ClassId where Rowstate = ‘Released’.

Update the message head (Out_Message_TAB). Set Rowstate = ‘Processing’, Rowversion = sysdate and commit the transaction.

Process the message lines (Out_Message_Line_TAB).