Hi, my name is August Engkilde. I am a SAP Cloud and Fiori Consultant at Gavdi Labs, Denmark. I have participated in the Fiori Makers club since the early days and presented several solutions in this forum.
This case, developed by Gavdi Labs, that I am about to present for you in this blog and in the next SAP Fiori Makers call Thursday December 12th. 2019, is particularly interesting and relevant for several reasons.
The main reason is of course that many companies want to move away from the old Portal and to provide a more modern and better user experience to their end-users. This can be achieved by using SAP’s Fiori based application development framework in the public or private cloud. But some companies still have reservations about this approach or did not yet start for other reasons.
In this SAP Fiori Makers call we will share some of our experiences.
Why not just link the Web Dynpro apps to new Fiori tiles in the Launchpad?
In general, you could do many of the transitions to a Cloud Launchpad simply by creating a Cloud Launchpad, adding some tiles, and link each tile to the underlying Web Dynpro application that is behind most of the portal links. But what do you gain with this approach? Better UX? Definitely not! Now you have two different designs in your solution; the new Launchpad Fiori design and the Web Dynpro apps that you might have applied a “fake” Fiori skin to, and you are still not mobile friendly.
Did you have the option to actually rethink your processes or the digital experience of your employees? Probably not! You just spent a big effort on a transition that is short-sighted, temporary and confusing for the users of the system. This could lead to frustrations among your users because of an unambitious and outdated digital experience.
Now let’s move on to the case that I want to present for you.
A large medicinal company in Denmark had decided to close their Web Dynpro portal by the end of 2019. Together with the customer we held some workshops where we jointly figured out what to do.
The first takeaways showed a modern IT organization that listens to the end-users, lives by flexibility and actually develop the apps that the end-users want and that have a major business impact. At the same time the solution, in terms of look and feel, should fit into a future digital roadmap where SAP SuccessFactors and SAP S/4 HANA are potential business critical platforms. The ambition was that the apps should work in web browsers and be accessible from mobile devices as well.
Looking into the crystal ball, since Fiori 3 where not presented yet, we believed that SAP SuccessFactors and SAP S/4 HANA will probably grow closer together and perhaps one day be delivered in the same Fiori Launchpad. Consequently, we saw, and still see, the SAP Fiori/UI5 tool as the means to build a new set of applications that would be the best future choice for the customer.
The Employe group Launchpad example from the solution’s development setup:
Employee ”Time” group (tiles):
Employee ”My Data” group (tiles):
How did we build the new SAP HR Fiori Apps and prepare them for a possible upcoming SAP SuccessFactors transition? By using Apache Olingo.
As mentioned, some of the apps that we were building would potentially need to talk to another backend at a future date. In order to prepare for this possible digital transition, we decided to build-in a Java Apache Olingomiddle layer between the frontend apps and the SAP OData Gateway. Apache Olingo can convert any web service into the OData protocol that SAP’s Fiori/UI5 applications use as the preferred and development wise most effective protocol. In this way we can integrate the same applications to a SAP SuccessFactors backend if needed. To further move away business rules from being handled in the front-end code, we are as well using SAP Cloud Business rules in situations where needed.
The data service architecture through Apache Olingo:
Designing the solution
During the application design phase our main focus was to simplify screens, thus improving the user experiences as much as possible, while still keeping the focus on the end-users needs and how the apps worked in the Web Dynpro portal. A lot of effort had already been put into optimizing the long-running portal applications, and the learnings and optimization should be reused, and the investment safeguarded by building on the previous project and lifecycle experience.
The development project was setup as a Scrum project. Before each sprint we carefully designed prototypes of the applications selected as candidates for inclusion into the sprint. The prototypes where discussed and tested with end-users before the final development as well as during the development and thereby securing the quality and acceptance of the final apps. End-users where constantly involved as well through key expert end-user’s feedback sessions.
Screenshot from the absence and attendance registration app.
Theming of the solution
As you can see from the screenshots of the solution, the customer has strong brand design guidelines that we needed to follow and comply with. The challenging part was to balance the customer brand and design guidelines with the general Fiori design guidelines.
The first impression was that the design looked very white. But in fact, this design is experienced as very simple and nice to work with. From a future perspective, the design as well closer to the upcoming Fiori 3 design that is also simpler and more white/grey than previous Fiori designs.
We used the SAP Cloud Theme designer and some custom CSS stylings to get the design to work. The hardest part was to make the Launchpad Design and the application design work together. It is our experience that they sometimes overrule each other. So, we recommend you do thorough testing, and to expect some iterations before you get it right.
More application examples from the solution:
Staff plan:
Manager Approvals:
Mobile examples:
SAP Fiori Makers colleagues
If you have any additional questions regarding this project, learnings or technologies, just post a comment below. I’m looking forward getting in contact with you.
In addition, you can join the next SAP Fiori Makers call, Thursday December 12th, 2019, where we will present the case in more details, and can answer your questions directly.
SAP Fiori Makers is a great community open to all who are interested in learning how to create exciting and more user-friendly enterprise apps by using SAP Fiori. Interested? Just check out our SAP Fiori Makers page to register for the call series.
This case, developed by Gavdi Labs, that I am about to present for you in this blog and in the next SAP Fiori Makers call Thursday December 12th. 2019, is particularly interesting and relevant for several reasons.
The main reason is of course that many companies want to move away from the old Portal and to provide a more modern and better user experience to their end-users. This can be achieved by using SAP’s Fiori based application development framework in the public or private cloud. But some companies still have reservations about this approach or did not yet start for other reasons.
In this SAP Fiori Makers call we will share some of our experiences.
Why not just link the Web Dynpro apps to new Fiori tiles in the Launchpad?
In general, you could do many of the transitions to a Cloud Launchpad simply by creating a Cloud Launchpad, adding some tiles, and link each tile to the underlying Web Dynpro application that is behind most of the portal links. But what do you gain with this approach? Better UX? Definitely not! Now you have two different designs in your solution; the new Launchpad Fiori design and the Web Dynpro apps that you might have applied a “fake” Fiori skin to, and you are still not mobile friendly.
Did you have the option to actually rethink your processes or the digital experience of your employees? Probably not! You just spent a big effort on a transition that is short-sighted, temporary and confusing for the users of the system. This could lead to frustrations among your users because of an unambitious and outdated digital experience.
Now let’s move on to the case that I want to present for you.
A large medicinal company in Denmark had decided to close their Web Dynpro portal by the end of 2019. Together with the customer we held some workshops where we jointly figured out what to do.
The first takeaways showed a modern IT organization that listens to the end-users, lives by flexibility and actually develop the apps that the end-users want and that have a major business impact. At the same time the solution, in terms of look and feel, should fit into a future digital roadmap where SAP SuccessFactors and SAP S/4 HANA are potential business critical platforms. The ambition was that the apps should work in web browsers and be accessible from mobile devices as well.
Looking into the crystal ball, since Fiori 3 where not presented yet, we believed that SAP SuccessFactors and SAP S/4 HANA will probably grow closer together and perhaps one day be delivered in the same Fiori Launchpad. Consequently, we saw, and still see, the SAP Fiori/UI5 tool as the means to build a new set of applications that would be the best future choice for the customer.
The Employe group Launchpad example from the solution’s development setup:
Employee ”Time” group (tiles):
Employee ”My Data” group (tiles):
How did we build the new SAP HR Fiori Apps and prepare them for a possible upcoming SAP SuccessFactors transition? By using Apache Olingo.
As mentioned, some of the apps that we were building would potentially need to talk to another backend at a future date. In order to prepare for this possible digital transition, we decided to build-in a Java Apache Olingomiddle layer between the frontend apps and the SAP OData Gateway. Apache Olingo can convert any web service into the OData protocol that SAP’s Fiori/UI5 applications use as the preferred and development wise most effective protocol. In this way we can integrate the same applications to a SAP SuccessFactors backend if needed. To further move away business rules from being handled in the front-end code, we are as well using SAP Cloud Business rules in situations where needed.
The data service architecture through Apache Olingo:
Designing the solution
During the application design phase our main focus was to simplify screens, thus improving the user experiences as much as possible, while still keeping the focus on the end-users needs and how the apps worked in the Web Dynpro portal. A lot of effort had already been put into optimizing the long-running portal applications, and the learnings and optimization should be reused, and the investment safeguarded by building on the previous project and lifecycle experience.
The development project was setup as a Scrum project. Before each sprint we carefully designed prototypes of the applications selected as candidates for inclusion into the sprint. The prototypes where discussed and tested with end-users before the final development as well as during the development and thereby securing the quality and acceptance of the final apps. End-users where constantly involved as well through key expert end-user’s feedback sessions.
Screenshot from the absence and attendance registration app.
Theming of the solution
As you can see from the screenshots of the solution, the customer has strong brand design guidelines that we needed to follow and comply with. The challenging part was to balance the customer brand and design guidelines with the general Fiori design guidelines.
The first impression was that the design looked very white. But in fact, this design is experienced as very simple and nice to work with. From a future perspective, the design as well closer to the upcoming Fiori 3 design that is also simpler and more white/grey than previous Fiori designs.
We used the SAP Cloud Theme designer and some custom CSS stylings to get the design to work. The hardest part was to make the Launchpad Design and the application design work together. It is our experience that they sometimes overrule each other. So, we recommend you do thorough testing, and to expect some iterations before you get it right.
More application examples from the solution:
Staff plan:
Manager Approvals:
Mobile examples:
SAP Fiori Makers colleagues
If you have any additional questions regarding this project, learnings or technologies, just post a comment below. I’m looking forward getting in contact with you.
In addition, you can join the next SAP Fiori Makers call, Thursday December 12th, 2019, where we will present the case in more details, and can answer your questions directly.
SAP Fiori Makers is a great community open to all who are interested in learning how to create exciting and more user-friendly enterprise apps by using SAP Fiori. Interested? Just check out our SAP Fiori Makers page to register for the call series.
- SAP Managed Tags:
