Overview

Signavio is a web-based tool for business process management. Connect it with LeanIX in order to link your application portfolio to business processes. The new integration 2.0 now allows mapping further Fact Sheets to glossary items in Signavio.

This guide is focused on advanced Signavio use cases and technical information. For general Signavio configuration information as well as basic use cases. Please see the Signavio documentation available in the User Documentation.

Endpoints

Signavio provides endpoints to obtain Signavio Processes as well as Glossary Items as structured data.

The LeanIX Signavio Integration currently provides access to three Signavio endpoints. The path within the structured data can be specified in the Information Source field of the configuration with a starting keyword that refers to each endpoint.

  • For Processes: /p/editordata?id=(id) keyword: editordata
  • For Processes: /p/model/(id)/info keyword: model
  • For Glossary Items: /p/glossary/(id)/info keyword: glossary

In the following sections we will describe how to explore the data that can be obtained from those endpoints using the Chrome Browser.

Editordata Endpoint

In this section we are going to explain how to use the Developer Tools of the Chrome Browser to explore the data retrievable from the /p/editordata?id=(id) endpoint.

  • Open up a process in Signavio with the model editor
  • Open the Developer Tools (Customize and Control (three dots) > More Tools > Developer Tools)
  • Select the Network tab in the Developer Tools and reload the model editor page
  • The Developer Tools now show all the calls the browser does when loading the model editor
  • Enter 'editordata' into the filter, to only see the call to the /p/editordata?id=(id) endpoint
  • Select the entry and select to the Preview tab
  • The Preview tab will show the data that is available via the /p/editordata?id=(id) endpoint
  • The complete data that is shown is available to the LeanIX Signavio Integration via the editordata keyword
  • One of the more interesting sections of this map is the model.properties map, which for example contains custom fields

Process Language Example

In the basic configuration examples available in the user documentation, we wanted to write the language of a process into a custom Fact Sheet field. The image below shows the language attribute within the JSON retrieved from the editordata endpoint using the Developer Tools. The path to the language has to start with the editordata keyword, because we obtain the data from this endpoint. Then the path within the data structure has to be added which is model.properties.language. Finally we have the complete path editordata.model.properties.language that can be added into the Information Source field.

Model Endpoint

In this section we are going to explain how to use the the Developer Tools of the Chrome Browser to explore the data retrievable from the /p/model/(id)/info endpoint. The Signavio model editor does not call the endpoint itself, thats why we are going to use the /p/directory/ endpoint to retrieve the same data as given by the /p/mode/(id)/info endpoint.

  • Open up a process in Signavio with the model editor
  • Open the Developer Tools (Customize and Control (three dots) > More Tools > Developer Tools)
  • Select the Network tab in the Developer Tools and reload the model editor page
  • The Developer Tools now show all the calls the browser does when loading the model editor
  • Enter 'p/directory/' into the filter, to only see the call to the /p/directory/ endpoint
  • Select the entry and select to the Preview tab
  • The Preview tab will show the data that is available via the /p/directory/ endpoint
  • The data given from this endpoint is a list of all the processes in the same directory
  • Select the entry where href: "/model/(id)" matches the id of the current process which can be found in the url
  • The subsection rep contains the same data as provided via the /p/model/(id)/info endpoint
  • The data shown below the rep keyword is available to the LeanIX Signavio Integration via the model keyword
  • An example of the data that can be retrieved from this endpoint is the published status which would have the Information Source path model.status.publish

Glossary Endpoint

