Archi Forum

Hi Herve,

I've not had much time to spend on the configuration but am now resuming work on it.  I've managed to configure the ini file to pull in many of the CI records from the CMDB tables, but with regards to relationships I noticed that they are mapped using the unique system_id in the ini file.  This appears to be unique and different from what is in your ini file.  I'm not a ServiceNow expert but was hoping that the config could have been mapped using their names in the same way as the tables are referenced - is using system_id the only way?

I may be answering my own question here - is it this way because the relationships are held in a single relationships table and their names can be completely customised, hence the mapping in the ini file must only rely on the system_id based on the names for the relationships given, i.e. there are no standardised out-of-the-box relationship names that will have the same system_id across SN environments as per CMDB.

Thanks,
Manjit

Hi Manjit,

Having such table with relationships name would make my life much easier too ... But unfortunately, I haven't found any. That's the reason why one must find the ServiceNow internal ID of the relationships and map this ID to an Archi relationship class.

Best regards
Hervé

Hi Herve,

I've been studying ServiceNow a little more and in our organisation there are 836346 relationship records in the cmdb_rel_ci table, and therefore cannot see how your configuration file relates to this, although have an idea and needs confirming by you.  What I have determined from our SN instance that there is a cmdb_rel_type table, which holds the relationship type declaration records, off which we have 46.  The relationship instantiations of these types are those in the cmdb_rel_ci, i.e. the 836346 records are of the 46 relationship types.

Now, what I understand from the snow_plugin.ini file relationships section is that each stated relationship mapping system_id is of the type, and where this is used for multiple instantiations these are pulled in with their system_id mapped to to the archi.relations.*.id.

To give and example of what my understanding is, form the ini file:

archi.relations.*.id                                         = sys_id    <<<<< This is the relationship instance of parent to child from cmdb_rel_ci table
archi.relations.*.name                                    = type#name
archi.relations.*.source                                   = child
archi.relations.*.target                                    = parent
archi.relations.*.folder                                     = ${class}
archi.relations.*.property.strength                    = connection_strength
archi.relations.*.property.source_action            = type#child_descriptor
archi.relations.*.property.target_action             = type#parent_description

# "Runs"
archi.relations.0454da4c6f7e9940f0721cef8d3ee4b9.archi_class = "CompositionRelationship"  <<<<< This is the system_id of the type for Runs (or more accurately 'Runs on::Runs' displayname) from the cmdb_rel_type table that drives the search and retrieval for all Runs instances from the cmdb_rel_ci table.

Is this an accurate description, and if so it would've been better to use the display name to query the system_id, but whitespace would need to be handled.

If this is not correct then I would be grateful if you can provide a detailed description of how it works and what tables in SN are being used.

Thanks,

Manjit

Hi Manjit,

My plugin is basically a ServiceNow web service generator. So if the comments I've put in the configuration file is quite unclear, you may have a look to the log file generated during the import process.

The mapping between ServiceNow CIs and Archi elements is quite straight forward as ServiceNow CIs are store in separate tables and the work consist to map ServiceNow tables to Archi classes, and for each element, map the ServiceNow fields to Archi properties.

The mapping between ServiceNow relationships and Archi relationships is much more complicated as the relationships are all stored in a single table called "cmdb_rel_ci" but are assigned to relationshp types using the type field. with numerical type ID that reference an entry in the "cmdb_rel_ci" table.

So in order to map a ServiceNow relationship to an Archi relationship, one must first manually parse the "cmdb_rel_type" table to retrieve the numerical type ID he wants to map. I cannot rely on the labels as they can be changed at any time (like translated) by the admin of your company.

That was for the ServiceNow webservice.



Then, there are two levels of mapping.

1 - The first one which is a general mapping, that will be applied by default on every line of every table. This general mapping is referenced by a wildcard.
          For instance :  archi.relations.*.id = sys_id
          will map the Archi relationship's ID to sys_id field of the ServiceNow relationship record.

2 - The second one is a specific mapping, which overrides the general mapping when it exists. This specific mapping is referenced by using the ServiceNow numerical type ID.
          For instance : archi.relations.2da380cc6f3ab944a77a2dc71e3ee49d.archi_class = "FlowRelationship"
          will specifically map the Archi relationship class to "FlowRelationship" when the ServiceNow relationship type is 2da380cc6f3ab944a77a2dc71e3ee49d.




Hope this helps. Please do not hesitate should you require more information.

Best regards
Hervé

Excellent - this is in line with what I had interpreted and your explanation further expands on how it works - thanks.