Very common task during the establishment of the IT Service Management processes and especially Incident Management is the integration of the SAP Service Desk with the already existing tools. As many of you may know, there is the standard web services interface ICT_SERVICE_DESK_API. It is described well in its’ whitepaper.

In theory, everything is very easy, you just need to perform the steps specified in SPRO:

1.PNG

  1. Create the technical user that will be used to call the web service
  2. Activate service ICT_SERVICE_DESK_API in the transaction SICF
  3. Configure the service provider for the service ICT_SERVICE_DESK_API in SOAMANAGER (steps are described in the IMG activity documentation)
  4. Configure Service Consumer. If the application has the SOAP API, provide the WSDL  If the integration is one way only (from application to SolMan) and you don’t have external interface and WSDL – skip this step

And now we reached the tricky part. We need to register the external help desk in the ICTCONF. This is necessary to get the GUID of the external application. And to get this GUID the external application needs to implement the SOAP interface with RequestSystemGUID function. This function needs to provide response with the unique number and this would be enough to do the registration.

After the implementation of the function is finished, reconfigure the logical port (step 4 of IMG), go to ICTCONF transaction and add new system.

Just fill the required information (Service desk name and logical port created on step 4) and continue:

2.PNG

But some applications (SOAPUI as an example) the SOAP interface or implementation of the function, so we cannot use the ICTCONF transaction as this transaction will do the RequestSystemGuid request and receive error. In this case we can fill the table ICT_SYSCONF manually:

3.PNG

  • The THIRD PARTY GUID can be any random generated value.
  • LOGICAL PORT is the port you created in step 4. If you skipped that step because no SOAP API available, just put some random name here.
  • NAME is the name of your application, you can choose any.

Next step after registering the external application for the ICT_SERVICE_DESK_API is to create the value mapping. And this should be done even if the values are the same in both applications.

This is done via the SPRO:

/wp-content/uploads/2015/03/5_662484.png

Select “Value Mapping (2)” on the next screen:

/wp-content/uploads/2015/03/6_662485.png

The minimum requirement is to map the values for the priority and for the text type which is done in this activity.

First, let’s map the priority. Add the new entry to the table and fill in required internal (value in Solution Manager) and external (value in external application) values:

/wp-content/uploads/2015/03/7_662492.png

Repeat the procedure for all the priority values:

8.PNG

Basically this is enough and you can proceed to call the service and it should work. But some not-mandatory parameters also could be added to the incident. The most common are different text for the descriptions, business impact and so on. To be able to pass this information you can map the values of the text types:

9.PNG

Now we can use the 3rd party interface to create the incident:

  1. Register the SOAP interface in your application via Solution Manager WSDL file (to find it go to SOAMANAGER -> Web services configuration, find your provider and click “Open binding WSDL configuration”)4.PNG
  2. Perform the RequestSystemGuid function to get the Solution Manager GUID. The Request XML should look like this:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:sap-com:document:sap:soap:functions:mc-style">
   <soapenv:Header/>
   <soapenv:Body>
      <urn:RequestSystemGuid/>
   </soapenv:Body>
</soapenv:Envelope> 

     In the response you will receive the GUID of Solution Manager. This should be stored and then used for the future API calls:


<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
   <soap-env:Header/>
   <soap-env:Body>
      <n0:RequestSystemGuidResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">
         <Errors/>
         <SystemGuid>0050569E758F1ED398E3D8C3084C8624</SystemGuid>
      </n0:RequestSystemGuidResponse>
   </soap-env:Body>
</soap-env:Envelope>

  3. To create the incident the ProcessIncident function should be used. It is well described in the whitepaper. The example call looks like this:


