# Script activity

> [HTML Version](script-activity.html)

This type of business process activity can be used to create integrations, for example, to send requests to an external system. Business process activity settings break into three tabs: **Settings**, **Context**, and **Scripts**.

## Settings tab

On the **Settings** tab, specify:

**(script-activity-1.png)**

- **Name**. Name of the business process activity.

- **Default name.** This name is displayed on the business process activity element when it is added to the business process diagram.

- **Activity color**. The color of the business process activity shape on the process diagram.

- **Description**. The description of the business process activity’s functionality and features.

- **Outdated**. This option allows you to hide the element from the business process designer so that users cannot add it to the diagrams of new processes. Outdated actions will continue to work unchanged in already created processes. For example, you can enable the option for an activity after a module update.

- **Message if the activity is outdated**. Text of the alert informing that a process includes outdated activities. This message is shown when a user publishes a process with outdated activities.

- **Execution model**. Specify the way the activity is performed:

	- **Synchronous**. Simple execution of a script specified in the activity, i. e. synchronous execution of the \[OBJECT\] function. An action with synchronous execution can be called as a function from other scripts. For more details, see the [Call activity in scripts](#call-actions-in-scripts) section of the article.

	- **Result Request**.The system executes the specified script and sends a status request to an external service. To implement this approach in a business process activity, you need to define the \[OBJECT\] function that checks the result. The business process will continue after the \[OBJECT\] function returns \[OBJECT\].

	- **Callback**.In a request to an external service, a URL that the result needs to be returned to is passed. This means that this URL is passed as the call parameter, and this URL will be called when the external service completes the task. Results of the call will be sent to this URL. The response URL is provided as an input argument to the \[OBJECT\] function. Any request for this URL is passed to the \[OBJECT\] function. After that, the process continues

- **Number of retries in case of error**. Specifies how many times the system will try to execute the activity.

- **Retry delay (sec)\***. Defines the frequency of attempts.

## Context tab

On the **Context** tab, you can add variables that are used to transfer data between an activity and a process or app. To do this, click **+ Add** and customize the variable according to its [type](360009707032.md). Then define which variables are input and output and specify whether they are required fields.

**(script_activity_01.png)**

For the **Script** activity, you can also configure [dynamic variable creation using a script](activities-features.md#bind-via-script). In this case, the set of variables is not specified in the activity settings, but is generated when the binding form is opened. For example, this is useful for integration with external services where the set of fields may change.

In addition, you can configure a custom binding form, for example, so that an employee sees an information box with tooltips.

For more information on configuring and mapping variables, see the [Binding variables for activities in business processes](activities-features.md) article.

**Note**: Before removing unused variables on the **Context** tab, ensure they are not placed on the custom mapping form—either as standalone fields or inside a widget. Otherwise, an error message will occur.

## Scripts tab

On the **Scripts** tab, you can create a business process activity script. Scripts are written in the [TypeScript](https://www.typescriptlang.org/) programming language. If you want to know more about the basic principles of script-writing in BRIX, please visit [BRIX TypeScript SDK](https://tssdk.brix365.com/en/latest/).

By default, in an activity script, you can only access properties, processes, and API methods from the module where the activity is configured. You can grant access to other system objects in the script using [Global constants](https://tssdk.brix365.com/en/modules/_03_globals_.html). To do this, click **Settings** in the menu at the top of the page.

**(script-activity-6.png)**

You can use the following options:

- **Global constants**. Check the Global option to be able to refer to objects from all workspaces in the system and to global parameters. For this purpose, the [Global](https://tssdk.brix365.com/en/latest/pages/quick-start/intro_globals.html#global) constant is used.

````
начало внимание

````
When the \[OBJECT\] constant is used in a script, the module with this activity cannot be [exported](export_extention.md).

````
конец внимание

- ````
**Optional dependencies (available in the Imports object)**. Select workspaces or custom modules to add [optional dependencies](optional-dependencies.md) to them. They can then be accessed via the [Imports](optional-dependencies.md#use-imports) constant. When using optional dependencies, the module can be exported without restrictions.

To create a dependency, click **+Add workspace** and select a system component. Then, in the **Alias** column, give it a unique name to be used in the script. Latin letters and numbers are acceptable, and you can use an underscore to separate words. By default, the workspace code or module ID is used.

After entering the activity details, click **Save** and **Publish** in the top pane of the settings window.

With the module enabled, the activity will be available in the [business process designer](360012265552.md#process-page), on the toolbar to the right of the modeling field, on the **Integrations** tab. You can add the graphical element on the process flow chart and [configure the settings for its execution](module-action.md).

## Trace activity scripts

When an activity is published, you can collect information about the execution of its script. This helps you evaluate the duration of individual requests, optimize the code, and identify the causes of errors.

To do this, enable tracing by activity in **Administration > Developer Tools**. After that, you will be able to view the collected data by selecting the **Tracing** option in the activity settings.

Read more about enabling tracing and trace information in the [Trace server scripts](server-script-tracing.md) article.

## Call activity in scripts

In business processes, custom function libraries can be created within modules through the use of actions. Unlike API methods, actions specify input and output variables with defined [types](360009707032.md). This helps to clearly understand what types of data need to be passed when calling an action and what the result of its execution will be.

Activities of the type **Script** with the **Synchronous** model can only be called in scripts.

An activity can be used:

- Within the module where it is configured: in scenarios of other actions, API methods, business processes, and event handlers.

- In scripts of other system components that have an [optional dependency](optional-dependencies.md) on the module with this action.

To call the activity, the \[OBJECT\] property is used; it is available if an appropriate activity is published in the module. The method \[OBJECT\] is used to call it, and an object with the activity’s input variables is passed as a parameter.

When accessing the \[OBJECT\] property and the activity, the \[OBJECT\] operator is used, [optional chaining operator](https://tssdk.brix365.com/en/latest/index.html#elvis-operator-). This is necessary to handle the scenario correctly in case the action is deleted from the module.

Note that if an input variable of the activity is mandatory and has a default value, it becomes optional in the input structure of the \[OBJECT\] method. Regardless of the mandatory nature of the output variable, it also becomes optional in the output structure of the method.

As an example, consider an action that retrieves exchange rates from the Central Bank. The action has input variable: currency code (type [String](https://tssdk.brix365.com/en/latest/modules/_02_types_.html#tstring)) and current date (type [Date](https://tssdk.brix365.com/en/latest/interfaces/_02_types_.tdate.html)). The output variable is the exchange rate (type [Number](https://tssdk.brix365.com/en/latest/modules/_02_types_.html#tfloat)).

In module scripts, the action can be called as follows:

````
// Create an object for passing activity execution parameters — the currency code and current date  
let input: \{  
    currency\_code: TString;  
    date: TDate;  
\};  
  
// Create an object that will store the result of the activity — currency code  
let output: \{  
    currency\_rate?: TFloat;  
\}  
  
// Write currency code from the context, and the current date, in order to pass the date to the input variables of the activity  
input = \{  
    currency\_code: Context.data.currency\_code,  
    date: new TDate(),  
\};  
  
// Call the activity for getting the exchange rate set inside the module  
output = await Namespace.action?.get\_currency\_rate?.call(input);  
  
// Check if the result is received  
if (output) \{  
    // Get data from the object that stores the result   
    Context.data.current\_currency\_rate = output.currency\_rate;  
\}

````
An activity can also be called from a script of a component that is not part of the module. For example, from a widget that belongs to a workspace or from an event handler of another module. To do this, in the component’s script settings,set an optional dependency from the module with this activity. After this, the activity can be accessed using the \[OBJECT\] constant. For more details, see [Optional dependencies](optional-dependencies.md).

Suppose in a business process script in a workspace, you set up an optional dependency from the module in which the activity to retrieve exchange rates is configured. In the dependency settings of the module, a unique name \[OBJECT\] is set. The activity can be called from the process script in the following way:

````
// Call \`get\_currency\` activity set up in the module  
// Pass the currency code and current date to the activity input variable  
const output = await Imports?.currency\_module?.action?.get\_currency\_rate?.call(\{  
    currency\_code: Context.data.currency\_code,  
    date: new TDate(),  
\});  
  
// Chech that the result of the activity is received  
if (output) \{  
    // Write the exchange rate obtained with the module to the process context variable  
    Context.data.current\_currency\_rate = output.currency\_rate;  
\}
````