Execute script

This interface can be used to execute scripts in FirstSpirit and classes originating from (customer-specific) modules (so-called “public executables”).

What are public executables?

Public executables are executable implementations that are installed on the FirstSpirit server via a module and executed via the schedule management.

For further documentation see Public (→Manual for Module Developers).

Script (Dialog)

Name

A new name for the script can be specified in this field.

Text form field

The script code (or an executable class) to be executed in this action is entered in this field.

The following applies to executable classes: After installation of the module, these executable implementations are available on the FirstSpirit server and can be called up at this point using a schedule entry script.

Public executables can be called by their name or by their class name.

Example: If the component definition in the module descriptor is:

<public>
    <name>DeploymentExecutor</name>
    <class>de.espirit.module.DeploymentExecutor</class>
</public>

Then the executable class is called here by the name:

#!executable-class 
DeploymentExecutor

or alternatively by the class name:

#!executable-class 
de.espirit.module.DeploymentExecutor

Properties button

Clicking on the Properties button opens a new dialog where the properties of this script can be edited. This is important, for instance, if the script is to carry out change actions in the project (e.g., create or modify objects).

Script properties

Connection

If required, this dialog can be used to establish its own connection to the server instead of using the current session to execute scripts.

Own connection (see fig. (1)): if this option is selected, a new server connection is established using the following data for executing the script.

User: the user name to be used to log on to the server.

Password: the password corresponding to the user specified above.

If the Own connection box is checked, the editorial permissions of the user specified here are evaluated and taken into account when executing the script.

It is possible to execute schedule entry scripts via the system connection, e.g.:

context.getUserService();

The variable context provides a special connection that only offers read-only access. This type of connection is used by scripts that have been configured without special user information. Only the operations that do not make changes can be executed using them. Otherwise, a security exception will cancel execution of the script.

If change operations are to be carried out in the project using a schedule entry script, the schedule entry script must use the specified user's login information. This user must have the relevant permissions (e.g. CAN_CHANGE, APPEND, DELETE, etc.) and must first be defined via the script properties (see above). A user-specific connection (based on the stored user information) must then be made within the script using the connection variable, e.g.:

connection.getProjectById(context.getProject().getId()).getUserService();

The schedule entry script then runs based on the specified user's permissions and evaluates its editorial permissions (e.g. for creation) for every changing operation.

If change actions in a script (within the schedule entry) are executed on project properties, this script has to be executed based on either the user's server or project administrator permissions.

Parameters

Parameters (see fig. (2)): all parameters are entered here that are to be taken into account when executing the script.

Scope of the parameters: Parameters are placed into the global context. This allows passing on and using the parameters in various scripts.

For all parameters, a name should be chosen that is unique server-wide. Background: Due to the global scope, scripts executed in parallel may overwrite parameter values if parameters of the same name are used.