HCM Processes and Forms: Mobilize Your Processes with UI5 and SAP Gateway Part I: Basic Thoughts

[ckuczera]

How to use Processes and Forms in Mobile Architecture Part I 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

We will start with the basics and how the different technologies can be used to process custom HR related processes using SAP Gateway and SAP UI5.

Basic Topics

We have checked and implemented the following points to get the data from the P&F framework up and running within the SAP Gateway and to fit the logic of P&F with the logic how OData is transferring data to mobile applications.

1. Access P&F Data and Process Events
2. Transfer Data from P&F to SAP GW
3. Get Configuration of FPM Form Formulas
4. Value Help Access
5. Performance Optimization

Next Steps / Open Points:

• Read List Forms
• Translations

This blog is focusing on FPM based processes. Adobe based processes should be possible as well, but will not fit to the auto generation logic of the SAP Gateway entities. But changing that a little bit, will ensure Adobe based processes to run in the mobile framework as well.

We took a simple P&F demo process to request "Sideline Jobs", which means "Nebentätigkeiten" in German, and is a standard infotype 0329 in Germany, to describe our solution.

1. Access P&F Data and Process Events

Well, let's start with the base: Accessing data from the P&F framework. We have analyzed the existing function modules to access / generate data from a P&F processes. At last we stopped to investigate in function modules and analyzed the coding of the FPM feeder class "CL_HRASR00_FPM_FEEDER"  which, in my opinion, contains the most powerful P&F data processor class "CL_HRASR00_WF_PROCESS_OBJECT" available in the SAP System.The data processor class is already covering all required actions to read, write data and to process the most important events, like "CHECK", "INITIALIZE", "SAVE" and "SAVE_DRAFT". The decision to use this class was taken really fast and until now we didn't find any issues.

The most important thing, using the data processor class, is the correct initialization and data access call passing the correct parameter based on the available information from the process. Depending on the process status, the data processor has to be initialized using:

• the process name -> when creating a draft version
• the step guid -> when reading history data
• the work item id -> in case of draft changes and workflow processing steps

After initializing the data processor, it is possible to read (initialize) the data and to process events, like save the draft or send the process to approval. Important in that case is the call of the data processor functions using exactly these parameters, which were passed to initialize the processor.

We have created a wrapper class initializing the processor and doing the whole work. All required information how to initialize and use the data processor were taken in a debugging session from the FPM feeder "CL_HRASR00_FPM_FEEDER" and the appropriate method calls "initialize_form", "submit_form_data" or "save_draft" of the class "CL_HRASR00_WF_PROCESS_OBJECT".

When reading the information by calling function "initialize_form", the data processor exports the possible value help information for all fields included in the process. This is really helpful when calling the value help details from the interface (see more in Chapter 5 Value Help Access).

But for now we should have a look on how the data is going to be transferred or converted between processes and forms and the gateway in the following chapter.

2. Transfer Data from P&F to SAP GW

Data conversion from and to the P&F framework is one issue we faced at the beginning of the prototype development. In general, a SAP Gateway entity is based on existing structures and exact data definition. The components (fields) of the structure are mapped to properties of the entity and are based on special EDM types, like EDM.String or EDM.DateTime.

The following screenshot shows the mapping of a SAP structure to a SAP Gateway entity "request" which is the base entity of each P&F based process in my SAP Gateway project. The entity structure "ZCK_WF_REQUEST_GW" includes the "T5ASRPROCESSES" table and adds some additional information, like process description, action to perform a.s.o.

The second screen shows the data structure and the mapped data element of the SAP Gateway entity "Process".

For more information regarding data mapping and SAP Gateway entity, just use the search of this fantastic SCN Forum, which helps a lot in all topics and questions around SAP.

Compared to the data logic of SAP Gateway, the P&F framework is using simple data value tables to transfer and process data. An issue is,       to process this data and to transfer it to SAP Gateway readable information. We focused on two possible solutions, which will be described next:

Option 1: Do not transfer and push data as a set (Table) of FieldValues to the Mobile APP

Well: not transferring data is simple. It's just an issue of reading the data, maybe adding some information about the data type and transferring it to the mobile application using a set of FieldValue Table like:

Displayed as a json stream below:

But: we were facing some issues in data mapping and data binding, especially when using date / time fields or numeric values. In general, it is required to transform the data, which in all cases is delivered as string value, within the user interface to UI5 readable information. At last we have decided to try the second option which is described below.

Option 2: Transfer the Data to an OData readable entity

Transferring the P&F data into SAP Gateway readable structure requires one step to do: manually creating the data structures and entities or generating them based on the P&F configuration. The first option is the easy way to go forward, but requires manual work after a process change to add, change or remove the data elements to the gateway entity structure.

