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:
Let find out what each of these API is meant to do and how to use it.
This API is to push or publish notifications to the frontend server. The API has below signature:
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
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:
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:
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.
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.
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
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:
- Create Notifications
- Delete Notifications
- Get Provider Configuration
- 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 FlagIV_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.
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_CONFIGIT_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 OPTIONALHere 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
- SAP Managed Tags:
1 Comment
