Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

MDG-M: How To Send an Email Notification to the Requestor at Time of Material Activation

Former Member
‎04-22-2014 12:38 AM

Greetings:


I recently added Outlook email notification to our MDG-M system and thought I would share our solution.


Our business requirements are as follows:


Requirement #1:

When a MDG Change Request (work item) is sent to an approver’s workflow inbox in MDG-M, send an email to the approver’s Outlook mailbox.

Our SOLUTION: Use Extended Notification.

Requirement #2:

When a work item receives final approval and the material is activated, send an email to the person that created the CR, i.e., the requestor.

Our SOLUTION: Create a sub-workflow using transaction SWDD, and call it from our BRFplus workflows.

Although I’ll give a very brief overview of Extended Notification, the main focus of this blog is to provide detail on how I accomplished requirement #2 – send an email to the CR requestor after final CR approval.


Req #1: Email Notification to Approvers using Extended Notification


The Extended Notification method is the latest and most flexible method for creating email notifications based on work items in a person’s workflow inbox.  The configuration is not specifically a part of the MDG module.  Rather, it is a general method of monitoring work items, including those created by MDG, and then generating an email notification based on your configured schedule.

To send an email notification to each Change Request approver in my MDG workflow, I am using Extended Notification.  Extended Notification will also send an email to the requestor if a Change Request is sent back to the requestor via the MDG workflow's “Send for Revision” action (because in this case, the work item is sent to the requestor’s workflow inbox).

For sending email to approvers, I believe Extended Notification is the best solution. In contrast, using the “SendMail” method (which I describe next in this blog for requestor notification), would require a lot of additional steps to be added to my BRFplus workflow configuration, i.e., a SendMail step would have to be added after every approval step of every BRFplus workflow.  I have many CR Types (each has their own workflow) and each has multiple approval steps.  Any change in business requirements would require tedious changes to BRFplus – no fun.  So that is why I took the Extended Notification approach for requirement #1.

Although I have provided a brief overview of Extended Notification below, there is already good documentation on how to setup Extended Notification so I won’t go into detail.  Extended Notification documentation I found useful:

