Skip to Content

Enable CRM Service Order application with edit functionality

In previous blog Create a CRM Service Order Fiori application within a couple of minutes I introduced the approach to generate a Fiori application which supports search and display on Service Order within just a few minutes.

In this blog, I will use one field in Service Order header level to demonstrate how to enable Service order change and save function.

After finished, the Fiori application has the following feature:

When you click edit button:


The fields in UI will become editable:


Change the posting date via Date picker controller and click save button, the change is successfully saved to backend:


Implementation detail

1. Most of CDS entities described in previous blog remain unchanged, only a small adaptation is needed, as highlighted below:


The reason is, since we need to support update scenario, we have to explicitly tell framework about this fact via annotation “transactionalProcessingDelegated“. Meanwhile, the automatically generated service provider class by annotation @OData.publish: true could not fulfill the update scenario – we have to create a new SEGW project via tcode SEGW manually, so we have to mark this flag as false to suppress the service automatically generation.

Finish the change and re-activate the consumption view.

2.  tcode SEGW, create a new SEGW project and choose Reference->Data Source from context menu, load the CDS view you change in previous step.


Once done, you should have the following hierarchy displayed. Generate Runtime Objects by clicking the button in toolbar.


3. Redefine three methods of automatically generated data provider class:



Source code could be found from my github.

You must be Logged on to comment or reply to a post.
    • Hi Saurabh,

      The source code is lost after SCN migration. I will upload it once I have time, perhaps this evening at my timezone or tomorrow, as I am on business trip now.

      Best regards,


  • Hi Jerry,

    nice blog, thank you!
    There is just one thing that is unclear to me about transactional Fiori Apps. How do you handle locking? According to the SAP Fiori Design Guidelines using a "Draft" mechanism is the method of choice to achieve this and as far as I know such a mechanism became part of the BOPF in Netweaver 7.51. Unfortunately, when dealing with legacy APIs (like "CRM_ORDER_MAINTAIN" in your case) we have no underlying BOPF Objects. You have any ideas how to handle locking or draft here since OData is stateless by it's nature?

    It's maybe a good idea to dive into BOPF code in NW 7.51 to get an idea how SAP thinks this can be solved. Nevertheless, I think it will be hard to achieve for legacy APIs anyway since they were simply not designed for such a purpose.



    • Hello Tobias,

      Thanks a lot for your comment, you are absolutely correct, currently this prototype didn't take lock concept into consideration at all. I know that the lock and draft handling is already available in S4/HANA but I am not working on that product so I cannot provide more useful input. Perhaps one day after I gained enough knowledge then I will share in the community.

      Best regards,


  • Hi Jerry,

    beside our CRM System I have actually a pretty new S4/HANA at hand and SAP took the easy way when it comes to transactional behaviour in Fiori Apps. Basically every transactional app (e.g. Business Partner Maintenance, Internal Order Management) is based on either SAP GUI for HTML or Web Dynpro emebedded in Fiori. I think SAP is aware that they do not have a good locking concept yet for SAPUI5 apps based on OData since the transaction behaviour of legacy APIs does not really fit that stateless REST approach. Nevertheless, as I mentioned in my last post SAP offers draft concepts for BOPF from NW 7.51 on and they also support draft handling in the SAP Fiori Elements (former SAPUI5 Smart Templates). But this actually requires the use of BOPF which only makes sense if you either design new BOs manually in BOPF or let them being created using the corresponding "ObjectModel" annotations in CDS.

    This leads me to another question. Why did you actually need the "ObjectModel" annotations in your consumption CDS? As far as I can see you have implemented the update/create methods in your OData service manually. Do you only need them to inform the SAPUI5 application that "Edit" mode is supported? Does the whole CDS entity become editable in the application by adding them?



  • Hi Jerry,

    I was going through your blog now, I am in need of such scenario as you have mentioned in blog for Service Order FIORI application, however, your github source code links appears broken. Can you please edit and provide correct link to the source code?