Introduction

What can you as a marketing expert do to ensure, that the campaign mail you just sent out to your customers is being perceived and displayed in the same way you intended to? There is a huge variety of different email clients and devices, so the same email HTML can be displayed differently among several devices. A good way to provide compatibility to current HTML standards and engines is using a web browser like Microsoft Internet Explorer or Google Chrome to render the email content.

How does that work? Improving on the custom solution presented in this blog entry from Tim Nusch we implemented in our 1708 release an API and Reusable Blocks which can be used to build a customer managed View in Browser functionality in the Cloud and in On-Premise versions of SAP Hybris Marketing. In this blog you will discover its 3 components ensuring the highest possible HTML fidelity of your email campaign messages among all devices.

Use case

The general use case for your end user is quite simple:

• Receive a marketing email containing a View in Browser link
• Click on the View in Browser link
• The received email is being opened in the devices default browser

For you as a marketing expert the use case is even more simple:

• Include a View in Browser link in your marketing email

But how does that special link have to look and which functionality does the website where the link points to have to deliver? Let’s dive a bit deeper.

Component 1: Message API

Overview

With 1708 we delivered GetPersonalizedMessage, a new service endpoint to the OData Service API_MKT_CAMPAIGN_MESSAGE_SRV. Its documentation can be found on the SAP API Hub (section Service Operations) and the SAP Help Portal:

Result { d (API_MKT_CAMPAIGN_MESSAGE_SRV.PersonalizedMessage, optional) } API_MKT_CAMPAIGN_MESSAGE_SRV.PersonalizedMessage { MessageContentText (string, optional): Represents the Entire Content of a Campaign Message Represents the entire content of a campaign message. This can be HTML content as well as other types of text-based campaign message content. }

The service endpoint has two input parameters you have to provide

• CampaignOutbound: unique ID per sent mail and contact
• LinkTrackingIsDisabled: describes if links in the email content should be tracked

Generally speaking you provide the link to the original message and contact and get the corresponding HTML email in return. This is what we use as View in Browser content.

Example

Let’s look at a sample request and response to the new service endpoint. We provide an existing outbound ID (D67F8C6C54C34759D4AD80EE726B9FD815947BCB), surround it with encoded sinqle quotes (%27), disable the link tracking (true) and we receive the following API call:

https://{HostOfYourSystem}:{PortOfYourSystem}/sap/opu/odata/sap/API_MKT_CAMPAIGN_MESSAGE_SRV/GetPersonalizedMessage?CampaignOutbound=%27D67F8C6C54C34759D4AD80EE726B9FD815947BCB%27&LinkTrackingIsDisabled=true

There are 2 possible results now: the outbound ID exists in the system and you get the expected response with the HTML email content via the property d:MessageContentText:

