Errorhandling and Performance Settings for Journey Builder Custom Activities

 

Salesforce updated the capabilities of custom Journey Builder activities and now provides a full code example for a regular activity as well as a split acivity. New features include performance optimizations and a couple of error handling options.

In yesterday’s “Technical Marketers Monthly Meeting” members of the Journey Builder team at Salesforce gave an update on new features and best practices for custom activities, that I’d like to highlight in this article.

New Configuration Options

As already mentioned additional settings have been introduced. Two of them address error handling and are already available and the one scheduled to be generally available in Q3 2020 addresses performance:

  • Timeout
    Specify the amount of time in ms, that you want Journey Builder to wait on an answer of the execute route (between 1,000 and 100,000 ms)
  • Retry
    Specify the number of times you want Journey Builder to retry your request (up to 5 times)
  • Retry Delay
    Note: hasn’t been mentioned in the webinar on these enhancements, but can be seen in Salesforce’s GitHub repository. From the name one can guess that it sets the time between the defined number of retires.
  • Parallel
    Specify the concurrency a single worker node can send requests to your service. Note: This is scheduled to be available in Q3 2020

To use these features, add them to your config.json in the execute-object nested in arguments (the following snippet only includes the new options):

{
	"arguments": {
		"execute": {
			"timeout": 90000,
			"retryCount": 5,
			"retryDelay": 100
		}
	}
}

Performance and Production Readiness

Also mentioned in the webinar, but nothing new are some considerations for your implementation. These aren’t specific to custom activities, but also apply to them. So this section is just meant as a refresher if you need it. If not, feel free to skip ;)

In order to have a stable solution you should do some performance testing of your API implementation. Here is a rough guideline for a good activity backend:

  • should be able to handle more than 150 concurrent requests
  • response time should be less than 50 ms and shouldn’t noticeably increase with higher load

You can use any API load testing tool to test the performance of your activity’s backend (Apache JMeter would be an appropriate example).

To ensure optimal reliability and performance you should also consider using automatic scaling, which most cloud service providers like Heroku, Amazon Web Services, Google Cloud Platform, etc. offer. Furthermore, as with any application, adding application logging and service monitoring is also a good idea in order to be able to closely monitor availability/uptime, performance, application errors, possible attacks, etc.

Use Cases

If you are new to custom activities, here are some common use cases that could require a custom activity:

Channel Integration

  • Print/Postal Service Providers
  • Twitter
  • Analytics
  • …

Control Flow (custom decision splits)

  • Based on external engagement data
  • Based on external loyalty engine data
  • …

Inbound and Outbound data

  • Trigger loyalty engine
  • Fetch coupon codes
  • Fetch account balances
  • Feed data into business intelligence systems
  • …

Technical Marketers Monthly Meeting

If you are a Marketing Cloud architect, developer or tech-savvy user, I highly encourage you to attend the “Technical Marketers Monthly Meetings”, where members of the Salesforce Marketing Cloud engineering and product teams talk about interesting topics and features they have profound knowledge of. With these insights you can get the most out of the platform for new use cases and optimize your current setup. There is also a Q&A session at the end to make sure everyone gets the information they need.

If you have any questions regarding this webinar series, get in touch with Guilda Hilaire from Salesforce, who is always happy to help.

Code examples on GitHub

Webinar Recording

If this summary motivated you to check out the whole webinar, the recording is available online here.

Written on April 24, 2020