Multi- & Full-Stack SAP UI5 & OData application development with storm
The new programming language storm allows to define applications and services. In the context of SAP, this is especially about OData services and UI5 apps. In this article, the basic concepts of the programming language are demonstrated using an example application.
The goal of the programming language developed by frequi is to generate source code of applications. The quality of the implementation should be as good as a good UI5 XML, JavaScript or OData expert would do.
1. Business Case
We will demonstrate this using the example of the fictitious company "Bavarian Robos", which is based in Germany, Bavaria, and builds robots for various purposes. During the development of robots, it is necessary to comply with a large number of rules and regulations during production. Among other things it is a regulation to classify all documents created for the product development. There is also a responsible business partner for a document. These documents are required and provided internally and to a large extent externally by development partners who are not on site.
We technically assume that the "Bavarian Robos" store all relevant data, such as product information or business partners, in their SAP ERP system ES4. At the same time, the company is implementing its strategy of developing fast and flexible applications accessed by external partners on the SAP Cloud Platform.
2. Implementation
We will start by implementing the OData service on the SAP Cloud Platform. Based on the requirements, we map all relevant data for a product information as a simple entity.
Step 1: New OData service
We start with the definition of the ProductInfo and the associated OData service:
This is already all that is required to create an OData service including a database persistence layer for the SAP Cloud Platform.
Let's have a look at what was generated here. Since we specified the SAP Cloud Platform (or the system type SapCloudNeo), we automatically generate Java code for all necessary artifacts. For example the JPA Entity:
Or here is an expert from the source code for the Data service for reading the Data Entity Set ProductInfos
And this of course embedded in a complete project, here exemplarily some generated packages and files unfolded:
But actually, we don't want to scare you off with too many files and details, the crucial aspect of development with storm is that you always keep the overview and don't have to know all details of the implementation.
So, please don't forget, from the nearly 18 lines of our storm file already many more necessary files have been created.
The project can now be deployed directly in the development environment Eclipse on the local TomEE 7 server and therefore the OData service is immediately available:
And this of course embedded in a complete project, here exemplarily some generated packages and files unfolded:
Step 2: Create a simple UI5 app
The strength of storm is that we can now describe the frontend in the same language as the backend services. That means we now define in the same file a first app, which consists of a launchpad, with which we can create new product information and search for this information:
These 12 lines are already sufficient to create a complete UI5 project when saving the storm file, which includes multiple UI5 views and creates all default CRUD UI's (Create, Read, Update, Delete).
When we deploy this, we have already created the following UI's:
- An introductory dashboard to our app:
- A UI for creating our ProductInfo entity. Again, just to remind you, we have only defined the following:
This is the only way to create a UI5 view that already implements many small details by default and intelligent assumptions:
-
a back button back to the dashboard
-
a wider input area
-
all necessary navigation routing configurations
-
standard buttons, because storm knows that this is an input UI for the entity ProductInfo.
- and a list UI with which we can search for product information:
Step 3: UI5 Extension - Documents
Of course, we have usually not yet implemented optimal interfaces that meet the business requirements with the current standard generated UI's. The idea of storm is that we specify our requirements more precisely step by step. Thereby storm maps the elements and UX patterns necessary for UI requirements in a template library. Thus we serve typical application requirements directly from the language syntax and extension UX patterns.
An example: When designing our programming language, we decided that, in addition to an entity (such as ProductInfo), another structuring element, the document (PDF, Word document, image, ...), requires its own syntactical mapping. This way, requirements are defined and implemented optimally and quickly.
In this case we have no specific metadata on the document itself. You are welcome to define additional fields analogous to the entities in order to use them in the persistence layer. We use our self-defined document type to attach up to 20 documents of this type as a reference to our ProductInfo entity:
We then add the storm Documents UX pattern to the UI, which generates all necessary UI elements, such as UI5 Control UploadCollection:
The result is a complete UI with which we can upload documents:
Since we have specified the SAP Cloud as the target platform, the documents are stored in an SAP Cloud Platform Document Service (CMIS) subfolder of /documents/productsinfos with the ID of the ProductInfo entity. All documents are placed in this folder, which receives the contents of the Name field from the ProductInfo as folder name. This way you already have a complete, well-ordered document storage in the SAP Cloud by declarative definition in storm.
Schritt 4: External OData services
In the business case, we defined that the ProductInfo should still be linked to the products and business partners from the ERP system. This means that we will now define the ERP system and reference the necessary OData Entity Sets that we need from there:
The generate ServiceGroup statement extracts all the information required by the specified OData service into a separate storm file that is copied into our project, so that we have immediate and very flexible access to all functions and Entity Sets in the OData services.
We add two fields to our entity definition, on the one hand we want to link a set of products to this entity, on the other hand a responsible business partner should be optionally specified:
Only these 5 lines were necessary, and we have now, when we generate the standard UI, already generated a fully functional UI5 app that allows to integrate other OData services:
The different visualization of the two lists can be flexibly derived from all values of the entity at the end of the field definition.
Step 5: Make UI more responsive, prettier and dynamic
Of course, the current UI is not yet breathtakingly beautiful, structured, flexible and adaptive.
Therefore we will build a tab-based UI with structured input areas from the current simple UI where all fields are underneath each other:
We define several areas, so-called Areas. In the UX Pattern Tabs, these are implemented as individual tabs. Within the form UX pattern, area means that we group the fields together.
The responsiveness is ensured by self-defined response patterns pattern6, pattern4, which have been implemented at different places above. You can also define and use these yourself:
This allows you to create any number of custom names and definitions for responsive patterns that work well for you.
Et voila, we thus have a very well structured UI with different tabs that you can immediately use productively:
As already shown, this is also responsive, here in the example of the display in a narrow window or smartphone:
Step 6: Integrate search
We have already defined a list UI that currently displays the list of product information. Now we turn it into a very powerful search interface including full text search and flexible filters and search tabs with just a few lines of code.
Here we use the storm SearchList UX Pattern, which allows to define the names of the fields to be used for the result list (@UI.ListElement or no further specifications) and their functions via annotations:
-
@UI.SearchTabFilter for automatic search tabs
-
@UI.SearchTerm for fields to be used in the full text search
-
@UI.SearchFilter, if we want to provide an input filter here
Here is the necessary definition of the Search UI:
This is used to create a professional and, in terms of business requirements, complete user interface including all necessary backend enhancements:
As soon as we click on Show Filter Bar, the filters defined above will also be displayed:
Each filter element UI is rendered as optimally as possible according to the information available to us. This is what the type filter looks like, for example:
In particular we would like to point out that due to the storm search definitions we have also implemented a full text search. This searches over several fields of the entity, here even automatically, in the file names of the uploaded documents:
3. Multi Stack: Migration from SAP Cloud to SAP NetWeaver
In addition to the local TomEE 7 server, the application we generated also runs on the SAP Cloud Platform and therefore uses the APIs required there for user/group management. SAP Cloud Document Service (CMIS) is used as document storage and further technical details like the Eclipse projects are specific only for this platform.
In its definition, storm abstracts precisely from these implementation specifics via the SystemType.
Previously we had created the SAP Cloud System like this:
If we now want to move from the SAP Cloud Platform to SAP NetWeaver Portal, you need to enter the following:
That settles everything! The instructions for generating apps and service groups, which all reference the system alias, are now informed that we now want to implement for another platform.
Your storm UI5 app has thus converted all document-related API's to SAP NetWeaver KM, which means that we now also store the documents there. The UME is now also used, and EAR projects are now also generated so that they can be immediately deployed on the NetWeaver stack.
So you as a user of storm have a very elegant and fast way to efficiently run OData and UI5 JavaScript development on all platforms supported by storm.
4. Summary
We have presented here some aspects of the storm programming language developed by frequi, showing in particular how efficiently you can create high-quality SAP Cloud and SAP NetWeaver UI5 applications with connection to ERP systems. Because the language storm in the current version supports especially the typical application scenarios such as dashboard, CRUD input UI's, and search in the best possible way, you can implement your requirements in these scenarios very quickly.
If we look at one of the lines in the generation log:
88 Lines created 107 files with 19976 Lines
it becomes clear that in the example -1- line storm code generated an average of -266- lines of real Java and JavaScript source code. This is what we call the storm efficiency factor.
But the language storm has much more to offer, like dynamic forms (show/hide certain UI areas based on application data or authorizations), custom actions and exits, flexible validations of the UI's field- or model-related, complete support of complex ACL authorizations, which are also implemented for data and documents at the same time, and of course the support of performant authorization-dependent searches for the entities created by us and much more.
Benefit from the fact that we have already efficiently implemented many standardUX patterns and you can only use them or add your own frontend and server code at the extension points prepared by us. And if you want, take the generated professional code and do whatever you want with it! A top UI5 app, once paid with us with a fair price, which is based on the complexity of the app.
Give yourself time!