cmdb.external#
The integration of external data sources into the Configuration Management Database (CMDB) can be simplified by various measures. First of all, it is important that the data is available in a standardized, easy-to-process format to make it easier to read and transfer to the CMDB. In addition, functions should be implemented that enable a complete, one-time data transfer as well as regular, automated synchronizations. It is crucial that each data element in the CMDB is linked to its origin in order to ensure the identifiability of the data sources. At the same time, clear rules and guidelines must be defined in order to delimit the scope of the data from the individual sources. The simultaneous integration of multiple data sources should also be supported, whereby conflicts and inconsistencies must be recognized and resolved. Finally, single-request operations should be implemented to allow users to perform data imports, synchronizations and queries through a single interface to increase usability and efficiency.
cmdb.external#
What are external identifiers?#
- User-defined string-based stable and unique IDs
- Composed of a "type" and a "id"
For example my_vendor_id / my_object_id
.
Why do we need external identifiers?#
- Clear identification of object and category data records
- Scoping: Completed data areas
- Caller does not need to know internal record IDs
How do external identifiers work?#
- Hierarchical approach
- User defines an external identifier for the object
- extType: Identifier for the data source/vendor
- extId: Identifier for the object
- User also defines an identifier (without extType) for each category entry
- API creates a mapping between identifiers and internal IDs
Examples of this would be:
- External identifier for an object
data-source-1 / windows-server100
- External identifier for each category entry
data-source-1 / windows-server100 / C__CATG__CPU / intel-1
The object is located on the first level. Here we define the extType on the one hand and the extId on the other. Both together form the complete identifier and uniquely identify the created object. On the next level, however, we have our category level. Each category starts with the corresponding constant and receives a unique ID on the level below.
From this structure, i-doit then automatically determines the final identifier, illustrated here using the example of intel-1 and intel-2. Here is an example of a push request to create an object via the new endpoint.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 |
|
and records the whole thing in an internal mapping table.
Scoping#
Scoping should ensure that two data sources do not get in each other's way, as we assume the following:
If different data sources feed their data into i-doit at the same time, we assume that each data source is leading in its own right and can be regarded as a single source of truth. Conversely, this means that an object can never appear in several data sources at the same time.
Based on this assumption, i-doit therefore implements the following safety net:
- Objects are clearly assigned to data sources
- An object can only be assigned to one data source
- A data source object cannot be managed by multiple data sources
- A further refinement: Existing objects cannot be manually assigned to a data source
- An object can only be assigned to one data source
We have similar handling at category level:
- Clear assignment of category entries to data sources
- A special feature of MV: MV entries can be edited manually even if they come from a data source
- The other way round, however, i.e. manually created multi-value category entries remain protected from access by the data source
- But there is also an exception here, namely for single-value categories: Manually created single-value category entries can be manipulated by data sources
- There is also an unauthorized and unmappable case: The data source "data-source-2" cannot have a CPU entry in an object that is managed by "data-source-1"
cmdb.external.push.v2#
Creation and updating of objects and category entries by a single request. In addition, various "strategies " allow us to map different use cases, although it should be mentioned that these are only located on the category layer.
The Push API also has procedures for converting human-readable values into their technical representation, for example dialog+, object references or category references. And very importantly:
By using the Push API, you do not have to do without general CMDB structures, such as the rights system, validation rule or logbook. Everything works as before!
Strategy | Entry exists single-value | Entry exists multi-value | Entry does not exist single-value | Entry does not exist multi-value |
---|---|---|---|---|
create | will be skipped | will be skipped | is created | is created |
update | will be updated | will be updated | is created | is created |
overwrite | will be updated | will be updated | is created | is created |
overwrite deletes all multi-value entries from i-doit that are not included in the request. Existing ones are updated or created
Request parameters#
Key | JSON data type | Required | Description |
---|---|---|---|
extType | String | Yes | Data source, for example: data-source-1 |
extId | String | Yes | Object, for example: windows-server100 |
class | String | Yes | Object type, for example: C__OBJTYPE__SERVER |
title | String | Yes | Object designation, for example: Server 100 |
Example#
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 |
|
cmdb.external.pull.v2#
Reading CMDB data based on the "External Identifier". When pulling, the external identifier determines the queried data, for example:
extType | extId | Aktion |
---|---|---|
data-source-1 | null | Reads all objects and any category data |
data-source-1 | windows-server100 | Reads windows100 and any category data |
data-source-1 / windows-server100 / C__CATG__CPU | null | Reads windows100 and all CPU entries |
data-source-1 / windows-server100 / C__CATG__CPU | intel-1 | Reads windows100 and only the CPU entry intel-1 |
Request parameters#
Key | JSON data type | Required | Description |
---|---|---|---|
extType | String | Yes | Data source, for example: data-source-1 |
extId | String | Yes | Object, for example: windows-server100 |
Example#
1 2 3 4 5 6 7 8 9 10 |
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 |
|