TIF 2019.1.0 Release Information

01 March 2019

1. Payload Configuration - Reuse of Data Set

In some cases you may use the same data-set across several fractions within a payload configuration. In order to avoid that the same data-set is evaluated multiple times during the creation of the payload, you can now set the attribute cacheResult to true on the <DataSet> element defining that caching is supported.

Example below:

<Payload
    xmlns:xs="http://www.w3.org/2001/XMLSchema"
    xmlns="http://technia.com/TIF/Payload"
    xmlns:common="http://technia.com/TIF/Common"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="http://technia.com/TIF/Payload http://products.technia.com/tif/schema/latest/Payload.xsd"
    rootElement="ProductData">

    <TableContent outerElement="Product.Basics">
        <Table ref="tvc:table:product/Product.Basics.xml" />
        <DataSet cacheResult="true" ref="tvc:dataset:product/GetProduct.xml" /> (1)
        <XMLSpec ref="tvc:xmlspec:product/Default.xml" />
    </TableContent>

    <TableContent outerElement="Product.Extended" if="View.Product.Extended">
        <Table ref="tvc:table:product/Product.Extended.xml" />
        <DataSet cacheResult="true" ref="tvc:dataset:product/GetProduct.xml" /> (2)
        <XMLSpec ref="tvc:xmlspec:product/Default.xml" />
    </TableContent>
</Payload>
1 cacheResult defined here as we want to reuse the output from this result later on
2 Same data-set references as above, we want to avoid evaluating the data-set again.

2. Custom Payload Transformer and Validator

It is possible to implement custom Java classes that validate and transform the payload.

Examples:

<Payload>
    ...
    <Transformer className="com.acme.MyTransformer" />
</Payload>
<Payload>
    ...
    <Validator className="com.acme.MyValidator" />
</Payload>

Also, there is an configuration option to transform XML payload to JSON:

<Payload>
    ...
    <Transformer type="json">
</Payload>

3. Create Update Configuration

3.1. XML Namespaces and XPath Expressions

The Create Update configurations uses XPaths heavily to identify nodes and traverse the incoming payload. In case your payload contains namespaces, it has been difficult to construct these XPath expressions nicely and correctly.

As of this release, you can now add namespace mappings to the configuration or even use automatic mapping by copy over the namespace/uri mapping from the source documents. The latter is convenient in case you know what prefixes are being used in advance.

Below is an example how the namespace configuration can be used.

<CreateConfiguration>

    <Namespaces>
        <Namespace prefix="a" uri="http://the_uri_for_a" />
        <Namespace prefix="b" uri="http://the_uri_for_b" />
    </Namespaces>

    <EntryPoint select="/a:ReadRequest/Resource[@xsi:type='b:Resource']/Item[@xsi:type='c:Product']" />

    <Config match="Item">
        <CreateValues>
            ...
        </CreateValues>
        <UpdateValues useForCreate="true">
            <Description select="Identifier[@xsi:type='d:ProductDescription']/text()"/>
        </UpdateValues>
    </Config>
 </CreateConfiguration>

3.2. NameField - Wildcards

The <NameField> have a new configuration option, allowing to specify if wildcard characters such as * and ? are allowed in the value. By default, wildcard characters are not allowed.

<Config match="Item">
        <IdentityMatch>
            <Name select="ItemNr/text()" allowWildcard="true"/>
            ...
        </IdentityMatch>
        ...
</Config>

4. Credentials Enhancements

The configuration of the credentials within the configurable REST and SOAP services have been enhanced.

Now you can configure some access restrictions based upon

  • ENOVIA/3DExperience role assignments

  • Role assignments in the Active Directory in case you use external authentication via Kerberos/SPNego.

In addition, you can also specify what ENOVIA/3DExperience Security Context you will run the service with. The used security context can be the "default" context, a specific context or a context mapped depending on the caller. This mapping may be based upon the actual remote-user, remote-user role assignment or request parameters.

Please read more here.

5. CXF Logger

The SOAP logger in CXF has been updated and will per default construct the service name (the name appearing in the Administration UI) based upon the URL and automatically remove any prefixes not part of the service URI.

E.g. the previous init-param to the logger filter called trim-service-name have been removed and is no longer used.

6. Config Directories

For convenience we have added support for a Java system parameter allowing specifying an extra directory holding configurations used in TIF. This is especially a nice feature during development, since you do not have to deploy configurations from your source directory into the TIF config directory.

The name of this system property is extraConfigDirectory and the value should be a path pointing to a directory.

In the Start script for TIF you could apply it like below:

export START_ARGS=-DextraConfigDirectory=/home/user/repos/test/cfg
...
This applies only to configuration files stored in ${TIF_ROOT}/modules/enovia/cfg. Other configuration files cannot be overridden via this.

In addition, we have added two more properties:

Name Description

configDirectory.webapp.enabled

Can be used to disable loading configuration files from the webapplications WEB-INF/tvc folder (in case you reference the Web-app root dir in the start of TIF).

configDirectory.default.enabled

Can be used to disable loading configurations from the default "cfg" folder.

7. Configuration Editor

The configuration editor is added to the Admin UI. With the editor, you can view, modify and create configuration files in the Admin UI. The editor might be useful for develop and brief adjustments.

The editor can be accessed from the "Configuration" menu in the Admin UI.

For more details, goto this page.

image
Figure 1. Configuration Editor

8. Mail Configuration

In some cases you may need to pass in extra settings required by the mail server, such as authentication settings among others.

You can specify additional "mail." properties in ${TIF_ROOT}/etc/tif.custom.properties, and these will automatically be passed over to the Java Mail API.

Example below how to pass in extra auth settings for SMTP.

mail.debug=true
mail.smtp.auth=true
mail.smtp.user=user_id
mail.smtp.password=the_secret_word

9. Fixed Bugs

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

Issue No Description

558

TIF Admin UI is logging out on when multiple TIF instances running on the same machine

553

Exception when transfer payload to Http destination fails

584

Not possible to resend a job with Elastic Search