Data Model Customizing

Here we describe how to customize the data model of LeanIX

Top level structure

{
  "factSheets": {
    "factSheetType": <FactSheetTypeDefinition>,
    ...
  },
  "relations": <...tbd>,
  "validators": <...tbd>,
  "externalIdFields": <...tbd>,
  "rules": {
    "defaultNamingRule": <NamingRuleDefinition>
  }
}

Fact Sheets

A Fact Sheet type is defined by a FactSheetTypeDefinition.

{
  "config": <FactSheetTypeConfig>,
  "fields": <FieldDefinitions>,
  "namingRule": <NamingRuleDefinition>
}

...TBD

Config

...TBD

Fields

The fields of a Fact Sheet can be defined within the fields section of each FactSheetTypeDefinition.

"fields": {
  "fieldName": {
    "type": "<field_type>",
    "inFacet": true|false,
    "inView": true|false,
    "viewAggregation": "MIN"|"MAX"|"OFF",
    "quickSearch": true|false,
    "fullTextSearch": true|false,
    "validators": null
  }
}

Type: STRING

String fields contain plain text.

"featureDescription": {
  "validators": null,
  "type": "STRING"
}

Type: AGGREGATED

Aggregated fields use one or multiple paths, to collect and aggregate values at related Fact Sheets or relations. How the values are aggregated is defined by an aggregation function.

Supported function are: "SUM", "AVG", "MIN", "MAX", "COUNT"

The path definition starts from the Fact Sheet Type on which the field is defined. The path has to end in a field with type DOUBLE which can either be defined on a relation or another Fact Sheet.

Examples of possible paths:
Path to a field on a relation: /relProviderToProject/annualCost
Path to a field on another Fact Sheet: /relProviderToITComponent/factSheet/costs
Path to a field on a relation two "hops" away: /relProviderToITComponent/factSheet/relITComponentToApplication/costTotalAnnual

"sumCapEx": {
  "paths": [
    {
      "path": "/relProviderToProject/factSheet/budgetCapEx"
    }
  ],
  "function": "SUM",
  "type": "AGGREGATED"
}
IT Component Aggregation Functions

These functions can be used to aggregate the number of connected IT Components to an Application. This includes IT Components, that are related to the application directly, as well as IT Components that are related to the Application via its children or required applications.

Supported Functions: "ITC_CRITICAL_COUNT", "ITC_ABS_COUNT", "ITC_CRITICAL_RATIO"

ITC_CRITICAL_COUNT: Counts all IT Components that are in the lifecycle phase "End of Life" at the current time
ITC_ABS_COUNT: Counts all related IT Components
ITC_CRITICAL_RATIO: Percentage of "critical" IT Components. (= ITC_CRITICAL_COUNT / ITC_ABS_COUNT)

Notice:

  • These functions do not accept a path in the configuration
  • Only use these functions in the fields section of the Fact Sheet definition for the Fact Sheet type Application. Adding it to another Fact Sheet type might result in errors after saving the Data Model.
    -) ITC_CRITICAL_RATIO: Percentage of "critical" needs to be configured as "type:percentage" inside of View Model.
"criticalComponents": {
  "function": "ITC_CRITICAL_COUNT",
  "type": "AGGREGATED"
}

VIEWS: inView and viewAggregation

Defines whether the field is available as view (in reporting) and how the field values should be aggregated into one value in case several values can be applied (e.g. if the field is on a relation or target Fact Sheet).

A field can appear as view in three places:
1) on a Fact Sheet on which the view is applied (FieldView),
2) on the relations of a Fact Sheet on which the view is applied on (RelationFieldView), or
3) on the target Fact Sheets of relations of a Fact Sheet on which the view is applied (TargetFactSheetFieldView).

Depending in which place we are evaluating the field, there might be several values that need to be aggregated into one value, which is then returned for the view. In these cases the viewAggregation comes into play in order to determine how the aggregation should happen. See:

Fact Sheet -------- Relation --------> Target Fact Sheet
(FieldView) -- (RelationFieldView) --> (TargetFactSheetFieldView)
(1 value) ------- (n values) --------> (n values)

Possible values for inView:

  • true: The field will be available as view
  • false: The field will not be available as view in any of the three cases

Possible values for viewAggregation:

  • "OFF": The field is not available as view in cases where it needs to be aggregated. This means it is not available as "RelationFieldView" or "TargetFactSheetFieldView"
  • "MIN": The field is available as "RelationFieldView" and as "TargetFactSheetFieldView". In these cases the minimal value is taken. For a Single Select field this means that the first value in the "values" definition is taken
  • "MAX": The field is available as "RelationFieldView" and as "TargetFactSheetFieldView". In these cases the maximum value is taken. For a Single Select field this means that the last value in the "values" definition is taken

