0

We are sending emails from Service Cloud by making a callout to Transactional API of Marketing Cloud. We are then writing the events response back to Service Cloud Logs(of emails/SMS sent) and update the status of Logs to sent/opened/bounced etc after the response from SFMC Event notification service(ENS).

We have a callback Salesforce sites which listens for the response and the business logic to then create a platform event. There is a trigger on this platform event which updates the status of Logs(as received from ENS). We are implementing the logic of retries(3 times) and resume checkpoint.

The issue we are facing is more often than not, the response from ENS is faster than logs being inserted into salesforce and even after retries the status is not updated for some of the logs, because the response sent by ENS is not able to find the logs to associate itself.

How could we avert this and make sure that all the responses from ENS is updated to correct Logs in CRM.

identigral
  • 7,543
  • 29
  • 32
  • 42
Chetan
  • 313
  • 3
  • 14

1 Answers1

1

You want the DML operation (insert of a Log entry) to commit before you call the Transactional API. Since DML and callouts can't coexist in the same transaction unless DML goes after the callout, you want to split these two operations into separate transactions. Sequencing these two transactions such that callout happens after DML is then possible by starting the 2nd transaction (callout) from the 1st transaction (DML). Chaining async calls via Queueable/@future is one way to do this. This Q&A is another good explanation of transaction sequencing in async context.

An easier approach is to recognize that you don't need to update the same Log entry with the results from ENS callback. There can be two separate Log entries - one that captures the request to Transactional API and the other that captures the response from ENS. You can correlate these two log entries via a variety of criteria, message ID (aka message key) being the easiest. To know the outcome of the message being sent via Transactional API, you can build a report or a page that produces a report-like output. This is where you can fuse the two Log entries into a single entity that shows a message and its corresponding send status.

identigral
  • 7,543
  • 29
  • 32
  • 42
  • I like the approach of writing two separate log entries and then corelate them later via messagekey or compositeId. But I am not sure if its worth the hassle to reinvent the current implementation. – Chetan Oct 17 '20 at 19:17
  • Also today, we are first calling the transactional API to send the message and then insert the same message logs with all the payload if there was no error in sending the messages. So are you suggesting I insert the logs before even actually sending the messages through the API?I dont think that will work because we also write the message keys(and other stuffs) to logs after the message is sent via API. Let me go through the article.Thanks for your response. – Chetan Oct 17 '20 at 19:37