Best practices for customizing the Service Graph Connectors?

[Amar_Be]

Hi everyone,

I'm currently working with the Service Graph Connector for Microsoft Azure, version 1.11. I need to map some additional fields from the data source to the CMDB classes.

I've found many topics explaining how to customize the ETL mappings of the Service Graph connectors, but they all suggest editing the out-of-the-box (OOTB) mappings directly. The issue with this approach is that any customization will be lost during the next update of the connector.

To avoid this, I thought of duplicating the data source and using it in a new custom mapping where I map the additional attributes and relationships.

This new mapping is then executed by a scheduled job after the original import job.

Is there a better way to customize the Service Graph connectors and preserve these modifications in case of an update?

The solution I've found works well for full imports.

However, for delta imports, I'm concerned that the first retrieval from the data source will set the last runtime date, and the second call won't retrieve anything since no changes will be detected.

I noticed that the method that gets and updates the last runtime date receives the data source ID as a parameter.

Does this mean that each data source has its own last runtime date, and therefore, a delta request from different data sources will retrieve the same items?

Thanks in advance for your help

[Kenneth Hosey1]

Kilo, 

We've asked for guidance on this from ServiceNow as well. My immediate need is to include additional custom fields from our Tanium instance into OoB fields in ServiceNow. I've opted (in the meantime) to modify the RTE since I'm just adding additional entities and mappings, not touching the pre-existing ones. This should allow us to upgrade the SGC without having collisions. Additionally, if there is a field that needs changed, we will do that in a new, higher order Entity Operation. 

I was hesitant to create additional data sources because of the volume we're dealing with. I figured this would be the least taxing on the system since we've already imported the data.

I know this isn't a specific, direct answer, but I hope it helps you in making your decision on how to proceed in the future.

Kenny Hosey

[RK2]

Hi,

When adding or importing new fields, it's perfectly fine to update the existing RTE instead of creating a new one. If ServiceNow introduces the same field in the future, you can compare and decide whether to remove the custom field.

I have performed multiple customizations with the Azure Service Graph connector, including editing out-of-the-box (OOTB) mappings.

It's recommended to update existing mappings rather than creating new ones. This way, all mappings will be in one place, allowing for the reuse of operations or data, which helps avoid code redundancy and makes troubleshooting easier in case of any issues.

[Amar_Be]

Thank you for your advice,

But what happen to the customizations when the connector is upgraded to a new version? I suppose they're lost.

Do you have a method to preserve them or do you just reapply your update sets after each upgrade?

[RK2]

Hi,
When they plugin gets upgraded the changes will not be lost, these will be shown under skipped records. you can manually check the skipped records and take necessary actions.