TIF ENOVIA Connector - Module Settings

23 August 2013

1. Module Settings

The settings for the ENOVIA Connector in TIF is found inside the file ${TIF_ROOT}/modules/enovia/etc/module.properties.

If you want to change or add something in this file, create an empty file with name module.custom.properties in the same directory. All your changes should go into the customized file.

Note also that you may apply instance specific properties. This may be important in case you have multiple TIF instances running and you need to configure the instances slightly different.

Read here for more details.

1.1. JAR Inclusion / Exclusion

In order to be able to connect to ENOVIA/3DExperience with the Java API, you need some JAR files from the ENOVIA/3DX installation. One way to do this is to set the WEBAPP_ROOT environment variable pointing to the root of your ENOVIA web application when starting up TIF. Typically this is done within the ${TIF_HOME}/bin/setenv.sh script or similar.

Note that some JAR files that you might have in the web application you point out, may contain JAR files that is in conflict with what TIF is using. Hence, you need to be able to control what to include/exclude.

The following properties are used to control this.

  • include.jar.file.pattern.defaults

  • include.jar.file.pattern

  • exclude.jar.file.pattern.defaults

  • exclude.jar.file.pattern

The properties ending with .defaults contains a pre-defined list of JAR files to either include or exclude provided by TIF. Generally, you should not override or modify these properties.

Instead, to control what to be excluded OR included, use these properties within your custom configuration file.

  • include.jar.file.pattern

  • exclude.jar.file.pattern

Both of these properties contains a ; separated list of regular expressions that are matched on the files in the web application (the lib directory).

As of version 2020.1.0, a more restrictive strategy was introduced (the include pattern) due to increasing number of support tickets caused by including too many conflicting JAR files in TIF.

Per default, TIF provides both a list of JARs to be included and a list of JARs to be excluded. And these are defined as follows:

exclude.jar.file.pattern.defaults=mx_axis.jar;\
    slf4j-.*\.jar;\
    logback-classic.jar;\
    logback-core.jar;\
    profiler-server.jar;\
    tvc-collaboration-.*\.jar;\
    tif-enovia-client-.*.jar;\
    jsf-.*\.jar;\
    jstl-.*\.jar;\
    ehcache-.*\.jar;\
    enoappmvc.jar;\
    fasterxml-jackson.*.jar;\
    jackson-.*.jar;\
    javax.*.jar;\
    .*rest.*.jar
exclude.jar.file.pattern=
include.jar.file.pattern.defaults=eMatrixServletRMI.jar;\
	enoviaKernel.jar;\
	FcsClient.jar;\
	FcsClientLargeFile.jar;\
	Mx_jdom.jar;\
	search_common.jar
include.jar.file.pattern=

Moreover, you can disable a pattern completely by using any of these properties

include.jar.file.pattern.enabled=true
exclude.jar.file.pattern.enabled=true

So to revert back to pre-2020.1.0 behaviour, you can simply add this into your custom property file.

include.jar.file.pattern.enabled=true

1.2. HTTP Support

There is support for HTTP inside TIF, for example running Webservices etc.

You may disable HTTP, or make configuration changes such as changing context paths. All of this is defined in the module.settings file.

1.3. Integration with Elastic Search

You can configure TIF to integrate with Elasticsearch in order to enhance the usage of the Admin UI.

This in turn will also reduce the load on the TIF server since some queries from the Admin UI adds a lot of work to the TIF server. E.g. CPU/memory can be used for job processing instead of running expensive Admin UI queries.

You need to install Elasticsearch as a separate service. We have tested TIF with versions 6.2 up-to 7.1 of Elasticsearch.

After setup of the Elasticsearch server, you need to configure some properties on the TIF side.

searchIndexer=elasticsearch
elasticSearch.hosts=http://name-of-host:9200

There are plenty of other properties that plays a role, but by default you don’t need to deal with them. You can read more about these properties within the module.properties file.

If you have multiple TIF instances in your production system, all of these should use the same Elasticsearch instance.

TIF separates the data within the index by the tif-node-id AND tif-instance-id.

But, don’t use the same Elasticsearch index for TEST instances as you use for your PRODUCTION instances.

1.3.1. Search Index Synchronization

TIF has a routine for adding legacy data not yet being indexed, to the index by a Search Index Synchronizer.

If your database contains large amount of jobs and payload data, it may take some time to completely add all data into the index. The data is added to the index in chunks in order to not make the TIF server unresponsive.

There is a background task running on the TIF server that takes care about this.

This task is configured by default like this:

searchIndexer.synchronizer.execute=0 0/5 * * * ?
searchIndexer.synchronizer.job.chunkSize=2000
searchIndexer.synchronizer.job.maxIterations=100
searchIndexer.synchronizer.payload.chunkSize=300
searchIndexer.synchronizer.payload.maxIterations=100

E.g. every fifth minute, look for un-indexed data. On each run, run maximum 100 iterations and on each iteration try to index max 2000 jobs.

You may need to elaborate on these settings to your environment. It may also be wise to use different values during the initial period when all legacy data is being added to the index, and later change to run this routine less often.

The payload data will be added to the index AFTER all jobs have been added.

The chunk size for payload may need to be changed depending on typical/average size of your payload data.

If either chunk size or max iterations is set to a negative value, then no synchronization will be made for that type.

Un-indexed data is either job-data being created in the past OR job-data that is created during a period when TIF does not have contact with your Elasticsearch server.

1.4. Clean-up routine for scheduled job executions

Clean-up routine for old scheduled job executions is performed by scheduled job "tidy-routine-for-scheduled-job-executions" under group "tif-internal-maintenance-jobs".

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