External service desk coupling SAP Solution Manager 7.1 – OTRS

Many customers have a service desk in place which is used for all departments, throughout the company. That service desk often is not SAP Solution Manager. This means that in many cases, it can become interesting to connect the SAP world to that service desk. This translates into scenario’s that leverage information from SAP systems or from SAP Solution Manager and then use the IT Service Management scenario in SAP Solution Manager to connect to the external (non-SAP) service desks in one way (shipping data out) or bi-directional (shipping data out and synchronizing in again or exchanging information in both ways).

A few examples:

Creating an incident (support message) from within a SAP application and sending it to an external service desk:

From within a SAP transaction, an end-user can create a support message. This data would then be sent to SAP Solution Manager and SAP Solution Manager can sent it further to the service desk that is used beyond SAP. This could be with or without a middleware in between as displayed in below line examples:

Managed SAP system (ERP for example) -> SAP Solution Manager -> External Service Desk

Managed SAP system (ERP for example) -> SAP Solution Manager -> Middleware (SAP PO for example) -> External Service Desk

This functionality is foreseen also in newer applications (Fiori applications) in the latest SAP ERP versions (S/4 HANA Digital Core) for example so it stays relevant towards the future as a scenario.

Creating an incident from within SAP Solution Manager (Technical Monitoring scenario for example) and sending it to an external service desk:

SAP Solution Manager -> External Service Desk

SAP Solution Manager -> Middleware (SAP PO for example) -> External Service Desk

These scenario’s could also send data back so it could become bi-directional. Depending on which side is considered the “master” different options can be explored to make this possible. You could create an incident from within Technical Monitoring, then have someone handle the ticket in the external service desk and synchronize the status back to SAP Solution Manager so an operator who works inside SAP Solution Manager (who only works there for example, first line operation support) sees the status of the incident which is being handled in the external service desk.

Relevant SCN sources (external service desk coupling content):

SCN content

Service Desk Implementation Guide Part II

Activating ICT_SERVICE_DESK_API in 7.1

SAP notes

2234342 – Status change is not done over External Service Desk

1483276 – Use of Customizing Parameters in DNO_CUST04, AGS_WORK_CUSTOM, and ICT_CUSTOM

2281823 – HTTP 500 Internal Server Error occurrs when opening a Webservice via an external alias

Whitepaper SAP Solution Manager 7.0 Service Desk WebService API

http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/e3eeb4a8-0b01-0010-bd99-f4a700a49d32?overridelayout=t…

There isn’t an awful lot of information available on SCN nor on SAP side on the standard WebService API that is delivered by SAP to make these kind of scenario’s work. The whitepaper describes how the web services work and what is possible with which operation.

A few good / interesting blog posts exist on SCN (although outdated) that provide additional information make it possible to get a better view on how the external service desk coupling is build up and functioning. I’m not going to discuss the basic setup or configuration of the external service desk coupling, this is already discussed in other blogs / threads. Instead I want to give some pointers which might help you when you have to set up a similar scenario.

Debugging and tracing:

As a consultant, don’t underestimate the power of the ability to debug through code. It can be the difference between getting the implementation done or being stuck and having to wait on SAP support. You don’t need to be a coder to “read” through code, check values of variables and get an understanding of what is happening in the system, figuring out why it’s acting the way it is.

To debug this scenario, I placed external breakpoints in the relevant class – methods on SAP Solution Manager side (for example CL_SOL_ICT_DNO_ORDER_API and CL_SOL_ICT_INTERNAL) when the external service desk (OTRS) would do a call to SAP Solution Manager.

Little things, like filling in a value in an item on the webservice “addInfo” can have a big impact on what the system does with the information that is available in the request. In transaction SRT_UTIL I would filter and trace on the web service path to capture incoming requests so I can check what the external service desk system is sending to SAP Solution Manager.

SOAPui can be used to perform requests to the different webservices and check what subtle differences might have as an effect.