The second option requires an auto generation of structures and entities for the SAP Gateway service, which is done really good by SAP when using transaction the SAP Gateway Service Builder SEGW to generate the SAP Gateway classes *_MPC, *_MPC_EXT, and *_DPC, *_DPC_EXT.

I have choosen the way to automatically generate the structures and entities on the fly, by reading the field configuration of the P&F process itself and creating the required entities and data fields in the OData service. This makes life in the user interface much easier!

The following screenshot shows the data field definition in the process designer HRASR_DT:

And the generated type definition in a model class "ZCL_ZGWP_REQUESTAPP_PFMODEL" which was created and added automatically to a transport request:

And at last we redefined the model provider class extension "ZCL_ZGWP_REQUESTAPP_MPC_EXT" function "define" to create the process data entities with a reduced field set containing only the required fields by one of the FPM forms included in the process:

Details how we have created these entities can be found in Part II which is describing the SAP Gateway project in detail.

Compared with the details of the FPM form, you can see that the entity really contains the fields which are included in the FPM form:

This is really cool! Auto generation of process fields as SAP Gateway entities created by ***MAGIC*** 😉 ... hmmm ... not really, check out the next chapter to see how we read the FPM configuration to reduce the fields in the SAP Gateway data entity.

3. Get Configuration of the FPM Form

The basic idea to read the WebDynPro configuration of the form was, to ensure the auto generation of the model entity types and to reduce the fields used in the SAP Gateway service to this information set, which is really required and used in the formula. Of course this feature is only available in the FPM based forms, because I was not able to read the appropriate information from Adobe based formulas or even roadmap based ones. To be honest, I didn't investigate that point for now 😉

The following screen shows the WebDynPro configuration of the FPM Form for my process "Sideline Job Request", the configuration of the form is not only containing information of the used fields, more interesting is the configuration displayed in bulled 1, 2 and 3 which is the type of display, the label visibility and at last the positioning of the field.

Reading the configuration is quite easy. It is just a matter of reading the xml stream containing the feeder configuration stored in table "wdy_config_data" using the form name, which in my case is "YHCM_PA_0329_REQUEST_FPM2" and converting the data to an ABAP structure that can be used in further steps.

I am not a friend of parsing xml structures manually, so I have decided to use a XSLT template and transfer the xml information directly to an ABAP structure which is displayed in the screens below:

The generated field list includes the selected input type in the FPM Form (DD for Drop Down or IN for Input Field):

Well done so far. Let's check possibilities to access value help data in the next chapter.

4. Value Help Access

As already mentioned in chapter 2, the function modules of P&F and the data processor class are providing value help information when reading the data of a process. When checking the export parameter, we can find the table "et_input_help_values" and "et_input_help_extended" in the signature of the method "initialize_form"

Exporting value help table "et_input_help_values"

The more simple value help table "et_input_help_extended":

Including value table in data ref (example for TTKEY Field table entry et_input_help_extended[2]-data->*):

Of course, value help is not always a simple value help as in this example. A P&F value help can as well use a standard WebDynPro Search Help created using transaction se11. It is as well possible to read these search value help values in the background and to display these fields in the user interface. More on this can be found in Part II the SAP Gateway developments.

5. Performance Optimization

Performance is a really critical point using SAP Fiori and mobile applications. The user is used to work fast and not waiting seconds for information to be displayed.

The SAP Gateway is working stateless, which means that in general the date must be read (initialized) per request (Get Request, Get Data, Get History and so on). A good option here is the batch processing logic of the OData model which bundle calls in one request.

To optimize the performance of the calls we have created a class that persists the information in the current user session, which allows to read the data once and access it in through the whole batch call.

The following screenshot shows the class signature of the persistence helper class storing the "FULLPROCESS" details in an instance attribute of the class.

The class attributes are defined as shown in the next screen:

The structure ZGWP_FULLPROCESS was created and contains the following information:

The persistence class is really helpful and the fact, that the data has to be read only once per batch request does a lot to increase the performance of the application. Once the data is read, we are storing converted information as an instance attribute of the class which is available in the current session until the batch process ends.

We will change the signature of this really helpful class soon to make use of data type "ANY" in order to use the class more flexible.

Furthermore we already extended the class to store the data in a cluster table, to allow to access the information during multiple batch calls.

Summary

Let's summarize this blog so far: accessing processes and forms related information and transporting it to the mobile application is possible and as described in the blog, can be used really flexible.

We will move forward in the next article, put all these information and achievements into a SAP Gateway service and display them in a mobile application in the last step.

Let's move to Part II