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
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.