Correspondences & Mail forms: Made for each other

[Former Member]

Is this for me: This is about outbound emails. Read the pain points in the first bullet list and look at the results at the end to determine if you should spend time here

Introduction: Emails are a great way to connect with customers and provide them with pertinent information. SAP has many different ways of sending emails and choosing the best way for your client depends on many factors. Our client is in the midst of a digital transformation (aren’t we all...or am I late to the party?). The idea behind this post is to help those who may embark on a similar exercise in the near future. The approach I outline here uses IS-U & CRM (only Business master data replicated).

Background: The client is not happy with the state of affairs. The only way we(the client) reach out to our customers is through letter post. When was the last time you read one?.. We do emails but for a few isolated processes using a few standalone applications. This gives rise to the inevitable question: Can we use SAP for this: with undertones of 'but its so complex', 'will it be user friendly',  and 'we don't know what we will get'?. This was going to be the first major project for the client after the upgrade, plus it was part of the foundation to their digital transformation. We(the consultants) were committed to do our best and deliver something that hopefully exceeded expectations.

Since the requirements were somewhat open ended, the first step was to understand the clients needs and pain points. We already had some idea based on the existing situation and we conducted sessions to get the complete picture. Now this is a list of our client's pain points but it may read like its yours :smile: :

• Multiple small applications, no single source of truth
• No visibility into the content being sent, no metrics
• Manual data entry, unfriendly, generally clunky
• Need for something better (undefined)

The following requirements came from our clients:

• The current design needs to continue working: not all customers may have an email address or we may not have it
• Don't break things: Touching the existing correspondence (FI-CA) was a no-no as the regression testing itself would overwhelm available resources
• It just works: like Apple or magic or..

Apart from addressing these pain points, we had to brainstorm the better. Through our session (all my great ideas were stricken through, but I am sure some of you can use them ), we came up with the following definition of better:

• Scalability: The solution should be able to handle a lot of volume and spikes
• Extensibility: To extend outputs to other channels when needed (such as SMS) etc.
• Retention & Retrieval: Outbound communication need to be stored and viewed
• User friendliness: The customer should be able to handle most content changes themselves
• User friendliness: Random redirects to pictures of baby animals in the CIC, which will definitely reduce stress
• Standards Compliant: HTML is the standard.
• Exceptions: Stable therefore low exceptions and plugs into current exception handling
• Reporting and controls
• Replace the company logo in the CIC with a mini-game, preferably Pac-Man..what ? whyy ? Google does it too, you know

Design: Based on these considerations, we looked at various options available within SAP to send emails. We decided that an integration of Correspondence and mail Forms was the most appropriate choice for our use case. It seemed to deliver most of the major functionality via standard code.  Correspondence was a natural choice because of the no-regression clause but it had other things going in its favor as well.

• Correspondence
  • Built to handle volume
    
  • Has the hooks in the right places  for triggers and other things(BTEs, FQEVENTS etc.)
  • Some logic resides in the application form (EFRM) and we did not want to duplicate it
  • Can leverage existing exception handling processes
  • Some reporting was already built in

• Mail forms
  • Again, built for high volume
  • Standards based: yay! now an agency or the client can work on the templates
  • User friendly: No weird interface to intimidate users. WSYIWYG

The high level design we converge on was to integrate the mail Forms with the correspondence framework via RFC. The correspondence framework supplies the triggers and the data and the Mail forms does the rendering and output. We also had to build a fair amount of custom stuff: retention, review, versioning etc. but more on that later.

Code: Here we only cover the major objects and on a high level (otherwise there simply is too much to cover).