In the end, you will want to combine all these to get a good understanding of what happens in the system due to which reason. The same is often also needed on the other side (on the external service desk side) to get issues out and end up with a consistent scenario. It might not be easy but it can definitely be worthwhile to debug and trace on both sides.

Requester and provider role as described in the whitepaper:

One of the problems I bumped into, connecting SAP Solution Manager and OTRS (open source service desk) was that the requester and provider role got switched up in the calls. If you look at the whitepaper and the blog post part II it describes how only certain operations of the webservice are available depending on the state an incident is in (beginningstate, processingstate, etc) and the role a system has got you’ll notice that when a ticket is new (in SAP Solution Manager) it’s in “BeginningState” = BS and when you send it to the external service desk, using operation ProcessIncident() it goes into state “ProviderProcessing” = PP. Then you would think you can use other operations but since the calls inverted the requester and provider, we couldn’t use it in that way and we only had “AddInfo()” and “CloseIncident()” to our disposal (see graphical representation above which differs from the flow depicted in the whitepaper because the roles didn’t match the statements in the code).

If you look at the whitepaper you’ll see that normally you’ve got more options to your disposal (Accept, Reject, …) and other intermediate states exist. When we performed calls in the system, we got the above result instead. We also wanted to get the scenario up and running avoiding code adjustments as much as possible, we ended up doing two minor adjustments in the end which makes it easier to maintain the solution afterwards.

AddInfo operation doesn’t update the status according to the whitepaper?

The AddInfo() operation, in principal, doesn’t update the user status according to the whitepaper. You can use customizing to set the “synchronization status” to a fixed user status value. However, it’s possible to configure the system to copy the user status out of the AddInfo() request coming from OTRS to SolMan which then changes the code that is executed because in the coding if the UserStatus is initial, the operation specific coding is called. If the UserStatus isn’t initial, a more generic piece of code is called to update the status thus making it possible to set any status, even when AddInfo() operation is called by OTRS (external service desk).

External Service Desk – Alternative Value Mapping(1) makes it possible to copy the UserStatus from an inbound request.

Customizing allows specific status to be set:

SAP Solution Manager customizing (ICT_CUSTOM) allows to set a specific status through customizing (see SAP note 1483276) so, for example, when the incident gets sent to the external service desk, you can place a specific user status in the customizing so the incident automatically shifts to that user status.

By customizing alone, we could set the following status flow up in SAP Solution Manager:

New -> Sent to OTRS -> In Process -> Closed

Combining different options:

When we then combine multiple options, it’s possible to synchronize any status using AddInfo() and a decent mapping from the status value of the incident in the external service desk to SAP Solution Manager.

New -> Sent to OTRS -> In Process -> <whatever status you want> -> Closed

For example:

New -> Sent to OTRS -> In Process -> Resolved -> Closed

New -> Sent to OTRS -> In Process -> Forwarded -> Resolved -> Closed

Meanwhile on the OTRS side:

On the OTRS side, a package was implemented to have a OTRS connector to SolMan ITSM available and also a specific filtering was put in place to more easily filter on tickets that are coming from SolMan.

Similar tracing and debugging was done on OTRS side, a small piece of code was adjusted also because OTRS kept sending “open” state instead of the correct state back to SolMan (might be version dependant) so in the end, we had someone from OTRS operations team write an SQL statement to read the correct state from the relevant database table and pass the correct state to the mapping.

Result:

The scenario which was put in place, makes it possible for an operator to create an incident based on a technical monitoring incident in the Solution Manager “Technical Monitoring – Alert Inbox” workcenter. This incident is automatically sent to the external service desk (automated through CRM action profile) where it is processed further. The status of the external service desk is synchronized back to SAP Solution Manager so the operators can see the status of the incident. When the incident is closed in the external service desk, the incident is SAP Solution Manager is closed and the alert gets confirmed.