SAP has provided tons of standard Fiori Apps in S/4HANA. They have also provided an app called Create Incident. But every client’s requirement is different and one size does not fit all. As the standard app did not cater our needs, we designed our own custom Fiori App for Change Request and Transport Approval in SOLMAN which uses ChaRM. Do not say, you are hearing ChaRM for the first time.
ChaRM is a tool delivered with SOLMAN which is used for management of Change Request. The abbreviation of ChaRM is derived from Change Request Management. You might also sometimes hear ChaRM+. ChaRM is very useful in the software delivery cycle from business design to technical design to testing to final push of the transports to the production system. ChaRM tracks all the change requests and transport requests in the change management system in the SAP Business Model.
In addition, ChaRM is workflow based approval system. ChaRM helps and ensures that all the dependent transports are moved together and in correct sequence. It overcomes the loop holes of traditional vanilla Transport Management System where dependent transports can miss and also the sequence of import of transports to the production can go wrong.
Well, well. I did not want to talk about ChaRM in this article. My focus is on a custom Fiori App which we developed for Change Request approval in SOLMAN.
I believe you if you did not hear about ChaRM. But you would have definitely heard about SOLMAN. ? OK.. I am not underestimating your knowledge. We all know, SOLMAN is used widely across companies to manage transport requests within SAP systems. But many ABAPer think SOLMAN is only used for saving Functional Specifications and Technical Specification.
On a serious note, a major scoop while transporting request to production is approval. This is done through SOLMAN which is a WebUI through which users log in and transport/approve request. Yes, the approver has to log in everytime to take any action. Wouldn’t an App be very handy in this case? Open the app and hit approve, reject button.
When I received a request for an App for change request management, I jumped off my seat and grabbed the opportunity. I drilled down the internet and even searched the SAP Fiori library multiple times. SAP has the Create Incident App. But it did not meet our need completely. And yes, no one in the internet space has developed it yet. My team and I would be the first one to develop the enhanced app for Change Request Management in SOLMAN and document it. Should we patent it?
We shouldn’t say this, but if you look at the link which the change request approver receives, which is made through CRM, it is not very user friendly and cumbersome to use too. We are in 2020. Give an App and the user would be happy. You never know, your change requests might start getting approved in seconds, without any follow ups.
Thus to simplify the process, let us build a custom Fiori App from scratch.
Our SOLMAN is CRM system and not ECC, thus all the OData Service has to be developed in CRM system.
As already discussed, the process is cumbersome and lengthy. Instead of doing hard work, we shall do smart work! Let us get only the approval process into the App which can be done anytime, anywhere from phone.
Remember the 5 basic principles of Fiori App? Role-based, Simple, Delightful, Coherent and Responsive.
This is how SOLMAN looks with the different stages of request creation/ request movement and request approval.
Our goal is to focus at UAT successfully tested status, so here comes the Logic:
- Once the request reaches QA and tested, it should then be approved by Process Owner before moving it to production system.
- Here comes the point, where we can dive in. We shall capture all request at this stage assigned to the partner function of the Process Owner.
- Our SOLMAN system is a CRM system. Get all request with status ‘UAT successfully tested’ and send it to the front end system via OData Service.
System Glance:
This system is an embedded system, means the gateway server and the back end server is the same. Thus the user who is logged in on front end will be the back end user too.
Let’s start with Part 1 of the development:
Create FM with only table parameter as ET_REQ – which contains the number of requests to be approved based on a date.(I have taken past 10 days).
Pseudo Code Glimpse:
In FM, I have submitted a report with ChaRM id process type , date , Status of request and partner function and retrieved all the data.
Process type: each object in CRM is differentiated by process type, like document type in ECC.
Status: When a particular object is at one stage, it is assigned a status through status profile.
Partner Function: as it is an embedded system, through sy-uname, we fetch the partner function assigned to a user (approver).
The report worked as life saver to me as it provided all the necessary data at one go. In CRM data is stored at BOL layer. Thanks to my colleague Vijay from Future group who helped me find the report.
Assign lt_req_data to et_req after processing as per requirement.
In , we have received all the request which is to be shown on the screen of approver and with the ID of the request, we can process as per our need to show the necessary data about the ChaRM Id via FM CRM_ORDER_READ.
Convert this FM into OData service.
This will also refresh OData Creation.:)
1) Go To SEGW and create an entity GetCharmId: Import it from RFC
Save and generate.
2) In DPC_EXT class, redefine method : getcharmidset_get_entityset.
Hope we all know what redefinition is!
Logic: Call the Function module in which we have already implemented the code, sy-uname wise, it will fetch the list of requests to be approved. So simple!
Great, now we can fetch the request at the front end. Hope you know how to consume OData in WebIDE. Else ask you front-end developer to create the below screen and consume your OData Service.
If you want to learn SAPUI5 yourself. Then start from below.
We have kept just an Approve button. After all SAP says to keep the Fiori App as Simple as possible.
Pseudo Logic for the 2nd task:
Once user clicks the approve button, the ChaRM Id will get approved and in the back end, its status should be changed.
Let’s create an FM to meet this requirement. This FM will have import parameters, ChaRM Id, Decision and export parameter as Message (to be displayed on the Fiori Screen).
Pseudo Logic in CRM:
CRM technical people will easily grasp this but normal ABAPers need not worry, as we have just used CRM specific FMs. FM and ABAP remains the same whether you work in CRM, SAP-ISU or APO.
Let’s break our logic into parts:
(i) In CRM, any document is considered as Object id as it is One Order Framework
So, convert this ChaRM Id as input to Object id of CRM and fetch it’s GUID(16 digit identifier of object id)
(ii) Read the status of the Object id from FM CRM_ORDER_READ
Read the status and update new (next status) by CRM_ORDER_MAINTAIN and CRM_ORDER_SAVE.
If no error, update status:
Thus, when status is approved, we pass on the message, request is approved.
(iii) Create corresponding OData Service for the above custom FM.
In the same project created earlier, create one more entity.
Now, we have to implement its get_entity method.
Pseudo Logic:
We will read the input from front end i.e. object id and decision and pass it in FM. Then we will fetch the message from FM and pass it to front end.
reading parameters:
Calling FM and passing output to front end.
Once Approver (Process/Product Owner) approves the request, (s)he gets the following message:
This is our custom SAP Fiori App which would replace the SOLMAN approval process. This app gives a better user experience and the Approvers do not might clicking it more often than needed (just like any other gaming apps). After all, work necessarily need not be boring. For a change, it can be delightful as well.
