Customization and Development

Introduction

Stelo tile builder provides a highly customizable framework to build dynamic data driven app launcher tiles for the Fiori launchpad.

The framework comprises of a front-end dynamic tile configurator and back-end gateway interface that exposes business data using ABAP function modules.

Creating a Dynamic App Launcher

Fiori launchpad designer provides a dynamic tile template using which data driven app launcher tiles can be created. However, the options available to configure the tile is limited.

This is a useful option where a gateway service has already been developed, but in other cases it is easier to use the Tilebuilder 'KPI' tile option.

App Launcher – Dynamic tile template

Fiori launchpad designer->Catalog->Tiles->Add tile->App Launcher - Dynamic

Dynamic data for the tile is retrieved from any data source configured in a “Service URL”. The data source has to return data in a specific structure – please refer to appendix for further details on the data structure.

The Tilebuilder framework exposes a generic Gateway interface using which business data can easily be retrieved from the back-end using ABAP function modules. The structure of the data service call is shown below. Please refer to “Creating data service function” section for further details on creating the function module to define the business logic to expose data.

Structure of the data service call

/sap/opu/odata/STB/TILE_SERVICE_SRV/TILEINFOSet(im_request='<User input>',im_function='<ABAP Function Module’>)

  • IM_REQUEST: Custom data can be passed using this variable to the backend function module
  • IM_FUNCTION: Name of the function module that returns business data

Service URL

/sap/opu/odata/STB/TILE_SERVICE_SRV/TILEINFOSet(im_request='GETDETAIL',im_function='Z_STELO_TILE_SERVICE_BLORDERS')

The screenshot below shows a dynamic tile built using dynamic tile template. The tile display a “Count” that is dynamically derived by invoking Stelo gateway interface and also shows some supplementary information on the footer.

 

Stelo Tile Builder ('Tilebuilder')

Tile Definition

LaunchPad tiles are created as normal using the Fiori Launchpad designer. Click on 'Add tile' and then choose one of the Stelo tile builder options based on the required tile size:

 

Tilebuilder provides advanced configuration options to display graphical controls in the app launcher tile where the content of the tile can be dynamically configured to display any UI5 content such as charting controls and images.

It also simplifies the data binding process which can easily be managed from the tile building interface.
 

 

Tilebuilder provides a tile preview in the top right corner of the screen so that users can see how the tile will look whilst building it.

Users can toggle between the binding view and data view 

Tile Properties

These are basic tile properties which can be set.  There properties can be static or dynamic by referencing a data output.

Title: The text at the top of the tile

Subtitle: Text the appears under the title

Footer: Text that appears at the bottom of the tile

Background Image: A URL to an image that takes up the entire tile, sitting behind other content.  Use 176 x 176 pixels for 1x1 tiles and 352 x 176 pixels for 2x1 sized tiles

Header Image: A small image that appears at the top right of the header section of the tile. Use a URL to a square image or use a reference to a sap icon (eg sap-icon://inbox) to show an icon at the top right of the tile.

Tile Theme: If a dark background is used the text colour can be changed to white by setting the theme to 'light'

Tile Mode: This can be set to 'Header' in order to suppress tile content and extend the header to fit in 4 lines for the header text instead of 2.

Keywords: Free text for searching; no tile functionality

Configuration

Here a predefined tile type can be selected or users can select the custom tile option is none of the predefined types match their requirements.  Dynamic tiles will fetch data from a back-end service and a refresh interval in seconds can be set to tell the tile how often it should refresh its data from the backend.

The backend service field stores the name of the function module to return tile data, from table /STB/DATASERVICE.

The configuration fields change based on the selected tile type. 10 tile types are available:

  • Static  (Just includes an icon like standard Fiori launchpad tiles, but can be dynamically determined)
  • Image (Like a static tile, but shows an image in the content instead of an icon)
  • Microchart - bullet
  • Microchart - column
  • Microchart - comparison
  • Microchart - radial
  • Microchart - harvey ball
  • Microchart - line
  • Custom view (add your own SAPUI5 code, optionally binding data to a service)
  • KPI (Shows a tile like the dynamic app launcher tile, but easier to build and with more options)

Tile Content Fragment

Tilebuilder generates a SAPUI5 fragment in real-time, based on the property values and bindings added.

It is read-only except for 'Custom' tile types, for which the developer must add the fragment manually, including any data bindings.

There is a button to refresh the tile preview, which is really useful to check that the tile content is correctly defined.

Data Preview

Once a backend service has been selected, the data returned by the service can be viewed in the data preview section.

There is a 'refresh preview' button to update this if there is a change to the service or import parameter.

The service data is in JSON format.

This view is helpful when binding the parameter in the tile configuration area, as the field names are available.

As bindings are made, the tile preview in the top right can also be refreshed to show real data.

Navigation Properties

These are the same as for standard Fiori tiles.  Both semantic object navigation and URL link navigation options are supported.


Structure of the data service call

The framework provides a generic Gateway service interface using which ABAP function modules can be invoked from the frontend.  


1:
2:
/sap/opu/odata/STB/TILE_SERVICE_SRV/TILEINFOSet(im_request='<User
input>',im_function='<ABAP Function Module>’)


There are 2 inputs that are passed into the service call:

  • IM_REQUEST: This is user defined data as entered into the ‘Request Input’ field
  • IM_FUNCTION: Name of the function module that ultimately be called in the backend.  This is set by selecting a ‘Backend service’ from the dropdown list.

Within Tilebuilder, you simply select the name of the function and add any import parameter.

EX_RESPONSE variable exposes the data required for the tile content as a JSON string.

 

Data binding technique

The data exposed by the gateway data service can be directly bound to the tile using the appropriate binding path as shown below.

Examples for each tile type are provided in the examples section.

Automatic data formatting

Convert String to Float - .formatStringToFloat

Tilebuiler provides automatic data formatting, to perform data type conversation from “String” to “Float” which is necessary to binding data to UI attributes that expect “numeric” data.

The generic gateway interface exposes data as “String” by default, but the generated fragment includes the required formatting for numeric fields.

 

Exposing business data 

To expose the required business data to a tile, an ABAP function module has to be created with the required signatures. The response from the function will then be exposed to the frontend tile via the generic Gateway interface provided by the Stelo tile builder framework.

Embedded Deployment

In this type of deployment Fiori frontend server and backend business suite components are installed on the same SAP system.

Create a new function module prefixed with ‘Z_’ by cloning /STB/DATASERVICE_SAMPLE function in the SAP system. This will create a function with the correct signature that will expose sample data to test Stelo tile builder.

  • EX_TILEINFO : All configurable properties for the dynamic tile is returned using this parameter. Refer to type /STB/TILEDATA for details about the properties available
  • EX_MESSAGE(optional) : BAPIRET2 messages which can be sent back to the app if necessary. Note that the table will be sent to the app in JSON string format
  • lv_json = /ui2/cl_json=>serialize( data = <internal table> compress = abap_true ).
  • EX_RESPONSE(optional) : The custom data to be returned to the app to drive microcharts etc. Convert the response into a JSON string using json converter method:
  • IM_REQUEST(optional) : User input data can be passed using this variable. This parameter can also be passed as blank if no user input is required to run the function

For a function module to be available for binding in the Stelo tile builder, it must be maintained in table /STB/DATASERVICE

The Function module name must be entered.  An RFC destination can be given it the function will be called on a different system.   The description is what will be displayed in the frontend dropdown with the function name in parenthesis as shown below.

Hub Deployment 

In this type of deployment Frontend gateway server and backend business suite components are installed on different SAP systems.

Create a new function module prefixed with ‘Z_’ (Z_STB_DATASERVICE_SAMPLE) by cloning /STB/DATASERVICE_SAMPLE function in the Frontend gateway server. This will create a function with the correct signature that will expose sample data to test Stelo tile builder.

  • IM_REQUEST(optional) : User input data can be passed using this variable. This parameter can also be passed as blank if no user input is required to run the function
  • EX_RESPONSE(optional) : The custom data to be returned to the app to drive microcharts etc. Convert the response into a JSON string using json converter method: lv_json = /ui2/cl_json=>serialize( data = <internal table> compress = abap_true ).
  • EX_MESSAGE(optional) : BAPIRET2 messages which can be sent back to the app if necessary. Note that the table will be sent to the app in JSON string format
  • EX_TILEINFO : All configurable properties for the dynamic tile is returned using this parameter. Refer to type /STB/TILEDATA for details about the properties available

It is sufficient to expose just the EX_TILEINFO parameter, for dynamic tiles that render a “COUNT”. For graphical UI controls, EX_RESPONSE parameter in JSON format is passed back to the frontend application.

To consume business data from the backend system:

  • Create a Remote enabled function module in the backend system with the required signatures and business logic to fetch backend data
  • Invoke the RFC created in the backend from the wrapper function (Z_STB_DATASERVICE_SAMPLE) created in the frontend gateway system. Refer to sample snippet below for details to invoke RFC call.

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
CALL FUNCTION 'Z_FETCH_BUSINESS_DATA' DESTINATION 'BACKEND-ECC'
    EXPORTING
      im_data  = im_request "Pass data received from Stelo tile builder designer
    IMPORTING
      ex_result = ex_data.  "Business data exposed by the backend system

*
* Convert internal table to json string
      lv_json = /ui2/cl_json=>serialize( data = ex_data compress = abap_true 
pretty_name = /ui2/cl_json=>pretty_mode-low_case ).
      ex_response = lv_json.
*

  • If the response from the backend system is in table/structure format then the payload has to be converted into a JSON string using json converter method: lv_json = /ui2/cl_json=>serialize( data = <response returned from the backend system> compress = abap_true ) before being returned to the app via EX_RESPONSE parameter. Refer to the sample function module /STB/DATASERVICE_SAMPLE for further details on the conversion.
  • EX_TILEINFO (Optional) parameter can also be filled with business data from the backend for dynamic tiles that render a "COUNT".  If required create a data structure called Z_STB_TILEDATA in the backend system manually referring to /STB/TILEDATA for details about the properties available. This structure can then be passed from the remote enabled function to the wrapper function created in Frontend gateway system. For graphical UI controls, EX_RESPONSE parameter in JSON format is passed back to the frontend application.

For a function module to be available for binding in the Stelo tile builder, it must be maintained in table /STB/DATASERVICE in the Frontend Gateway system

The Function module name must be entered.  An RFC destination can be given it the function will be called on a different system.  The description is what will be displayed in the frontend dropdown with the function name in parenthesis as shown below.

 

Tile Settings for Arch Products

Stelo

Stelo Dashboard

The URL must reference the app name chosen when the Dashboard app was installed

Stelo Inbox

The Semantic object must be formType and the Action must be 'all'.  You can create an Approval app for a single document type by putting the document type in the Action field.

The URL must reference the app name chosen when the Inbox app was installed.

Inbox count

We provide a service with the Inbox count that can be called from a standard dynamic tile:  /sap/opu/odata/STELO/UTILITIES_SRV/InboxCountSet/$count

To use a Tilebuilder KPI tile instead, you need to write a short function to return the item count instead. (See notes below for Varo)

Floe

Floe Designer

Floe Designer is delivered as a Fiori App with ID 'floe'

Floe History

Floe History report is transaction /FLOE/EMAIL_HISTORY

Aquiller

Aquiller Inbox

Aquiller Inbox is a Fiori app with ID flmcg.Inbox

Varo

Form Manager

Form Manager is a BSP app, so it runs outside the Fiori LaunchPad

Form Dashboard

Form Dashboard is transaction /FLM/FORM_DASHBOARD

Form Posting Engine

Form Posting Engine is transaction /FLM/FPE

Varo Inbox Count

To return an Inbox Count for Varo or Stelo use a Tilebuilder function.

Call function /FLM/GET_INBOX_FOR_USER, setting parameter im_docs_supported to /flm/core=>c_flm_docs for Varo or /flm/core=>c_stelo_docs for Stelo.

Optionally filter by form type if this has been passed in as the import parameter (im_request) from the tile Request Input field. 

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:
31:
32:
33:
34:
35:
36:
37:
38:
39:
40:
41:
42:
43:
44:
FUNCTION zstb_varo_inbox.
*"----------------------------------------------------------------------
*"*"Local Interface:
*"  IMPORTING
*"     VALUE(IM_REQUEST) TYPE  STRING OPTIONAL
*"  EXPORTING
*"     VALUE(EX_MESSAGE) TYPE  BAPIRET2
*"     VALUE(EX_RESPONSE) TYPE  STRING
*"     VALUE(EX_TILEINFO) TYPE  /STB/TILEDATA
*"----------------------------------------------------------------------
  "--------------------------------------------------------------------
  "*"Local Interface:
  "  IMPORTING
  "     VALUE(IM_REQUEST) TYPE  STRING OPTIONAL
  "  EXPORTING
  "     VALUE(EX_MESSAGE) TYPE  BAPIRET2
  "     VALUE(EX_RESPONSE) TYPE  STRING
  "     VALUE(EX_TILEINFO) TYPE  /STB/TILEDATA
  "--------------------------------------------------------------------
*--------------------------------------------------------------------*
* This function module is a sample which fills diffrent chart types.
* Customers can copy to create their own function modules.
*--------------------------------------------------------------------*
*
  DATA: lt_inbox       TYPE /flm/get_inbox_user_t,
        lv_lines       TYPE i,
        lt_ftype       TYPE TABLE OF /flm/ftype,
        ls_ftype       TYPE /flm/ftype,
        lv_destination TYPE rfcdest.
*
  lv_destination = im_request.
*
  CALL FUNCTION '/FLM/GET_INBOX_FOR_USER' DESTINATION lv_destination
    EXPORTING
      im_user           = sy-uname
      im_docs_supported = /flm/core=>c_flm_docs
    IMPORTING
      ex_inbox_for_user = lt_inbox.
*
  lv_lines = lines( lt_inbox ).
*
  ex_tileinfo-number = lv_lines.
*
ENDFUNCTION.