Join the #BuildWithBuildAgent Challenge! Get recognized, earn exclusive swag, and inspire the ServiceNow Community with what you can build using Build Agent.  Join the Challenge.

SAP Integration

Rekha Jalle
Tera Contributor

3 hours ago

Hi All,

I implemented an integration with SAP where we have three connectors across the Dev, UAT, and Prod environments. The web services provided by the client are different in each environment. These web services are used in catalog forms and flows. We have three catalog items, and we are calling the web services in a custom action script step.
Since the web services differ across environments, but the overall logic remains the same, everything currently works correctly in Dev, UAT, and Prod. However, the client wants to clone Prod, and if they do that, the Dev and UAT integrations will stop working due to the overwritten web service URLs.

0 Helpfuls
  • 14 Views
1 REPLY 1

tiagomacul
Giga Sage

15m ago - last edited 7m ago

Hi!

This is a very common and critical challenge in Application Lifecycle Management (ALM) when dealing with integrations (especially with SAP or other external systems).

 

You are correct: cloning Production down to Dev and UAT will overwrite the non-production integration configurations (like the endpoint URLs in the Outbound REST Messages or SOAP Messages), causing them to point back to the Production SAP environment.

 

The solution is to use CMDB Data Preservers and System Properties to secure the environment-specific values during the clone process.

 

🛡️ Best Practice Solution: Preserve Data & Credentials

 

You need to use ServiceNow's Clone Exclusion and Data Preserver features to protect your non-production integration configurations.

 

1. Protect Environment-Specific Credentials

 

If you are using Credentials (Username/Password or API Keys) for authentication in your REST/SOAP messages:

  • Create Data Preservers: Define a Data Preserver on the source instance (Prod) for the [sys_auth_credential] table.

    • Condition: Use a condition to preserve only the non-production credential records on the target instance (Dev/UAT).

    • Example: If your Dev credential is named "SAP Dev Auth," you would typically use a simpler method: preserve all records in this table. When the Prod data comes down, the existing Dev credentials are preserved and not overwritten.

 

2. Protect Endpoint URLs (REST/SOAP Messages)

 

The Web Service Endpoints (URLs) are typically stored in the [sys_rest_message] or [sys_soap_message] tables. These are Configuration records, not transactional data.

  • Exclude/Preserve the Tables: Since these tables contain the definitions used in your flows/actions, the best practice is often to preserve these records, preventing the entire Production record definition from overwriting the non-production definition.

    • If you preserve the entire record: You need to ensure the sys_id of your Dev/UAT REST message is different from the Prod message, which is usually true during development but must be verified.

 

0 Helpfuls