How to do ontology mapping comparisons between different marketplace versions?

[donkos]

My Google Chronicle integration is fairly behind - I am looking to update but one of the versions explicitly mentions there being an ontology mapping change in the release notes - I have been trying to compare the existing mapping rules with the ones provided by support for the newest version - there seems to be a fairly big difference in the entity rules themselves (different event types) - how should one do a comparison between the rules present in different versions?

[ylandovskyy]

Hey @donkos ,

Google Chronicle integration was majorly updated and it is recommended to be on the latest version of ontology mapping. Most of the fields are defined at the product level for ease of management, the only exception to this is Email related events. This connector is also used for SCC Enterprise agenda, which has it's own custom mapping.

If you had some custom changes, then I would suggest to do a screenshot of those and if the ontology is not aligned - apply your changes.

[donkos]

I know its recommended to keep the versions and ontology mappings up to date. 

My concern is for changes to these two scenarios:

• I rely on a particular type of entity to be extracted as a hostname for example because I use an entity scope of "All Hostnames" in an action - how can I validate the same entities and types will get extracted after the update?
• I have actions that rely on particular event fields - how I can confirm if those event fields still exist in the new version or whether they've been changed?

[ylandovskyy]

@donkos 

Unfortunately, there is no native view inside the platform that allows you to see the delta between ontology mappings.

In terms of event fields, you can create a second connector and have it ingest a little bit into that test environment. This allows you to see the new changes and their impact before updating the connector that pushes into the main env.

Considering that this ontology is so sensitive for your use case, then I would suggest to not overwrite it and leave it as custom.

[donkos]

Considering that this ontology is so sensitive for your use case, then I would suggest to not overwrite it and leave it as custom.


Isnt there the risk that if I never overwrite the ontology that the event fields created by the connector could become updated by a new version and thus stop matching with the event fields in the ontology mapping?

[ylandovskyy]

@donkos It's theoretically possible, but if you will see this situation happening, then you can quickly change to the official version of mapping.

For example, if you will export import the same integration - it will make the whole integration "custom". The platform will then allow you to upgrade to "commercial" version.

So, you will always have a way to upgrade to the commercial ontology.

Generally speaking, we rarely change the structure of events, because we know that it causes regressions. So, even if there was a lot of changes done in the past, the risks of missing something are really small.