The transport connectors handle the communication between the business system and message hubs, output services/devices, and application connectors. The need to transport messages outside a particular system node can occur, e.g. because of a process which is implemented across systems, a user or customer notification, the need to hardcopy something, or for many different reasons.
These are the transport connectors included in IFS Connect. The links leads to the instructions on how to administrate them.
As much as the technical implementation differ between the transport connectors, they all have a common set of functionality which they provide to the applications. Transport connector can be of the type Sender that handles the Outbound messages and Reader that handles Inbound messages.
Connector's native code is executed in a separate thread utilizing concept of Application Server's Work Managers. Thread isolation gives better possibilities for catching possible errors and hang-ups during execution of the native code.
Connect Senders are used for sending messages to other business systems, message hubs, output services/devices. The need to send outbound messages occur because of a process which is implemented across systems, a user or a customer notification, a need to hardcopy something or for many different reasons. In any case, connector senders will do the Protocol adaptation which handles IFS protocol on one side, and a potentially different protocol (perhaps API based) on the other side.
All Senders are running in the J2EE server, no external server is
needed for outbound messages like notifications.
Connect Readers are used for receiving messages from other business systems, message hubs, output devices and so on. Processes implemented across systems may need to require information exchange that involves Connect Readers. Similarly to senders, readers will do the protocol adaptation to IFS internal protocol.
All Readers are running in the J2EE server, no external server is needed for inbound messages.
Note: Please note that if upgrading from IFS Applications 9 (or earlier) the old Connect Server needs to be stopped and removed. Read more about Removing Connect Server.
Connector Reader framework architecture is based on EJB Timers and JMS messaging. Each Connector Reader instance, i.e. an instance configured in Setup IFS Connect window in Solution Manager, will correspond to a single timer. The Middleware Server chooses then the node to execute the reader on and has a capability to move the reader (timer) to another node, if necessary. There will be always only one instance of a particular reader (EJB timer) in the entire cluster. It will guarantee failover and scalability. Connector Reader framework, which is a part of IFS Connect framework, is deployed to the Integration cluster.
The following diagram shows the message flow through the Connector Reader framework:
A reader (timer) fires twice in a minute and scans the message source creating a list of messages that don't have been processed yet. Listing of messages doesn't involve reading them (e.g. light ware directory listing). For each listed message a JMS message with the message's unique ID will be sent. Message Driven Beans (MDB's) reading from the JMS queue will be instantiated by the Middleware Server and can reside on different nodes in the cluster. The server decides the number of MDB's reading form the JMS queue. This makes it possible to process a number of messages in parallel.
Information about messages that cannot be read or deleted (e.g. corrupted or locked files) is written to the database with proper status and can be examine in the Connect Reader Queue window in Solution Manager.
The above diagram shows possible state transitions for rows in the Connect Reader Queue.
When the reader's timer service sends a JMS message about a listed message,
it creates also a corresponding record in Connect Reader Queue table with status
Listed. The MDB is reading the JMS message and with the listed message ID is
trying to read it, process and then delete. On success the database record is
removed.
On failure while trying to read the message the MDB will change the record
state to Read Retried and set up a retry counter. On next listing the reader's
timer service will change the record status to Read Retry and send again
corresponding JMS message. The MDB will try to read and process message again and then
either delete the record (on success) or change status again to Read Retried and
increase the retry counter. If the retry counter reached the maximum value
defined for the reader, the MDB will set record status to Read Failed and the
corresponding message will be ignored in future listings.
Similar algorithm has been implemented for deletion. Failure on delete try
will cause the database record status to be set to Delete Retried, which will
cause in turn the timer service to change the status to Delete Retry and send
the JMS message. If the number of tries reached the maximum value, the MDB will
set the final status to Delete Failed and the corresponding message will not be
listed any more. Of course messages that failed on delete attempts have already
been successfully processed,
A Connect Reader Queue record can have following states:
For some readers this is not possible to create message listing without reading the messages. In some circumstances it is also impossible to create/extract an unique message ID. This type of readers has to be processed in a loop, which means that messages are read entirely by the reader and posted to the JMS queue. Instead of nativeList such readers implement nativeLoop and for each message call a callback method processMessage. This message will post a JMS message containing the read message in full, not just message ID. The MDB will simply read the message content and process it. The Connect Reader Queue table is not used at all for this type of readers. Even if reading and processing of messages is separated those readers will not perform as well as readers that can list messages.
Mail and JMS readers are of this type.