HCM Processes and Forms: Mobilize Your Processes with UI5 and SAP Gateway Part III: The UI5 Request APP

[ckuczera]

How to use Processes and Forms in Mobile Architecture Part III of III

This blog will explain how Processes and Forms can fit into the mobile world of SAP Fiori / UI5 and SAP Gateway.

The blog is split up to three different documents:

1. Part I: Basic Technology blog with hints how to use the technology and power of SAP Gateway and Proc...
2. Part II: Best Practice Gateway Blog showing how to use the Data and Definition Document of a P&F Pro...
3. Part III: Build up the APP Consuming Processes and make use of the powerful Extension-Concept of SAP

My colleague Ralf Jörg Bauer took the part to implement the UI5 based mobile application for this processes and forms project. Ralf is a UI5 developer and we decided together not only to create a simple request application, but make use of the powerful extension concept of SAP for mobile applications in order to build a base application supporting the standard functionality, like navigation, error handling, list filtering and grouping and of course create, delete, change of a request.

The formula itself is implemented as a Smart Form in an extension project of the "base" Application. For more details on this topic, see the following chapters.

Again, we took our demo process "Sideline Job Request" (Antrag auf Nebentätigkeiten in German) to demonstrate the functionality of the user interface in this blog. Furthermore, we have added a second demo request type "Address Change Request" (Antrag auf Addressänderung in German) to demonstrate some additional functionalities. We are sorry to provide all screenshots in German, but we didn't work on the translation before creating this blog.

The Processes and Forms Request Application

The blog describes the development and procedure how we came to the mobile application in the following steps:

1. Create the Base Application and Fundamentals
2. Make use of Start-Filters to reduce the available processes per APP
3. View Settings Dialog for filtering, sorting, grouping and error handling
4. Starting new Processes
5. Make use of the Extension Concept in UI5
6. Make use of SmartForms

1. Create the Base Application and Fundamentals

We have chosen a Master-Detail Application as the base for our application. In the standard implementation the master block is a list of items which can be chosen by the user to display details in the detail page on the right hand side.

Per default, the detail page contains an object header at the top and an icon tab bar at the very middle of the screen. In our solution the icon tab bar contains the following 3 items.

• First item with details of the formula which in fact only contains an extension point in the base application
• Process attributes with details of the process itself, which is represented by the entity "Process" or "ProcessSet"
• Table of history entries, where the user also can click on to see more details about the steps.

The following acreenahot shows the set up of the base application without additional extensions for now:

2. Make use of Start-Filters to reduce the available processes per APP

Due to the fact that the solution should cover multiple request types without big effort when implementing the formula of the processes itself, we decided to add a startup parameter to reduce the available processes per default in the list, filter and sorter logic. We achieved this a using startup parameter, which can be fetched in the component file and configured in the "Run Configuration" of the SAP Web IDE and of course as startup parameter in the launchpad tile configuration.

The following screenshot shows the configuration set to display two different request types set in the tile definition.

1. 0001 = Address Change
2. 0002 = Sideline Job Request

Changing this setting to requesttypes=0002 will per default filter on the request type for "Sideline Jobs":

Of course these settings have to be used when building up the request for the list of processes. As you want to keep these filters as static filters on the list of processes we had to be careful when applying filters by the user himself in order not to overwrite the initial filters. We have stored the base filters in an array of the component which is accessible in each controller of the application.

3. View Settings Dialog for filtering, sorting, grouping and error handling

We have added a standard filtering, sorting and grouping button to the toolbar of the master list and implemented the view in a fragment which can be opened as described below:

After calling the fragment and opening the dialog, we had to make sure that the filter values are build based on the startup filter settings as well. Therefore the request type filter is used to request the filter attributes directly from the backend system and not calculating the values in the the user interface.

The request "RequestFilterSet?$filter=(FilterKey eq 'RequestType') and (RequestType eq '0001' or RequestType eq '0002')" is send and returns only the relevant status filters for the predefined request types:

At the end we have the expected result in the search:

After implementing the filter logic we have added another cool feature in order to handle errors / warnings of the P&F Framework in a user friendly way. Due to the fact that processes and forms can display several error messages / warnings after each save event, we have added a MessageIndicator which is displayed after each event when receiving errors:

This visualization is similar to the one in the real processes and forms framework:

Ok. That's all for now. Using the filtering and error handling options we will check the options how to create new processes in the following chapter

4. Starting new Processes

We have also added an "Add" Button in the toolbar of the master page. This opens a new dialog where the user can select the process to create and the employee to create the process for. We have as well added a restriction for employee selection to the process list which allows a detailed control of people a process can be started for. The employee selection is based on the OADP framework explained in Part II and very flexible in configuration and usage:

In case of start type "HRASRB" (Start by Manager) the employee selection is switching to standard evaluation "Team: Direct Reports" and "Team: All Employees". The start type is part of the processes and forms logic and as well defined in the start parameter "requestmode" in the tile definition.

5. Make use of the Extension Concept in UI5

As already explained we have added extension points on several UI elements of the base application to ensure that the implementation of a process formula can be made without high effort. The following screen shows the different extension points marked in blue:

In fact, the extension of the base app can add additional functionality as icon tab bar elements or even replace different elements, like toolbar, list or the header elements of the standard app. The most interesting section for our extension project is the content section, which does not contain any fields in the base application.

This is the normal use of extension points. To make our application more flexible we used extension points in a dynamic way. With the following code we are creating extension points dynamically within the data section of the base application.

The last lines are used for the FieldControl properties which define how a field is displayed or is marked as mandatory. In the backend the FieldControlSet is created depending on the step of the process, which as well is a standard feature of processes and forms.

At last you need to declare each fragment in the extension manifest file as described below:

We have created one folder per request type, but this depends on the customer and is not required:

The dataFragments.xml holds the form which gets loaded into the data section of the icon tab bar. In our example we used a smart form with some additional properties from the data model which we just created at the same time we created the extension points dynamically.

The following chapter shows an example implementation of the dataFragments.xml file for our demo process "Sideline Job Request".

6. Make use of SmartForms

As already described in the previous article the SAP Gateway Entities for the data information of a process are generated automatically. Furthermore we are creating the annotations for the value help as well. This makes life in the user interface really simple when adding a form based on the great SmartForm control.

The following XML View Code shows the only additional development per form in the extension of the UI Part for request type 0002:

This XML definition displays the following form in the data section:

The biggest advantage using SmartForm is the direct mapping to data types, labels and value help based on the metadata file and annotation information. Great work SAP Team!!!

That's the whole work that has to be done when adding a new process because the base implementation does the rest of the work. That's really cool!

Summary

The extension concept for SAP UI5 applications is really powerful and allows to create reusable mobile applications. We have developed this base application and the extensions to reduce effort during development of detail screens per process.

As described in the previous blogs, we are able to consume processes based on the P&F framework in mobile applications by implementing general functionality in the base component and adding additional special data sections or logic in the extension projects.

We will keep investigating this topic and maybe add another Part how to solve the approval process which was as well part of the prototype but for now not "ready" enough to create a separate blog entry.