Content
- Introduction
- Use Case: Replication of Service Tickets to JIRA
- Implementation
- Improvements
- Further Use Cases
Introduction
In almost every SAP C4C project, there are customer-specific adaptations that cannot be mapped in the standard, e.g. via additional fields or workflows. The solution for this is often PDI or SDK, i.e. the adaptation or extension of the source code within the Cloud for Customer solution. However, this also has disadvantages, such as a lack of know-how, poor maintainability or dependencies, since the source code is part of the solution. A much better solution are side-by-side extensions that implement the extensions using microservices. These have the advantage that they are developed on a different platform and are therefore loosely coupled. This improves maintainability because the systems can be operated and developed separately. In addition, the functionality of the microservices can also be used in other places without having to implement the service redundantly.
Use Case
This architecture can be illustrated by the following use case:
In the C4C Service module, functionality is needed for a C4C ticket to be replicated to Jira. The users would like to trigger this via a button. The solution for this is as follows:
The click on this button replicates the ticket to JIRA:
In addition to implementation via PDI, this requirement can also be realized via HTML Mashup, Mashup Web Service and SAP Cloud Platform Integration.
Implementation
SAP Cloud Platform Integration (Microservice)
We roll up the process from behind and start with the IFlow on the SAP CPI. The IFlow acts as a microservice that is called by C4C and contains the logic for Jira replication. This provides an HTTP endpoint that the C4C Mashup Web Service can call as an API and pass the data for Jira. In our example, the message contains the ticket number as well as the subject. Afterwards, the C4C message has to be parsed, because C4C sends the data as x-www-form-urlencoded (form) via web service, but the Jira Api cannot work with it. This is done using Groovy Script. After that, the body for the Jira API is compiled by dynamically inserting the C4C data. To create a Jira ticket, this body is sent as HTTP POST to the JIRA API.
HTTP Endpoint
Configure the endpoint address and make sure, that the endpoint is not CSRF protected.
Parse Message
The message from C4C comes in an URL Form encoded style like
ticketID=761&ticketDescription=Machine+is+brokenWe need to parse this to JSON (or XML) in order to access the properties. The following script retrieves the incoming message, parses it to json, access the c4c ticket fields and saves them as a property for later use in the message for the Jira API:
import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
def Message processData(Message message) {
//Body
def body = message.getBody(java.lang.String)
//def body = "ticketID=751&ticketDescription=Bereichsmeeting";
//Headers
def json = body.split('&').collectEntries{e->
e.split('=').collect{ URLDecoder.decode(it, "UTF-8") }
}
message.setProperty("ticketID", json.ticketID);
message.setProperty("ticketDescription", json.ticketDescription);
return message;
}Set Body
The retrieved information are then assembled to a JSON message:
{
"fields": {
"project": {
"key": "CLODEM"
},
"summary": "${property.ticketID} - ${property.ticketDescription}",
"description": "${in.body}",
"issuetype": {
"name": "Task"
}
}
}Call Jira API
The last step is to call the Jira API via Request Reply with HTTP. You need to configure the following parameters
- Address: Endpoint of your JIRA tenant API: https://<tenant>.atlassian.net/rest/api/latest/issue/
- Method: POST
- Authentication: BASIC (consider using OAuth for productive usage)
- Credential Name: Name of the Security Credential for JIRA Access stored in CPI
C4C Mashup Web Service
In order for the CPI Microservice to be invoked from C4C, a Mashup Web Service is required. This configures
- The endpoint: configured in the CPI HTTPS Inbound adapter
- The authentication: BASIC (S-user) or OAuth
- Service Protocol: XML
- HTTP Method: POST - to pass data to CPI
- Content Type: FORM
- Parameters that will be passed to CPI
The web service is addressed in the HTML mashup via the ID.
C4C HTML Mashup
An HTML mashup is required so that the logic can be called up via a button in the ticket interface. To extract the ticket data, a port binding must be present.
This mashup visualizes the button in HTML, extracts the ticket data from the mashup context and calls the previously created web service with the parameters via JavaScript.
Finally, the mashup is embedded in the UI and can be used by users.
Improvements
Authentication and Security
In the example the authentication between SAP C4C and SAP CPI is done via Basic Auth (S-User). For productive use, the use of OAuth is recommended.
Error / Success Handling
Neither the IFlow nor the code in the mashup has logic to handle success or error messages. In a productive deployment, success prompts should be generated to the user as well as logs or retries in case of errors.
Retrieving additional data
In the example, only the parameter data (ticket ID and description) is transferred to JIRA. If additional data is required, it can be retrieved in IFlow via the Request-Reply pattern using the OData API.
Event Notification
In the Jira use case, each ticket is manually transferred to JIRA via a button click. If this should be done automatically, e.g. directly at creation or at a special status, C4C Event Notifications can be used for triggering the CPI Microservices instead of the Mashup.
Kyma / Extension Factory
The state of the art solution for side by side extensions for SAP C4C is actually the Kyma Runtime on the SAP Cloud Platform, which is integrated via C4C Event Notifications. The microservice can also be developed with this. In addition, one benefits from additional features such as scalability, multi-cloud support, simplified authentication and API catalogs. However, since many SAP C4C customers do not have a Kyma infrastructure but already use SAP Cloud Platform Integration as middleware, this architecture is particularly interesting from an ROI point of view.
Further Use Cases
Change/create any objects in C4C
Another use case for this architecture is the modification or creation of C4C data objects that cannot be handled via workflow. For example, a C4C ticket status should be changed as soon as an offer referenced to the ticket has been sent.
Triggering SAP processes
Another common use case is the creation/modification of SAP ERP or S/4HANA objects to map end-to-end processes. For example, a CS order can be created in ERP from a C4C ticket via a mashup button.
Complex mailings
C4C workflows already reach their limits when it comes to personalizing emails with salutations or languages. This Blueprint can also be used to send emails via CPI that cannot be created dynamically with C4C Workflows.
I hope you can generate ideas from the blog post for implementing your own use case. Feel free to contact me with questions or feedback
- SAP Managed Tags:
4 Comments
