TIF 2025.2.0 Release Information
This release was published 2025-05-16
Source Object Info Resolver
The Job configuration allows resolving some information from the source object using the construct below.
<Job>
<Name>Part Basic</Name>
<SourceObjectInfo>
<Text>TEST:</Text>
<Basic>type</Basic>
<Basic>name</Basic>
<Text>, status:</Text>
<Basic>current</Basic>
<Text>, Weight:</Text>
<Attribute>Weight</Attribute>
<!-- or: <Select>attribute[Weight]</Select> -->
</SourceObjectInfo>
</Job>
or using a customized handler like below:
<Job>
<Name>Part Basic</Name>
<SourceObjectInfo className="com.technia.tif.enovia.job.impl.SourceObjectDescriberFromJobParam" jobParam="nameOfParam" />
</Job>
The class name used, must implement the interface com.technia.tif.enovia.job.SourceObjectDescriber.
The example above is an example implementation, which is capable of resolving the value from a job parameter.
In the Admin UI, the information is shown in the column called "Source Object Info".
Queue Polling / Prefetch
The queue polling logic, which is responsible for getting the Job objects from the Queues in the ENOVIA/3DEXPERIENCE database have been rewritten as of this release to support prefetching of > 1 job per DB request.
The purpose of performing pre-fetch of jobs is to increase the throughput for queues that contains many jobs.
Pre-fetching is only enabled if the queue-consumer is configured for exclusive access. E.g. there is only one TIF Instance that processes jobs from such queue.
Below example shows how to set the exclusive flag for either the default queue or a custom queue.
# Default queue
defaultQueueListener.exclusive = true
# A custom queue
queueListener.AnotherQueue.exclusive = true
Per default, the pre-fetch size is set to 10 * <NR-OF-CONSUMER-THREADS>. This can be changed via the prefetchSize property as shown below:
# Default queue
defaultQueueListener.exclusive = true
defaultQueueListener.prefetchSize = 25
# A custom queue
queueListener.AnotherQueue.exclusive = true
queueListener.AnotherQueue.prefetchSize = 50
Batch Jobs - File Handling
There are a few improvements introduced for file handling in batch jobs. Now, instead of checking in a file, it is possible to inject a custom file handler, which receives the file as input. This handler can be used to execute custom Java code in response to file actions.
Additionally, there is a new configuration attribute called storePayload, which allows to store the processed file as an outbound payload. The payload can later be used as input, for example, to launch a new job. One possible use case is to forward the generated PDF file to a File Package job, which transfers the file to a remote destination along with associated metadata.
Furthermore, there is a new option to inject custom Java code to serve as a file filter. This is useful in cases where the static filter options do not meet your requirements.
See the examples below. More details are available in the Batch Job documentation.
File filter with a custom Java class:
<Job>
...
<FileModifier>
<FileFilter className="com.acme.tif.MyFilter" />
...
</FileModifier>
</Job>
File handler with a custom Java class:
<Job>
...
<FileModifier>
...
<CreatePDF>
<Handler className="com.acme.tif.MyHandler" />
</CreatePDF>
</FileModifier>
</Job>
The attribute storePayload:
<Job>
...
<FileModifier>
...
<CreatePDF storePayload="true" payloadFileName="${name}.pdf">
...
</CreatePDF>
</FileModifier>
</Job>
Planned Upcoming Changes
As announced in past release, there are some upcoming changes planned that are good to be aware of. These are described here.
Fixed Bugs
Below is the list of fixed bugs as of this release.
| Issue No | Description |
|---|---|
1039 |
Unable to create user without email enabled |
1041 |
Custom REST service that does not require authentication returning a 401 status code IF container based authorization enabled for other webservices. |
1047 |
Migration executor fails to initialize |