Configurations

In TIF Cloud you can setup different "Configurations". A configuration consists of a name, a type, some content and with some optional key/values (properties) attached.

The configuration itself is used in different integration use cases. Either the configuration will contain some execution logic declared in Script format, such as JavaScript, or it will contain input parameters to some pre-defined integration-type (a parameterized type).

The type property on the configuration defines what kind of content you can have in the configuration itself.

Some type’s might also provide an additional UI in order to simplify editing the content of the configuration.

Referencing a Configuration

A configuration is referenced from an event-mapping or a REST-mapping.

Within the Event/REST-mapping, you will point out a configuration that will perform the job. The type on the configuration defines how the configuration will be executed. Each type has its own executor capable of interpreting the content of the configuration.

If the configuration is of type "JavaScript", then the content of the configuration will be executed as a javascript within the TIF Cloud backend.

There might be other kind of configuration types available, which instead just will contain some "input parameters" to a pre-defined executor. In such case, the configuration that you point out will only carry a reference to the pre-defined executor via its "type", and the configuration content will be used as input for this pre-defined executor.

Once a job is started, the application will automatically track what version of a specific configuration that was used to perform the job. So two jobs executed at different time using the same event mapping may use two different versions of the same configuration IF changes have been made to the configuration between the execution of the two jobs.

Configuration Properties

These are the properties that is available on a configuration

  • name

    • Logical name of the configuration.

    • Use forward slash (/) to build up hierarchical names logically grouped together. Similar to package names in Java.

  • type

    • Defines the configuration type. This value is used to resolve what "Executor" to be used.

    • You can for example point out built-in executors like "sap:sendEBOM" or similar. NOTE: The available built-in executors available to chose among depends on licenses and what features that have been granted to an environment.

    • Or you can specify "JavaScript" and by so allowing scripting to take place.

  • content

    • Depending on the configuration type chosen, the content of the configuration follows different format.

    • In case type is set to "JavaScript" then the content is java-script code.

  • properties

    • Key/value pairs providing additional input for the executor.

    • Certain executors are parameterized and allows to be configured via these properties.

  • version

    • Over time when the configuration is developed, the application may create snapshot versions of the configuration in order to be able to track exactly how a configuration was defined when a job was executed.

Creating a Configuration

Only users having the role 'Configuration Editor' can create and edit configurations.

Within the Administration UI, creating a configuration is done from the Actions menu.

create config
Figure 1. Create new Configuration

When creating the configuration, you need to give it a name and a type. Names can contain forward slashes in order to build tree-like structures of configurations.

create config input
Figure 2. Configuration Name and Type

When editing the configuration, a suitable editor depending on the type will be opened.

edit config
Figure 3. Edit Configuration

In the UI you save the changes made to the configuration via the save icon. Moreover, there is a "play" button available, which allows you to test the configuration.

config buttons
Figure 4. Configuration Actions
Configurations that belongs to extensions installed from the Marketplace will generally appear as read-only in the editor.

Flow Design Configurations

Flow Design is a special type of configuration that enables building and configuring integration use cases using a graphical design interface. The interface consists of two main entities: nodes and edges, which connect the nodes together.

A node is an instance of a Flow module that appears in the design configuration. There can be multiple instances (nodes) of the same module within a single design.

An edge is a connection between two nodes.

A Flow module is a piece of JavaScript code executed in a sequence defined by the design. Each module consists of metadata and JavaScript code. The metadata defines how the module appears in the design and how it behaves. For example, a module can:

  • Consume one or more inputs from other modules

  • Produce output for other modules

  • Perform callbacks to other modules

  • Allow user-defined settings that can be configured per module instance

Module metadata and JavaScript code are configured at the Flow Module level. All instances of the module share the same metadata definition and JavaScript implementation. For example, any change made to the metadata or JavaScript in the module will affect all module instances across all design configurations where the module is used.

The Module JavaScript is executed similarly to regular TIF Cloud JS configurations, but it also has access to the special FlowAPI JavaScript API. This API can be used to read and write module inputs and outputs, and to perform callbacks to connected modules.

The design view is shown in the figure below.

flow config 2
Figure 5. Flow Design Screen
  1. Buttons for adding modules, saving the configuration, and running the Code Tester.

  2. Controls for zooming in and out, and for running the animation that demonstrates the execution order.

  3. The main screen displaying modules and their connections.

An example flow is shown in the figure below.

flow config 1
Figure 6. Flow Design Configuration
  • The module "Query Data" connects with a remote system and queries data. The queried data works as output from this module.

  • The module "Transfer data" receives input from the "Query Data" module. The input contains the queried data that should be transferred to an ERP system.

  • Before transferring, the module "Transfer Data" must convert and map the input data to a suitable format. To perform this, the code in the module iterates the input data by one level at the time, and on each level it makes a callback to the module "Map Data" that converts the data to correct format. The figure above illustrates the components in the design screen:

    1. A node — an instance of a Flow module.

    2. An edge connecting two modules: the module named "Query Data" produces output that is consumed by the module "Transfer Data to SAP".

    3. An edge connecting two modules: the module "Transfer Data to SAP" performs a callback to the module "Map Data to SAP Format".

    4. Module instance actions allow access to module properties, configuration details, and the option to delete the module instance.

    5. Edge actions allow to access edge properties and provide the option to delete the edge.

Flow Module Meta-Data

The metadata defines how a module appears in the design and how it behaves. Several aspects can be configured:

  • Label and description of the module.

  • Whether the module can produce output or receive input.

  • Whether the module can receive multiple inputs.

  • Whether input is required or optional.

  • Whether output is required or optional.

  • Whether the module can invoke a callback to other modules.

  • Whether the module can receive callbacks, and thus act as a callback module.

  • Setting definitions that the user can fill in. These settings are visible in the Module Properties screen for each module instance.

Module that receives callback, cannot receive input or produce output.

Execution Flow

Flow design configuration is executed sequentially, with the execution order determined by the module connection hierarchy. Modules that do not require any input are executed first, followed by modules that receive input from other modules.

Each module instance produces a single output per execution. While it receives input only once from other modules, it can accept multiple inputs.

A module can also invoke callbacks to other modules. These callbacks may be repeated multiple times during the module’s execution.

An example of flow execution:

  • The module "Query Data" connects to a remote system and retrieves data. The retrieved data serves as the output of this module.

  • The module "Transfer Data" receives input from the "Query Data" module. This input contains the data that should be transferred to another system.

  • Before transferring, the "Transfer Data" module must convert and map the input data into a suitable format. To achieve this, the module’s code iterates through the input data one level at a time. At each level, it makes a callback to the "Map Data" module, which converts the data into the correct format.

Module Javascript

The module JavaScript is executed similarly to regular TIF Cloud JS configurations and has access to the same APIs. Interaction with the flow design execution from within the module is done via the flowAPI. Read more about Flow Javascript API.