Skip to Content

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

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. 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:


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:


  • 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:


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


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:


Repeat the procedure for all the priority values:


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:


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="" xmlns:urn="urn:sap-com:document:sap:soap:functions:mc-style">

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="">
      <n0:RequestSystemGuidResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

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="" xmlns:urn="urn:sap-com:document:sap:soap:functions:mc-style">
            <IncidentGuid><Unique value for the incident GUID</IncidentGuid>
            <ShortDescription>Test WS incident creation</ShortDescription>
                      <item>This is a test from SOAP UI</item>
                      <item>incident was created successfully</item>

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="">
      <n0:ProcessIncidentResponse xmlns:n0="urn:sap-com:document:sap:soap:functions:mc-style">

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


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

You must be Logged on to comment or reply to a post.
  • 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"?

    • 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,


    • 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,


  • 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


    Rahul Yedapally

    • 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,


  • 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


    • 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,


  • 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

  • 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


    • 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,

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


    Rahul Yedapally

    • 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,

  • 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


    • Hi, Daniel,

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

      <AddInfoValue>AIC_CAT_01_07                           MEGAFON_SAP_SM_TEMPLATE                 C</AddInfoValue>

      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,


  • 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?


  • I am getting the below error when following the blog steps.Please help.



    <Val2>Content data for object 'CRM_P_URL' not found</Val2>


    • I saw this error message today at customer side and the reason was that the

      <ictattachments> section was set as follows which is incorrect:







      if there are no values used, you should have either







      and not have any item tags in between beginning and end of that section


      Best regards



      • Hello Tom,

        Thanks for the message.

        I faced error like:

        <Val2>Service Desk interface internal error</Val2>

        Your suggestion solved it.




  • Dear Victor,

    Thank you for the great post.

    I have the following question on the topic.

    In our company there is integration between Solman 7.1 and Lotus Notes which works fine.

    Recently we installed new Solman 7.2 and transferred the integration functionality to new system.

    So we integrated SM 7.2 SP6 with Lotus notes successfully.

    Incidents (ZMIN) are created in Solman from lotus without errors.

    After when we create as follow-up ZMCR from the ZMIN incidents created from Lotus, we get errors like:

    • Service desk attachment ID XXXXXXXXXXX is inconsistent.
    • Service desk GUID XXXXXXXXXXX is nomeaningful here.
    • Service desk system ID XXXXXXXXXX is nomeaningful here.
    • Context root 0000 is inconsistent.
    • Service desk text ID XXXXXXXXXX is nomeaningful here.

    Screenshot of the error messages from ZMCR is here:

    Please note these errors are faced only in Solman 7.2.

    Could you suggest solution for the issue.

    Thank you and regards,




  • Hi Victor,

    That's a great article .Thanks for providing very use full info.

    My Scenario is that the incident creation will happen in Solution Manager and it has to be replicated in 3rd party service desk(IBM control desk in this case) and the incident process will happen there till closure. once the incident is closed in external system the same has has to be updated in Solution Manager incident too with all the details.including attachments needs to be updated in Solman.

    Kindly suggest how to achieve this task.


    Naresh y

  • I see this is related to external service desk to solman ITSM. Is it possible to connect with other applications ie. Control-M and then log service requests?

  • Hi Victor..

    Nice Blog, its really helped to start the 3 rd Party integration.

    We have Successfully processed the 1 st step :  RequestGUID, we got but in second step ProcessIncident we facing issue, i have followed the same step for this blog, here i need to now what the parent GUID you have processed. and we are using the ZMIN transaction type for our process, if once this specified blog content refer the SMIN or ZMIN transaction . I hope waiting for your reply.


    Saranraj Vasanthakumar