Skip to Content
Technical Articles

Fiori Push Notification – How to develop Fiori Notifications – Part 1

One of the key feature of the Fiori 2.0 is the push notification. The notification gives the power to intimate different users to based on the some event occurrence. There are lots of blogs available which explains how to configure the push notification based on deployment options (Click here for different deployment options)

This blog post focuses mainly on creating your own Fiori Notification.

I am splitting the blog into three parts:

1) Building the Notification

2) Publishing the notification

2) Create the Notification Provider

 

Building Notification

You can try building the notifications in the ABAP report or a class, whichever you are comfortable with. A notification object should be derived from domain type starts IWNGW.

IWNGW is the namespace for the notification related structures, table types, domain, and data element.

ID is a unique identifier of each notification, and this is understood as GUID. It is recommended to have it generated by the system. To generate system have a factory class which you can use to generate this id.

DATA: lv_system_uuid TYPE REF TO if_system_uuid,
      id             TYPE /iwngw/notification_id.

lv_system_uuid = cl_uuid_factory=>create_system_uuid( ).
id             = lv_system_uuid->create_uuid_x16( ).

Next is the TYPE_KEY and TYPE_VERSION, this is mandatory and classifies your notification. Also in the latter part, we will detail out the use of TYPE_KEY and TYPE_VERSION for showing the notification.

There is no specified TYPE_KEY, a CHAR32 field, and you are free to choose the key.

TYPE_VERSION is also CHAR20 field and you are free to choose the version, you can have alphanumeric typical version character as ‘1.0.0’.

DATA: notif_type  TYPE /IWNGW/NOTIFICATION_TYPE_KEY,
      n_type_ver. TYPE /IWNGW/NOTIFICATION_TYPE_VERS.

PRIORITY is the priority of your notification and also mandatory to set. Based on this, the Fiori notification framework decides the display of notification. For example, if you set the priority to HIGH, the notification will be preferenced to pop out in the launchpad, as soon as it is delivered, contrary to LOW which will only raise the number and will be shown whenever the user clicks on the bell icon. Also, in the launchpad, users have ability to group the notification by the priority. It can take 4 values as shown below.

DATA:
high    TYPE char20 VALUE 'HIGH',
medium  TYPE char20 VALUE 'MEDIUM',
neutral TYPE char20 VALUE 'NEUTRAL',
low     TYPE char20 VALUE 'LOW'.

priority TYPE /iwngw/notification_priority.

 

ACTOR_ID, ACTOR_TYPE, ACTOR_DISPLAY_TEXT, and ACTOR_IMAGE_URL all these fields are the attribute of the actor, an agent who trigger the notification.

When a notification is shown on the launchpad, you can set the agent as per your business need to tag a notification to a person or group. All the actor related fields are free text and no restrictions.

Also none of them are mandatory, so you can also set them as blank string.

 

DATA:
actor_id TYPE /iwngw/notif_actor_id,
actor_type TYPE /iwngw/notif_actor_type,
actor_display_text TYPE /iwngw/notif_actor_disp_text,
actor_image_url TYPE /iwngw/notif_actor_img_url.

 

RECIPIENTS are table type and an important field for the notification. In this, you can pass multiple recipients for this notification.

An important note, the notification recipient user-id, is the front end user. In case, you have a different user store on frontend and backend, then you have to make sure that recipients are users from the frontend system.

TYPES:
    BEGIN OF ty_s_notification_recipient,
      id TYPE uname,
    END OF ty_s_notification_recipient .
TYPES:
    ty_t_notification_recipient TYPE STANDARD TABLE OF ty_s_notification_recipient WITH KEY id .

Once you create a variable for ty_t_notification_recipient, you have to fill ID against the user-id.

PARAMETERS are also one of the key fields when we want to pass some parameters to the notification framework and need to be shown on the launchpad.

It is like key-value pairs and it is even stored in such a way only. When Fiori triggers the notification read call and builds the text to show the notification, we can add this parameter as arguments and the relevant value will be picked up.

