The Notification Framework enables you to keep your business partners informed about the status and the progress of business transactions. It enables you to subscribe yourself or a group of persons to a transaction or to transactions that have specific attributes.
Nice. Sounds really good. But:
Currently, you can use the Notification Framework for service requests and master service requests.
Actually, there are quite a number of "frameworks" (e.g. ways) to accomplish notification tasks available in SAP CRM. This one is available from CRM 7.0 EHP2 SP6. Recently I tried this framework and found that its functionality is quite suitable for my project needs. The restriction about business object type quoted above made me integrate this framework into a new business object type. In my project it was Complaints. Here I'd like to briefly describe some customizing steps needed to make this framework actually works. As well I will show how to enable this framework for a not (yet) covered business object type from a development perspective.
First of all you need to activate business function Notification Framework and E-Mail (CRM_ITSM_ALERTS) to enable this functionality in general.
After activation, you'll find an option to create subscriptions in SERVICEPRO business role under Service Operations entry in the navigation bar
- Search: Subscriptions (logical link id CT-NF-SR; Work Center Link Group ID CT-APPL-SR)
- Create: Subscription (logical link id CT-NF-CR; Work Center Link Group ID CT-APPL-CR)
And directly in Service Requests' UI.
Notifications here are based on subscriptions which are created beforehand. Subscription is a set of:
- the header with business object type, validity period and status (active or not);
- message templates - channels to use to notify subscribers;
- conditions - conditions to check while processing any changes in a document;
- subscribers - who will receive notifications of this subscription and by which channels.
The processing of subscriptions and notifications is shown on the picture below:
(credentials to SAP Help Documentation)
As per help documentation (which is actually very nice and complete) you'll need to do some basic customizing (under IMG -> CRM -> Transactions -> Settings for Service Requests -> Notification Framework) such as setting number range and system parameters to make this framework work.
Additionally, you need to schedule a report CRM_NF_CORE_QOUT_PROCESSING with appropriate variants for background processing of the notification queue.
Along with that, the help document says that your middleware must be active and the processing of BDocs for the relevant business objects is active as well. This middleware stuff actually stuck me up. Everything seemed to be in place. But no queue entries had been created during the transactional change. But note 1818151 - ITSM Enhancement - Setup of Notification Framework helped. And the magic words "middleware must be active" mean that functional module CRM_NF_MW_1ORDER_ADAPTER must be active in SMW3FDCUST to perform actual comparison and write queue entries.
After that, we need to enable this framework to serve new business object type. This one requires a new entry in IMG -> CRM -> Transactions -> Settings for Service Requests -> Notification Framework -> Define Conditions of Subscription Processing. Put a desired business object type and provide handler class. Do not forget to activate this entry in Send Notification on Change field. Under Notification Filters of the new entry you can put UI filters along with table name, field name, description and framework logical criterion (about this one see below). These filters will be available when you'll create a subscription for this new business object type.
Handler class needs to implement interface IF_CRM_NF_API_REF_BOR_HNDL. Class CL_CRM_NF_CORE_OTYP_HNDL_1O can suite as an example. But it has some restrictions to overcome. If you need new filters then you'll need to implement your own class (it's better to create inherited one from the standard class). Personally, I redefined GET_F4_VALUES method to provide appropriate search helps (in the same manner as it's done in standard method but simply create a redefinition to make the new method available and not only inherited), GET_OPERATORS - to provide available operators for new filters (the same reason as the previous one). Also, you might need to redefine BUILD_SEGMENT_KEYS method in case you want to provide additional tables or complex logic in joins. But I did not. And the main adjustment has been done to PERFORM_COMPARISON method. It was needed because in standard delivery the system assumes that each filter can be used only once in conditions. For instance, you can not set conditions in the subscription as the following one (for simplification): if Process Type equals 'ZPR1' OR Process Type equals 'ZPR2'. There is even a comment in the code:
* if any 1 check fail, then the entire check fail
So the system will process two values of the same filter with AND logical operation. You can find my implementation of PERFORM_COMPARISON method at github where I implemented in my opinion more suitable logic (e.g. different filters are connected with AND but criteria for the same filter are connected with OR).
In general, this framework is very customizable.
You can redefine handlers for communication channels. Or even define a new one (web services or APC for example :wink: ), but the number is restricted to 5 additional channels currently. In standard delivery SMS, E-mails and CRM alerts are supported. Certainly, you can freely redefine these standard handlers. Also, there is a standard implementation for SERVICE1 channel with BAdI BADI_CRM_NF_CHN_OUTPUT_FILL available (even with two standard implementations).
You can define new subscribers types with appropriate handlers. Or redefine existing ones. Business Partner, Organization Unit and User are available by default. Recently SAP introduced a new subscriber type DR "Dynamic recipient" with OSS Note 2161849 - New subscriber type 'Dynamic recipient' for Notification Framework. Quite a useful by the way.
That's almost all what I'd like to mention about customizing. The last thing is Framework Logical Criterion I promised to describe earlier. You set it during UI filter creation in Conditions of Subscription Processing. This criterion (actually string variable) helps to distinguish similar tables/fields by an additional parameter. For example, it can store a particular partner function if you want to define a filter for table PARTNER.
Within this framework, there is an option to directly subscribe to a particular document. So you can just press a button on overview screen of a document and you'll get notified about any changes made to this document. The function is implemented in service requests (e.g. component/view SRQM_INCIDENT_H/IncidentOV). There is a Subscribe/Unsubscribe button in place. Technically it uses three methods of BTAdminH entity:
- checkNf to check if subscription already exists;
- subscribeNf to actually subscribe to the document;
- unsubscribeNf to delete a subscription.
All methods are implemented in CL_CRM_ADMINH_RUN_BTIL.
From subscription perspective, this direct subscribing function creates a subscription with the condition: 'Process type' equals current process type of the document AND Transaction Number equals to current document object id. But also direct subscribing function requires some additional default settings made per process type in IMG -> CRM -> Transactions -> Settings for Service Requests -> Notification Framework -> Define Defaults for Direct Subscribing. Here you set if the subscriber should be set as BP (if the search for BP of current users fails the framework will create a subscription for a user). Also, you set default validity in days to restrict the time period within which the subscription will be valid. And you can make a choice to include transaction id and/or user id and/or creation date in the description of the subscription. Under channels, you define which channels are used and with which mail forms as templates in such a direct created subscription.
So if you want to bring this direct subscribing functionality to your new business object type UI then you'll need to implement this Subscribe/Unsubscribe button in the similar way as it's done in SRQM_INCIDENT_H/IncidentOV.
Need to be mentioned that this framework has a pretty good API to use in your custom development. See class CL_CRM_NF_API_DOC_IL and function module CRM_NOTIF_CREATE_ASYNC_SUB as an example.
Regarding authorization. The framework uses authorization objects
- CRM_NF_API
- CRM_NF_SUB
- CRM_NF_SUP
More information about authorization concept of Notification Framework is available in SAP Help portal.
Finalizing my thoughts and opinions: this framework is much more customizable, flexible and promising comparing to any other frameworks available within SAP CRM to notify end users for some changes within the business document (actions, alerts, workflows etc.).
- SAP Managed Tags:
9 Comments
