Multi- & full-stack SAP UI5 & OData application development with storm
storm is a new programming language, developed by frequi, which allows you to define applications and services. In the context of SAP, this applies in particular to OData Services and UI5 Apps. In this article, the basic concepts of the programming language are shown in a sample application.
1. Business Case
We will illustrate this with 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 variety of rules and regulations during production. Among other things, it is a requirement to classify all documents created for product development. There is also a responsible business partner for a document. These documents are required and provided internally and largely 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 your SAP ERP system ES4. At the same time, the company is implementing the strategy of developing fast, flexible applications that are accessed by external partners, on the SAP Cloud Platform.
We start with the implementation of the OData service on the SAP Cloud Platform. Based on the requirements, we map all relevant data to a product information as a simple entity.
2.1 Step 1: New OData Service
We first start with the definition of the ProductInfo and the corresponding OData service:
This is all it takes 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 have 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 a snippet from the source code of the OData service for reading the OData Entity Set ProductInfos:
In addition of course, all files are embedded in a complete project, with a few generated packages and files unfolded as examples in the screenshot:
However, we do not really want to scare you away with too many files and details, the crucial aspect of development with storm is that you always have an overview and do not need to know all the details of the implementation.
So, do not forget, the nearly 18 lines of our storm file have already produced many more required files.
The project is deployed directly to the local TomEE 7 server in the Eclipse development environment and the OData service is immediately available:
2.2 Step 2: Create simple UI5 App
The strength of storm is that in addition to the backend services, we can now also describe the frontend in the same language. This means that we now define a first app in the same file, which consists of a launchpad with which we can create new product infos and search for this information:
These 12 lines are sufficient to create a complete UI5 project when saving the storm file, which includes several 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:
– the Dashboard as a start screen of our app:
– a UI to create our ProductInfo Entity. Let me remind you again. We have only defined the following:
This is the simplest 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 input form for the available fields
- all required navigation routing configurations
- default buttons, because storm knows that this is an input UI for the entity ProductInfo
– and a list UI, which we can use to search for product information:
2.3 Step 3: UI 5 extension – Documents
Of course, with the current UI’s generated by default we have not yet implemented optimal interfaces that fully meet the requirements of the business. The idea behind storm is to gradually specify our requirements more precisely. storm displays the elements and UX patterns for UI requirements in a template library. This allows us to meet typical application requirements directly from the language syntax and the UX pattern extensions.
An example: When designing our programming language, we decided that in addition to an entity (such as ProductInfo) a further structuring element, the document (PDF, Word document, image, …) needs its own syntactic representation. In this way, requirements are defined and implemented optimal and quickly.
In our example, we have no specific metadata on the document itself. You are welcome to define other fields in the same way as the entities 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 ProduktInfo entity:
The UI is then supplemented by the storm Documents UX pattern, which generates all necessary UI elements, such as the UI5 UploadCollection:
This results in a complete UI which can be used to upload documents:
The documents are stored in a SAP Platform Document Service (CMIS) subfolder of /documents/productsinfos with the ID of the ProduktInfo entity, because we have specified the SAP Cloud as the target platform. All documents are placed in this folder, which contains the contents of the Name field from the ProduktInfo as the folder name. The declarative definition in storm already provides a complete, well-ordered document storage in the SAP Cloud Platform without any additional effort.
2.4 Step 4: External OData services
In the business case, we have defined that the ProduktInfo should be linked to the products and business partners from a ERP system. I. e. we will now define the ERP system and reference the OData entity sets we need from there:
The generate ServiceGroup statement extracts all information required by the specified OData service into a separate storm file, which is copied to our project so that we can immediately access all functions and entity sets in the OData services very flexibly.
We add two additional fields to our entity definition: On the one hand, we want to link some products to this entity and on the other hand, we want to be able to optionally specify a responsible business partner:
Only these 5 lines were necessary and we have already generated a completely correct working UI5 app, which allows us to integrate other OData services:
The different visualization of the two lists can be derived flexibly from all values of the entity at the end of the field definition.
2.5 Step 5: Make the UI responsive, more beautiful and dynamic
Of course, the current UI is not yet breathtakingly beautiful and structured and not yet flexible and adaptive.
Therefore, we will build a tab-based UI that has structured input areas from the currently simple UI, where all fields are located one below the other:
We define a tab based UI with two areas as tabs. Within the Form UX pattern the areas are treated as field groups.
Responsiveness is ensured by self-defined response patterns pattern6 and pattern4, which have been installed at different points above. You can also define and use you own patterns:
In this way, you can create your own names and definitions for responsive patterns that work well for you.
Et voila, we have a very well structured UI with different tabs, which you can use immediately productively:
The app is also responsive, here is the example of the representation in a small window or smartphone:
2.6 Step 6: Search integration
We have already defined a list UI that currently displays the list of product information. Now we turn it into a very powerful search UI with a few lines of code, including full text search and flexible filters and search tabs.
We use the storm SearchList UX Pattern here, which allows you to define the names of the fields to be used for the result list ((@UI.ListElement or no further information at all) 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:
From this, a professional and in the sense of the business requirements complete UI including all necessary backend extensions is created:
As soon as we click on Show Filter Bar, the filters defined above are also displayed:
Each filter element UI is optimally rendered according to the information available to us. For example, the Type filter looks like this:
In particular, we would like to point out that due to the storm search definitions we have implemented a full text search which searches through several fields of the entity, here even automatically in the filenames of the uploaded documents:
3. Multi-stack: Switch from SAP Cloud to SAP NetWeaver
The application we create runs beside the local TomEE 7 server also on the SAP Cloud and therefore uses the necessary API’s for user/group management as well as SAP Document Service (CMIS) as document storage.
In its definition, storm abstracts precisely from these implementation specifications using the SystemType.
Previously, we had set up the SAP Cloud system as follows:
If we now want to convert from SAP Cloud to SAP NetWeaver Portal, we enter the following information:
That’s it! The instructions for generating apps and service groups which all reference the system alias are now informed that we should now want implement for another platform.
Your storm UI5 app has therefore converted all document-related APIs to SAP NetWeaver KM, i. e. we now also store the documents there. The UME is also used now, and EAR projects are now created so that they can be deployed to the NetWeaver stack immediately.
We have shown here some aspects of the storm programming language developed by frequi, which shows in particular how efficiently you can implement high-quality persistence based UI5 apps for SAP Cloud and SAP NetWeaver with connection to ERP systems. Because the storm language in the current version supports the typical application scenarios such as dashboard, CRUD input UI’s and searches out of the box, you can implement your requirements very quickly in these scenarios.
If we look at some lines from the generation log:
88 Lines created 107 files with 19976 Lines
However, the storm language has much more to offer, such as dynamic forms (hiding complete or hiding certain UI areas based on application data or authorizations), custom actions and exits, flexible validation of the UI’s field- or model-specific, complete support of complex ACL authorizations that are also implemented for data and documents at the same time, and of course support for high-performance authorization-dependent searches in the entities we create, and much more.
Benefit from the fact that we have already implemented many standard UX patterns efficiently. And you can just use them, or add your own custom frontend and server code to the exits prepared for you. In addition, if you want, take the generated professional code and do whatever you want with it! A top UI5 App, just once paid to us for every platform with a fair price, which is based on the complexity of the app.
Give yourself time!