SWN_SELSEN Notification based on Email Templates

[MateuszAdamus]

Introduction

Hi and welcome to my next SAP Community blog post.

As some of you may know, SWN_SELSEN is a standard report used for sending workflow related notifications. The report provides extensive customizing via SWNCONFIG transaction, which, for example, have been described in this SAP Community blog post: Sending Mail using Extended notification.

One of the options open for customizing are message templates and handlers. These give a possibility to create a custom handler based on a fully custom logic contained in an ABAP class. Thus allowing developers to implement and create notification emails based on specific needs.

Today I would like to present you a custom class which enables usage of HTML Email Templates with SWN_SELSEN report.

Disclaimer: the class implements only a simple scenario, in which there is one message per notification and all notifications are in English. Additional development might be required for more complex scenarios.

Implementation

The custom class should implement IF_SWN_MESSAGE interface. This will allow the system to use it for the notification creation.

In my case the class inherits from the standard CL_SWN_MESSAGE_STD class, which is used by the SWN_SELSEN as the default message template handler (check the SWN_SELSEN configuration section below). This way the class has the interface implemented already and you can focus only on changing the logic where it is required.

And by "where it is required" I mean the IF_SWN_MESSAGE~BUILD method mostly. This method is used to build the body of the notification email and this is where the logic using email templates is implemented. Below you can find what I thought as the most important parts of the logic, the rest is available in the class uploaded to the GitHub repository.

Finding the email template

As you can see in the code presented below, logic tries to find the email template twice:

1. First, it looks for a template containing the ID of a single WF task. This gives you a possibility to create different email templates for different tasks in the same WF definition;


2. Second, it looks for a template containing the ID of a WF definition. This is in case of notifications sent on WF definition level. This can also be used as a fallback, if an email template for a specific WF task is not found.

In both cases the logic looks for an email template which name has a:

• "YY1_" prefix - this is a standard prefix used for email templates in Fiori application;


• "_CRT_ALL" suffix - again, this is a standard suffix used for email templates which are to be used regardless of the result of a WF action.

You should change these (the prefix and the suffix) if you have a different naming convention in your system.

DO 2 TIMES.

  CASE sy-index.

    WHEN 1.

      CHECK ld_task->task IS NOT INITIAL.

      DATA(lv_template_name) = |YY1_{ substring( val = ld_task->task off = 2 ) }_CRT_ALL|.

    WHEN 2.

      CHECK ld_task->top_task IS NOT INITIAL.

      lv_template_name = |YY1_{ substring( val = ld_task->top_task off = 2 ) }_CRT_ALL|.

  ENDCASE.



" ...



ENDDO.

Generating the email body

If the email template is found the logic generates the body of the email. For this a table with the key values for the template is prepared (here the assumption is that the key has only one field: "WORKFLOWTASKINTERNALID") and email template is rendered into the M_SUBJECT and BODY attributes of the class.

If your CDS view, on which the email template is based on, has more than one, or different, key fields, you need to modify this part of the code accordingly.

DATA(lo_email_api) = cl_smtg_email_api=>get_instance( iv_template_id = |{ lv_template_name }| ).

DATA(lt_cds_key) = VALUE if_smtg_email_template=>ty_gt_data_key( ( name = 'WORKFLOWTASKINTERNALID' value = lo_notification->app_key ) ).

			

lo_email_api->render(

  EXPORTING

    iv_language = 'E'

    it_data_key = lt_cds_key

  IMPORTING

    ev_subject = m_subject

    ev_body_html = body ).

As you can see the email template is rendered in English language.

Configuration

After you've finished implementing the message template handler class you need to let the SWN_SELSEN report know, that it is to use the new class, and when to do it.

For this you need to make two simple steps in the SWN_SELSEN configuration (transaction SWNCONFIG).

1. Define a message template with the new class as the message template handler.
   You can change the handler for the default message template, but I would suggest to create a new custom message template, and assign it later to the WF notifications you are sure you have the email templates prepared for. This way the system will send the notification with the standard logic by default, and with the new logic for the ones you prepared email templates for.To define the new message template go to "Message Template" section in the configuration, copy the standard message template and change its name and handler class (as shown in the image presented below).
   


2. Assign the newly created message template to the notification category you want to use it for.
   For this, go to "Assigned Message Templates" section in the configuration and select the newly created message template in the "Message Template" column (as shown in the image presented below).
   

And you're done. After these two steps the system should be sending the email notifications based on the email templates for the WF tasks you configured them for.

Summary

As you can see, with the use of a simple ABAP class and some configuration you are able to use email templates with the workflow notifications, thus simplifying the process of the design of email layouts.

You can download the solution from GitHub. Let me know your thoughts in the comments.