Skip to Content
Technical Articles
Author's profile photo Saurabh Srivastava
Saurabh Srivastava
January 21, 2020 1 minute read

SAP MDG – Email to Recipient for Change Request Update

Table of Contents

  1. Introduction
  2. Overview
  3. Scenario
  4. Solution
  5. Conclusion
  1. Introduction – The purpose of this document is to explain how to notify the respective user for Change request update via Email.
  2. Overview – In SAP MDG Change Request travel to the different level of approver in that system SAP provide a provision to update User (Requestor / Approver) for action or informative item.
  3. Scenario

      1. A CR reaches to Approver for action than an Email should be triggered to his work email ID so action can be taken with immediate effect.
      2. On final action (Approve/Reject /Revision) at ‘Change Request’ should be updated to CR-Creator (requestor).

  4. Solution

    To implement Email functionality, we need to follow 3 simple steps.

      1. Define ‘Service Name’ in MDG-Configuration.
      2. Mention Service Name in ‘Decision Table’(Rule Base Workflow).
      3. Handle Service in BADI and trigger Email Code.

Define ‘Service Name’ in MDG-Configuration: Goto MDGIMG(t-code) and Create New ’Service Name’.

 

Mention Service Name in ‘Decision Table’(Rule Base Workflow):  Open Decision table of desired CR.

Handle Service in BADI and trigger Email Code.

BADI : USMD_SSW_SYSTEM_METHOD_CALLER

Method :  IF_USMD_SSW_SYST_METHOD_CALLER~CALL_SYSTEM_METHOD

Its Importing parameter : IV_SERVICE_NAME

Whose value will be IV_SERVICE_NAME = ‘Z_EMAIL_SERVICE’.

 

If IV_SERVICE_NAME = ‘Z_EMAIL_SERVICE’ + Business Condition (if Any).

“  Email Function Module/Method.

Endif.

Email can be checked in SOST t-Code

   5. Conclusion: This  process will activate email functionality and system will update Approver and Requestor on  CR activity

Thanks.

Assigned Tags

      6 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo Neelesh Thackeray
      Neelesh Thackeray

      Thanks for this wonderful article and very useful information, Saurabh !!

       

       

      Author's profile photo Saurabh Srivastava
      Saurabh Srivastava
      Blog Post Author

      Thanks Neelesh.

      Author's profile photo Peranandam Chinnathambi
      Peranandam Chinnathambi

      This approach is having some dis advantages that you need to configure service for every step and development & maintenance effort is more since user frequency ask to change trigger point of email. I would suggest to use extended email notification with little bit of custom logic by including changing trigger point dynamically/email content. and also extended email notification having more advantages like integration with UWL, grouping email by use cases, dynamic change of email content etc... for more information please  some online documentation like 

      Author's profile photo Saurabh Srivastava
      Saurabh Srivastava
      Blog Post Author

      Hi Chinnathambi,

      Thanks for your feedback, I would appreciate if you can elaborate your concern,

      So far I get target point: Configure service & Maintenance. Please find my responses below

      1. Usually, Email are trigger on the final completion of Change Request.
      2. Even if the User asks EMAIL for each step approval then also we need to mention extra service name & maintain in Decision table which is a one-time activity. ( effort-wise 5% extra)
      3. The logic for email can be controlled very easily on the basis of the service name.

      Lastly: Approach suggested by you is also the prefered method, but there can be another way too which may suit to requirement.

      Thanks

      Author's profile photo Peranandam Chinnathambi
      Peranandam Chinnathambi

      Hello Saurabh,

      As I said, maintenance and development effort is high in your approach.

      Extended email notification is a re-usable framework for all kind of application which is comes with out of box capability( dynamic subscription, interaction with devices, grouping email, dynamic email content, trigger point ). however i have seen one disadvantage with this. that is, it will not send email to the non dialogue task as out of box. How ever this can be achieved with Little of custom logic by re-implementing scenario handler. So for this is the best approach by comparing all other approach( BCS call using service configuration in RBW, sub-workflow ). thanks.

      Author's profile photo Shruthi Rajendran
      Shruthi Rajendran

      Hi Peranandam,

      Could you please elaborate more on how to dynamically change the email content and recipient for each workitem using Extended mail notification framework? This concept is new to me and it would be helpful if you could share any link/guide document which contains these information.