Validate Your Server-Side JavaScript using WSProxy

Script activity completes successfully unless an unhandled exception or execution timeout prevents the script from running to completion. Write defensive code and consider good error handling strategies to ensure that Script activities complete or fail as expected.

Without any intervention a raised error will cause the Script activity to fail.

Use a try/catch block to handle expected errors. Errors handled in a catch block do not cause the Script activity to fail. This allows the script to take action to potentially recover from error or to log the problem for later troubleshooting. For example, a logging data extension could be created to store error timestamps, messages, and other helpful information. The catch block is an opportunity to collect error details and write them to a logging data extension. When using this type of data extension, the data should be cleaned up by a data retention policy on the data extension and reviewed regularly.

WSProxy errors are reported using a status field on the result instead of raising an exception. Use the ErrorUtil.ThrowWSProxyError function to throw an exception based on the result status.

Inspect the status and handle the error with custom logic if raising an exception is not the necessary error handling strategy.

Errors can occur due to resource constraints in the execution environment. A script activity will fail if it requires more than 6GB of memory. Be wary of failures due to loading large datasets from remote APIs or loading an entire dataset into a local variable. The best way to process large amounts of data is through batching. In batching, the data can be processed by loading a small chunk of data into memory and processing the data. Then, that data can be released, and another can be loaded for processing. It is crucial to load and process the data in chunks rather than loading the data in chunks and then processing the whole dataset together as shown in the example below.