Best Practice for processing inputs from (Fiori) Frontend in the Backend

[former_member509411]

Usually a business application (built in Fiori) provides the SAP user either

• a view at data from the SAP system, but WITHOUT real input options (creating new data in the backend tables). SAP calls these apps factsheet/analytical app.
• a tool to handle a business process, e.g. to create a sales order, WITH input (and thus creating, changing, updating data in the backend tables). SAP calls these apps transactional apps.

So given we build a transactional app, we need to receive and process inputs from the Fiori frontend to do something with it (business process) and e.g. save the result in the backend.

I've read about different approaches so far, including:

• ODATA and building services (that can process and check the inputs) in NW Gateway Service Builder
• ODATA and BOPF (Business Objects Processing Framework), like above approach on steroids
• Other?

Primary question:

A.) What is the most recommended approach to receive and process input from the frontend, and which other approaches do exist?

Further questions:

B.) With CDS-views (Core Data Service) we have a way of providing standardized ways to read from the database/backend and create a ODATA-services. Can these auto-generated services be extended with write/update/delete capabilities, that we can use in Fiori to not only show data, but write (POST/UPDATE)?

C.) Do above mentioned (and not mentioned) approaches differ, if we talk about S/4HANA On-Premise vs. S/4HANA Cloud deployment?

[Jorge_Baltazar · Accepted solution]

Hi Jan,

I would list 4 approaches to build custom Fiori apps listed in order following the recommended approaches for S/4HANA:

1. New ABAP Programming Model + BOPF: With this approach you would build a CDS view with annotations including BOPF capabilities and Draft persistence. "Extensions" would only be available on the CDS layer as you would have complete control on the ABAP code defined in the BOPF framework and this approach would be useful to create a fully transactional app (CRUD)

2. Referenced Data Source: With this approach you would build a CDS view with annotations which would later be consumed by the Gateway Service Builder (SEGW). Once in SEGW you can redefine your Data Provider Classes to meet your requirements, extensions would be available for both CDS and OData service and you can use this approach to create a transactional app but you may find some restrictions like the one found in this blog: How to handle navigation between CDS based entities and non-CDS based entities

3. New ABAP Programming Model: With this approach you would only define a CDS view and add the @OData.publish=true annotation to automatically generate an OData service, extensions would only be available for the CDS views as all the apps built with this approach will use the same standard methods which do not offer extension options and you would mostly use this approach for read enabled Fiori apps like custom reports and analytics.

4. Classical Gateway Service Development: In this approach you would create your own classes and map them to your entities in transaction SEGW. Though you can build a transactional app with this approach you will not benefit from the innovations in S/4HANA nor tools like WebIDE as this tool reduces the UI development effort by reading the annotations in the CDS. Yes, you can manually set annotations for your OData service but your development efforts will rise and no business benefits will come from a large development effort.

For your last questions, yes, development approaches between S/4HANA On-Premise and S/4HANA Cloud do differ as in S/4HANA Cloud you can only work with whitelisted API's released by SAP. For example, in S/4HANA Cloud you will not have access to transaction SEGW nor ADT to build your custom CDS views and you would only have access to the Create Custom CDS view app.

Some well documented extension cases can be found in the Extensibility Explorer which can help you understand the development approaches in S/4HANA Cloud.

[former_member509411 · Accepted solution]

Thank you for your elaborate answer!