With the 2024/10 update of SAP Build Process Automation, new feature “Script Task” are now available. Until now, Java Script could be used in automation (RPA), but what has been added this time is the ability to execute Java Script in a process (=workflow). This is a very useful feature, so I would like to introduce it and explain some points related to its use.
The “Script Task” is a task that can be used on a process.
“Script Task” can be added in the same way as forms.
This is an editor for editing scripts. It contains a sample, or rather example, code in commented out form. (It would be better to remove it.) You write the JavaScript code you want to execute here.
You write the JavaScript code you want to execute here.
What kind of code to write? Basically, it is “code that assigns a value to a custom variable”.
Currently, there are restrictions on what code you can write (and execute). Some of the important ones are ….
The values of fields set in forms and other forms are accessible as “read-only variables”. They cannot be overwritten.Custom variables can be read and assigned (overwritten).The language specification follows ECMA 5.1 Java Script and is executed as server-side Java Script.It is not possible to load external libraries by “import”,”require”, etc.
The value of a form or other field is information entered by the user that is also stored as a context log. Considering that the logs are used for auditing purposes, etc., I think it makes sense that they cannot be overwritten.
I have tried to access an external service in this script and get information from it, but this seems to be a difficult task, as “import” and “require” are not available and “fetch” fails due to Promise issues. If you want to access external services, you should use “Action”.
To access a form or custom variable in a script, like this
If you click on the name of a field or variable displayed in the process list, the name will be paste to the code, and you should use this.
Being able to assign to custom variables from scripts makes things like the data type conversions I wrote earlier much easier. It seems to reduce the number of steps.
Test execution of the script can also be done from this button.
However, in the case of this code, $.context.custom.customvariable1 and $.context.form_form1_1.num1 are values that should be obtained by the workflow process instance, so they cannot be executed properly. Therefore,
We need to declare and assign initial values to those variables in the Test Variable tab.
Let’s run the test.
Execution completed. The custom variable is assigned the value of the numeric type field converted to a string type and the specified string concatenated together.
A little care must be taken when running tests. If the code is selected in the code editor, only that portion of the code will be tested. This is convenient, but it may cause you to wonder, “Why isn’t it running properly?” This is a convenience, but it can also be a point of contention. If you intentionally want to run a part of the code, but not the other way around, you might want to get in the habit of clicking somewhere else to deselect the code and run it before running the test. Also, from what I have tried, it seems that this debug execution is done in the browser’s JavaScript. (From the behavior of toLocalString(), etc.). The debug execution is supposed to be executed by server-side JavaScript, so there is a difference in behavior. It may be necessary to check the formatting and deploy to a test environment to test it again.
Note that “return” is not required for scripts in script tasks. If you want to perform a calculation in this script task and use the result in the next phase of the process, for example, you must assign the result to a custom variable and use it. Therefore, in most cases, the end of the code will be in the form of an assignment of a value to a custom variable.
I played around a bit with the code editor because the auto-completion feature like IntelliSense works.
Apparently, I can use properties from SAP Workflow Management.
https://help.sap.com/docs/workflow-capability/workflow-cloud-foundry/cheat-sheet-for-workflow-expressions
Among them, there are some that cannot be easily obtained with the current SAP Build Process Automation. In fact, it is difficult to see “the time when the previous approval or application was completed” in the process. If this were to be done, it would be in the form of accessing the SAP Build Process Automation API using an action and obtaining it from the log, but this can actually be done easily.
variable to refer to the completion date and time of the form (including approvals).
(The <Formname> part is the same as $.context.<Formname>. <Fieldname> of the form, so use that.)
I have just tested that the locale-specified format/time conversion with toLocaleString() works in the test run, but after deploying, it fails to convert to JST or Japanese date format even if the locale is specified like toLocaleString(‘ja-JP’). Therefore, as shown above, we manually set +9 hours and convert the date format to Japanese one.
The date and time of the trigger cannot be obtained, so if necessary, write a script task to set the current date and time in a custom variable after the trigger.
In the past, I published an article entitled A Little Technique for SAP Build Process Automation – Variable Definitions. In that article, I explained how to set variables using Decision. In fact, it is not possible to get and set the current date and time (the date and time when the process was performed) using the Decision method. However, using script tasks, it is possible to have the date and time in a variable, which can be used to change the processing or display.
Power users, please use the script task to your advantage.
With the 2024/10 update of SAP Build Process Automation, new feature “Script Task” are now available. Until now, Java Script could be used in automation (RPA), but what has been added this time is the ability to execute Java Script in a process (=workflow). This is a very useful feature, so I would like to introduce it and explain some points related to its use.The “Script Task” is a task that can be used on a process. “Script Task” can be added in the same way as forms.This is an editor for editing scripts. It contains a sample, or rather example, code in commented out form. (It would be better to remove it.) You write the JavaScript code you want to execute here.You write the JavaScript code you want to execute here.What kind of code to write? Basically, it is “code that assigns a value to a custom variable”.Currently, there are restrictions on what code you can write (and execute). Some of the important ones are ….The values of fields set in forms and other forms are accessible as “read-only variables”. They cannot be overwritten.Custom variables can be read and assigned (overwritten).The language specification follows ECMA 5.1 Java Script and is executed as server-side Java Script.It is not possible to load external libraries by “import”,”require”, etc.The value of a form or other field is information entered by the user that is also stored as a context log. Considering that the logs are used for auditing purposes, etc., I think it makes sense that they cannot be overwritten.I have tried to access an external service in this script and get information from it, but this seems to be a difficult task, as “import” and “require” are not available and “fetch” fails due to Promise issues. If you want to access external services, you should use “Action”.To access a form or custom variable in a script, like this$.context.<Formname>.<Fieldname>Note that the value of the trigger (form) must be following.$.context.startEvent.<Fieldname> However, instead of typing directly, use the right side of script editior. If you click on the name of a field or variable displayed in the process list, the name will be paste to the code, and you should use this.Being able to assign to custom variables from scripts makes things like the data type conversions I wrote earlier much easier. It seems to reduce the number of steps.Test execution of the script can also be done from this button.However, in the case of this code, $.context.custom.customvariable1 and $.context.form_form1_1.num1 are values that should be obtained by the workflow process instance, so they cannot be executed properly. Therefore, We need to declare and assign initial values to those variables in the Test Variable tab.Let’s run the test.Execution completed. The custom variable is assigned the value of the numeric type field converted to a string type and the specified string concatenated together.A little care must be taken when running tests. If the code is selected in the code editor, only that portion of the code will be tested. This is convenient, but it may cause you to wonder, “Why isn’t it running properly?” This is a convenience, but it can also be a point of contention. If you intentionally want to run a part of the code, but not the other way around, you might want to get in the habit of clicking somewhere else to deselect the code and run it before running the test. Also, from what I have tried, it seems that this debug execution is done in the browser’s JavaScript. (From the behavior of toLocalString(), etc.). The debug execution is supposed to be executed by server-side JavaScript, so there is a difference in behavior. It may be necessary to check the formatting and deploy to a test environment to test it again.Note that “return” is not required for scripts in script tasks. If you want to perform a calculation in this script task and use the result in the next phase of the process, for example, you must assign the result to a custom variable and use it. Therefore, in most cases, the end of the code will be in the form of an assignment of a value to a custom variable.I played around a bit with the code editor because the auto-completion feature like IntelliSense works.Apparently, I can use properties from SAP Workflow Management.https://help.sap.com/docs/workflow-capability/workflow-cloud-foundry/cheat-sheet-for-workflow-expressionsAmong them, there are some that cannot be easily obtained with the current SAP Build Process Automation. In fact, it is difficult to see “the time when the previous approval or application was completed” in the process. If this were to be done, it would be in the form of accessing the SAP Build Process Automation API using an action and obtaining it from the log, but this can actually be done easily. $.usertasks.<Formname>.last.completedAtvariable to refer to the completion date and time of the form (including approvals).(The <Formname> part is the same as $.context.<Formname>. <Fieldname> of the form, so use that.)I have just tested that the locale-specified format/time conversion with toLocaleString() works in the test run, but after deploying, it fails to convert to JST or Japanese date format even if the locale is specified like toLocaleString(‘ja-JP’). Therefore, as shown above, we manually set +9 hours and convert the date format to Japanese one. The date and time of the trigger cannot be obtained, so if necessary, write a script task to set the current date and time in a custom variable after the trigger.In the past, I published an article entitled A Little Technique for SAP Build Process Automation – Variable Definitions. In that article, I explained how to set variables using Decision. In fact, it is not possible to get and set the current date and time (the date and time when the process was performed) using the Decision method. However, using script tasks, it is possible to have the date and time in a variable, which can be used to change the processing or display.Power users, please use the script task to your advantage. Read More Technology Blogs by SAP articles
#SAP
#SAPTechnologyblog