Relations

...TBD

Validators

...TBD

ExternalID fields

...TBD

Naming Rules

Every Fact Sheet has two fields implicitely defined: fullName and displayName.
These fields cannot be updated directly by the user; they are constructed from Fact Sheet data as defined by a naming rule. The constructed value of the displayName field must be unique over all Fact Sheets of a given type.

A naming rule defines how the full and display names of a Fact Sheet are constructed. For example, it can specify that the full name consists of the Fact Sheet's name with the value of the Fact Sheet's release field appended. The display name could for example consist of the Fact Sheet's full name, prepended with the parent Fact Sheet's display name.

When any of a full or display name's components is modified (for example, when the parent Fact Sheet's name is changed), the full and display names of all dependent Fact Sheets are recalculated to reflect that change.

Note that the full and display names are always visible to any workspace user. No Permission must be defined to read these values. So, even if a user is not permitted to see some field, she will see its value if it is used as a full or display name component.

Naming rules may be defined per Fact Sheet type and apply to Fact Sheets of that type. In addition to that, there is one default naming rule that applies to all Fact Sheets whose type has no naming rule defined.

A naming rule has two parts:

  1. a "regular": part that applies normally
  2. an optional "autogenerate": part that applies if the Fact Sheet's name is AUTOGENERATED. (If there is no autogenerate part, the regular part is always used.)

Each of these parts defines how the fullName and the displayName field of a Fact Sheet is constructed.

{
  "regular": {
    "fullName": [<NameComponentDefinition> ...],
    "displayName": [<NameComponentDefinition> ...]
  },
  "autogenerate": {
    "fullName": [<NameComponentDefinition> ...],
    "displayName": [<NameComponentDefinition> ...]
  }
}
{
  "regular": {
    "fullName": [
      {
        "field": "name"
      }
    ],
    "displayName": [
      {
        "field": "fullName"
      },
      {
        "relation": "relToParent",
        "separator": " / ",
        "operation": "PREPEND"
      }
    ]
  },
  "autogenerate": {
    "fullName": [
      {
        "field": "type"
      },
      {
        "field": "id",
        "separator": " ",
        "operation": "APPEND"
      }
    ],
    "displayName": [
      {
        "field": "fullName"
      },
      {
        "relation": "relToParent",
        "separator": " / ",
        "operation": "PREPEND"
      }
    ]
  }
}

Application of a naming rule

A Fact Sheet's fullName field is constructed as follows:

Each NameComponentDefinition in the JSON array provides, in order, one component to the fullName field. That component is either appended or prepended to the name constructed so far, separated with a separator string. The value of the component can be either

  • the value of a STRING type field or an external id field of the Fact Sheet. In this case, the "field" key (see below) must be used.
  • the value of the displayName field of a related Fact Sheet. In this case, the "relation" key (see below) must be used, with a value as given in the from or to parts of a relation definition in the data model. The relation must have a multiplicity of 1.
{
  "field": "<field name>",
  "separator": " ",
  "operation": "APPEND"
}
{
  "relation": "<relation name>",
  "separator": " / ",
  "operation": "PREPEND"
}

The displayName field is constructed in the same way.

The first NameComponentDefinition of a fullName field may not contain separator nor operation and must contain a field name referencing either name, type, or id.

The first NameComponentDefinition of a displayName field may not contain separator nor operation and must contain a field name referencing either name, fullName, type, or id.

Fact Sheet type specific naming rules may reference only field names and relation names that are defined for the Fact Sheet type.

The default naming rules may reference only field names and relation names that are defined for all (each) Fact Sheet types.

How to add a new relation

  1. Define relation in data model
{
  "relations": {
    ... existing relations,
 
   "<New Relation, e.g. userGroupProcessRelation>": {
			"from": {
				"factSheetType": "<Fact Sheet Type, e.g. User Group>",
				"multiplicity": "*",
				"name": "<From Name, e.g. relUserGroupToProcess>"
			},
			"to": {
				"factSheetType": "<Fact Sheet Type, e.g. Process>",
				"multiplicity": "*",
				"name": "<To Name, e.g. relProcessToUserGroup>"
			},
			"fields": {},
			"constrainingRelations": null,
			"constraints": []
		}
 
  }
}
  1. Define translation key

  2. Define relation in view model

Data Model Customizing


Here we describe how to customize the data model of LeanIX

Suggested Edits are limited on API Reference Pages

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