All kinds of executables (e.g., user forms, database statements, or web services) that may be associated with process steps are represented by activity templates; i.e., a developer who wants to provide a new application service either needs to configures an existing activity template or implement a new one and add it to the Activity Repository. The Activity Repository then makes it available and accessible within the ADEPT2 Process Template Editor during process modeling.

Generally, an activity template provides all information to the Process Template Editor about mandatory or optional input / output parameters, as well as information about data dependencies to other activity templates. The process implementer just drags and drops the selected activity template from the Activity Repository Browser window of the Process Template Editor (cf. Fig. 1) onto the desired location in the process graph.

 

Fig. 1: Activity Repository Browser window in the AristaFlow Process Template Editor

Depending on the intended purpose of usage, an activity template can be very specific or rather generic. When using a specific template everything can be pre-defined; e.g., the number and types of input / output parameters of the activity as well as all settings. In this case, the only remaining task for the process implementer is to check whether the proposed mapping of input and output parameters to process data elements (i.e., the process variables used within this process to communicate among activities) is correct. Using a specific database activity template, for example, allows to fix the input and output parameters, the details of the database used, the connection parameters, and the fully specified SQL statement. A more generic activity template, in turn, may leave open the SQL statement, the number and types of parameters, or the settings for the database connection (in parts or even completely).

To simplify the implementation of activity templates, AristaFlow offers several levels of abstraction. At the lowest one, it provides a so-called Execution Environment for each kind of basic operation supported by AristaFlow. For example, AristaFlow offers execution environments for SQL statements, Web services, EXE files, BeanShell scripts, basic file operations, and system-generated forms. However, the implementation of an execution environment requires some knowledge about AristaFlow internals and, therefore, will typically not be the task of an ordinary application developer, but will be performed by system implementers.

An execution environment defines the set of methods needed to interact with the AristaFlow runtime system as well as to implement the operations and facilities that shall be provided by the activity template. An activity template for database access, for example, may allow the user to specify connection details as illustrated in Fig. 2.

 

Fig. 3: Database activity template with predefined SQL statement

In general, the AristaFlow runtime environment needs some information about the runtime behavior of the activities; e.g., whether or not they may be aborted, suspended, or undone. The implementer of an activity template has to implement interface methods that inform the AristaFlow runtime environment which of these facilities are supported by the activity. For this case he must also provide the implementation of this functionality.

The task of implementing a new activity template will be simple, if it can be based on a generic activity template. In this case, the implementation is essentially reduced to putting the appropriate entries into the set of forms representing the activity template. For example, if a database activity template shall be implemented which selects a tuple from a predefined relation in a predefined database based on a primary key value, one form will fix the required input parameters and the output parameters for the attribute values of the tuple, a second one the database connection (cf. Fig. 2), and a third one the SQL statement (cf. Fig. 3). Fig. 1 lists examples of specialized activity templates which offer different kinds of operations on a customer table.

 

Fig. 3: Database activity template with predefined SQL statement