I found another really good document on the web titled, E-Mail Extended Notifications v1.1.pdf, but for the life of me, I cannot remember where I got it and I am unable to attach a PDF here (I also don't know the author).  If anyone knows what document I am talking about, I'd love to add a link here.

Brief Overview of Extended Notification

The Extended Notification process is comprised of two phases:

  • Selection:  The relevant work items are selected and notifications are created and stored in database table SWN_NOTIF.
  • Delivery:  The notifications are selected from SWN_NOTIF and messages are created and sent to the users.

The selection and delivery schedules require customizing via transaction SWNCONFIG.  Alternatively, the configuration can be performed using the simplified SWNADMIN transaction but SWNADMIN does not support recording of changes in a transport (and SWNADMIN does not have all configuration options).

Program SWN_SELSEN then has to be scheduled periodically.  Program SWN_SELSEN processes both the selection and the delivery, as configured via
SWNCONFIG.  Email notifications created by SWN_SELSEN, can be monitored via transaction SOST (SAPconnect).

We also scheduled a batch job to run program RSWNNOTIFDEL to physically delete records from table SWN_NOTIF that were logically marked as deleted by program SWN_SELSEN.  Our variant uses 15 days as the “Minimum Age” for deleting records.

Req #2: Final Approval Notification to Requestor using SWDD Sub-workflow

Our second business requirement is to notify the requestor when the MDG Change Request receives final approval and the Material activation is successful.  Because the Change Request work item does not go back to the requestor’s inbox after final approval, Extended Notification can’t be use for this requirement.

For this requirement, I created my own sub-workflow using transaction SWDD.  I then added a step to the BRFplus workflow to call my sub-workflow.  I am by no means a workflow expert and this is the first time I have used SWDD to build a sub-workflow.  To get started, I referenced section 3.1 of the following “how-to” document (How To...MDG-M Send an E-Mail Notification during the governance process😞  https://scn.sap.com/docs/DOC-49089

However, the problem with the above document is the example in section 3.1 only shows how to configure the Send Mail step with a single, hard-coded e-mail address.  In my case, the recipient is dynamic – I want to send the email to the person that created the change request, i.e., the requestor.  To make the recipient dynamic, a little ABAP code is required. I am not an ABAP developer so I like to accomplish as much as I can via configuration, without extra code. Section 3.2 of the above document (49089) does discuss how to accomplish the full email notification with a BADI system call.  However, wanting to avoid as much extra code as possible, I did not pursue the BADI approach.

There is also a MDG-F How To document for Mail Notification that is a good reference on how to create a workflow task that retrieves the email receiver’s ID:  http://scn.sap.com/docs/DOC-15088

My approach is a hybrid of those discussed in the above how-to documents.

Sub-workflow Overview

Below is what my completed sub-workflow definition looks like in transaction SWDD:

Note the following which I have highlighted above:

  • When creating a new workflow, SAP will give it a number.  Mine is WS99900002.  When I add this sub-workflow as a service call to by BRFplus workflow, WS99900002 is the service number that will be referenced.  This is discussed at the end of this blog.
  • This workflow has three steps:
    • Get CR Creator – This is where we had to put some ABAP code to lookup the CR Creator ID from the standard MDG Change Request table usmd120c.
    • Send Email – This is where you specify the email recipient and email content.
    • Workflow End
  • I created three workflow containers:
    • CR_CREATOR_NAME – This contains the first and last name of the CR Creator (it is not their ID).  You only need this container if you want to include the creator’s name in your email body.
    • EMAILRECEIVER – This contains the CR Creator’s ID, prefixed with “US”, which I believe tells the system the ID is a USER ID.  The “US” prefix is mandatory to make this work.
    • Change_Request – This contains some basic information about the change request such as the CR Number and CR Description. Unfortunately, it does not contain the Creator ID – that’s why the Get CR Creator workflow step is required.

Step-by-Step Sub-workflow Build

Here are the steps to create the sub-workflow in transaction SWDD.

Create Workflow Containers

In the left-hand workflow container pane, create a new container by double-clicking “<Double-Click to Create>”.

CR_CREATOR_NAME

I defined CR_CREATOR_NAME as follows:

I have checked the Import property:

EMAILRECEIVER

EMAILRECEIVER uses a standard Data Type that is available called TSWHACTOR:

Both Import and Export are checked because this container is “imported” to the Get CR Creator step (where ABAP code will set the "US" prefix and the ID), and then “exported” and used by the Send Email step:

If you expand this container in the workflow container pane, you will see that Data Type TSWHACTOR has two fields, Object Type and Agent ID:

The ABAP code will set these two values in the Get CR Creator step.  Object Type gets set to “US”.

Change_Request

The Change_Request container uses standard object BUS2250, provided by MDG:

This will provide you the CR Number, Material Number (stored in SINGLE_VALUE_OBJ) and CR Description:

Create Workflow Steps

To create a new workflow step, click the Create icon and select the Step Type from the dialog

Get CR Creator Step

The Get CR Creator step is an Activity Step Type.  It requires a Task to be defined.  I initially tried to create the Task from scratch but soon realized I wasn’t sure of all the necessary settings to get an Activity step to work.  Therefore, I decided to copy an existing task from the standard MDG workflow WS60800086.

I opened workflow WS60800086 in transaction SWDD to see the steps.  I decided to copy the task TS75707952, used by the “Check Change Request” step:

To copy task TS task 75707952, I used transaction PFTC_COP.  SAP assigned 99900005 as my new TS task number.  Transaction PFTC_CHG can then be used to maintain your new task:

The only three things I have changed in my copy of the task are the Name, Work Item Text:

And created an EMAILRECEIVER container with the same definition as that which was defined in my workflow (described earlier):

After creating the task, you can now go back to SWDD and add the Activity step called Get CR Creator to your workflow, and assign it your new task - in my case, task TS99900005.

Next, click the Binding button to define the binding:

Here is the binding I have defined for the step.  The CHANGE_REQUEST is passed into the step so that the CR Number can be retrieved by the Program Exit (our ABAP code).  The two EMAILRECEIVER attributes will be populated in the Program Exit and passed back out of the step:

The code written by our ABAP developer for the Program Exit class is attached to this blog - see ABAP Code to Get Email Receiver.txt.  The code retrieves the CR creator's ID from table usmd120c.  Again, I am not an ABAP developer so I am not including the steps to define the class.

Once the class is defined, you will reference it in the Program Exits tab of the Get CR Creator step.  We named our class CL_WFEXIT_REQUESTER_EMAIL:

Send Email Step

Next, add a Send Mail step to your workflow.

The Recipient Expression will be &EMAILRECEIVER& - this is our EMAILRECIEVER container.  Define your Subject text and Body text.  In my case, I am including the expressions to display the CR Creator, CR Number, CR Description and the CR Material Number:

Click the Insert Expression button below the Subject or body, to get a list of available expressions.

Workflow End Step

Lastly, add the Workflow End step, which is an Event creator Step Type.  For the Container Element, choose your Change_Request container which uses BOR Object Type BUS2250.  For the Event, choose SUBWORKFLOW_PROCESSED:

Click the Binding button and bind CHANGE_REQUEST to _EVT_OBJECT:

Add Sub-workflow to BRFplus Workflow

In the MDGIMG (under Process Modeling > Workflow > Rule-Based Workflow > Define Change Request Steps for Rule-Based Workflow), I created a new Change Request Step for my Rule-Based Workflow:

I named the new CR Step “Send Email” and defined it as CR Step Number "11":

Next, run transaction USMD_SSW_RULE to edit your BRFplus workflow.  Because I want to send an email to the requester upon successful activation of the material, in the Single Value Decision Table, I changed the row for Previous Action “31 (Activation successful)”.  I used the new Condition Alias “20” (any unused number) and for the New Chng. Req. Step, selected the new CR Step “11 (Send Email)”:

In the Non-User Agent Decision Table, Condition Alias “20” was added with a Process Pattern of “03 (Call Sub-Workflow)" and the Service Name equal to my sub-workflow created via transaction SWDD, i.e., “WS99900002”:

Recipient’s User Profile

Each user that will receive email from the sub-workflow must have their email address entered in their User Profile (transaction SU0) and the Communication Method must be set to INT E-Mail.

Basis Configuration

In addition to the configuration described above, your Basis team has to configure external delivery of email from your SAP system using transaction SCOT.  I am not a Basis person and there is other documentation out there on this so I won’t go into any of the SCOT detail.  We have the SCOT batch job scheduled to run every minute.  The SCOT batch job picks up the notifications you see in transaction SOST and sends them out.  When an email has been successfully generated by either Extended Notification or your BRF+ SendMail step, it will appear in transaction SOST with a yellow status. When the SCOT batch job successfully delivers the send request, the status turns green.


I hope this blog was useful for those of you trying to get email notification configured for MDG.

Warm Regards,

Rob Scofield

6 Comments
Labels in this area
Popular Blog Posts