Skip to Content
Technical Articles
Author's profile photo Prashil Wasnik

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


This blog post is a continuation of my blog series on Fiori Push Notification.

In the first part, we have seen how we can create Notification Objects. This blog post will mainly focus on the Notification APIs that are provided by the Notification Framework. Also, we will see how we can push or publish notification objects.

Notification Framework provides only these APIs:

  1. Create Notifications
  2. Delete Notifications
  3. Get Provider Configuration
  4. Clear Cache

Let find out what each of these API is meant to do and how to use it.

Create Notifications:

This API is to push or publish notifications to the frontend server. The API has below signature:

IV_PROVIDER	         TYPE TY_S_PROVIDER-ID	    Provider Id
IT_NOTIFICATION	     TYPE TY_T_NOTIFICATION	    Notifications to be triggered
value( IV_RETURN )	 TYPE FLAG	                Success Flag

IV_PROVIDER is the id of the provider class.

A short summary of provider class, consider it as a consumer for the notifications we pushed. The provider class consumes the information on the published notification and shows it on the launchpad. More of the notification provider will be on the next part of the blog series.

If provider class is registered, the ID can be found at the following path:

SAP Customizing IMG » SAP Gateway » Notification Channel » Notification Channel Provider Enablement » Manage Notification Provider


Customizing for Notification Provider

IT_NOTIFICATION is the collection of notification objects that we would like to publish. Note that it can take multiple notification objects and publish all at once.

IV_RETURN is an acknowledgment return that the framework generates if all everything pushed is as accepted.

An example, how to use it:

 DATA: lrx_api          TYPE REF TO /iwngw/cx_notification_api,
       lv_api_return.   TYPE        flag.

        iv_provider_id = iv_provider
        it_notification = it_notification).
   CATCH /iwngw/cx_notification_api INTO lrx_api.
      lrx_api->get_text( ).


Delete Notifications:

Delete Notifications is much simpler to understand if we are good with Create Notifications.

For deleting the notification, we need to collect the notification id’s that we would like to delete and the notification provider id.

The API signature:


IT_PROVIDER_ID is the same notification provider id, which is discussed in create notification API.

IT_NOTIFICATION_ID is the unique notification GUID that is created which building the notification.

The way to use:

          iv_provider_id = lv_provider
          it_notification_id = lt_notif_id ).
    CATCH /iwngw/cx_notification_api INTO lrx_api.



Get Provider Configuration:

This API will provide information related to the provider class. Most important is whether the provider class is set to active or not.

It is recommended that before we start building or publishing the notification, we should first check if the provider class is activated into the configuration else we will end up doing a lot of unnecessary processes.

Signature for the API:


IT_PROVIDER_ID is same as above.

Importing parameter RS_RESULT is the provider configuration object.

 DATA: ls_pr_config TYPE /iwngw/if_notif_provider=>ty_s_provider_config,
       lv_pr_id     TYPE /iwngw/notif_provider_id.

  ls_pr_config = /iwngw/cl_notification_api=>get_provider_config( lv_pr_id ).
  IF ls_pr_config-active IS abap_true.
  "Perform next steps


Clear Cache:

This one clears all notification metadata, which includes notification type texts and action texts so that the latest values can be fetched from the notification provider during the callback.

Signature is:


Here IT_NOTIF_TYPE_KEY is an optional importing parameter, if not provided it will clear cache for all of the notification type, else it can be specific to particular notification key.

Ultimately, it calls the BAPI /IWNGW/FM_HUB_CACHE_CLEANUP, which also can be executed independently into the frontend server.


        CALL METHOD /iwngw/cl_notification_api=>clear_cache
            iv_provider_id    = lv_provider_id
            it_notif_type_key = lt_key
            et_return         = et_return.
      CATCH /iwngw/cx_notification_api INTO DATA(lo_exception).


With these APIs, it gives much flexibility for the notification to work with.

The obvious question here why there is no update function. In my personal opinion, a notification is an alerting system for the user to pay attention to information at a particular given time. Usually, the same alerts are not supposed to be updated instead a new alert should be sent.

Next in the blog series, we will see how to create a provider class and handle different actions.


Prashil Wasnik

Assigned Tags

      Be the first to leave a comment
      You must be Logged on to comment or reply to a post.