Forschungsprojekt ECOMOD

Referenzgeschäftsprozesse und Strategien im E-Commerce

Forschungsgruppe Unternehmensmodellierung
  Mapping Business Processes to WorkflowsDiese Seite auf Deutsch  

Business Process Modelling
Workflow Modelling
Conceptual Mapping

Implementation Issues

Conceptual Mapping
On this page we present the mapping of business process model concepts to workflow descriptions in XPDL.
Workflow Process Definitions
Every workflow process definition in XPDL generally consists of activities, transitions, applications, participants, and workflow-relevant data. Hence, such a workflow process definition comprises its activities and corresponding resources. Additionally, every workflow process definition consists of two different headers and a body. The two headers are the definition header and the redefinable header (see table below). The workflow process definition header is valid for all sub-activities and a workflow process redefinable header might be overridden in subflows.
Definition Header
  • Meta-information on a process and
  • Instance-specific data
  • For example: version, temporal unit, estimated duration, priority
Re-definable Header
  • Meta-information on a workflow process
  • Properties can be overridden in subprocesses
  • For example: author, publication status
Activity Set
  • Set of activities and transitions
Workflow Process Definition Header
Attributes of a definition header for workflow processes are listed in the table to your right. The creation date is assigned to a process definition during its definition and therefore represents the definition time of a workflow schema. This information can be extracted from the modelling tool supporting MEMO-OrgML and is not part of the MEMO languages' specification. The workflow process' description can be seen as the description of the top-level process of a decomposition hierarchy in MEMO-OrgML.
The valid-from- and valid-to-attributes allow to specify a period of time for the validity of a process definition. Hence, a process definition can only be used between valid from and valid to (empty string means unlimited validity). Since there is no equivalent concept in MEMO-OrgML we assume an unlimited validity for all processes. The other attributes only contain information on workflow instances. The duration- and limit-attribute (the limit has to be interpreted by a specific WfMS and has no meaning in the context of XPDL) contain an expected duration for the execution of the given workflow-process using a specific duration unit. The time estimation is an aggregation of waiting- and working-time and duration. The waiting time corresponds to the time needed for the preparation of a process' execution and the working time correlates with the expected execution time. Those concepts are not part of the MEMO-OrgML and have to be added to a process model.
OrgML (Meta Data)XPDL: Definition Header
Creation Date (meta)Created (creation date)
Process DescriptionDescription
 -Duration & Duration Unit
 -Limit (vendor-specific)
 -Time Estimation
 -Valid From/To
 -Waiting Time
 -Working Time
Workflow Process Re-definable Header
The attributes of a workflow process redefinable header are listed in the figure to your right. The meta-information on the author of a model and its version can be derived from the data available in the modelling tool. The codepage specifies the character-set used for the presentation of texts. Country keys are specified by the ISO in the ISO 3166 standard. The publication status indicates whether a process definition is under revision (UNDER_REVISION), released (RELEASED) or in use (UNDER_TEST). Responsible(s) corresponds to an organisational unit which is responsible for the execution of a given workflow process. The responsible person can be derived from the organisational unit in the MEMO-diagram.
OrgML (Meta Data)XPDL: Re-definable Header
Modeller (meta)Author
 - Codepage
 -Country keyt
 -Publication status
Organisational UnitResponsible(s)
Version (meta)Version
Generation of headers
XPDL-workflow-headers contain information on a workflow process (e.g. author, version), process-information (e.g. description, responsible(s)) and instance-related information (e.g. duration, time-estimation). This kind of information is not part of a language specification. Instead, it can be managed by a modelling tool and then be mapped directly to an XPDL-based description. Some process information (e.g. priority) is not yet available in MEMO-OrgML and has to be added to a process' definition. Instance-specific information should not be included in a business process modelling language for conceptual modelling. However, it can complement existing business processes on a different level of abstraction.
Mapping of Resources, Applications, and relevant Information
At first sight, resources seem to be easy to map to workflow participants, workflow applications, and workflow-relevant data. However, this task is hampered by some details concerning the abstraction level of resources on the one hand and the concepts given in XPDL on the other hand.
Human Resources
According to MEMO-OrgML, a human resource is an abstraction on persons, employees, roles, or other staff-related perspectives. In XPDL, a workflow participant "is an abstraction level between the real performer and the activity, which has to be performed. During run time these abstract definitions are evaluated and assigned to concrete human(s) and/or program(s)." [Nori02, p. 43]. Mapping of an abstract actor (as given in an XPDL-description) to a concrete actor (e.g. the user of a WfMS) has to be done by the workflow-management-system.
As shown in the table to your right, the resource's properties 'name' and 'description' can directly be mapped to an XPDL-file. The properties attributes 'qualification' and 'competenceProfile' will be neglected because they have no direct correspondents in XPDL. A unique identifier required by XPDL can be generated in the context of the mapping of OrgML to XPDL. Such an identifier corresponds to an object identifier in MEMO and the generated XPSL-Id has to be unique within the XPDL-definition.
The specifications of "participant-type", "extended attributes" and "external reference" are an extension to a business process model (modelled using MEMO-OrgML). Alternatives for a participant type are resources, roles, organisational units, humans, and software systems [Nori02, p. 44].
OrgML: Human ResourceXPDL: Participant
 -Participant Type
 -Extended Attributes
 -External Reference
