TIF 2020.1.0 Release Information 2020-01-24

JAR Inclusion / Exclusion

Please read this since this is a behaviour change

A new strategy have been taken when TIF evaluates if a JAR file from the ENOVIA/3DEXPERIENCE web-application should be included or not in TIF.

A JAR file must per default now match the included list and must not match the excluded list. This change have been introduced due to that we have noticed some support incidents, all boiling down to too generous inclusion of JAR files from the ENOVIA/3DEXPERIENCE web application.

In previous releases of TIF, you could only control what JAR files to be excluded from the ENOVIA/3DEXPERIENCE web application via the exclude.jar.file.pattern setting.

As of this release, there are two new properties controlling the inclusion rules (in addition to the exclusion setting).

include.jar.file.pattern: This is the property you should use in your custom configuration file in order to declare additional JAR files to be included OVER the default added files.

This property is empty default.
include.jar.file.pattern.defaults: This property contains the default list of included JAR files. This property should generally not be modified in your own custom configuration file as this list is intended to be provided from TIF.

E.g. this pattern may be updated in future versions of TIF.

Theses properties follows the same syntax as the exclusion properties, e.g. regular expressions, separated with a semi colon ;.

To disable the use of the new inclusion rules, one can set the property include.jar.file.pattern.enabled to false OR use a regular expression that matches anything like .*.

Create update integration - File checkin event + processor

When a file is being checked-in, an event is fired allowing a custom event listener to react on this. For example, you might want to generate new thumbnails when an image or drawing is checked-in.

Below is an example how to react to such event in the listener.

    public void handleEvent(IntegrationEvent event) {
        switch (event.getType()) {
            case FILE_CHECKEDIN:
                FileEvent fe = (FileEvent) event;
                // do something with this event
                break;
            }
        }
    }

Also, all file check-in operations are dispatched via a FileProcessor. It is possible to override the default processor and provide your own.

To specify your own file processor, use the element <FileProcessor> within the <Config> element to define the class that implements the interface com.technia.tif.enovia.integration.create.FileProcessor.

Create update integration - XPath functions

Support for using XPath functions have been added when for example selecting values from the source payload. An example of such function could be to select a substring of something.

In case you want to use an XPath function, you need to define what that function returns. Possible supported return types are NODE, NODESET, STRING, NUMBER and BOOLEAN.

Below is an example how to use this feature.

<UpdateValues>
    <Attribute name="attribute_SomeAttribute"
               select="substring-after(Something/text(), ':')" (1)
               selectReturnType="STRING" (2)
               ifNull="fail" />
</UpdateValues>

1	Here we have a select expression containing an XPath function call.
2	Here we define that this function returns a string.

Create update integration - Relationship delete override

The relationship processor within the create/update integration now allows override the deletion of a relationship.

The interface com.technia.tif.enovia.integration.create.RelationshipProcessor has been changed and the following method has been added:

import com.technia.tif.enovia.integration.create.Context;
import com.technia.tif.enovia.integration.create.def.ConnectSpec;
import com.technia.tif.enovia.integration.create.RelationshipData;
...
void processDelete(Context context,
                   ConnectSpec config,
                   RelationshipData data);

Create update integration - Revise behavior and vault pattern

The revise behavior configuration of the Create / Update integration now supports defining a vault pattern that will be used when querying for the last revision. This can be useful in case you want to narrow your query for certain reason.

<ReviseBehavior
    reviseWithFile="true"
    searchVaultPattern="vault_SpecialVault,vault_eServiceProduction" (1)
    searchType="type_Part"
    searchExpandType="true" />

1	Custom vault pattern applied.

Request parameters of a REST service

The job details view of a REST service now also displays the request parameters.

These request parameters can also be exported as a part of the export to PDF/CSV functionality.

Clean-up routine for scheduled job executions

The clean-up routine for old scheduled job executions is now carried out via the internal scheduler at certain time intervals in order to be able to control this better.

By default, the clean-up runs once per hour and keeps 20 newest execution entries in the log history. The settings can be configured in ${TIF_ROOT}/modules/enovia/etc/module.custom.properties.

Defaults are as follows:

scheduledJobCleanser.enabled=true
scheduledJobCleanser.execute=0 0 0-23 * * ?
scheduledJobCleanser.keepCount=20

Fixed Bugs

Below is the list of fixed bugs as of this release.

Issue No	Description
680	Cannot access from/to id on a relationship from the RelationshipEvent object in the create/update integration
682	XML error when parsing custom executor config
683	RabbitMQ VirtualHost entry in destinations is not used while consuming a rabbitMQ message
686	The modified date is not updated correctly in the create/update integration if some other property was changed during the same operation