If we provide a non existing outbound ID (e.g. 1234), we get an OData error:

 CUAN_ME/812 Page not found. CEC-MKT-BF /SAP/ API_MKT_CAMPAIGN_MESSAGE_SRV 0001 51089CA78E2503B0E005998463AD0F06 See SAP Note 1797736 for error analysis (https://service.sap.com/sap/support/notes/1797736) CUAN_ME/812 Page not found. error CUAN_ME/810 No execution run found for Outbound ID 1234. error 

Component 2: Servlet

Now you have got basically all you need: a URL which can be displayed in a web browser and contains the HTML email content. What’s missing? Consider the following drawbacks if you would include the URL above as a View in Browser link in your marketing email:

• The end user will have to provide credentials for the backend system where the OData Service is called. Just clicking the link will lead to a logon popup which is not what we want.
• The outbound ID is dynamic, meaning each contact has his own unique outbound ID per received email. We can’t just insert the same static URL in the email.
• The OData response is provided in the XML format, meaning that you will only see the cryptic XML structure and not the original HTML content rendered in your browser.
• The end user will see an error message in XML if something goes wrong down the line. Wouldn’t it be better to redirect the user to your default landing page as a fallback in case of an error?

How can you solve these issues and offer better usability for the end user? By implementing a web servlet responsible for the tasks mentioned above. There are several technical possibilities to implement such a servlet, e.g.:

• Online services as Amazon API Gateway or Apigee
• Custom web servlet with Java, PHP, Node.js, …

The servlet implementation has to deliver the features mentioned above to ensure a seamless end user experience for the View in Browser functionality and be deployed and reachable under a public URL.

We at SAP developed a small implementation example for such a servlet as a Java Servlet (in short: one single .WAR file). You as a customer can deploy that for yourself on your own webserver but also on SAP Cloud Platform (SCP). The SCP deployment is described below:

1. Activate the communication arrangement for the scenario SAP_COM_0094 with a communication user with basic authentication (for more details on that, see the documentation in the SAP Help Portal)
2. Take the URL of your cloud application upto “.com” (example: mysystem12345.s4hana.ondemand.com)
3. Append “-api” after the system ID (example: mysystem12345-api.s4hana.ondemand.com)
4. Logon to your SCP account, navigate to Java Applications and click Deploy Application:
5. A popup appears where you upload the provided .WAR file and provide JVM Arguments taken from the communication user (see step 1) and the api URL (see step 3): -DhostSystem=mysystem12345-api.s4hana.ondemand.com -DuserName=XXXXXXX -Dpassword=XXXXXXXXXXXX. Enter an application name and click Deploy:
6. Click Start on the next screen:
7. Wait for some seconds until the application switches its state from Starting to Started:
8. Click on the link with the application name you provided (see step 6) and copy the application URL:

As a result now you have got the application URL to your servlet which we will use in the next step, inserting the View In Browser link into the marketing email. Communicate the URL to the user responsible for the email creation, e.g. via email.

Important: If you would like to use the implementation example provided by SAP (servlet file uploaded with step 5), just add a comment below this blog post or send an email to [email protected].

Component 3: View in Browser link

Now you have got an accessible URL to the web servlet responsible for mapping the parameters to the OData Service, changing the HTTP response type for browser rendering HTML content, providing credentials and redirecting to the fallback URL if an error happens. Let’s suppose your servlet URL looks as follows (it’s the same from the step before):

https://www.myservlet.mydomain.com

Before you insert that link as a View in Browser link, you could provide the desired fallback URL base64 encoded as URL parameter or the servlet could have that URL implemented per default. If you decide to append the fallback URL to the link above, it could look like this:

Servlet URL: https://www.myfallback.com Base64 encoded: aHR0cHM6Ly93d3cubXlmYWxsYmFjay5jb20= Appended to servlet URL: https://www.myservlet.mydomain.com?FallbackURL=aHR0cHM6Ly93d3cubXlmYWxsYmFjay5jb20

Remember that the parameter name FallbackURL is completely arbitrary, only the called servlet has to parse and decode it to redirect there in case of an OData Service error. Now insert a regular link in your email in Content Studio, assign the URL and check Append Outbound ID:

If Append Outbound ID is checked it is provided in sent emails via the parameter sap-outbound-id in the View in Browser link. Its value has to be passed to the OData Service as parameter CampaignOutbound by the servlet implemented the step before. Uncheck Trackable for Campaign Analytics because you don’t want to track the View in Browser link itself.

Bonus: Reusable View in Browser link

Do you want to use that View in Browser link you just created in multiple emails, e.g. always in the email header? Define the block as reusable and you can reuse it in your marketing emails without further effort:

Just drag and drop the newly created block in your message:

More documentation to Reusable Blocks is available in the SAP Help Portal.

Conclusion

You should now be able to understand the technical details regarding the API based View in Browser functionality in Content Studio 1708. If you are interested in a SAP managed implementation, check out one of the next releases… ;-).

Do you like this blog entry? Share on your favorite social media :-). Questions, feedback or additions? Leave it in the comments!

References

• Similar blog post about View in Browser (but without 1708 API)
• OData Service documentation SAP API Hub
• OData Service documentation SAP Help Portal
• Reusable Blocks SAP Help Portal
• Servlet via Amazon API Gateway
• Servlet via Apigee