Release Information

Release Information - Version 1.17

Password Policy

A password policy has been assigned to the Administration UI. This will only affect new user accounts or when an existing user is changing their password.

The new policy has these restrictions:

May not contain user-name nor email
Minimum length: 16
At least one special character
Expires after 180 days
Not allowed to reuse any of the five last used passwords

Http Client - Retry Support

The HTTP client used in the various integration configurations now has built-in support for retry management.

There are some reasonable default settings applied to the HTTP client, but can be overridden programmatically.

You can control the following retry settings:

Max attempts: How many attempts to call an endpoint in total, including the first initial call
Delay: A delay to be applied between two calls.
Backoff multiplier: A multiplier to be applied on the delay value on each retry. For example, having a backoff multiplier of 1.2 means that the delay after the second retry is multiplied with 1.2. And each upcoming delay is multiplied again with a factor of 1.2
Max delay: The maximum delay, no matter what the delay and the back-off multiplier calculates to, this is the maximum delay.
Allowed HTTP status codes: Defines the HTTP status codes that would yield a retry. Normally errors due to client errors, should not be retried without modifications. But, various systems uses response codes slightly different thus this configuration option allows fine tuning that behavior.
Honor Retry After HTTP response header: If the called server returns an HTTP response header named Retry After, which often is used together with the 429 response code, this setting tells if to honor that or not.

This value is allowed to be greater than the 'Max Delay'.

If to allow retries on non-idempotent requests: Normally, only idempotent request are retried. That means request using method GET, PUT, DELETE are retried. POST and PATCH are not.

See this document for further details regarding the retry support in the HTTP client.

The Http Client used for the 3DEXPERIENCE™ REST API, can also be configured.

Please read more here.

Support for Query Filter

The following entities:

Event Mappings
REST Mappings
Services

Supports better and more precise filtering in the Administration UI. Example below for Service entities.

Figure 1. Service Filter

Show a View button when an entity is created

Once a new entity of type event mapping, rest mapping, custom feature, email trigger, webhook trigger, scheduled task, agent, auth settings, destination is created, a link is shown to open the new entity.

Job Execution Time

Per default, jobs may not execute for more than 2h. This was a fixed time limit for all tenants, until now.

As of this release, each tenant may configure/control this value individually.

On the application settings page, found via "Settings" → "Common Settings" → "Application", the max job execution time settings can be changed.

Figure 2. Application Settings

Max value is 4h. Remember that jobs should normally not run for more than max up to a few minutes to allow reasonable throughput of your integration jobs. Having very long running jobs will just pile up a large backlog of jobs.

DS API Gateway Support

DS are gradually moving towards using one central service for their API calls. This central service is called API Gateway.

TIF have added support for using the API Gateway as of this release.

Since using the API Gateway requires an API key to be sent on each service call made, you will need to create at least one such API Key within the 3DEXPERIENCE™ application and add this into TIF. Also, you need to configure your TIF environment to operate in API Gateway mode via the DSX connection settings page as shown in the screenshot below:

Figure 3. Configure use of API Gateway

Read more about the DS API Gateway here.

Make sure that all customizations that has been made, supports using the gateway mode before switching over to using the API Gateway

Monaco editor

The code editor used in TIF Cloud have been replaced with the Monaco Editor.

The Monaco Editor is the code editor used in VS Code, developed by Microsoft™. It is licensed under the MIT License and supports Edge, Chrome, Firefox, Safari and Opera.

The Monaco editor is not supported in mobile browsers or mobile web frameworks.

Connection Settings UI

The UI for the DS connection settings has been slightly improved to distinguish fields that contain generated values from the fields that require user input.

The fields are moved into different tabs.

Figure 4. Connection Settings

TIF Executor API - Improvements

JSON-ata Support

TIF now supports JSONata — a lightweight query and transformation language for JSON data. JSONata lets you express sophisticated queries in a compact and intuitive notation, manipulate and combine extracted data using a rich set of built-in operators and functions, and shape the results into any JSON output structure using standard object and array syntax.

User-defined functions are also supported, enabling advanced expressions for virtually any JSON query or transformation task.

An example of how to use the new JSONata API is shown below:

const data = { /* ... */ }; // Object or JSON string here
const ata = '$sum(Account.Order.Product.(Price * Quantity))';
const evaluator = context.jsonAPI().jsonAta(ata); (1)
const result = evaluator.evaluate(data); (2)
const expected = 336.36;

1	Get the JSONata evaluator for the given expression
2	Evaluates the expression over some data

Remove all outbound files

When a job is executed, the logic may attach data/files to the job result, e.g. outbound payload.

A new method has been added to allow removing all such data using a oneliner, like:

const removedCount = context.result().removeData();
if (removedCount > 0) {
    console.log('Removed %d outbound payload from the result', removedCount);
}

3DEXPERIENCE™ REST API - Improvements

Document Helper Service

The document helper service, available via the "dsxAPI" has a new method that simplifies the use case create and connect a new document.

See this page for details.

Getting the TenantSession object

In previous versions, to get the TenantSession object, you had to pass in the application object as argument like this:

const api = context.dsxAPI();
const space = api.getSpaceService();
const session = api.getTenantSession(space); (1)
const engItemService = space.getEngItemService();

1	Getting the session with the Space application service argument

There is no need to change any existing code, as this pattern will still work. But for the future, you could simplify the above like this:

const api = context.dsxAPI();
const session = api.getTenantSession(); (1)

api.getSpaceService().getEngItemService().search(session, ...);

1	Same session used regardless of what application is being used

E.g the same session object is used for all services.

Check if API Gateway Mode is enabled

On the session object, one can check whether the API Gateway mode is enabled.

session.isUsingApiGateway()

This may be needed in cases where the Generic Service is being used to call a 3DEXPERIENCE™ webservice, since the URI’s are different depending on the connection mode used.