Work Managers

By using Work Managers the IFS Connect framework can achieve thread isolation when executing native code within Connector Senders and Readers, but also when calling BizAPIs or other operations within Service Handlers. Furthermore Work Managers can be used for better control of Message Driven Beans (MDBs) behavior used by the IFS Connect framework.

Contents

Overview

IFS Connect framework is using Work Manager API, from the commonj.work Java package, to run native code in Connector Senders and Readers, but also BizAPIs and service handler operations, in a separate thread. Work Managers and the associated threads are controlled by the Middleware Server. With this concept it is possible to run a particular piece of code in another thread while the caller is waiting for the thread execution to be finished. It is also possible to define a maximum amount of time (work timeout) the caller is supposed to wait for the thread to finish. If the code executed in another thread takes too long time, for example because of it is hanging on external resource, the caller can abandon the called code in the other thread and continue with the flow. The other thread may finish its execution later on or may be hanging, but the result will not be delivered to the caller in such situation and the actual Application or Reader Message will be marked as failed.

Work timeouts can be specified in Setup IFS Connect window located in Solution Manager / Integration / IFS Connect

Work timeout for Connector Senders and Readers

You can specify the work timeout for each instance of Connector Sender or Reader in Setup IFS Connect window. On each sender or reader instance you'll find a parameter with name WORK_TIMEOUT that is accepting an integer value representing work timeout in seconds. If not specified the default value is taken.

Work timeout for BizAPIs, Service Operations and PL/SQL methods

In Setup IFS Connect window, Servers, configuration of J2EE_SERVER instance you will find a grid allowing you to enter work timeouts for BizAPIs, Service handler operations and PL/SQL methods:

Here you can enter a BizAPI name or operation/method name in the left column and define work timeout in seconds in the right column. A list of available BizAPIs is presented as a drop down list, but to enter an operation name not connected to a BizAPI you have to enter the handler name and operation name on form HandlerName:OperationName. When entering PL/SQL method name use form Package.Method. On save the entered data is validated against the system and if a BizAPI or operation is not found the warning will be displayed, but the data will be saved anyway. The PL/SQL method name is not validated. A syntactic incorrect name will however generate an error.

Note however that both validation and population of the drop down list with BizAPIs are done by connecting to the Integration cluster, which may not be reachable of different reasons when configuring timeouts.

If work timeout for a particular BizAPI, operation or PL/SQL method is not specified the default value will be taken then.

Read more about how to work with grid parameters.

Default Work timeout

If work timeout for a particular instance is not specified the default value will be taken. The default work timeout can also be defined in the Setup IFS Connect window, Servers, configuration of J2EE_SERVER instance. Here you will find an integer parameter with name DEFAULT_WORK_TIMEOUT that will allow you to specify the default timeout in seconds:

Message Driven Beans

All Message Driven Beans used by the IFS Connect framework (see also Batch Processor) have corresponding Work Managers defined in the Middleware Server. By default only some of them have additional constraints defined, but it is possible to add/modify constraints to all Work Manages, if necessary.

Synchronous invocation from PLSQL Acces Provider

For best performance, low latency and good throughput, all Message Driven Beans and Connect Senders involved in processing of outbound synchronous message have their Work Managers defined with additional constraints (Forwarder MDB, Invoke MDB, Connect Sender Invoke; both Main and Integration cluster).

The defined constraints are:

The default values should be sufficient in the most of cases, but if necessary can be changed to values more suitable for the actual installation. It is possible to enable statistics and with help from R&D organization find out the proper values of the constraints.