TIF 2017.2.0 Release Information

The registration of reply handlers have been improved in order to align with the way XML based listeners are registered (see below). E.g. upon startup, the available reply-handler configurations will be deployed automatically.

Note that the old way of registering a reply handler within the module.properties file is still supported. You can also disable the auto-registration if you would like to.

Another change made, is related to how you configure the availability of an ENOVIA™ context during the processing of the reply handler. Earlier, this was something you configured within the module.properties by using the context properties. These are for technical reasons not supported since they were not working as intended. There is a new way of configuring this within the XML configuration instead. Example below:

Read more in this document.

Support for authentication via spnego/kerberos has been added.

Please read more in the following documents regarding details of the setup

Files that are processed via a Directory/File listener in TIF are now logged in the TIF database and can be monitored within the Administration UI.

The different types of listeners supported by TIF can now be defined in XML files as part of the XML configuration tree.

The listeners in question are:

This will make it easier to handle configurations across installations but also make it easier to validate configurations using XML schemas to catch up errors. Moreover, this way of specifying a listener also allows reloading them without re-starting the TIF server, e.g if you need to change a configuration you simply have to restart the service from within the TIF Administration UI.

Saxon-HE 9.7 XSLT processor is included to TIF Core to support XSLT 2.0 stylesheets.

This will allow you to do more powerful stylesheets, for example when generating payloads.

Earlier a Rest Service definition were required to have a <ServiceName> element defining its URI. As of this release, if this element is not present - the service name is calculated automatically based upon were in the filesystem the configuration is located.

For example, a rest service definition stored as ${TIF_ROOT}/modules/enovia/cfg/restservice/test/part-data.xml will have its service-name calculated to test/part-data.

SOAPAction header in SOAP destinations can be constructed only using base URL that can be empty. Action and method are now optional, not required.

The Administration UI is now using Bootstrap 3 as its presentation framework instead of version 2.