How to Handle Script Task Limit Exceeded Error in process Automation for Email Body Generation

[#1]

Hello Experts,

I am working on an automation in SAP Build Process Automation (BPA) where we need to fetch data from an API and include it in the body of an email. Without the use of Agent.
Here’s the scenario:

• We are using an HTTP action to call the API and retrieve the data.
• A script task is used to convert the API response (which contains a responseArray with multiple EDIDC and EDID4 objects) into an HTML table to be used as the email body.
• The script generates the HTML content and stores it in the context variable $.context.htmlTable.

However, we are facing an issue because the data size exceeds the 100 KB limit for the script task in BPA, 
"Script Task" failed
Error message: Execution of task 'script_1' has been stopped while executing the statement [<...], as it reached the time limit

. The API response can contain a large number of records, and converting this into HTML is causing the script to go beyond the allowed limit.

Here is the script we are using

// Step 1: Get the API response

var responseArray = $.context.action_get_getZidocZidoc_1.result.responseArray;

// Step 2: Validate response

if (!responseArray || responseArray.length === 0) {

throw new Error("No records found");

}

// Step 3: Escape HTML

function escapeHtml(text) {

text = (text === null || text === undefined) ? "" : String(text);

return text.replace(/&/g, "&").replace(/</g, "<").replace(/>/g, ">");

}

// Step 4: Build table rows

var rows = "";

for (var i = 0; i < responseArray.length; i++) {

var edidc = responseArray[i]["EDIDC"] || {};

rows += "<tr>" +

"<td>" + escapeHtml(edidc["DOCNUM"]) + "</td>" +

"<td>" + escapeHtml(edidc["IDOCTP"]) + "</td>" +

"<td>" + escapeHtml(edidc["MESTYP"]) + "</td>" +

"<td>" + escapeHtml(edidc["CREDAT"]) + "</td>" +

"<td>" + escapeHtml(edidc["SNDPRN"]) + "</td>" +

"<td>" + escapeHtml(edidc["RCVPRN"]) + "</td>" +

"<td>" + escapeHtml(edidc["STATUS"]) + "</td>" +

"</tr>";

}

// Step 5: Final table

var html = "<h3>IDOC Report</h3>" +

"<table border='1' cellpadding='5' cellspacing='0'>" +

"<tr><th>DOCNUM</th><th>IDOCTP</th><th>MESTYP</th><th>CREDAT</th><th>SNDPRN</th><th>RCVPRN</th><th>STATUS</th></tr>" +

rows +

"</table>";

// Step 6: Store in context

$.context.htmlTable = html;

Could you please suggest a solution or workaround to handle this limit exceeded error? Some ideas we are considering include:

• Splitting the data into smaller chunks and processing them in multiple script tasks.
• Using an external service to generate the HTML and call it via an action.
• Any other best practices or standard approaches in BPA for handling large datasets in script tasks.
  

  Any guidance or examples would be greatly appreciated. Thank you!

[CarloBoarotto]

Hi,

I have the same problem, because I was asked to implement a process that has to parse a CSV file coming from an external service and extract some information from specific columns.

After some research I have found that this problem has been reported as a BPA Issue: problem: https://userapps.support.sap.com/sap/support/knowledge/en/3593613

Considered:

• the difficulties and restrictions to implement proper scripting (see https://help.sap.com/docs/build-process-automation/sap-build-process-automation/restrictions-on-scri...),
• no debugging functionalities: you can't use console.log() to write to the process log,
• the lack of proper libraries, for instance I wanted to use the JS function atob (you can use it in HTML pages <script>) to convert Base64 content but it wasn't allowed,
• the poor testing functionality, for instance there is no way to save the variables used for testing and debug and a lot of test execution timeouts (you have to exit the test and the test variables are lost!),

I will strongly suggest to implement a micro-service written in Node.js and deploy it to Cloud Foundry. BPA processes should be only used for the Actions (calling your micro-services), Forms and Approval Forms. Or if you are familiar with UI5/Fiori I would suggest you to write your own interface to have more flexibility.

I have the impression that the No-Code or Low-Code approach is only valid for very basic tasks...

Cheers,

Carlo