This blog is a practical look at the process of integrating SAP Service Cloud/C4C and Field Service Management (FSM), using the documentation provided here: FSM C4C Integration Docs
I will be going into further depth about the potential issues faced and what they mean as sometimes integration errors can be hard to diagnose or not have an obvious root cause. As the documentation covers the overall steps to achieve the integration I will not be rehashing it, instead, I will focus on the actual issues I encountered along the way, how I diagnosed them and ultimately resolved them.
Firstly, why would you want to integrate these two systems?
Well, SAP FSM provides additional planning and crowdsourcing abilities for service management and it may be desirable to use these to manage service calls to dispatch and plan, or even use the crowdsourcing features.
Essentially the initial ticket planning or creation can be done in SAP Service Cloud, coming from a variety of sources, whilst the actual Scheduling and Field Service execution are handled in the SAP Field Service Management system.
The following diagram is in the above documentation outlining the interaction points and showing SAP Cloud Platform Integration (SCPI) in the middle handling the interactions.
The first error I encountered was basic SSL errors like the following.
“SRT: Processing error in Internet Communication Framework: (“ICF Error when receiving the response: ICM_HTTP_SSL_ERROR”)
This one is a fairly common one you might see if you forget to add the certificates to each system (or add the wrong one), fortunately, the error message is fairly self-explanatory in this case. Unlike the next two issues as we will see.
The resolution here is pretty simple, make sure the certificate for each system is in the trusted certificates list/certificate store.
The integration documentation referenced in the start of this blog details how to do this for the systems involved, however, do make sure you have the correct server’s certificate stored. For instance, SCPI access our itspaces area via https://p2***-tmn.hci.ap1.hana.ondemand.com/, however, the actual endpoint for the messages is more like https://p2****-iflmap.hcisbp.ap1.hana.ondemand.com – it is important to note the distinction when adding the certificates.
In this example, I needed to add the certificate from p2****-iflmap.hcisbp.ap1 to the C4C trusted certificates to enable this SSL connection to complete successfully.
After fixing the above and checking the certificates in other systems, I got a new error when trying to send a ticket from FSM to C4C. In the message monitoring in C4C, I noticed the following error:
“Exception: Error in message header mapping; agent class is CL_APCRM_SRQ_REPL_IPA”
My initial thought was to check the mappings of the FSM request types and user status to C4C types, so I went back over the documentation, verified all of the settings were in place but they all seemed correct.
It turns out this is most likely due to the Communication System in C4C. The Business Instance must be the same as the Company ID (not name) as the Company in FSM.
If this is correct and you are still getting this error, SAP Note 2596951 – Exception: Error In Message Header Mapping Agent Class Is CL_**** has some other pointers about why you might have this issue.
This requirement is mentioned in the documentation; however, it is not mentioned what type of error you might get should you miss the fine print. This one was particularly difficult to diagnose and I resorted to searching through SAP Notes after verifying all of the configurations I could.
This one was encountered when trying to go the more intuitive direction, Tickets in C4C replicating to FSM.
In the message monitoring in C4C I could see the following error, which by itself is not very descriptive:
Clicking view -> error log we can see the full error details:
This error is sufficiently cryptic, some sort of exception somewhere. “java.lang.Exception: C4C ID 24:- null@ line 50 in Ticket – FSM response error handling.groovy”
My first thought was some required data that I hadn’t populated in C4C, but it turns out we can diagnose a bit further to find the real cause of this one.
In SCPI we can set the Log Configuration to Trace and retrigger the message. From the Operations view -> Manage Integration Content we can find the iFlow in question:
From here set the Log Level to trace (it will default back to debug after 10 minutes – I’d also recommend setting it back to info once everything is sorted).
Once you have triggered a message again, you can see it in the “Monitor Message Processing” section:
From here click on Logs -> Trace and find any step with the red exclamation point – this is where the failure occurred.
In the Payload section, we can see the actual response from FSM is effectively “Not enough permissions”.
In this case, it was a simple fix in FSM to make sure the Client used in the integration/SCPI Keystore had access to the appropriate company.
After trawling through settings, logs and referring back to the documentation several times, finally, I achieved success, able to replicate a ticket from C4C to FSM and vice-versa.
In the below example, the ticket was created in FSM and replicated back into C4C:
We can see this in the message logs in SCPI
And the second success, replicating a ticket created in C4C for allocation in FSM:
In this example I am not replicating Business Partners/Employees yet, however, these are iFlows that are available. In order to make this work, I created them manually in FSM, making sure the external ID field matched the ID in C4C. If you don’t do this on the C4C -> FSM side you will see an error like “Resource [BUSINESSPARTNER] with externalId [xxxxxxx] was not found. In a future blog, I might go over any counter-intuitive errors encountered along the way if any.
These sorts of errors are pretty easy to spot in the logs fortunately and are fairly obvious as to what needs to be done.
The monitoring and tracking tools in SCPI are quite powerful, you can see the logs at any step along the iFlow and identify which part is not working correctly (once you are able to hit SCPI successfully).
It would have been nice if the errors (e.g. the authorisation issue) had propagated up to be easier to find.
Overall this process took me about 2-3 days, and that included setting up a new SCPI instance, configuring all of the access on each system etc. Compared to manually integrating through any form of custom integration this whole process is much simpler. Of course, there is still work to be done to replicate business partners, materials and so on.