Create oData service for Fiori app

[Louis-Arnaud]

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

[kammaje_cis · Accepted solution]

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

[Louis-Arnaud · Accepted solution]

Thank you Krishna, that's exactly what I wanted to understand.

Do you have any link or documentation that confirm that design principle for building Fiori App ?

[kammaje_cis · Accepted solution]

Did you mean this?

http://experience.sap.com/fiori-design/

http://experience.sap.com/fiori-design/foundation/get-started/

[Former Member · Accepted solution]

HI Louis,

From the perspective of Fiori app, the general principle is "one app per use case".

From the perspective of ODATA services, the general principle is "one service per app".

In addition to the sites mentioned by Krishna, you can also refer to to the following site for understanding UX and Fiori design principles - https://designthinkingwithsap.com/ .

Thanks,

Indrajit

[Louis-Arnaud · Accepted solution]

I was thinking of oData design (the outside-in model you talked about). I didn't find any documentation from SAP that say clearly to use this model (the entity attributes are defined according to the screen).

[Former Member · Accepted solution]

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

[sreehari_vpillai]

You can have a look here.

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

[Louis-Arnaud]

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.