Hi all,
Starting with SAP Fiori Elements can be really overwhelming, just by the huge amount of tutorials, blog posts or other sources available for this technology.
Just as flexible the possibilities within Fiori are, as flexible and maybe confusing is the way of getting your SAP Fiori Elements app up and running. Topics (or Buzzwords, it's up to you) like CDS, SEGW, Code-based Implementation or OData contribute to the bright variety of SAP Fiori Elements.
In this blog post, I’ll try to discuss how to decide - based on your requirements- an suitable SAP Fiori Elements approach for your desired app. This also includes an high-level overview of possibilities on how to start with SAP Fiori Elements.
For now, I want to highlight 3 available Best Practises, which are discussed in detail.
Using a ABAP CDS View (ABAP Core Data Services View) and expose it as an OData Service is the fastest approach in this blog post. CDS is best described by the idea of developing business logic in terms of selecting the right data source and its associations. Some smaller transformation tasks (e.g. concatenation of values or adding new fields based on existing ones) and the addition of the Object Model is also possible. For generating a good-looking SAP Fiori Elements app, the logic needs to be aggregated with UI annotations.
By adding
the ABAP CDS View is automatically exposed as an OData Service, which in turn can be used in the Web IDE or the Business Application Studio through the Wizard.
It is getting more interesting if your requirements contain CUD (Create, Update, Delete) operations. The BOPF Framework can be used to accomplish straight-forward CUD.
If you need to enrich one of those operations with custom logic (e.g. instead of just updating an entry, the original entry needs to be cloned, its timestamp updated and a specific deprecated flag set), the plain CDS View approach might not be the best choice, as you will see in the following sections.
It is also possible to not rely on a ABAP CDS View, but controlling and building up everything from scratch. Using the SAP Gateway Service Builder (transaction SEGW) we can decide on what information source we are interested in and how they relate to optional associations.
This is the most time-consuming approach since the relation between multiple entities needs to be mapped. Additionally (and even more time-consuming if not well practiced), after exposing the project as an OData Service and consuming it, all the UI annotations need to be added manually (there are graphical tools integrated in the Web IDE, but you can use the plain XML editor as well).
Nevertheless, it is the best approach when it comes to have full control on the most-granular level possible (e.g. for provide value help, define read-only fields, define non-updateable fields). Also, the CUD operations (and even more, like custom actions, which are not part of this blog post) are completely based on ABAP methods, which can be implemented on your own, allowing you to define the complete behavior.
Having the best of both worlds would be awesome, right? Designing the data model, associations and the UI fast and easy with a ABAP CDS View but still be able to fully control the logic behind creating, updating and deleting an entity.
Guess what, this is the third and last discussed approach of this blog post. It is possible to start a project in the SAP Gateway Client Service Builder, as mentioned in the second approach, but instead of providing static DDIC objects as baseline for your data model, you can reference a ABAP CDS View! Instead of importing an ABAP Dictionary Structure, you can reference a data source and use your created ABAP CDS View.
Based on the degree of effort you put into modelling the ABAP CDS View, you do not have to take care of
Up until now it sounds like exposing the ABAP CDS View directly as an OData Service, as described in the first approach.
The benefit comes with the second part: Since we referenced the ABAP CDS View in a Gateway project, we automatically receive the common setup (classes and methods) for such a "SEGW" project. This includes the required methods for the CUD operations (and you are automatically provided with those methods for each entity within your ABAP CDS View!).
It would be very unfair for the other two options if the third one wouldn't have a downsite, so here you are:
Even though we mark the ABAP CDS View as a reference and not a static DDIC object, there are some limitations in terms of quick adaptability: Changes in the fundamental data model (like adding a value help through a new association) are not updated automatically. Re-generating the runtime artifacts doesn't do the trick either.
The workaround I apply is to a) think about the needed data model thoroughly before starting to put the ABAP CDS View into the Gateway project and b) if there are major data model changes, create a new project, reference the ABAP CDS View again and delete the original project (including its generated classes in order to keep the workspace clean!). The biggest effort in b) is to redefine the CUD operations and paste the custom code into the new project.
Anyways, changes in UI annotations or field-based changes are automatically applied to the SAP Fiori Elements app, just with a simple refresh of the webpage!
Quick Tipp:
Don't forget to annotate your referenced ABAP CDS View with
in order to get the required buttons on the UI without manual effort. The functionality is automatically routed to your defined methods for those operations.
The following table depicts the most important advantages and disadvantages:
To create a more sophisticated advice, the following figure clarifies the requirements, mapped to action recommendations:
I hope you gained a better understanding or insights of different use-cases based on customer-specific requirements when it comes to SAP Fiori Elements.
There is a vast variety of ways to publish a SAP Fiori Elements app to your customer. As the requirements are probably rather complex than straight-forward, I personally am in favor of the last approach, using the ABAP CDS View as a reference and building the OData Service at top of it, using lots of features out-of-the-box. It is a very comfortable trade-off between the required flexibility to make the customer happy and the fast development cycles which come with ABAP CDS Views. Additionally, it is great to not have to care about the Frontend development at all, since a) getting the UI without writing it on your own accelerates the development massively and b) the generated UI is consistent with all the SAP Design Guidelines - everything is at exactly the place, it belongs to.
In the very beginning, SAP Fiori Elements can be really hard and frustrating but the more you cope with the whole topic, the more it will unveil its great potential to you - and we all are still learning, day to day!
Thanks, Peter
Starting with SAP Fiori Elements can be really overwhelming, just by the huge amount of tutorials, blog posts or other sources available for this technology.
Just as flexible the possibilities within Fiori are, as flexible and maybe confusing is the way of getting your SAP Fiori Elements app up and running. Topics (or Buzzwords, it's up to you) like CDS, SEGW, Code-based Implementation or OData contribute to the bright variety of SAP Fiori Elements.
In this blog post, I’ll try to discuss how to decide - based on your requirements- an suitable SAP Fiori Elements approach for your desired app. This also includes an high-level overview of possibilities on how to start with SAP Fiori Elements.
For now, I want to highlight 3 available Best Practises, which are discussed in detail.
Please be aware that the provided guidelines are applicable for HANA editions below 1909. As with 1909 the new ABAP RESTful Application Programming Model (RAP) was introduced, it is highly recommendable to have a closer look at this new, powerful approach as well!
1. Plain CDS View Approach
Using a ABAP CDS View (ABAP Core Data Services View) and expose it as an OData Service is the fastest approach in this blog post. CDS is best described by the idea of developing business logic in terms of selecting the right data source and its associations. Some smaller transformation tasks (e.g. concatenation of values or adding new fields based on existing ones) and the addition of the Object Model is also possible. For generating a good-looking SAP Fiori Elements app, the logic needs to be aggregated with UI annotations.
By adding
@OData.publish: truethe ABAP CDS View is automatically exposed as an OData Service, which in turn can be used in the Web IDE or the Business Application Studio through the Wizard.
It is getting more interesting if your requirements contain CUD (Create, Update, Delete) operations. The BOPF Framework can be used to accomplish straight-forward CUD.
If you need to enrich one of those operations with custom logic (e.g. instead of just updating an entry, the original entry needs to be cloned, its timestamp updated and a specific deprecated flag set), the plain CDS View approach might not be the best choice, as you will see in the following sections.
2. Plain Code-based Approach
It is also possible to not rely on a ABAP CDS View, but controlling and building up everything from scratch. Using the SAP Gateway Service Builder (transaction SEGW) we can decide on what information source we are interested in and how they relate to optional associations.
This is the most time-consuming approach since the relation between multiple entities needs to be mapped. Additionally (and even more time-consuming if not well practiced), after exposing the project as an OData Service and consuming it, all the UI annotations need to be added manually (there are graphical tools integrated in the Web IDE, but you can use the plain XML editor as well).
Nevertheless, it is the best approach when it comes to have full control on the most-granular level possible (e.g. for provide value help, define read-only fields, define non-updateable fields). Also, the CUD operations (and even more, like custom actions, which are not part of this blog post) are completely based on ABAP methods, which can be implemented on your own, allowing you to define the complete behavior.
3. Code-based with CDS View Reference Approach
Having the best of both worlds would be awesome, right? Designing the data model, associations and the UI fast and easy with a ABAP CDS View but still be able to fully control the logic behind creating, updating and deleting an entity.
Guess what, this is the third and last discussed approach of this blog post. It is possible to start a project in the SAP Gateway Client Service Builder, as mentioned in the second approach, but instead of providing static DDIC objects as baseline for your data model, you can reference a ABAP CDS View! Instead of importing an ABAP Dictionary Structure, you can reference a data source and use your created ABAP CDS View.
Based on the degree of effort you put into modelling the ABAP CDS View, you do not have to take care of
- defining a data structure / data model
- modelling their associations (plus navigation properties)
- navigation at all
- read the whole dataset (GET_ENTITYSET)
- read a specific data (GET_ENTITY)
Up until now it sounds like exposing the ABAP CDS View directly as an OData Service, as described in the first approach.
The benefit comes with the second part: Since we referenced the ABAP CDS View in a Gateway project, we automatically receive the common setup (classes and methods) for such a "SEGW" project. This includes the required methods for the CUD operations (and you are automatically provided with those methods for each entity within your ABAP CDS View!).
It would be very unfair for the other two options if the third one wouldn't have a downsite, so here you are:
Even though we mark the ABAP CDS View as a reference and not a static DDIC object, there are some limitations in terms of quick adaptability: Changes in the fundamental data model (like adding a value help through a new association) are not updated automatically. Re-generating the runtime artifacts doesn't do the trick either.
The workaround I apply is to a) think about the needed data model thoroughly before starting to put the ABAP CDS View into the Gateway project and b) if there are major data model changes, create a new project, reference the ABAP CDS View again and delete the original project (including its generated classes in order to keep the workspace clean!). The biggest effort in b) is to redefine the CUD operations and paste the custom code into the new project.
Anyways, changes in UI annotations or field-based changes are automatically applied to the SAP Fiori Elements app, just with a simple refresh of the webpage!
Quick Tipp:
Don't forget to annotate your referenced ABAP CDS View with
@ObjectModel.createEnabled: true
@ObjectModel.updateEnabled: true
@ObjectModel.deleteEnabled: truein order to get the required buttons on the UI without manual effort. The functionality is automatically routed to your defined methods for those operations.
Summary
The following table depicts the most important advantages and disadvantages:
| Plain CDS | Plain Code-based | Code-based with CDS Reference | |||
|---|---|---|---|---|---|
| ? | ? | ? | ? | ? | ? |
| Very rapid and easy development | Very limited in controlling the behavior in CUD operations through BOPF | Full control on a very granular level | UI needs to be designed afterwards in the Web IDE | Still rapid and rather easy development | Changes in fundamental data model are not updated in the reference and hence need a newly created project |
| UI designed by annotations | Full control of behavior in CUD operations | Full control of behavior in CUD operations | |||
| UI designed by annotations | |||||
To create a more sophisticated advice, the following figure clarifies the requirements, mapped to action recommendations:
Requirements and Recommendations
I hope you gained a better understanding or insights of different use-cases based on customer-specific requirements when it comes to SAP Fiori Elements.
Conclusion
There is a vast variety of ways to publish a SAP Fiori Elements app to your customer. As the requirements are probably rather complex than straight-forward, I personally am in favor of the last approach, using the ABAP CDS View as a reference and building the OData Service at top of it, using lots of features out-of-the-box. It is a very comfortable trade-off between the required flexibility to make the customer happy and the fast development cycles which come with ABAP CDS Views. Additionally, it is great to not have to care about the Frontend development at all, since a) getting the UI without writing it on your own accelerates the development massively and b) the generated UI is consistent with all the SAP Design Guidelines - everything is at exactly the place, it belongs to.
In the very beginning, SAP Fiori Elements can be really hard and frustrating but the more you cope with the whole topic, the more it will unveil its great potential to you - and we all are still learning, day to day!
Thanks, Peter
- SAP Managed Tags:
3 Comments
| User | Count |
|---|---|
| 12 | |
| 10 | |
| 9 | |
| 7 | |
| 7 | |
| 7 | |
| 6 | |
| 6 | |
| 5 | |
| 4 |
