Integrating with SAP Hybris Cloud for Service – Creating Service Tickets with data from external systems
Integrating with a cloud-based solution is both an interesting as well as a challenging occupation. Especially in SAP’s Hybris Cloud environments there is only limited flexibility for making customizing or creating custom code to control the inbound or outbound message processing. To get things working as desired, one might come to the point where additional logic needs to be added in the integration layer. In this blog, one of such challenges will be described and it will be explained how this was tackled by using SAP’s Process Orchestration 7.5 (SAP PRO 7.5). Note: this scenario can also be reproduced by using an older version of PO, and even by PI as it is not using any BPM/BRM component.
During the implementation of SAP Hybris Cloud for Service, one of the business requirements was to create service tickets that are based on incoming data from external systems. Several (non-SAP) systems are providing this information via web services and other protocols to the customer’s SAP PRO 7.5 environment. Task for the integration consultant to map and route these messages to SAP’s Hybris Cloud for Service standard ‘Manage Tickets’ inbound web service.
Since SAP Hybris Cloud for Service defines its own number ranges for all kinds of objects, such as business partners and installation points, it also expects new service tickets to be created based on these specific number ranges. In this blog, these number ranges will be called “internal IDs”. Since all external systems integrate based on SAP ECC numbers (“external IDs”) available, the challenge is how to create service tickets in SAP Hybris Cloud for Service based on these external ID ranges.
In this particular example SAP’s Process Orchestration environment was used as middleware tool, since this system was already available in the customer’s system landscape. Hence, there was no need to acquire tools like SAP Hybris Data Hub or other middleware systems that perhaps could have executed the same functionality.
Query the SAP Hybris Cloud for Service ObjectIdentifierMapping
Starting point for exploring any feasible solutions has been the fact that external IDs are stored already in SAP Hybris Cloud for Service when using the standard SAP master data interface between ECC and SAP Hybris Cloud for Service. For instance, the standard SAP mapping for replicating installation points called “ERP_COD_InstallationPointBulkReplicateRequest”, puts through the ERP installation point from the iDoc to SAP Hybris Cloud for Service. Please also find the figure below. SAP Hybris Cloud for Service’s inbound program to process these messages stores this external ID, but also creates a new internal ID for the exact same installation point. The link between these two objects can be retrieved via the “ID mapping for Integration” section in SAP Hybris Cloud for Service.
Figure: Masterdata interface between ECC and SAP Hybris Cloud for Service
Eventually we decided to make use of the standard SAP Hybris Cloud for Service’s web service “Query Object Identifier Mapping”. With this web service it is possible to retrieve the internal ID based on the external ID which is provided by the sending (source) system. An overview of this setup can be seen in the figure below.
Figure: Scenario overview
Below screenshot shows a SOAPUI request and response. More information on how to construct this request can be found by following this URL: https://help.sap.com/doc/saphelp_byd1702_en/2017.02/en-US/PUBLISHING/PSM_ISI_R_II_QUERY_OBJECT_ID_MAPPING_IN.html
As displayed in the screenshot, the request contains the element/tag “LowerBoundaryRemoteID” in which the external ID should be filled. The response provides the element/tag “LocalObjectID” which reflects the internal ID; the number that should be used to log a ticket in SAP Hybris Cloud for Service. In case the web service does not give any hits, the UDF will return a blank value. The same happens when the LowerBoundaryRemoteID is not being provided by the mapping.
Note that in case of using basic authentication while performing the SOAP call (via SOAPUI), the credentials from the communication arrangement should be used. Using any other user may prompt an authorization error.
Figure: SOAPUI request and response to the ObjectIdentifierMapping
Now it’s important to include this web service call in the process orchestration as some kind of SOAP lookup. SAP PRO 7.5 only provides a limited number of lookups for graphical mapping, the RFC lookup and the JDBC lookup. This means a User Defined Function (UDF) should be created in order to achieve this within a graphical mapping. Another option would be creating a BPM. After some considerations, it was decided to go for the UDF approach. Reasons, amongst others:
- Using BPM can be quite performance consuming
- Relatively simple SOAP call which requires limited effort of Java UDF developments. Creating a BPM with only one or two of these lookups would be quite excessive
- Ease of maintenance, required knowledge and subsequent costs are likely to be lower in case BPM is not being used for this
A couple of blogs have been written about writing these kinds of UDFs, such as:
Steps to be taken to construct a properly working UDF:
1. Import Java Libraries into PI
2. Create a SOAP Receiver Communication Channel
3. Formulate a correct XML request in the UDF
AbstractTrace trace = container.getTrace();
String CustomerID = “”;
Channel channel = LookupService.getChannel(“BS_SAPCOD“,”CC_SOAP_CustomerID_Receive“,);
SystemAccessor accessor = LookupService.getSystemAccessor(channel);
String SOAPxml =
“<?xml version=\”1.0\” encoding=\”UTF-8\”?>” +
“<ns0:ObjectIdentifierMappingByElementsQuery_sync xmlns:ns0=\”http://sap.com/xi/SAPGlobal20/Global\”>” +
InputStream inputStream = new ByteArrayInputStream(SOAPxml.getBytes());
XmlPayload payload = LookupService.getXmlPayload(inputStream);
Payload SOAPOutPayload = null;
SOAPOutPayload = accessor.call(payload);
InputStream inp = SOAPOutPayload.getContent();
DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = factory.newDocumentBuilder();
Document document = builder.parse(inp);
NodeList list = document.getElementsByTagName(“LocalObjectID“);
Node node = list.item(0);
if (node != null)
node = node.getFirstChild();
if (node != null)
CustomerID = node.getNodeValue();
catch (Exception e)
trace.addWarning(“ERROR in UDF ” + e);
The figure below shows a successful execution of this User-defined mapping function, where “C4C_CustomerID_Lookup” is the name of the UDF. The input and output are similar to the SOAPUI call that has been displayed earlier in this blog.
Figure: ‘Display queues’ in SAP PRO’s shows the execution of the Webservice lookup
As visible in the code above, the RemoteIdentifierType has been set as 918, and the LocalIdentifierType as 888. With these SAP codes it is possible to query the ‘Customer’ object in SAP Hybris Cloud for Service. It is also possible to find the internal and external IDs of other Hybris objects. These codes can be found by using the oData console in SAP Hybris Cloud for Service itself, under Entity Set “ExternalIDMappingExternalIDSchemeCodeCollection”. To be precise, this oData service with operation ‘Get’:
In this blog, I have highlighted how to create service tickets in SAP’s Hybris Cloud for Service via SAP Process Orchestration based on input from external systems that only provide non-SAP Hybris Cloud for Service (external) ID ranges. Key in solving this challenge is to make use of Hybris’ extensive set of web services, creating a SOAP lookup UDF in the SAP middleware and leveraging the master data interfaces between SAP ECC and SAP Hybris Cloud for Service.
Hopefully, this blog makes life in integration with SAP’s cloud products a bit easier and helps you come up with more interesting and innovative solutions and approaches!
In case of questions, please don’t hesitate to leave a comment!
Written by: Ronan Mol
Contributions: Kas Timsi, Rob Pennings and Björn Stevens