Part III Tool Support & Case Study
9.3 Concepts Supporting Parametrization and the Creation of
Local and Global Variables
To simplify variant creation, local variables can be defined within a transition, using the transition configuration dialog. Each variable has a name, a type, and a value. Name and value must be a string, and possible types are “text”
or “SQL”. The variable values are not allowed to contain references to other variables. At design time, placeholders for variables (e.g., “$(s1)” for variable
“s1”) are inserted by the developer in the execution string. At run-time, when the transition occurs, the DWE replaces the placeholders by the string values bound to the respective variables3. The variables are evaluated in the order of definition, and the placeholders are replaced with the respective value also in this order. This replacement is done before the execution string is executed.
For a variable of type “text”, its name is bound to a fixed string value, e.g., the variable “master” in Fig. 9.5 is permanently bound to the string “2”.
Such variables (which are actually constants) may help to convey the meaning of certain parameter values within the execution string.
For a variable of type “SQL”, a valid SQL query is specified at design-time in its value field, whose result after execution in the database must be a string.
At run-time, the name of the SQL-type variable is bound to the string which results from the execution of the query. For example, the query associated to the variable “ProgAppend” in Fig. 9.5 could evaluate at run-time to the string
“c:\coreassets\HelperPrograms\pptAppend.exe”, which is obtained from the respective relation in the database.
A similar dialog allows the definition of global variables that are accessible from all transitions in the workflow. Similar to local variables, global variables have a name, type, and value. The type can be either “text” or “SQL”, and a value is not allowed to contain references to other variables. The global variables are evaluated when the workflow execution is initiated. During the replacement of placeholders in the execution string of a transition, its local properties environment with local variables is searched first, i.e., if there is a local and global variable with the same name, the value of the local one will be taken; if a variable name is not found in the local properties but declared as a global variable, the respective global value is taken. Should the execution string of a transition contain a variable name that is neither declared locally nor globally, an error message is shown and the workflow execution is stopped.
The concept of variables, especially that of SQL-type variables that ob-tain values from the database, simplifies the variant creation for information products. Especially parameter data that is passed on to helper programs can now be stored and modified separately in the database. This data can be modified independently of the control flow structure, without having to look at the internal details of transitions. In addition, an updated attribute value is automatically used in all locations querying the respective data. Finally, the database has at the same time a documentation function.
3This corresponds to a call by value (see [Lou02, ALSU07]).
9.3 Concepts Supporting Parametrization and the Creation of Variants 157 Pre-SQL and Post-SQL Statements
Pre-SQL and post-SQL statements are SQL update statements [ST05] which can be defined within one transition (see also 7.2.3). If specified, a pre-SQL statement is executed before the execution of the respective execution string, and a post-SQL statement after it.
When a particular information product is created in execution mode, dif-ferent sets of transitions may be executed, depending on the choices made by the application engineer. Pre-SQL and post-SQL statements can be used to maintain a more detailed execution log, and to document in an automated way the features selected for a variant. For example, a pre-SQL statement could insert in the log a tuple with details on the selected features, and the post-SQL statement logs the successful creation. Using a delete statement in the pre-SQL of a transition at the start of the workflow, the execution log can be automatically cleared in case that the workflow is re-executed.
9.3.2 Helper Programs
The adaptivity of the DWE to different application areas is achieved by sep-arating the workflow engine from the programs that actually create a variant of an information product. These helper programs are called by the workflow engine (similar to [Hol95]), and their behavior is controlled by the parameters passed on to them.
The helper programs are used for example to compose a variant out of construction artifacts, to convert or copy files, add metadata, etc. Helper pro-grams can also be wrappers constructed around other applications that should be integrated into the automated workflow, without the user being aware of them. Conceptually, such wrappers are an additional software layer between the DWE and an external application. Technically, wrappers are themselves executable programs that expose a predefined interface to the DWE. When executed by the DWE, a wrapper internally calls the external application, possibly passing data to it and processing results (see Fig. 9.6). The wrapper also catches exit codes from the application after its execution and reports the success or possible exceptions to the DWE.
An example of such a wrapper is the “pptAppend.exe” program which is used to integrate the MS-Powerpoint application into an automated workflow.
This program can be called with two PPT files as parameters, and the slides of the second file are appended to the first file. Internally, this is accomplished by calling the installed Powerpoint application; this automation is based on the Component Object Model (COM) [Tur00].
Desktop Workflow Engine (DWE)
pptAppend.exe
MS Powerpoint
COM Interface
Wrapper Program
Other Application call & wait
for execution
call & wait for execution
exit code exit code
Fig. 9.6. Integrating external applications with wrappers into the DWE.