attributes -
qualification -
competenceProfile -
Extended attributes are name-value pairs and allow the annotation of system-specific information for different WfMS-products. (Note the difference between resource-attributes and extended attributes: A resource-attribute is a name-type-pair and an extended attribute is a name-value-pair.) The name is used to identify the extended attribute and the value contains information relevant for a particular WfMS. An external reference is a reference to an external document providing the specification of a workflow-related entity. Such a document can for example be a globally available XML-DTD (specifying the structure of a workflow entity) or a web-services interface-definition (using WSDL). All these extensions have to be provided by a workflow-specific extension to business-process-models.
The XPDL's notion of a workflow application declaration mostly corresponds to software used within a business process. A workflow application represents a software-tool required for the execution of a workflow. Every application might be invoked by the WfMS and the XPDL abstracts from concrete implementations. Every application is defined as a symbolic reference in XPDL which has to be assigned to concrete applications by the WfMS.
The resource's (software) properties 'name' and 'description' can be directly mapped to an XPDL-document. The properties 'systemRequirements' and 'scalability' will be neglected because they have no correspondents in XPDL. XPDL requires a unique identifier, which cannot be expressed in MEMO-OrgML. However, such an identifier could either be explicitly assigned to OrgML models (which would require a small extension of the language) or generated within the automatic mapping of OrgML to XPDL. External attributes and an external reference are handled equivalent to the respective attributes for Human Resources (see above).
The attribute 'Formal Parameters' corresponds to a list of single formal parameters which are specified using the following properties:
  • Id: Identifier
  • Data Type: Type of the formal parameter
  • Description: Textual description of the formal parameter
  • Index: Position in the parameter list
  • Mode:
    • IN: read-only parameter
    • OUT: write-only parameter
    • INOUT: Parameters used as in- and output parameter
The Id of a formal parameter has to be unique within the namespace of a process.
OrgML: SoftwareXPDL: Application
 -Formal Parameters
 -Extended Attributes
 -External Reference
systemRequirements -
scalability -
In the context of business process modelling, the description of information usually corresponds to the specification of information types which are used within a business process. In contrast to this, workflow-relevant data is associated with variables containing concrete information. Such variables are generally referenced by a unique name (as identifier) and correspond to a given type.
The appropriate Id for a workflow specification might be generated automatically. Name, description and data type can directly be resolved from the corresponding attributes of the MEMO-process model (see table to your right). Extended attributes have to be handled the same way as extended attributes of human resources and applications. Additionally, an initial value might be assigned to a variable. The maximum length and the property of being a collection can be determined by the attributes Is Array (the variable is a multi-valued type) and Length (upper bound of a sequence).
OrgML: InformationXPDL: Data
typeDescriptionData Type
 -Extended Attributes
 -Initial Value
 -Is Array
Mapping of Process Types
MEMO-OrgML supports several different kinds of process types, which have to be mapped to appropriate (i.e. similar) concepts given in XPDL. In MEMO-OrgML there are concepts such as composed, manual, automated, and semi-automated processes. In XPDL, there are generic and block activities. Conceptual relationships between MEMO-OrgML-processes and XPDL-activities are discussed in this section.
Manual Processes
There are various alternative options for mapping manual processes to workflows (see the corresponding research report for details). The alternative chosen comprises mapping manual processes to workflow activities. Every manual process will be mapped to an activity with a human actor and no applications. Consequently, manual processes correspond to some kind of dummy-activities in a workflow-schema. Such a dummy-activity only serves for the recognition of the completion of a manual process. The termination of a manual process might trigger the start of a following process. As an effect, every manual activity has to be confirmed in the WfMS. The described option allows mapping the process itself as well as relevant participants (human resources) to the workflow model.
OrgML: Manual ProcessXPDL: Generic Activity
organisational unitPerformer
 -Transition Restrictions:
  • Join: AND, XOR
  • Split: AND, XOR
