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):
Service Desk Implementation Guide Part II
Activating ICT_SERVICE_DESK_API in 7.1
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
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
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.
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.
wow Tom thats a Great post, we have OTRS internally and will try to implement this.
Question, back in the day solution manager had an "enterprise edition" with enhanced integration to external service desk tools, that has been migrated to current solman editions am I correct?
Enterprise Edition was available in SolMan 7.0 EHP1. All the functionality that was offered there has been made available for Enterprise Support customers, free of charge so yes, that would be correct. For Standard Support customers it's a more complex story because there it depends on what was delivered in which version etc. You can find more information on SAP Support Portal SAP Solution Manager | SAP Support Portal under Usage Rights on the lower right corner.
Great blog Tom! 😉
It can help not only interfacing with OTRS but with other tools as well.
As you and I already discussed, SolMan interface with 3rd party Service Desk is a topic with very little information available and at the same time there are many customers interested in it.
Thanks for sharing,
Thanks. Yes indeed, it's a commonly asked question at customer side and there is little information available.The amount of questions on SCN also prove the point that I wouldn't do SAP any harm to release more information or get a better understanding going for the community at large.
The blog is geared towards OTRS specific case but has hints and thoughts in it for configuration that are generic. Each external service desk will have it's own way of working / thinking on this interface so it can differ to a large extent as well depending on the other product and what they have available (many external service desks offer "connectors" which have a specific implementation for example).
We are trying to setup an interface connection between Sap Solman 7.1 & an external ticketing system.
For transaction types Incidents, as copies from SMIN, we have no problems & we can trigger signals towards our exteral helpdesk system..
For transaction types Service Requests, as copy from SMRQ, we do the exact same setup regarding SPPFCADM & SOAMANAGER, but we get nothing, not even an error. I tried a whole variety of setup regarding actions & definitions,... nothing works.
Did you receive an answer from SAP in the meantime?
I didn't see this comment but I answered via via by mail in the meantime.
SAP only has foreseen standard interface in incident management, other scenario's which are similar (but not the same) require creating of a web service (can be done via ABAP class that is then exposed as a web service) in order to perform the interfacing with an external product.
Thanks again for the mail.
I have received no answer from SAP yet.. Will keep you updated if I do.
I was able to send out XML signals for service requests & change requests, but not yet in the correct formet or processing capabilities (eg. ReplicateIncident SOAPUI in stead of ProcessIncident)
received answer, just as you said:
I double checked with our developer.
And the result is that external service desk is only designed for incidents.
For 7.2 there is no plan to support other transaction types currently.
If you think the function is necessary,you can check note#11 to create development request.
Thanks for sharing the feedback.
Thank you for the post!
I think my problem is easier than the post but I couldn't find the way.
We give daily basis to more than 10 customers and we had to install Solman for each customer. But It's too hard to control Alert Inbox or ITSM for each customer. And we use email notification for alerts, but email is email. And we have our own Solution Manager system. Can we consolidate all system alerts in our Solman by the way Alert Inbox or ITSM etc?
Glad you like the post.
Alert Inbox doesn't have such an interface available as far as I know. The only way to get all the customers in the same inbox (in standard) would be to connect their systems to your own SAP Solution Manager environment and do the monitoring of all customers in there. That way you can have a central view on things. It's not meant to be separated out though so would only be for access of the particular SAP Partner and not for the SAP customers in question.
ITSM is a different thing in terms of having interface options available. You can have a VAR scenario in ITSM that separates out customers and incidents can be interfaced to other systems using a standard interface of SAP.
The recommended way would really be to have a central SAP Solution Manager on your side that is connected to all the customer systems to gather all the data centrally and handle it centrally also.
We started to use ITSM 3rd Party Integration. In every Solman system alerts will create an incident and all the incidents will transfer to our solman.
Update : as of last week, our RFC tickets are able to be send to an external service desk!