| Implementation Issues |
|
|
The mapping of business process models to XPDL-documents is the basis for the development of a prototype for software-generation. The underlying vision is the automatic generation of software (i.e. executable programs) out of models. To achieve this goal, we used the following approach:
|
- Creating business process models using MEMO-OrgML
- Extending the business process models by workflow-relevant information
- Mapping each business process model to an XPDL-document
- Executing the processes on the basis of the XPDL-document using a Workflow-Engine
(including importing the XPDL-description into the WfMS and customizing the WfMS)
|
|
MetaEdit+ 4 and the
Shark Workflow Engine by Enhydra were used in order to develop a prototype for software generation.
(Download: Patch for import in MetaEdit)
|
| Implementing a modelling language using MetaEdit+ |
We implemented a MEMO-OrgML modelling tool using MetaEdit+. MetaEdit+ is a tool for the development of modelling tools and currently available in version 4. Basic concepts of MetaEdit+ are objects, relationships, roles, and diagrams.
- Objects represent the nodes within a diagram.
- Relationships represent the edges between (or connecting) objects.
- Roles specify additional information on the appearance of an object in a given relationship.
- Proper combinations of objects via relationships using roles are defined in diagrams.
|
| Implementation of MEMO-OrgML |
The two most important diagram types of MEMO-OrgML have been implemented: Decomposition of processes and Process models.
A process-decomposition-diagram expresses decomposition-relationships between processes. Every composed process consists of several elementary and/or composed processes. Every composed process has the role of a composite in the context of decomposition. Every subordinated process (with respect to a decomposition-relationship) plays the role of a part. A part can either be another composed process or an elementary process.
A composed process used in a process-decomposition-diagram can be further specified by a process-model-diagram. Such a diagram can be connected to a given model-element by a so called explosion. An explosion is a concept given in MetaEdit+ that allows for the connection of an object in a diagram to another diagram. This concept can be used to connect a composed process with a process-model-diagram. (Please refer to the corresponding research report for more details and examples.)
|
| Implemenation of additional diagrams |
In order to map a business-process-model to an XPDL-document, missing information has to be added to the business-process-model. The section on conceptual mapping describes rules for mapping the concepts of MEMO-OrgML to the concepts of XPDL. Since the language concepts of MEMO-OrgML have not yet been documented thoroughly, we decided - for practicality reasons - to extend the existing process modelling concepts by additional diagrams representing the information required for valid workflow descriptions in XPDL. Two diagram-types have been added to achieve this goal: workflow-specification-diagram and workflow-activity-specification-diagram.
A workflow-specification-diagram supplements a business-process-model with workflow-related abstractions. This diagram-type contains objects of the following types:
- Workflow Process: A workflow-process contains a reference to a corresponding business-process. Usually, the corresponding business process is a composed process which in turn consists of other business processes and their control-flow. Business processes are mapped to XPDL-activities according to the rules given in the section on mapping. Additionally, a link to the documentation of a business process and the annotation of extended attributes is possible.
- Workflow Participant: A workflow-participant is an XPDL-specific concept and determines the actor of a workflow. Such a participant is associated with an organisational unit in MEMO-OrgML and is supplemented with extended attributes and a participant-classifier. Possible classifiers are the ones given in the section on workflow modelling
- Workflow Application: An application is the specification of a workflow-related tool. Such a tool can either be an internal procedure or an external application (the section on workflow modelling). The application-object in a workflow-specification specifies a unique identifier, name, and formal parameters of a workflow-application.
- Workflow Information: A workflow-information-object specifies information used in a workflow and can be seen as a variable. This specification consists of a unique identifier, a name and a data-type as well as a default-value and other XPDL-related fields (refer to the section on mapping).
A workflow-activity-specification-diagram is associated with an elementary process (using an explosion). The workflow-activity-specification describes the workflow-application as well as actual parameters used for the execution of such a process. Generally speaking, a workflow-activity-specification-diagram relates a process to an application and the assignment of actual parameters. Hence, an activity-specification associated with a process binds an application to workflow information. Additionally, it is specified whether an application is an internal procedure or an external tool.
|
| Top |
| Generation of XPDL-Documents with MetaEdit+ |
The mapping of MEMO-OrgML-models to XPDL-conformant workflow-definitions is realised using the code-generation mechanisms of MetaEdit+. MetaEdit+ includes a language for the specification of mappings between internal models and external textual specifications.
Every workflow-process-specification is mapped to one XPDL-file. The header of the XML process-definition-language-based file starts with the XML-header (determining the XML-version and character-encoding). The WfMC recommends the generation of at least one package for each XPDL-file [Nori02, p. 19]. (For details about the structure and syntax of the headers see the corresponding research report.)
Every generated XPDL-file consists of exactly one package-definition and one workflow-definition included in this package. The workflow-definition consists of the following sub-definitions:
- data-fields
- participants
- applications
|
- activity-sets
- activities
- transitions
|
The specification of data-fields, participants, and applications is derived from the workflow-specification diagrams. Afterwards, the activity-sets are generated based on the workflow-specification-diagram. There will be an activity-set for every composed process in the decomposition-diagram (except for the root-process). The root-process is mapped to the package specification and the workflow-process-specification. Every composed process which is part of a decomposition of the root process will be mapped to an activity set. Each activity-set contains the herein included processes as well as their transitions.
|
After the generation of the headers, the workflow-process' data-fields, participants and applications as well as activity-sets, MEMO-OrgML processes are mapped to workflow-activities. Every process (composed or elementary) is mapped to exactly one activity using the direct mapping exemplified here and following the rules given in the table to your right.
- A manual process is performed by a human being and requires no IT-related resource. Hence, the corresponding activity-specification requires a workflow-participant and does not allow the annotation of a workflow-application. The workflow-activity has to be started manually (indicating the beginning of the execution of the manual process) and finished manually (end of process) as well.
- A semi-automated process also requires a participant but a workflow-application has to be specified, too. It has to be started and finished by the human participant.
- An automated process will be started and terminated automatically (by the WfMS). It does not necessarily need a participant (it can be annotated) but requires a workflow-application.
- A block-activity contains a set of activities (an activity-set) and does not require a participant or an application. Hence, a composed process is mapped to a block activity (as well as to an activity set containing its subsequent processes).
|
|
| Manual process | Participant: required
Application: not applicable
Start-mode: manual
Finish-mode: manual |
| Semi-automated process | Participant: required
Application: required
Start-mode: manual
Finish-mode: manual |
| Automated process | Participant: not required
Application: required
Start-mode: automatic
Finish-mode: automatic |
| Composed process | Participant: not required
Application: not required
Start-mode: not applicable
Finish-mode: not applicable |
|
|
|
A transition between two workflow activities corresponds to a followed-by relationship. A transition starting in activity A and ending in activity B means, that activity B can be started after the termination of activity A. Information about the kind of control-flow is not part of a transition-specification. Nevertheless it will be part of the activities' specification. Another conceptual difference between process-models in MEMO-OrgML and XPDL-activities is the absence of events in a workflow-specification. The mapping of MEMO-OrgML's control-flow to XPDL-transitions will be explained using an abstract example in the figure below.This example consists of four processes and three events. The process called A is followed by event No. 10 which in turn results in the parallel (or concurrent) execution of processes B and C. The termination of process B is connected to the occurrence of event No. 11 and the one of C to the occurrence of 12. If both events occurred (parallel join), process D can be started.
The generation of transitions is based on a simple algorithm: Every MEMO-event will be mapped to at least one transition. There will be one transition for every combination of starting (from) and ending (to) points. Event No. 10 given in the model above will for example be mapped to two transitions: One transition from A to B and one from A to C. The unique identifier of each transition is generated by concatenating the identifier of the preceding process, the event's id and the identifier of the succeeding process. The information about the type of control-flow is associated with the preceding process. The split-transition-restriction of process A is set to AND. The events 11 and 12 will be mapped to one transition each and the join-transition-restriction of process D is set to AND.
|
| Top |
| Using Shark/Enhydra as Workflow Engine |
An open-source workflow-engine implemented in the programming language Java has been used for the execution of the XPDL-files. The Shark-engine fully supports the XPDL-standard of the WfMC and provides the association of workflow-participants with concrete users as well as the association of workflow-applications (in XPDL) with procedures.
|
| Mapping participants to users |
Workflow-participants can be declared using the XPDL-concepts presented here. Different types of participants are
- Resource (also: resource-set; a set of resources)
- Role
- Organizational_Unit
- Human
- System
The Shark-engine provides a mechanism for the association of participants with specific users of the WfMS. This is applicable if the type of the participant is a resource (resource-set), role or organisational unit. Depending on the context, the role of an escalation coordinator for example might be assigned to a specific user and reassigned to another user after the reorganisation of the company. If a participant cannot automatically be mapped to a Shark-user, the activity will - by default - be assigned to the administrator. If the type of participant is Human the participant will be mapped to a WfMS-user with the same name. For example: A workflow-participant of the type Human and with the name jjung will be associated with the local user (say: in the Enhydra Shark-engine) named jjung. If the participant's type is System, the actor is assumed to be a software-system and the activity is performed by a workflow-application. Hence, the association between workflow-participants and WfMS-users generally has to be defined by an administrator. Such an association can be omitted for human participants and software systems. In the latter cases an automatic assignment is provided by the workflow-engine.
|
| Updating workflow data |
The XPDL-standard provides no mechanism for the manipulation of workflow-relevant data except for the execution of workflow-applications. The Shark-engine allows for the manipulation of data by using extended attributes in the context of workflow-activities. The relevant extended attributes are listed as follows:
- Name: VariableToProcess_UPDATE - Value: <workflow-data>
- Name: VariableToProcess_VIEW - Value: <workflow-data>
The first attribute specifies data which can be manipulated in a workflow-activity and the second one only allows for the display of a variable's value. The symbolic identifier <workflow-data> has to be replaced by a specific workflow-data's name.
|
| Mapping workflow applications to procedures/appliations |
A workflow-application is specified in an XPDL-file by an application-declaration (as explained here). Such a specification only includes a symbolic reference to a concrete application. Generally, the WfMC distinguishes between a procedure (an application implemented within the WfMS) and an application (an external piece of software). The current version of the Shark-engine only supports internal procedures implemented in Java. The association of a workflow-application to a procedure is provided by the Shark-engine. Every application included in an XPDL-specification has to be associated with a Java class which is under the control of the Shark-engine. Such a Java-class has to be placed in the storedprocedure-directory of the Shark-installation and has to implement a public static method called execute without a return parameter.
|
| Top |
