TIF ENOVIA/3DExperience Server - Jobs and Queues

Jobs executed on the TIF server may be initiated through some event within the ENOVIA/3DEXPERIENCE application. You may for example configure a trigger that will initiate a job (for example promote event, create event etc.).

The kind of jobs that most typical is initiated in this way are Outbound Integration Jobs and/or Batch Jobs.

When this happens, then within the ENOVIA/3DEXPERIENCE database a business object of type "TIF Job" in a separate vault dedicated to TIF is created. This job object holds the necessary information for the later execution of the Job on the TIF side. The Job object is then connected to a Queue object (type is "TIF Queue").

These TIF Job business objects will after completion, at some point in the future, be deleted automatically by a scheduled task running at the TIF server.

A job may be configured to be executed in one particular queue (if not defined, the default queue will be used). See chapter Create Trigger for some additional information. The reason for this might be to ensure that only certain TIF instances are processing certain jobs, and/or for scalability reasons.

A setup of TIF might look like the diagram below illustrates.

Jobs and Queues

In this case we have four queues setup in ENOVIA/3DEXPERIENCE and we are using two different TIF instances (TIF processes). TIF Instance 1 picks job from the default queue including the queue with name "Queue 1".

The second TIF instance processes jobs from "Queue 2" and "Queue 3".

To configure TIF for listening to a particular queue or configure it to NOT listen on the default queue, please look at the page Module Settings

Configuring Queues

In the module properties file you define which Queues you will listen to, e.g. what queues in ENOVIA/3DEXPERIENCE you will process jobs for.

If you have set up several TIF instance, you may want to configure which instances that processes jobs from what queues.

By default, there is always a 'default queue' available in TIF. If you for example have multiple TIF instances running, each instance will by default process jobs from this default queue.

To disable listen on the default queue, you will use the following property

defaultQueueListener.enabled = false

Most common is to allocate jobs with the default queue. However, in some cases it might be useful to process certain jobs in its own queue. When you create the job object, you simply specify the name of the queue - this queue is automatically created if it doesn’t exist.

However, in order to process jobs from this queue, you need at least one TIF instance that listens on such queue.

In order to setup a listener for a particular queue, look at the example below:

queueListener.MyQueue.enabled = true
queueListener.MyQueue.name = My Queue
queueListener.MyQueue.threadCount = 5
queueListener.MyQueue.sleepInterval = 15000
queueListener.MyQueue.exclusive = false
queueListener.MyQueue.start = true

When declaring a queue, you use a prefix following this format:

queueListener.<ID>.

Each queue uses its own <ID> value and it can be whatever value as long as the key itself is a valid Java property, however, recommended is to use something relevant for the queue in order to make debugging a bit easier.
name

Defines the name of the business object stored within the ENOVIA/3DEXPERIENCE database.

threadCount

The thread-count property defines how many worker threads will be used, e.g. how many concurrent jobs will be processed by this queue.

Default is 5 unless defined

sleepInterval

The sleep-interval is a value in milliseconds defining how long time to sleep until next check (if no jobs were found in the queue in the previous check).

Default is 15000 (15s)

exclusive

The exclusive flag should be set if you are sure that you don’t have any other TIF instance polling the same queue.

When a queue poller have exclusive access to a queue, the polling will be much more efficient as there are no need to lock/unlock objects to ensure exclusive access.

Also note that in exclusive mode, TIF will per default also batch poll more items in order to reduce the number of database calls. The default prefetch size is set to 10*<number-of-threads> but can be changed.

start

The start flag can be used to create/setup the queue listener but not starting the job consumption when the TIF server is starting up.

If set to FALSE, the queue consumer must be started manually from the Administration UI.

Default is true.

There are also some additional properties that can be used to control the queue consumer:

# Declare EXCLUSIVE access + Override PRE-FETCH-SIZE
queueListener.MyQueue.exclusive = true
queueListener.MyQueue.prefetchSize = 25

In the above example, we declare the queue consumer to have exclusive access to the Queue. We can also override the pre-fetch size with some other value.

Prefetch is done in order to reduce the overhead for getting and starting up new jobs from a Queue.

# Declare a delay in SECONDS how much delay a job must have at minimum
# between creation AND pickup time.
queueListener.MyQueue.pickupDelay = 10

It is possible to configure pickup delay in seconds. In practice, the queue listener reacts on created jobs with delay by not picking up jobs created within queueListener.MyQueue.pickupDelay.

The pickup delay works well in combination with exclusive jobs to prevent for example triggers from creating duplicate jobs.

It is also possible to configure pickup delay for jobs created in a certain queue OR for a certain job type via TVC init parameters. See the ENOVIA/3DEXPERIENCE Client part of the documentation.

Create new Queue in ENOVIA/3DEXPERIENCE

To set up a new queue in ENOVIA/3DEXPERIENCE, use the following MQL code as base for so.

add bus "TIF Queue" "MyQueue" "" vault "TIF" policy "TIF Queue";

Queue Polling

Jobs are polled from the queue in the order they are created. E.g. first in first out.

This is by default accomplished by performing an expansion of the Queue with limit 1.

There has been some issues reported related to returning of jobs in wrong order. This is caused by a bug in ENOVIA/3DEXPERIENCE and to work around this issue - it is possible to change the polling strategy.

To change the polling strategy, use the property defaultQueuePollStrategy in module.properties.

Allowed values are

  • query-connection

  • expand-select

  • expand-iterator

  • expansion-iterator

  • mql-expand

  • mql-query

  • query

TIF will by default use either expand-iterator or expand-select depending on backend Database. But if you experience issues with job processing order, you should try changing this value to "query-connection".