API integration strategy

[Tone1]

Hey folks,

I wanted to pick your brains a bit about how you guys handle platform access via APIs. I'm specifically interested in how you approach integrating data from different teams into ServiceNow Foundation Data and the CMDB.

Right now, I'm juggling a bunch of different options and not sure which one to go with. I've got scripted REST APIs, inbound web services, IH ETL with Import API on Temp Table, and a few others up my sleeve. I think IH ETL and the Import API might be the way to go for CMDB data, but I'm still not sure about handling organizational data.

With all these different API options, it's a bit tough to figure out which one's best for the job. Plus, I want to make sure we're future-proofing our approach and incorporating features like transform maps and versioning. And I'm definitely not keen on letting people just write directly to the tables without any checks and balances, so Authenticaiton must be handled as well.

I'd love to hear your thoughts on all this, especially in terms of identifying the best API approach for each scenario and addressing my concerns about insuring data integrity and future-proofing. Your expertise would be a huge help in guiding me towards a solid API integration strategy.

Thanks in advance for your time and input.

[Sohail Khilji]

Hi @Tone1 ,

Keep it simple rather than trying multiple integration options.

I belive your focusing on 2 diffrecne things 1.Foundation data 2. CMDB data.

Generally you can get all the required foundation data by simply doing an OOTB integration with Active directory, this will give almost all the required foundation data that your expecting on the platform like SAMusersname, email, company, department, address etc... (tables..).

And for CMDB you got to integrate with the platform which your customer was previously using and transform all the data from other system to servicenow. (There are seveal approches , it all depends on how and what the status of customer was before and during onboarding)...

I hope this help... 🙂

[Tone1]

Thank you for your input, Sohail. However, our Active Directory is not a single source of truth. It's primarily a user repository that lacks accurate department, company, and address information. Therefore, we need to ingest this data from another source in a "push" manner, rather than "pull." This is where APIs come into play. Additionally, we have several sources already in use for CMDB data, including discovery, jdbc, servicegraph and others. However, we now need to provide a mechanism for people to write into ServiceNow tables via APIs.

My goal is to streamline this and establish a consistent API operations process that is independent of the product tables. I don't want there to be any difference if someone wants to write to cdbm_ci_ip_network, cmn_department, or service_offering. The process and technical implementation for providing such APIs should be more or less the same. That's why I'm asking for advice on which of the different implementation methods would be best suited to achieve this goal.

[BellBoy]

To establish a robust and future-proof API integration strategy for managing ServiceNow Foundation Data and the CMDB, it’s crucial to weigh your options carefully. Here's a structured approach to guide your decision-making, incorporating best practices recommended by software development experts https://tech-stack.com/  :

1. Define API Integration Requirements
Clearly outline the goals for your API integrations:

Foundation Data: Prioritize accuracy and consistency, especially for organizational data.
CMDB Data: Focus on maintaining relationships and avoiding duplicates.
Data Governance: Ensure all data adheres to your standards and complies with policies.
Authentication & Authorization: Guarantee secure and controlled access to APIs.
2. Evaluate Your Integration Options
Each integration approach has its strengths, and selecting the right one depends on your specific use case.

A. Scripted REST APIs
Use Case: Flexible when dealing with custom business logic or dynamic data processing.
Pros:
Full control over request/response payloads.
Can integrate seamlessly with external systems.
Cons:
Requires more development and maintenance effort.
Best For: Custom, transactional integrations with external systems.
B. Inbound Web Services
Use Case: Standardized SOAP or REST APIs for simpler integrations.
Pros:
Quick to configure for straightforward data exchanges.
Cons:
Limited flexibility for complex transformations.
Best For: Lightweight integrations or cases where a standardized API can handle the requirements.
C. IntegrationHub ETL with Import API (Temp Table)
Use Case: Bulk data processing, especially for CMDB updates.
Pros:
Built-in data transformation and staging.
Supports data cleansing before committing to target tables.
Aligns with ServiceNow's best practices.
Cons:
May not be ideal for real-time data processing.
Best For: CMDB updates and structured organizational data imports.
D. Transform Maps with Import Sets
Use Case: Data transformation and validation during imports.
Pros:
Out-of-the-box support for ServiceNow workflows.
Ensures data consistency via field mappings and validation rules.
Cons:
Requires additional setup for complex mappings.
Best For: Enforcing data integrity and pre-processing imported data.
3. Ensure Data Integrity
To avoid uncontrolled writes and maintain high data quality:

Use Temp Tables: Route all incoming data to temporary staging tables for cleansing and validation.
Apply Transform Maps: Map fields accurately and enforce validation logic before importing.
Version Control: Track and manage API versions to ensure backward compatibility and smooth updates.
Authentication: Implement OAuth 2.0 or Basic Authentication for secure access to APIs.
4. Plan for Scalability and Future-Proofing
Standardization: Adopt consistent API standards (RESTful architecture, JSON for payloads, etc.).
Governance: Create an API governance model to oversee changes and maintain quality.
Monitoring & Analytics: Use ServiceNow’s native tools or external platforms for API usage tracking and performance monitoring.
Documentation: Maintain detailed API documentation to ensure seamless onboarding for new teams.
5. Decision Framework
Here’s how to approach integration scenarios:

For bulk imports (e.g., organizational data): Use IntegrationHub ETL and the Import API with staging tables for validation.
For CMDB updates: Combine Import API with Transform Maps to ensure data integrity.
For real-time integrations (e.g., external system sync): Go with Scripted REST APIs.
For lightweight, standardized data exchange: Use Inbound Web Services.
6. Align with Software Development Best Practices
Engage software development experts to review your API design, security, and scalability.
Conduct regular code reviews and updates to ensure alignment with best practices.
Leverage CI/CD pipelines for automated testing and deployment of API updates.
By selecting the right tools for the right tasks, employing a robust validation process, and prioritizing security, you’ll set a strong foundation for your API integration strategy. This approach ensures data consistency, protects against unauthorized access, and supports long-term scalability.