TIF 2023.1.0 Release Information 2023-01-20
JDK Note
The lowest JDK version supported by TIF is currently JDK 8. This will be the last version of TIF supporting that version.
The upcoming release of TIF will have JDK 11 as its lowest JDK.
Instance Specific Destinations File
The destinations.xml file within the ${TIF_HOME}/etc directory now supports having instance specific variants.
This means that you can have multiple destinations.xml files with content that varies depending on which TIF instance you are running.
The files are read in the following order:
-
etc/destinations.xml
-
etc/destinations-<TIF-INSTANCE-ID>.xml
-
etc/destinations-<TIF-NODE-ID>.xml
-
etc/destinations-<TIF-NODE-ID>-<TIF-INSTANCE-ID>.xml
JMS Listener
Reply To
A JMS listener can now be configured with reply-to destination information. This information is used to overcome the case when the incoming message either lacks this information, or you want to override the one set.
Example configuration:
<JMSListener>
<Name>Reply-to Example Listener</Name>
<Destination id="jms-test-src" />
<MessageSelector>JMSCorrelationID like '${tif.instance.id}|%'</MessageSelector>
<Transacted>true</Transacted>
<ReplyTo destinationId="jms-test-dest" override="true"> (1)
<Header name="abc" value="123" /> (2)
</ReplyTo>
<Handler type="TransformXML" />
<Arguments>
<Argument name="json-in">true</Argument>
<Argument name="stylesheet">tvc:xslt/ConvertData.xslt</Argument>
</Arguments>
</JMSListener>| 1 | Define where replies are put. The destinationId references a declared destination within TIF. . The override flag is per default true but if set to false the reply-to destination, if available, from the incoming message defines the destination of the reply message. |
| 2 | Adds additional header to the response message |
Transacted
A new configuration option have been added to allow set/override the transacted mode for a message handler.
<JMSListener>
<Transacted>true</Transacted>
</JMSListener>Normally this is defined by the message handler itself, however, declaring it here overrides the message handler and is useful in those cases you are using a pre-defined handler and don’t want or cannot change the source code.
Transaction Type for Custom Job
By default, TIF does not start a transaction inside the ENOVIA/3DEXPERIENCE database for the custom executor.
To change this behavior, you can use the txType attribute like shown in the example below.
<Job>
<!-- txType accepts values "none", "read" and "update" -->
<Executor className="com.acme.MyExecutor" txType="read" />
...
</Job>
The attribute txType fixes the bug TIF-920 and also replaces the old configuration format.
|
Hosted REST Services & Job Logging
The job logger for hosted REST services now filters out invalid requests (status code 4xx) to REST services that are not yet persisted in the TIF database. In this case the logger does not create any jobs, and such invalid requests are only logged to the TIF log file.
Services are created upon first successful request, and after that all subsequents requests, including invalid, are persisted.
Job Event Handler for Changing Source Object
There is a new job event handler <ChangeSourceObject> that is applicable to outbound ENOVIA/3DEXPERIENCE jobs.
This handler allows to promote or demote the source object, or for setting attribute values on the source object.
Attribute values can either be static or it can be extracted from a response that is returned by an outbound destination.
An example configuration:
<Job>
...
<TransferData>
...
<Destinations>
<Http id="http-xml" />
<Http id="http-json" />
</Destinations>
</TransferData>
<Events>
<Success>
<ChangeSourceObject>
<!-- Promotes the source object -->
<Promote />
<!-- Sets attribute value that is resolved from an XML response -->
<SetAttribute name="attribute_First" xpath="/root/sub" destinationId="http-xml" />
<!-- JSON path is also supported -->
<SetAttribute name="attribute_Second" jsonPath="$.root.sub" destinationId="http-json" />
</ChangeSourceObject>
</Success>
</Events>
</Job>Customize File Check-In for Batch Job
The file check-in action for CreatePDF, PDFWatermark and UpdateProperties can be customized by injecting a Java class.
For example:
<Job>
...
<FileModifier>
...
<CreatePDF>
<Checkin fileName="${name}.pdf" className="com.acme.tif.CustomCheckin" />
</CreatePDF>
</FileModifier>
</Job>The class must implement the interface com.technia.tif.enovia.job.executors.file.CheckinAction, or
extend the default action com.technia.tif.enovia.job.executors.file.DefaultCheckinAction.
This opens possibilities to either override the check-in operation or perform additional logic before or after the check-in operation took place.