• Mail Forms: The component is available in many standard roles (e.g. SALESPRO). We added it to our custom work center by adding the following link groups to our new work center. (Don't forget to activate them in the role if you doe the same)
  

           

• Attribute Context: An attribute context is a structure that we use to supply data to our mail form. While we created a new one, any suitable exiting structure should suffice as long as it has the fields we need. It needs to be added to customizing:

         

• Mail form: We created our mail form and assigned the attribute context to it . Its easy enough to change it later (in case its not defined).
  

         

          The WYSIWYG editor is nice but you can switch to the 'source' mode (blue button) and pasteHTML direclty (such as provided from an                agency). Text elements can be dynamic based on values in the attribute context and adding attributes (dynamic values) is something your client can                also do, once the right attribute context is defined.

         

              Many other blogs cover this in excruciating detail, I have found them to be a useful resource.

• Lets start composing our emails. Our data & triggers reside in ECC while the email composition is done in CRM. This is very obviously solved by an RFC. here is the import signature of our RFC and it returns an BAPIRET_2 erro message if one occurs:

IV_SENDER	TYPE	AD_SMTPADR	Sender email address
IV_PARTNER	TYPE	BU_PARTNER	Partner/Account
IV_MAILFORM_ID	TYPE	CRMT_PML_ID	Mail form ID
IT_RECEIVERS	TYPE	Table of type SRADDRESS	Receivers (To, CC, etc)
IT_INPUTFIELDS	TYPE	CRMT_ERMS_NAME_VALUES	Context Attributes values: Key value pair
IV_ACTIVE_VERSION	TYPE	XFELD	( Version : custom functionality)

          We need to string together two Function Modules within our RFC ' CRM_ERMS_MAIL_COMPOSE' & ' CRM_ERMS_MAIL_SEND'. Sample code:

         

• Transformation: The RFC needs a key value table from ECC. Since our print form also contains application logic, it would be best if we could somehow simulate the print and get the key values without actually invoking the print. This is achieved by the following code.  Set the parameter LS_PRINTPARAMS-GET_XSF to true to get the 'canonical XML representation' wrapped in the smartform  (<sf> </sf>) tags.

         

          The "smartform parameter" name above can be determined by looking at the interface of the output  smartform linked to the printform. So some valid                values  could be mail_sender, user_setting or v_date

         

• Custom Functionality: The rest of the functionality below is custom

• Extensibility & triggers: With composition take care of, we need to integrate the functionality i.e. call the RFC when the output is triggered. There are many hooks available and each is very specific but generally its a event (BTE or FQEVENT). We may call the RFC directly from our hook but with extensibilty in mind, we create an interface that is implemented by channel specific handler classes. The hook then reads the channel configuration and invokes the appropriate method to trigger the output. Currently, we only implement handlers for the email channel but adding another channel such as SMS is as easy as defining a new handler class and adding it to the configuration.

• Retention: We store the key value pairs generated in the transformation step in the DB within a cluster table (history table). The DB is updated with the trigger of the output in the previous step. We also created a versioning system for the mail forms. The key advantage to this approach is that we don't need to  store generated  emails. The stored key value pairs can merged on the fly with the active in time version to render the output sent to the customer. Each output aslo gets assigned a 6 character alpha numeric key to uniely identify the corresponding instate to the customer/CSR and is rendered inconspicuously. This plays an important part in the next step.

• Retrieval: The client and its CSRs now have an insight into what was sent to the customer. A custom view was made available to the CSRs based on the history table. The view has one click actions to view the HTML and reissue the email. To do this we pass the stored key value pairs to CRM via an RFC which calls the previousl used 'CRM_ERMS_MAIL_COMPOSE' FM to render the HTML. This HTML( parameter iv_body ) is now cached in the SAP server with a unique URL and is rendered within an iframe. The 6 character alpha numeric key is used to construct a unique url for the email.

         

Result: We were able to hit all our checkboxes. We are self reporting that we got a lot of postive feedback from out client (and some cake too) :smile: . The solution is working without any reported issues (which always makes me wonder if its being used at all, but we even got responses from our customer at our no-reply box so it must be).

Here are some pixelated pictures( email & cic view):

Alternatives: What are some possible alternatives for those without CRM? Is roll your own a good option? Using the SAP BTF editor and something like WWW_HTML_MERGER. Not that I would recommend it ever

Next Steps: Our client want some emails to be manual with in-place editing. This will be challenging as (far as I know) SAP doesn't have such functionality. A couple of possibilities are to use a view with dynamically generated XML or IFRAME where the HTML is rendered with input fields instead of content. I am not relishing the thought of either of those options. has someone done something similar? Is there a better way?