ServiceNow Apps and Store

CC4 links SAP Solution Manager with ServiceNow, both ways and without middleware. A certified application in the ServiceNow Store.

Maintenance for SAP Solution Manager ends in 2027.

The challenge: one case, two ticket systems

Change documents and incidents originate in SAP Solution Manager, but the people who work on them live in ServiceNow. As long as neither system knows about the other, somebody keeps the same case twice.

The effort is the smaller problem. The bigger one is the audit trail: it splits across two systems, and at audit time somebody has to assemble what should have been in one place.

One ticket system instead of two

Transport status outside the SAP team

No re-entry by hand

One audit trail for the auditors

What the application does

Change documents and incidents from SAP Solution Manager appear as ServiceNow tickets and stay that way. Edits happen on both sides, and the state syncs in both directions.

The sync carries status, fields, comments and attachments. Write a comment in ServiceNow and it shows up on the SAP document shortly after; move the status in Solution Manager and the ServiceNow ticket follows. Double maintenance ends, and with it the question of which of the two versions counted.

Bidirectional

What happens in ServiceNow arrives in Solution Manager, and the other way round. Status, fields, comments and attachments travel with it, not just the identifier.

Without middleware

No additional system between the two that needs maintaining and licensing. SAP and ServiceNow talk to each other directly, so when something stalls there is no third component to investigate.

From the Store

A certified scoped application, installed like any other, through the approval route your platform already uses.

How it works: what gets set up

On the SAP side there is an OData service in Solution Manager, which we deliver as an SAP transport. On the ServiceNow side there is the application from the Store. For the return path, SAP calls the ServiceNow REST endpoints, where business rules process the update.

The real work sits in the connection profiles. Per profile you pick the SAP process type and, separately, which fields correspond and which status maps onto which. Running several profiles side by side is the normal case. What such a link feels like in practice is described in Flexible Cross Connector Jira/SolMan interface solution with LAPP.

Why this matters now

Maintenance for SAP Solution Manager ends in 2027. Consolidate your SAP change control in ServiceNow before then and the processes already sit where they will stay, decoupled from the timetable on the SAP side.

The other order is the expensive one: switch off Solution Manager first, then work out where change and incident go. That leaves you without an audit trail at the exact moment the auditors ask for it.

Both directions, on every change

The sync does not run once at import but on every change, on both sides.

Syncing in both directions

Who builds the application

Cross ALM is an IT and process consultancy based in Berlin, grown out of a team of former SAP employees and SAP specialists. We are a certified partner of SAP and Atlassian, a ServiceNow Select Build Partner and a registered SAP Application Development Partner.

The application in the ServiceNow Store is our own product. Whoever sets it up at your site belongs to the team that built it, and can therefore also answer why a field behaves the way it does.

Our own product

The application is listed in the ServiceNow Store and on the Atlassian Marketplace. It gets developed further rather than rebuilt per project.

Both sides

SAP knowledge for the OData service and Solution Manager, ServiceNow knowledge for the scoped application and business rules. One team for both.

ITIL consulting

Our consultants are ITIL certified. The link is technology; whether the process behind it holds is a different question, and we ask it.

Starting in three steps

The link can start small: one process type, one system landscape. What comes after that is your call, made on what you can see by then.

Check the prerequisites

We look at your Solution Manager version, the network routes and the authorisations, and tell you what is missing.

Set up one profile

One process type, one landscape, field and status mapping written down. After that the benefit is visible rather than asserted.

Extend and hand over

Further process types and landscapes, automations, training and the handover to your operations team.

From customer projects

What connecting to Solution Manager looks like in real landscapes is written up in our project reports: Jira-Solman Integration with BSR covers a municipal operator, Flexible Cross Connector Jira/SolMan interface solution with LAPP an industrial manufacturer, and DevSecOps for SAP with ChaRM at Deutsche Bahn shows how far change and transport control can be automated.

How this looks in your landscape