The Id will be generated out of the manual process' identifier and the attributes name and description can be directly mapped from the process definition to the XPDL-document. The organisational unit of a manual process can be mapped to the performer of the workflow activity. The transition restriction specifies whether all incoming transitions (Join) are synchronised (AND) or alternative (XOR) as well as all outgoing transitions (Split) are parallel (AND) or alternative (XOR). This information is determined by the kind of in- and outgoing arcs of the business process models.
A parallel split will be mapped to an AND-split and an alternative split to an XOR-split. Analogously, a parallel join is mapped to an AND-join and an alternative join to an XOR-join. Information which is not included in the business process model but necessary for a workflow activity's specification is shown in the table below.
As most of the workflow-relevant data is not available in a business process model, there has to be an extension to those models. We emphasise a so called workflow-diagram for every business process which has to be mapped to a workflow schema. This diagram contains all additional information for the implementation and simulation of business processes in a workflow-environment.
DeadlineSpecification of a deadline and an action to be taken if it is reached.
DocumentationIdentifier of an external documentation file (e.g. URL or a filename).
Start ModeManual Mode: The user has to start the activity manually (indicating the beginning of his work)
Finish Mode Manual Mode: The activity has to finish according to a user's interaction (indicating the end of his work).
ImplementationNo: Implementation by manual procedures
IconReference to an external file containing an image for the representation of an activity.
LimitExpected maximum duration for the execution of a process (vendor-specific)
PriorityA value describing the initial priority of a process.
Simulation InformationEstimations for the simulation of an activity.
Semi-automated Processes
In MEMO-OrgML semi-automated processes are executed by human resources using IT-related resources (soft- and hardware). Hence, semi-automated processes rely on human and software-technical resources. Those kinds of processes can be mapped to generic activities.
Mapping of general information on a semi-automated process is equivalent to the one of a manual process as shown above. Most workflow-specific information can be generated using a workflow-diagram. Additionally Start- and Finish-Mode as well as the process' implementation have to be determined:
Start ModeManual Mode: The user has to start the activity manually (indicating the beginning of his work)
Finish Mode Manual Mode: The activity has to finish according to a user's interaction (indicating the end of his work).
ImplementationTool: Implementation is supported by an application
Fully Automated Processes
An automatic process is executed without the intervention of a human participant. Nevertheless, an organisational unit can be assigned to an automatic process, too. That means that it is responsible for the execution of this process. Basically, the mapping of automated processes can be handled like a manual process (see table). In contrast to a manual or semi-automatic process the assignment of a performer has no effect on the execution of an automatic process.
Start ModeAutomatic: Triggered by the system.
Finish ModeAutomatic: Triggered by the system.
ImplementationTool: Implementation is supported by an application
Aggregated Processes
Aggregated processes in MEMO-OrgML have no inherent implementation but consist of other processes. A block-activity in XPDL corresponds to a set of sub-activities and has no own resources. We will not use subflows, because every subflow contains its own set of performers and tools. As there is no support of name-spaces (in OrgML) we will not support the concept of sub flows. Hence, every aggregated process will be mapped to a block-activity and all contained processes are collected into an activity set.
Mapping of Control Flow and Events
The type of control flow is determined by the workflow activity's definition. All outgoing transitions of an activity are either parallel (AND) or alternative (XOR). Every join (incoming transitions) is either a parallel or alternative synchronisation. The specification of joins and splits is associated with a process' definition.
Events do not exist as specific concepts in XPDL. Hence, there is no direct correspondence between events in a business process model and a workflow-schema. Nevertheless events given in a business process model can be used for the definition of conditions for firing of a transition. As given in the table to your right an event's name and description can be mapped to an XPDL-description. The Id can be constructed from an event's Id and context. The condition has to be complemented to the activities description. Preceding and succeeding activities can be derived from the business process model.
OrgML: EventXPDL: Transition Information
 -From (set of activities)
 -To (set of activities)