In this section we are going to explain how to use the the Developer Tools of the Chrome Browser to explore the data retrievable from the /p/glossary/(id)/info endpoint. The /p/glossary/(id)/info endpoint itself is not used by the browser when loading a glossary item but it is still possible to explore the data via the /p/glossary endpoint that is used to get the data.

  • Open up Signavio dictionary
  • Open the Developer Tools (Customize and Control (three dots) > More Tools > Developer Tools)
  • Select the Network tab in the Developer Tools
  • Select a Glossary Item
  • The Developer Tools now show all the calls the browser does when loading the Glossary Item
  • Enter 'glossary' into the filter to get a subset of the calls
  • Select the last call and select the preview tab
  • Select the entry with the key value pair rel: "info"
  • The subsection rep contains the same data as provided via the /p/glossary/(id)/info endpoint
  • The data shown below the rep keyword is available to the LeanIX Signavio Integration via the glossary keyword
  • An example of the data that can be retrieved from this endpoint is the category name which would have the Information Source path glossary.categoryName

Advanced Tab

Signavio Integrations allows additional options to control the synchronization at a higher level of detail. Next to the Basic section in the settings page we also have the Advanced section, which shows the complete configuration as a data structure and allows us to modify it using a provided JSON editor.

The difference in using the Basic section compared to the Advance section is that we can introduce more complex expressions in certain properties. To avoid edition of these complex expressions using the Basic section, they are shown as disabled input fields.

In the following sections we will explore the structure of the configuration data and show how to modify it for more complex synchronization scenarios. These sample configurations cases covers the Basic cases introduced before followed by JSON configurations. Afterwards we will introduce more complex mappings like Tags and Subscriptions.

To get a complete description of the JSON data structure of the configuration, see the section The Configuration Data Shape.

Case 1: A Signavio Field to a Static Value