The parameters are collected into the notification parameter bundle, the bundle is language specific parameter collection. When you push your parameters table into the bundle you also have to specify the language key for the parameter.

It means that we can language specific parameters as well.

DATA: 
 parameter_bundles   TYPE ty_t_notification_param_bundle,
 parameter_bundle    TYPE ty_s_notification_param_bundle,
 notification_params TYPE ty_t_notification_parameter,
 notification_param. TYPE ty_s_notification_parameter.
 
 APPEND INITIAL LINE TO notification_params INTO ASSIGNING FIELD-SYMBOL <notif_param>.
 <notif_param>-name = 'TEST'.
 <notif_param>-value = 'This is test param'.
 
 APPEND INITIAL LINE TO notification_bundles INTO ASSIGNING FIELD-SYMBOL <notif_bundle>.
 <notif_bundle>-parameters = notification_params.
 <notif_bundle>-language = 'EN'.
 

A navigation target object, target action, and navigation parameters are required if we like to have intent-based navigation to Fiori application.

NAVIGATION_TARGET_OBJECT is a semantic object of the targetted Fiori tile.

NAVIGATION_TARGET_ACTION is the semantic action of the targetted Fiori tile.

If we require to pass any parameters for intent navigation, you can collect those parameters into NAVIGATION_PARAMETERS.

Whenever you click on the notification on the launchpad, the framework will navigate to the intended application.

 

navigation_target_object TYPE /iwngw/notif_nav_obj,
navigation_target_action TYPE /iwngw/notif_nav_action,
navigation_parameters TYPE ty_t_navigation_parameter,

Many times, we need different actions to perform right at the notification, and navigation to any app is not needed. In this case, we use notification actions.

But this is not part of the navigation object instead, we can achieve this using the notification provider class.

In my upcoming blogs, I will details out how to use the notification api’s to publish the notification and create a notification provider class.

Also more on notification, we can find the documentation here.

Thanks

Prashil Wasnik

5 Comments
You must be Logged on to comment or reply to a post.
  • Hi Prashil,

    Found this blog interesting. Thanks for the excellent write up.

    I have a question regarding the notification in general. In my business scenario users are doing some actions which are being processed at backend system and at a later point of time, when the processing completes, we want to push a notification to the application so that the next time user opens the application, on the notification icon he sees the successful/failed transaction he made the last time.
    Is there a way to implement such operation?

    I understand the launchpad notification concept but we want to show the notifications specifically on the application level.

    Eagerly waiting for the next blogs of this series.

    Thanks,
    Saswata

    • Hi Saswata,

      Thank you for your interest. I understand that you would like to update the notification with the status of the transaction performed.

      Clearly, the notification APIs don’t provide functions to update an existing notification, so there is no standard way of doing it but if it has to be done, you have to diligently, create custom logic to update the notification relevant tables. I have never tried this but to my understanding of the framework, it might work.

      I think the best way to achieve this is by manipulating your notification object parameters. Let’s consider in your notification you also publish the status of the transaction as well.

      At the initial state, keep the status as blank or initial. Once the transaction is performed and committed, you can trigger an update call to modify the parameter in the notification object and unmark the IS_READ flag from the notification object. Also, if you want to bring it to the top, you also need to work with timestamp of the notification.

      Thanks

      Prashil

      • Thanks for the silver lining there…Couple of question, what are the notification relevant tables we are talking about? Is the modification on the status to be done through another GW call to SAP?

        To be more specific about my question I raised, in other open source applications, to get notifications we use mongoDb or any other auxiliary database to fetch those notifications when the app loads. All backend transactions update the notification in your intermediate DB. You only read those notifications without making any actual backend(SAP) calls for the first time you launch your application(not your fiori launchpad). We would be happy to leverage messagepopover kind of control to show the notifications which have been stored in non-relational database.
        Is there any option available to achieve that?

        Thanks again…

        • Hi Saswata,

          Unfortunately, I can’t comment only the open-source applications, it requires a detail study of the architecture.

          About the notification related table, I will soon publish a blog on this series which will dig deeper into the tables and its use.

          Thanks
          Prashil