Skip to Content
Technical Articles

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

Hi,

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%20for%20Notification%20Provider

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.

 TRY.
   /iwngw/cl_notification_api=>create_notifications(
      EXPORTING
        iv_provider_id = iv_provider
        it_notification = it_notification).
   CATCH /iwngw/cx_notification_api INTO lrx_api.
   " HANDLE ERROR
      lrx_api->get_text( ).
 ENDTRY.

 

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:

IV_PROVIDER_ID	        TYPE /IWNGW/IF_NOTIF_PROVIDER=>TY_S_PROVIDER-ID
IT_NOTIFICATION_ID	TYPE /IWNGW/IF_NOTIF_PROVIDER=>TY_T_NOTIFICATION_ID	

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:

   TRY.
      /iwngw/cl_notification_api=>delete_notifications(
       EXPORTING
          iv_provider_id = lv_provider
          it_notification_id = lt_notif_id ).
    CATCH /iwngw/cx_notification_api INTO lrx_api.
      "HANDLE ERROR

   ENDTRY.

 

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:

    IV_PROVIDER_ID	TYPE /IWNGW/IF_NOTIF_PROVIDER=>TY_S_PROVIDER-ID
    value( RS_RESULT )	TYPE /IWNGW/IF_NOTIF_PROVIDER=>TY_S_PROVIDER_CONFIG

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

 

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:

IV_PROVIDER_ID	    TYPE /IWNGW/IF_NOTIF_PROVIDER=>TY_S_PROVIDER-ID
IT_NOTIF_TYPE_KEY   TYPE /IWNGW/IF_NOTIF_PROVIDER=>TY_T_NOTIFICATION_TYPE_ID OPTIONAL

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.

 

TRY.
        CALL METHOD /iwngw/cl_notification_api=>clear_cache
          EXPORTING
            iv_provider_id    = lv_provider_id
            it_notif_type_key = lt_key
          IMPORTING
            et_return         = et_return.
      CATCH /iwngw/cx_notification_api INTO DATA(lo_exception).
        "HANDLE EXCEPTION
    ENDTRY.

 

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.

Thanks

Prashil Wasnik

/
Customizing%20for%20Notification%20Provider
Be the first to leave a comment
You must be Logged on to comment or reply to a post.