The synchronization that assigns a fixed value to a Fact Sheet field as shown in the Basic Section (Basic Case 1:

The equivalent configuration in JSON format is shown in the following listing:

"inboundMappings": [
    {
        "leanixType": "factSheetField",
        "fields": [
            {
                "leanixFieldName": "comment",
                "inboundPropertyPath": "Synchronized by LeanIX Signavio Integration",
                "valueMappings": []
            }
        ]
    }
]

Case 2: Signavio Attributes to Fields

The configuration that synchronizes a Signavio attribute into a Fact Sheet Field is shown (Basic Case 2):

The corresponding JSON structure is:

"inboundMappings": [
    {
        "leanixType": "factSheetField",
        "fields": [
            {
                "leanixFieldName": "language",
                "inboundPropertyPath": "${editordata.model.properties.language}",
                "valueMappings": []
            }
        ]
    }
]

New Fact Sheets created will have the field language with the same value taken from the Signavio endopoint editordata, the value for the path given in inboundPropertyPath is explained in Endpoints. The expression ${...} is part of EL (Expression Language) used by Leanix Signavio Integration to offer a flexible way to work with data from Signavio Endpoints.

Case 3: Signavio attributes with Value Mappings

In this case the Signavio attribute language in mapped into a custom Fact Sheet field language. Additionally, the value is mapped from their common name into the international two-letter code (Basic Case 3):

The JSON data structure shows the list of value mappings as maps inside the valueMappings keyword.

"inboundMappings": [
    {
        "leanixType": "factSheetField",
        "fields": [
            {
                "leanixFieldName": "language",
                "inboundPropertyPath": "${editordata.model.properties.language}",
                "valueMappings": [
                    {
                        "outputExpression": "EN",
                        "regexMatch": "English"
                    },
                    {
                        "outputExpression": "DE",
                        "regexMatch": "German"
                    }
                ]
            }
        ]
    }
]

The regexMatch keyword allows to define a Regular Expression. In this example it is a fixed string and the value retrieved from the inboundPropertyPath editordata.model.prperties.language will be compared to this string. The first matching mapping will be used and the outputexpression will be written into the leanix field specified in leanixFieldName.

It is easily possible to define a default avlue that is used if none of the defined (regEx) options match.
This functionality is only available in the JSON (advanced) configuration. In the below example all other languages or empty input will result in "Other"

"inboundMappings": [
    {
        "leanixType": "factSheetField",
        "fields": [
            {
                "leanixFieldName": "language",
                "inboundPropertyPath": "${editordata.model.properties.language}",
                "valueMappings": [
                    {
                        "outputExpression": "EN",
                        "regexMatch": "English"
                    },
                    {
                        "outputExpression": "DE",
                        "regexMatch": "German"
                    }
                ],
                "defaultValue": "Other"
            }
        ]
    }
]

Case 4: Multiple Signavio Attributes Combined

In this case we will combine two Signavio attributes into Fact Sheet field. In our example we are going to write into a custom Fact Sheet field called publish. We need to identify the path to the attributes we want to combine, in our case: model.status.publish and model.type. Some values we could find in Signavio for model.type attribute are: Organization Chart, Event-driven process chain (EPC), or Business Process Diagram (BPMN 2.0), and for model.status.publish are true, false. As a result we expect to have a value like true - Business Process Diagram (BPMN 2.0).

"inboundMappings": [
    {
        "leanixType": "factSheetField",
        "fields": [
            {
                "leanixFieldName": "publish",
                "inboundPropertyPath": "${model.status.publish} - ${model.type}",
                "valueMappings": []
            }
        ]
    }
]

The keyword inboundPropertyPath defines the path to obtain the data from Signavio endpoints, however it is not restricted to only express data paths, it is also possible to use all functionality provided by EL (Expression Language: https://jcp.org/en/jsr/detail?id=245.) expressions. As in our example, we can concatenate two Signavio attributes separated by dash - character.

After the synchronization, the publish Fact Sheet field will have the value reslfrom the concatenation of model.status.publish attribute, then a dash character(-) followed by the value of model.type. The next image shows the History view where we can find the value for field publish set to false - Organization Chart.

Case 5: Use Complex Expressions in Value Mappings

Inside valueMappings keyword, each element of the list allows the mapping of the value to a final result given by the keyword outputExpression. In previous examples, we set fixed text values in this keyword, however it is possible to use more complex EL expressions that combine other objects of data.

In the following JSON config, we are combining part (the first 5 characters) of the Signavio name concatenated with the attribute language to obtain the final value for the field processnumber.

"inboundMappings": [
    {
        "leanixType": "factSheetField",
        "fields": [
            {
                "leanixFieldName": "processnumber",
                "inboundPropertyPath": "${model.name}",
                "valueMappings": [
                    {
                        "outputExpression": "${input.substring(0,5)} - ${editordata.model.properties.language}",
                        "regexMatch": "^[0-9].*"
                    }
                ]
            }
        ]
    }
]

In outputExpression, the symbol input represents the result obtained after the expression in inboundPropertyPath (the model name: ${model.name}) is resolved. In general, the input keyword is only available in outputExpression and offers a flexible way to modify the inboundPropertyPath value. We are also verifying that only models that have a name that starts with a number are used to obtain the processnumber field, this is guaranteed by the regexMatch "^[0-9].*" .

After the synchronization, a Signavio Diagram named 1.1.3 Summary of objections is synchronized to a Fact Sheet with the value 1.1.3 - English in the field processnumber.

Unknown property handling

It might be that some advanced expressions may contain references to properties on Signavio Processes that exist for some processes but do not exist on others. To avoid error messages, a flag "ignoreUnknownProperty" can be set to true. By using this, the admin can keep the logs clean in cases where such warnings are expected and can be ignored.

"inboundMappings": [
    {
        "leanixType": "factSheetField",
        "fields": [
            {
                "leanixFieldName": "processnumber",
                "inboundPropertyPath": "${model.name}",
                "valueMappings": [
                    {
                        "outputExpression": "${input.substring(0,5)} - ${editordata.model.properties.language}",
                        "regexMatch": "^[0-9].*"
                    }
                ],
                "ignoreUnknownProperty": true
            }
        ]
    }
]

Case 6: Tagging Fact Sheets using Signavio Attributes

In this sample case, we want to map the value of publish attribute in Signavio to be applied as a tag in LeanIX. To synchronize Signavio attributes into Fact Sheet tags, we have to define the fields that compose a Tag: name and group, also set the leanixType to tag. The following JSON configuration data shows an example of synchronization to tags.

"inboundMappings": [
    {
        "leanixType": "tag",
        "fields": [
            {
                "leanixFieldName": "group",
                "inboundPropertyPath": "PublishStatus",
                "valueMappings": []
            },
            {
                "leanixFieldName": "name",
                "inboundPropertyPath": "${model.status.publish}",
                "valueMappings": [
                    {
                        "outputExpression": "published",
                        "regexMatch": "true"
                    },
                    {
                        "outputExpression": "non-published",
                        "regexMatch": "false"
                    }
                ],
              "defaultValue": "",
							"ignoreUnknownProperty": true
            }
        ]
    }
]

New Fact Sheets will be tagged as published or non-published depending of the value from Signavio publish attribute. The tag group for all Fact Sheets will be PublishStatus. It is necessary that the Tag Group and Tags are created by the Administrator before the synchronization, the bellow image shows the tag groups for this example:

Both fields group and name are resolved using the same mechanism explained in previous sections, which consists in taking the value from inboundPropertyPath and use it together with valueMappings list to calculate the final result. In our example the group is resolved as a static text: PublishStatus, and the name of the tag is based on the value mapping of the model.status.publish value.

After the synchronization, the Fact Sheet created has the tag non-published because the Signavio attribute model.publish was false.

Tagging Mode Multiple/Single

In order to remove the existing tags when a new tag is supposed to be applied recommendation is to use mode "Single"

Case 7: Signavio Collaboration Hub

To be able to go to the Signavio Collaboration Hub directly from the LeanIX interface we need to add a new custom field to the specified process fact sheet and configure a inboundmapping. The custom field has to be called collaborationHubUrl. And the inboundmapping configuration is shown below:

"inboundMappings": [
    {
        "leanixType": "factSheetField",
        "fields": [
            {
                "leanixFieldName": "collaborationHubUrl",
                "inboundPropertyPath": "${model.status.publish}",
                "valueMappings": [
                    {
                        "outputExpression": "https://editor.signavio.com/p/hub-preview#model/${editordata.modelId}",
                        "regexMatch": "true"
                    },
                    {
                        "outputExpression": "",
                        "regexMatch": "false"
                    }
                ]
            }
        ]
    }
]

In our example the link to the Signavio Collaboration Hub is only shown when the model is published. The two possible values for model.status.publish are true or false, using the valueMappings we are filtering the cases for true to have the URL that points to Signavio Collaboration Hub. To build a URL for each model we need to add the id from editordata.modelId. The domain as well as the path in the URL might be different for your Signavio setup.

After the synchronization, all published models will be shown with a Collaboration Hub link in the LeanIX interface:

Case 8: Mapping Signavio Attributes to Subscriptions

In this sample case, we will show how to synchronize Signavio Attributes to add Subscriptions in LeanIX Fact Sheets. Business Owner defined in Signavio models will have a subscription to the corresponding Fact Sheet as role Process Owner with the type Responsible.

We set leanixType keyword as subscription, and add the field definitions for a Fact Sheet Subscription: email , type, role, and optionally comment, as shown in the JSON configuration:

"inboundMappings": [
    {
        "leanixType": "subscription",
        "fields": [
            {
                "leanixFieldName": "email",
                "inboundPropertyPath": "${glossaryItem.get(editordata.model.properties['meta-processowner']).metaDataValues['meta-zustndigeemailadresse']}",
                "valueMappings": []
            },
            {
                "leanixFieldName": "type",
                "inboundPropertyPath": "RESPONSIBLE",
                "valueMappings": []
            },
            {
                "leanixFieldName": "comment",
                "inboundPropertyPath": "Subscription role added by Signavio integration",
                "valueMappings": []
            },
            {
                "leanixFieldName": "role",
                "inboundPropertyPath": "Process Owner",
                "valueMappings": []
            }
        ]
    }
]
  • leanixFieldName = email Field: Defines the data path to obtain the email address from Signavio. This is a two steps process: first, obtain the data for the Signavio Item that represents a Role for business Owner; and second, obtain the Glossary Item data associated with the previous reference. In the inboundPropertyPath expression , the data path editordata.model.properties['meta-processowner'] resolves to a value similar to "/glossary/<id>", which is then used by the symbol glossaryItem.get(...) to obtain a complete Glossary Item data object; then, the email is taken from the Glossary Item using the path .metaDataValues['meta-zustndigeemailadresse'].
  • leanixFieldName = type Field: Defines the value for the type of subscription.
  • leanixFieldName = role Field: Defines the value for the role of the subscription, in our example Process Owner.
  • leanixFieldName = comment Field: Defines the comment applied to the subscription.

It is necessary the LeanIX administrador creates the Subscription Roles before the synchronization is executed, for this example the role to create is: Process Owner. Also, for every email that is obtained during the synchronization, it is expected that a LeanIX user email already exists, otherwise the subscription will be ignored for that non-existing email address and a warning will be logged to Sync Logging.

Case 9: Mapping Signavio Glossary Items to Fact Sheets

In this case, we will create Fact Sheets based on Signavio Glossary Items making use of advanced inbound mapping capabilities. The Glossary Item in Signavio Dictionary is shown bellow.

In the bellow data configuration we can see the glossaryCategorySyncDescriptors property of the global configuration that contains one element defining the options for the synchronization. We suppressed some parts of the config for clarity and shows only the inboundMappings section.

{
	...
 "glossaryCategorySyncDescriptors": [
        {
            "inboundMappings": [
                {
                    "leanixType": "factSheetField",
                    "fields": [
                        {
                            "leanixFieldName": "meta_cause",
                            "inboundPropertyPath": "${glossary.metaDataValues['meta-cause']}",
                            "valueMappings": [
                                {
                                    "outputExpression": "${input.replaceAll('^[0-9.]+ (.*)','$1')}",
                                    "regexMatch": "^[0-9.]+ .*"
                                }
                            ]
                        },
                        {
                            "leanixFieldName": "meta_consequence",
                            "inboundPropertyPath": "${glossary.metaDataValues['meta-consequence']}",
                            "valueMappings": [
                                {
                                    "outputExpression": "${input.toUpperCase()}",
                                    "regexMatch": "^possible.*"
                                }
                            ]
                        }
                    ]
                }
            ],
			      ...
        }
	...
}

In the previous data configuration, there are two elements that define mapping options for two Fact Sheets fields:

  • In leanixFieldName = meta_cause Field: It takes the value from Signavio attribute meta-cause obtained using the mechanism explained in Signavio Endpoints section. Using valueMappings we are only considering those values that have numbers in its content. The last expression inside outputExpression defines how to modify the data before applying to the Fact Sheet, for our example we are removing the numeric part from 0.1.2 Admission of candidates.

  • In leanixFieldName = meta_consequence Field: It takes the value from Signavio attribute meta-consequence. In valueMappings we are only considering those values that starts with the word possible. The last expression inside outputExpression defines how to modify the data, which for our example is converting the value to uppercase.

The new Fact Sheet created using the previous configuration is shown bellow. The values for the fields meta_cause and meta_consequence are Admission of candidates and POSSIBLE OUTRAGE respectively.

Case 10: Ignoring linked Process Model relations based on Custom Attributes for Top-Down and Bottom-Up

Signavio offers linkage of diagrams (eg: process models) against each other based on a special custom attributes type Diagram Link. Some customers uses this way of linkage to express a special relationship between objects. Such a custom attribute can be defined in Setup / Define notation/attributes, like:

Configuration of a customer attribute used to link another diagram.

Configuration of a customer attribute used to link another diagram.

In case a Process Model should be linked via a custom attribute, the linkage must be done inside the Custom Attributes area at the right side of the screen. For instance this looks like:

Setting a link to another process model using a custom attribute.

Setting a link to another process model using a custom attribute.

To exclude relations based on custom attributes for the top-down or bottom-up synchronizations, the field excludeCustomRelations must be set to true.

...
"processSyncDescriptors": [
		{
			"inboundMappings": [],
			"active": true,
			"directoryIds": [
				"10d342f5db704199968d86688c528073"
			],
			"linkProcessingMode": "PARENT_CHILD",
			"publishedOnly": false,
			"startNodeId": null,
			"filterExpression": null,
			"leanixParentFactSheetId": null,
			"blacklist": [],
			"shortDescription": "",
			"excludeCustomRelations": true
		}
  ...

Case 11: maximumDeletionRatio used to protect of unwanted data loss

The configuration field maximumDeletionRatio specifies a ratio that is always checked before the synchronization decides whether or not to delete data in strict mode in LeanIX or Signavio. This feature is a kind of safety net used to protect your data when setting up or changing the synchronization configuration and this is not perfect and contains mistakes.

Before a deletion the synchronization computes for each process sync descriptor and glossary sync descriptor the ratio:
computed ratio = 100 * <Number of items that should be deleted> / <Number of items processed (read)>

A deletion of items is only allowed in case of :
a) <Number of items processed> < 10 OR
b) <computed ratio> < maximumDeletionRatio

{
	"active": true,
	"maximumDeletionRatio": 50,
	"timerBasedSync": true,
...

Case 12: forceWrite used to create glossary items with conflicting name

For glossary item synchronizations that goes from LeanIX to Signavio, the configuration field forceWrite can be used create or update glossary items which already exists on Signavio side in different glossary categories. The normal behavior in Signavio prohibits to create duplicate glossary items even if they are located in different glossary categories.

{
	"glossaryCategorySyncDescriptors": [
		{
			"active": true,
      ...
			"forceWrite": true
		}
	],
  ...
}

forceWrite should be only used after careful analysis of the Signavio workspace

forceWrite should be only used after careful analysis of the Signavio workspace as this will create duplicates in Signavio GlossaryCategory.

Configuration Complete JSON Example

A complete sample configuration structure is shown below. It is a JSON map where top level keywords represents global options that are applied to every synchronization. The sample list has been obfuscated to hide sensitive information, it is intended to be used only as a reference , not to be copied into your configuration.

{
	"active": true,
	"timerBasedSync": false,
	"strict": false,
	"processFactSheetType": "Process",
	"leanixConfig": {
		"workspaceId": "XXXXXX-5391-40c7-a47e-YYYYYY",
		"targetSystem": "https://url.for.server",
		"userId": "xxxxxxx-336a-4092-ae60-yyyy"
	},
	"signavioConfig": {
		"url": "https://editor.signavio.com",
		"username": "[email protected]",
		"password": "xxxxxxxxxx-xxxxxxxxxx",
		"tenantId": "f6a3ca755bec1e13xxfeb",
		"loginParams": ""
	},
	"glossaryCategorySyncDescriptors": [
		{
			"active": true,
			"factSheetType": "Application",
			"masterSite": "LEANIX",
			"strict": false,
			"relationName": "relProcessToApplication",
			"inboundMappings": [],
			"filter": null,
			"glossaryCategoryId": "d693d09****f87e290"
		}
	],
	"processSyncDescriptors": [
		{
			"inboundMappings": [],
			"active": false,
			"directoryIds": [
				"1111111111111111"
			],
			"linkProcessingMode": "NO_PROCESSING",
			"publishedOnly": false,
			"startNodeId": null,
			"leanixParentFactSheetId": null,
			"blacklist": [],
			"shortDescription": ""
		}
	]
}

The corresponding Basic section for the previous Advanced data configuration is shown in the following image.

We can identify some elements between both sections, like the strict property, set to False as it is unchecked in the Basic section, similarly, the property processFactSheetType represents the Fact Sheet Type field set as Process, and the rows we have in sections Signavio Processes and Glossary Category Mappings are kept in processSyncDescriptors and glossaryCategorySyncDescriptors properties in the structure.

Because almost all elements in the configuration are easily managed by using the Basic section, we will explain in detail the inboundMappings property where we will find elements that can be extended only using the Advanced section.

Advanced Applying Filter to the Processes coming from Signavio

When you want to only pull specific processes from Signavio, you can filter in the advanced Section by using "filterExpression" attribute with JUEL expression.

"filterExpression": "${model.description.equals('SOME_VALUE')}"

Links to glossary items used in filtered processes

The Integration will collect all linked glossary items that are used by filtered processes (like Applications) and link them to the last unfiltered process in the hierarchy. This allows to filter low level processes while still keeping all linked Glossary items and properly create relations from it.

Advanced Inbound Mappings (Processes and Glossary Items)

The inboundMappings can be used in both Processes and Glossary Items configurations, it consists of a list of JSON maps as shown.

{
    ...
    "inboundMappings": [
        {
            "leanixType": "",
            "fields": [
                {
                    "leanixFieldName": "",
                    "inboundPropertyPath": "",
                    "valueMappings": [
                        {
                            "outputExpression": "",
                            "regexMatch": ""
                        }
                    ]
                }
            ]
        },
        ...
    ],
    ...
}

Each element inside this list of Inbound Mappings have the following keywords:

  • leanixType: Specify into which Leanix data type the data is written. Allowed values are:
Type of Descriptor Allowed Values
Processes (processSyncDescriptors) factSheetField, tag, subscription
Glossary Items ( glossaryCategorySyncDescriptors) factSheetField
  • fields: A list that describes the incoming data path, how it is transformed and where it is written to.

Each member in fields list has the following properties:

  • leanixFieldName: the Fact Sheet field where data is written into. Depending of the leanixType value, it should contain optional or required Fact Sheets fields. The table bellow shows the expected definitions for each possible value of leanixType:

For Processes:

leanixType Allowed values Description
factSheetField Data model field name The name of a field defined for the fact sheet type in your LeanIX Data Model. Supported data types: SINGLE_SELECT, STRING, DOUBLE, INTEGER.
tag required: name. Optional: group The tag must exist before the synchronization. If group is not specified, Others is used.
subscription required: email, type, role. Optional: comment The role must exist before the synchronization.

For Glossary Items:

leanixType Allowed values Description
factSheetField Data model field name The name of a field defined for the fact sheet type in your LeanIX Data Model. Supported data types: SINGLE_SELECT, STRING, DOUBLE, INTEGER.
  • inboundPropertyPath: Specify path/expression for Signavio endpoints (See section Signavio Endpoints). The symbols that are available are the same as shown in the table below:
    for outputExpression except for ${input}.
  • valueMappings: Optional, it allows to specify mappings of the values that have been obtained based on inboundPropertyPath value.

Each member inside valueMappings have the following properties:

  • regexMatch: A regular expression to which the value of the inboundPropertyPath has to match, the simplest case is an static text, but any Java Regular Expression could be used here. The elements in the list of value Mappings are evaluated until the first matched is found.

  • outputExpression: An expression that resolves the final value for the Fact Sheet field. We can use fixed values, like a text, or the combination of multiple fields. The table bellow shows the symbols that are available inside the expressions.

For processes:

Symbol Meaning Example
input The value resolved by inboundPropertyPath expression ${input}
model The data taken from model endpoint ${model.status.publish}
editordata The data taken from editordata endpoint ${editordata.model.properties.language}
glossaryItem A utility object for Glossary Items referenced in Signavio Attributes ${glossaryItem.get('12423')}

For Glossary Items:

Symbol Meaning Example
input The value resolved by inboundPropertyPath expression ${input}
glossary The data coming taken from glossary endpoint ${glossary.metaDataValues['meta-cause']}

The example expressions in the previous table follow the syntax defined by Expression Language (or just EL). EL expressions allows advanced operations like splitting, concatenating or selection of substrings for any of the symbols available. A description for EL can be found in https://jcp.org/en/jsr/detail?id=245.

Updated 2 months ago


Signavio


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.