Extending An Integration

Guide to extend integration to customize it to your organizational needs

Any out-of-box LeanIX integration provides users to implement custom Integration API processors to process the original LDIF generated by integration. This is powered by the Integration API capability called execution groups

The documentation discusses the following

  1. What are the possible use cases?
  2. How to enhance existing Integration Hub data source with execution group?
  3. How to examine generated LDIF by integration?
  4. How to implement custom Integration API processors to add additional logic to the default integrations to cater to your organizational specifics?


  1. (Discussed in example section) Extend CICD Integration to automatically populate MuleSoft Integration API ID.

Modify Integration Hub data source

Integration Hub data sources by default do not have the ability to execute custom processors. Make the following changes to add this ability.

Switch to the Advanced view in the Integration Hub tab. myGroup should be replaced by the unique execution group ID specific to each integration. This can be fetched from the integration guide.

  "name": "{example-integration-name}",
  "connectorConfiguration": {
  "secretsConfiguration": {
-  "bindingKey": {
-    "connectorType": "leanix-vsm-connector",
-    "connectorId": "{integration-connector-id}",
-    "connectorVersion": "1.0.0",
-    "processingDirection": "inbound",
-    "processingMode": "full",
-    "lxVersion": "1.0.0"
-  },
+  "executionGroup": "myGroup"

Examination of generated LDIF for extension

All integrations are powered by Integration API to inject the source data into the workspace. Integration API depends on source data in LDIF format. All integrations generate an LDIF and the LDIF can be referred to using the Test Run feature in Integration Hub UI.


External execution integrations

External execution integrations like SonarQube integration are triggered as a self-start execution from the deployment location. Hence, Test Run is not available for such integrations. In these cases, the LDIF can be acquired from the logs or sync logs from previous Integration Hub executions.

Example `Test Run` output from MuleSoft integrationExample `Test Run` output from MuleSoft integration

Example Test Run output from MuleSoft integration

The data in the LDIF can be used to update aggregated fields, add subscriptions based on a specific value etc. One such real-life example is discussed in following "Example" section.

Create Integration API connector

A new Integration API connector should be created from the Integration API tab under admin UI. Make sure that Processing Direction is inbound and Processing Mode is full.

Example new Integration API connector creationExample new Integration API connector creation

Example new Integration API connector creation

Implementing Custom Integration API processors

Refer to inbound Integration API processors to implement processors that uses the above generated LDIF. The execution group ID should match with the Integration Hub data source execution group ID.

    "processors": [
            "processorType": "inboundFactSheet",
            "processorName": "example processor name",
            "processorDescription": "example description",
            "enabled": true
    "variables": {},
+    "executionGroups": [
+        "myGroup"
+    ]


Use case

The out-of-the-box MuleSoft integration requires MuleSoft API ID to be filled in manually to link an API factsheet to Software Artifact factsheet. Refer to MuleSoft integration guide for more details on this topic. Extending CICD manifest with MuleSoft ID allows to automate this process.

1. Update CICD manifest

id: cicd-connector-v2
name: cicd-connector-v2
description: CI/CD
self: https://github.com/leanix/self-url
owner: [email protected]
  - name: vcs
    url: https://github.com/leanix/project-url
+ additional:
+  mulesoftId: fulfillment-test-api-1.0.0

2. Examine the LDIF from CICD integration

LDIF structure can be fetched from one of the previous sync logs. Following is the LDIF structure of content.type = service

  "content": [
      "type": "service",
      "id": "cicd-connector-v2",
      "data": {
        "name": "cicd-connector-v2",
        "description": "CI/CD revamped",
        "owner": "[email protected]",
        "self": "https://github.com/leanix/self-url",
        "links": [
            "name": "vcs",
            "url": "https://github.com/leanix/project-url"
+        "custom": {
+         "mulesoftId": "fulfillment-test-api-1.0.0"
+        }

3. Create custom Integration API processors for CICD integration

  "processors": [
      "processorType": "inboundFactSheet",
      "processorName": "Add Mulesoft ID from custom data",
      "processorDescription": "Add Mulesoft ID from custom data",
      "type": "Microservice",
      "run": 10,
      "identifier": {
        "external": {
          "id": {
            "expr": "${content.id}"
          "type": {
            "expr": "cicdId"
      "filter": {
        "exactType": "service",
        "advanced": "${data.custom.mulesoftId != null}"
      "updates": [
          "key": {
            "expr": "mulesoftApiId.externalId"
          "values": [
              "expr": "${data.custom.mulesoftId}"
  "variables": {},
  "executionGroups": ["vsmCiCd"]


Meta model

Refer to "Self-Configuration" tab for the respective factsheet to investigate the field keys

4. Trigger CICD integration

After the successful execution notice that Mulesoft API ID is now populated with fulfillment-test-api-1.0.0

5. Start MuleSoft Integration Hub data source

Automatically relation is established after running MuleSoft integrationAutomatically relation is established after running MuleSoft integration

Automatically relation is established after running MuleSoft integration

Did this page help you?