IntegrationHub ETL vs GlideRecord

[AustinD08141749]

Hello ServiceNow enthusiasts,

While looking to make some modifications to one of my ServiceNow applications that imports some third party CMDB data I've been researching ServiceNow's IntegrationHub offering.

After spending the past few days researching, I believe I understand the use case for IntegrationHub ETL, but I'm left with one question:  do I really need to use IntegrationHub ETL to integrate third party CMDB data?

It seems like I could just create my own staging tables and transform maps, then populate them using a GlideRecord in some server side script include.  It seems like doing this would provide the exact same functionality as the Robust Transform Engine, no?

I can implement my own custom logic to prevent duplicate CIs, which seems like it would fulfill the purpose of the Identification and Reconciliation engine.

From my perspective it seems like the main advantage of IntegrationHub ETL would be it's ease of use and access to OOTB Spokes.  If at all possible I'd like to use the GlideRecord approach, since it's what I'm most comfortable with, but I want to make sure I'm not misunderstanding some critical part of IntegrationHub ETL's functionality.

Does anyone see an problem with what I'm suggesting?  Or something I've overlooked?

Thanks in advance for your thoughts!

[Shivalika]

Hello @AustinD08141749 

I have been using Integration HUB ETL - for Microsoft Intune, Microsoft Okta, and also Solarwinds integrations. 

So, this is not only about Transform engines and IRE. As you said it has q whole guided setup, right from setting up the credentials, data sources, mapping the fields, creating custom fields and mapping them, robust transformer in batches. I mean it's a complete package. 

It's very essential if you get stuck anywhere servicenow will definitely help you out. 

And if you are just bothered about using GlideRecord and all - there is always a "Post Import Script" and also "Script section" which you can apply on the imported data - before being transformed where glideRecord usage is open. 

From my personal experience of all this time working with ETL, I feel it's truly user friendly and also Data Streams. I may not be able to gather all the perks at one place right now, but definitely there are others. You may check out documentation also. Also it supports non-CMDB tables. 

https://www.servicenow.com/docs/bundle/washingtondc-servicenow-platform/page/product/configuration-m...

I hope this helps. 

Kindly mark my answer as helpful and accept solution if it helped you in anyway. This will help me be recognized for the efforts and also move this questions from unsolved to solved bucket. 

Regards,

Shivalika 

My LinkedIn - https://www.linkedin.com/in/shivalika-gupta-540346194

My youtube - https://youtube.com/playlist?list=PLsHuNzTd

kE5Cn4PyS7HdV0Vg8JsfdgQlA&si=0WynLcOwNeEISQCY

[Robert H · Accepted solution]

Hello @AustinD08141749 ,

As almost always, the answer is: "it depends".

If you are just importing a small handful of attributes from a single table, and you do not have any other imports or integrations that feed the same CMDB table, then of course you could achieve this quickly using basic features like Transform Maps, coalesce field configuration, and maybe you won't even have to script anything.

But if you are planning to import from products like Microsoft SCCM or Intune, where lots of tables are involved, or if you have multiple sources for the same CMDB tables, then you would be better off using not creating everything from scratch and instead using the solutions that are specifically built for that purpose, and where you will get support if something it not working.

Regards,

Robert

[AustinD08141749]

Thanks a ton for your thoughts here Robert -- you've broken it down quite nicely. 

I think I was just looking for some reassurance that there wasn't some insanely valuable IntegrationHub features I'd be missing out on if I went this route.  For my purposes I think a pretty quick GlideRecord insertion should be sufficient.

Best wishes,

Austin