Skip to Content

Create oData service for Fiori app

Hello,

My question is about best practices when you create a oData service in order to build a fiori app based on this service.

I know that the normal way would be to create a oData independently to the app that use the service, but when I look at standard fiori app, I can see that they build one oData service for one Fiori app. The oData service is not build to be reuse by another application.

For example, for the sales order, the header look like this :

order number

customer number

customer name

customer address

Ship to number

ship to name

Ship to address

total amount

currency

As you can see, custom and ship to name and address are in the entity header, although there should be only the customer and ship to number and an association to an entity customer with the name and address :

Header

order number

customer number

Ship to number

total amount

currency

Customer

customer number

customer name

customer address

the second model looks better and is more like a database model, but the SAPUI5 application is easier to develop with the first model. Also, with the second model, we would have to implement more methods (basic relation) in order to improve performance.

I started my development with the first option (the oData look like what I want to display in the screen instead of a database model), but I would like to know if it is a good practice.

thank you

Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

2 Answers

  • Best Answer
    Jun 30, 2015 at 04:07 AM

    It is important to understand that OData service is NOT designed for reuse. If you start defining a OData model from reusing perspective, then it will be become a very huge model and a complex service.

    When you build a OData mode,

    -> You define Navigations, only if the UI app requires it.

    -> You have properties which are just required for the UI

    So the basic idea is Outside-In design. That is

    Look at the UI -> build the OData model ->Implement that model

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member Louis-Arnaud BOUQUIN

      If you follow the principle of "one service per app", it is up to you whether you want to design the UI first or ODATA model first.

      A typical sequence of design and development of Fiori app is -

      -> Using SAP Fiori prototyping kit, create mock up of the UI first.


      -> Based on the UI mockup, generate an EDMX file as a dummy for the ODATA model and use it for Fiori app UI development using Web IDE.


      -> Parallaly another developer can develop the ODATA at the backend.


      -> Replace the EDMX file by the actual ODATA model in the Fiori app

  • Jun 29, 2015 at 12:43 PM

    You can have a look here.

    SAPUI5 – Best practises- Do’s & don’t do’s

    FIORI is a UI5 application.So , UI5 best practices are also applicable hence sharing the doc.

    If there is no navigation from once screen to another screen(and if you are not expecting it in future ) , there is no point in keeping them as separate entity and consume them using odata association . Let it be a win-win design in terms of flexibility and performance .

    Cheers

    Add comment
    10|10000 characters needed characters exceeded

    • Thanks Sreehari,

      you said : "If there is no navigation from once screen to another screen(and if you are not expecting it in future ) "

      But :

      1. Even if there is no navigation from one screen to another, we could expect to have a oData with multiple entities and select from all theses entities to build our screen. in the example that I gave, select header entity, customer entity for customer and customer entity for ship to.

      2. I can't expect what will happen in the future, that's why it may be more interesting to have a oData model which is more flexible.

      As I don't have a lot of experience in SAPUI5/oData, I can't have the necessary distance to know what is the best practice.