<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:sap-com:document:sap:soap:functions:mc-style">
   <soapenv:Header/>
   <soapenv:Body>
      <urn:ProcessIncident>
         <IctAdditionalInfos/>
         <IctAttachments/>
         <IctHead>
            <IncidentGuid><Unique value for the incident GUID</IncidentGuid>
            <RequesterGuid>0050569E758F1EE49B819F6374359E11</RequesterGuid>
            <ProviderGuid>0050569E758F1ED398E3D8C3084C8624</ProviderGuid>
            <AgentId></AgentId>
            <ReporterId>1</ReporterId>
            <ShortDescription>Test WS incident creation</ShortDescription>
            <Priority>2</Priority>
            <Language>RU</Language>
            <RequestedBegin>20150310130000</RequestedBegin>
            <RequestedEnd>20150410130000</RequestedEnd>
         </IctHead>
         <IctId>3</IctId>
         <IctPersons>
               <item>
                    <PersonId>1</PersonId>
                    <PersonIdExt>dummy1</PersonIdExt>
                    <***></***>
                     <FirstName>Victor</FirstName>
                     <LastName>Palkin</LastName>
                     <Telephone>
                           <PhoneNo></PhoneNo>
                           <PhoneNoExtension></PhoneNoExtension>
                      </Telephone>
                      <MobilePhone></MobilePhone>
                      <Fax>
                      <FaxNo></FaxNo>
                      <FaxNoExtension></FaxNoExtension>
                      </Fax>
                      <Email>victor.palkin@sap.com</Email>
                 </item>
       </IctPersons>
       <IctSapNotes/>
       <IctSolutions/>
       <IctStatements>
            <item>
                 <TextType>SU99</TextType>
                 <Texts>
                      <item>This is a test from SOAP UI</item>
                      <item>incident was created successfully</item>
                 </Texts>
            <Timestamp>20150310124800</Timestamp>
            <PersonId>1</PersonId>
            <Language>ru</Language>
            </item>
         </IctStatements>
         <IctTimestamp>20150310124800</IctTimestamp>
         <IctUrls/>
      </urn:ProcessIncident>
   </soapenv:Body>
</soapenv:Envelope>

     If everything was configured correctly, you should receive the response with the id of created incident and mapped id of the requester:


<soap-env:Envelope xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/">
   <soap-env:Header/>
   <soap-env:Body>
      <n0:ProcessIncidentResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">
         <Errors/>
         <PersonMaps>
            <item>
               <PersonId>1</PersonId>
               <PersonIdExt>0000000343</PersonIdExt>
            </item>
         </PersonMaps>
         <PrdIctId>8000008790</PrdIctId>
      </n0:ProcessIncidentResponse>
   </soap-env:Body>
</soap-env:Envelope>

     And now you can see the new incident in the CRM UI:

10.PNG

The ICT_SERVICE_DESK_API can be used for much more complex scenarios, all the possibilities are described in the whitepaper.

To report this post you need to login first.

19 Comments

You must be Logged on to comment or reply to a post.

  1. Patrick Dean

    Hi there, can anyone tell me why the “ReporterID” in the <IctHead>  header is “2”, when PersonID in <IctPersons>  of the Requester is “1” and PersonIDExt is “12”?

    (0) 
    1. Victor Palkin Post author

      Hi, Patrick,

      Thanks for noticing. That was a typo. The Person ID in the head section should be the same PersonID as in the Persons section. PersonIDExt is the identifier of the person in the external application. In this scenario it’s just some dummy value.

      I fixed this typo

      Best regards,

      Victor

      (0) 
  2. Patrick Dean

    Thanks for getting back to me! :Any idea how to populate the “Sold To” party? I’m thinking some kind of BADI/Exit/mapping on the way in?

    (0) 
    1. Victor Palkin Post author

      Hi Patrick,

      I can see two options:

      • Easy: you can use the field “AgentID” to pass the “SoldTo Party”. To achieve it in the “Define Extended Interface Mapping” actitivity in SPRO you can set up the SoldTo Party partner function as a function for AgentID field
      • Hard: if the field AgentId is already in use, then you can try to pass it in <AdditionalInfos> section as an additional parameter. Then you will be able to process this parameter if you re-implement the enhancement spot BADI_SOL_ICT_MAPPING and the Badi BADI_SOL_ICT_MAPPING_INBOUND, where you can read the SoldToParty value from the incoming data and put it into the the incident by the GUID.

      Best regards,

      Victor

      (0) 
  3. Rahul Yedapally

    Nice Document  Thanks Victor .

    I am Looking for different scenario -> Customer has solman service desk -> if First level support does not slove the issue it should escalate to second level support

    Second level support uses external third party Tool

    How do we configure solman to external service desk

    Can U please help with your valuable inputs

    Thanks,

    Rahul Yedapally

    (0) 
    1. Victor Palkin Post author

      Hi, Rahul,

      That is indeed much more complex scenario.

      This requires to run a small integration project and depends on the 3rd party tool. The general prerequisite is that the 3rd party tool has the SOAP or REST APIs. In majority of the cases such integration requires the custom development.

      The options are the following

      • P2P integration
        • If you read the whitepaper you will see that the interface described there is bidirectional and can be used for both tools. So if you can implement almost EXACTLY the same SOAP API on the 3rd party tool side, then on the Solution Manager side it will be very easy, you’ll just need to go through all the steps in SPRO “External integration” and activate and customize the default integration PPF action for your transaction type. For example you can schedule action “Send to external help desk” for status “Forwarded”
        • The most common scenario: Usually it is not possible to implement similar interface. In this case you require some ABAP 🙂 . You will need to get the WSDL file of the 3rd party tool and in SE80 create a new Service Consumer object. This will generate a set of ABAP classes that will be very easy to use to call the function of the 3rd party tool. After that you will need to implement a new PPF action to call the web service of 3rd party tool via the Service Consumer. Then you can schedule this action for automatic or manual execution. Standard PPF actions for integration can be used as a basis for the development.
      • Integration with the middleware

           In this scenario you can try to use some middleware, for example SAP PI to map the      SOAP APIs of the two tools. Then you can again use the standard PPF action to      acheive your goals with schedule/start conditions

      Best regards,

      Victor

      (0) 
  4. Rahul Yedapally

    Thanks Victor, Good article

    Could you please help us on how to get the incidentGUID from SOAP UI client

    We have done integration for  third party  (internal tool) to solman 7.1 SP14 ITSM , configured as per the above document

    we are using SOAP UI client for Testing , wile passing the values from SOAP UI screen to solman ITSM it has been requested for  incident GUID 32 char

    attached error screen for your Reference

    soap.PNG

    (0) 
    1. Victor Palkin Post author

      Hi, Rahul,

      This error is usually thrown when the value in the field RequesterGUID is not the same as the value maintained in the ICT_SYSCONF table or ICTCONF transaction as mentioned in the article.

      Please check that.

      Also, check the value in the ProviderGUID, if it’s really the guid of Solution Manager.

      Best regards,

      Victor

      (0) 
  5. Rahul Yedapally

    Hello Victor,

    Thanks for your update , I have check your blog and we have few issue while  testing incident creation from SOAP UI screen

    1.No Entry exists in table ICT_INCIDENTATTR

    2. We have test this scenario through SOAP UI client

    How to create incidents in Solution Manager 7.1 from the external application


    While Testing with Process incident , we haven’t received any ticket in SAP incident manager screen


    3) In SOAP UI Insted of incident id we are getting system GUI-ID as output response


    attached screen for your Reference/wp-content/uploads/2016/04/info_931465.png

    (0) 
  6. Rahul Yedapally

    Hello Victor,

    We have Resolved above issue by removing Request GUID Function

    While Testing with Process incident , below is the issue while processing the request




    /wp-content/uploads/2016/04/issue_931653.png

    (0) 
    1. Victor Palkin Post author

      Hi, Rahul,

      You have questionmarks in the fields AgentId and ReporterId. This fields should have the id of the persons that are described in IctPersons structure so that the value equals PersonId in IctPersons. Please check the whitepaper for the reference. Also you have a questionmark in the field “S ex”.

      You either leave the field empty or put the value there.

      PS. SCN replaces the word “S ex” with ***, that’s also creating a confusion.

      Best regards,

      (0) 
  7. Rahul Yedapally

    Finally we did it ..Thank you very much Victor , interesting topic Good to know the concept of  third party tool integration with solman ITSM 

    Cheers,

    Rahul Yedapally

    (0) 
    1. Victor Palkin Post author

      Hi, Alexander,

      It is very similar, the XML structure is exactly the same, just mantain mandatory fields in the IctHead structure and use CloseIncident method.

      The trick there is that before that the initial replication of the incident should have already happened so that IctGuid is created and the interface should be in the certain status. Please refer to the white paper, there you can see which methods are allowed in which state.

      Best regards,
      Victor

      (0) 
  8. Daniel Norström

    Hi Victor!

    Great examples and great article! Many thanks!!

    I have some questions.

    How would you populate the multicategory fields in 7.1 via the interface?

    And to get the full partner determination working. Can we execute BRFPLUS determination during creation of the 3rd party ticket directly?

    In addition, would it be just as easy to create the CMCR in Solution Manager rather than the ZMIN since the 3rd party tool already have the Incident and we only need the Solution Manager part for the Change Request Management ZMCR. From time to time and scenario to scenario I can imagine only the ZMMJ would be needed.

    Do you have any experience here or any advice?

    Best Regards

    Daniel

    (0) 
    1. Victor Palkin Post author

      Hi, Daniel,

      1) You can add a value to the IctAddionalInfos structure. Add there the code

      <item>
      <AddInfoAttribute>SAPMultiLevelCategoryID</AddInfoAttribute>
      <AddInfoValue>AIC_CAT_01_07                           MEGAFON_SAP_SM_TEMPLATE                 C</AddInfoValue>
      </item>

      There is a trick with the value. It should be the concatenation of three strings

      <Category ID><SchemaID><KatalogType>

      And you need to be careful that each strgin has exact number of characters. Add spaces if needed

      <Category ID> – 40 symbols

      <SchemaID> – 40 symbols

      <KatalogType> – 1 symbol

      So in the end the value should look like:
      AIC_CAT_01_07                           MEGAFON_SAP_SM_TEMPLATE                 C

      you can simplify the values in XML if you maintain the mapping in SPRO.

      2) Yes, PPF determination works

      3) Yes, you can use it for ZMCR, and for my experience it is a more common scenario, there is a problem with the SOCM context values, but the can be overcome with some minor enhancements

      Best regards,
      Victor

       

      (0) 
  9. zhu chuhao

    Hi Victor!

    Great examples and great article! Many thanks!!

    I hava a problem about the CloseIncident method.I’m migrating confirmed incidents from our old solman system to the new one.

    I use ReadCompleteIncident to get complete data of the confirmed incidents in old system,and use ProcessingIncident to create new ones in new system,then use CloseIncident to close it.

    The closeincident method seems work fine when i use ListunclosedIncidents to check it,and status in table ICT_INCIDENTATTR changed ‘CL’.But status still keeps ‘New’ when i see the incident in the CRM UI.

    Could you give me some suggestion?

     

    (0) 

Leave a Reply