Document directory
- § 2-1 workflow definition exchange
- 2-2 workflow client application interface
- § 2-3 Application call interface
- § 2-4 collaboration capability abstraction Specification
- § 2-5 WfMC audit data specifications
Overview of Workflow Reference specifications [Abstract] the workflow management system is called the next-generation enterprise business operating system. While paying close attention to the requirements and flexibility of workflow applications, people seldom pay attention to the specifications of workflow applications and the nature of application processes. This document provides an overview of the workflow reference model based on the WfMC specifications. [Keyword] WfMC activity performer process modeling business group action § 1 a workflow management system consists of the following components. (1) process definition tool is used to create a business process description that can be processed by a computer. It can be a formal process definition language or object relationship model, or a group of routing commands that simply specify information transmission between users. (2) process definition (data) contains all the necessary information for the business process to be executed by the workflow execution subsystem. The information includes the start and end conditions, composition activities, activity scheduling rules, the work that the participants of various businesses need to do, and the call information of related applications and data. (3) workflow execution subsystem (WES) and workflow engine workflow execution subsystem (business) process execution environment, including one or more workflow engines. The workflow engine is the core software component of WfMS. Its functions include interpreting process definitions, creating process instances and controlling their execution, scheduling various activities, adding work items to user worksheets, and calling applications through application interfaces (APIS; provides supervision and management functions. The workflow execution subsystem can contain multiple workflow engines. Different workflow engines execute workflows in collaboration. (4) workflow control data refers to the system data managed by Wes and the workflow engine, such as the status information of the workflow instance and the status information of each activity. (5) workflow-related data refers to data related to business process flows. WfMS uses the data to determine the status transfer of workflow instances, such as process scheduling decision data and inter-activity transmission data. Workflow-related data can be used by the workflow engine or called by applications. (6) the worksheet and worksheet handler worksheet list a series of work items related to participants in the business process, and the worksheet handler manages the interaction between the user and the worksheet. The Worksheet processing program provides the following functions: You can select a work item in the worksheet, reassign a work item, and report the completion of the work item, call the corresponding application when the work item is processed. (7) applications and application data applications can be directly called by WfMS or indirectly called through the application proxy. By calling an application, WfMS completes an activity partially or completely automatically, or supports the work of business participants. Unlike workflow control data and related data, application data is partial data for applications and invisible to other components of WfMS. 2. Reference specifications of the workflow management system the international Workflow Management Alliance (WfMC) defines a complete set of reference specifications, which consists of five interfaces. The process of building a workflow management system is a process that follows specifications and standards and is also a process of continuous innovation. § 2-1 workflow definition switching I. The interface between the workflow definition Switching Model Simulation and definition tool and the workflow management software is called the process definition input/output interface. An interface is essentially an exchange format and a set of API calls. It performs a process-defined exchange through a series of physical or electronic media. The definition exchange can be complete or partially (for example, only changing the attributes of an activity in a definition ). Using this standardized form has obvious advantages: (1) it defines a separation point between build-time and runtime, the definition generated by a tool can be used for multiple different workflow products, so that users can freely select workflow products. (2) A process definition can be used for several Collaborative workflow products to implement distributed workflow services (the exchange process definition is only one aspect of this distributed service ). The workflow definition exchange interface WfMC has made two tasks in this field.
(1) A metadata model is introduced to indicate objects, their relationships, and attributes in a processing process definition. It can also form the basis for information exchange formats between products.
(2) API calls between workflow systems or between workflow systems and definition tools provide a public way to access workflow process definitions. The access method can be read-only, read-write, or write-only, and operate on the definition of standard objects in the meta model or a specific product set (such as registering a product. 2. A basic meta-model WfMC develops a meta-model defined in the processing process, which is used to determine a group (the initial horizontal exchange in the simple processing process definition) basic Object Model. Other object models are provided by the supplier or further explored. The workflow metadata model assumes that the following types have the following attributes: workflow type definition workflow processing process name version number processing process start and end condition security, audit and other control data activity name activity type (sub-stream, automatic stream, etc) other Time Series constraints of Activity start and end conditions conversion condition flow or execution condition flow-related data Data name and path data type role name and organization entity call application type and name parameter location or access path
In a distributed service, activity distribution in the workflow engine must be specified in the processing process definition (as an attribute of the activity ). The definition of the processing involves security and management, such as privileged control and Super User management activities, and other aspects should also be considered. In the definition exchange format, it is assumed that a fuzzy symbolic naming scheme can be mapped to the real name and address of the runtime core service. This may require a dynamic address mechanism (such as through the directory service) or a mechanism other than the definition of the processing process. Other Industrial Organizations are working in this area, such as simulation and case exchange tools; the WfMC solution is developed with the joint efforts of other organizations. 3. A group of APIs in the access process definition api wapi is used to access the process definition data. We expect these specifications to cover the following common types. Commands for operating a list, individual objects, or attributes are not provided. Sessions are established between participating systems. Create/disconnect sessions. workflow definition operations get a list of workflow processing process definition names from a repository or other resource lists from the processes provided to sessions. in the definition list, select/exclude a workflow processing process that defines the highest read/write level definition object workflow definition object operations in the workflow definition create, obtain and delete objects get, set and delete object attributes workflow client function work queue the handler directly deals with users of the system, it may be provided as part of a workflow product, written by the user, or integrated with office services in a desktop environment, such as the mail and work-in-progress folders, to provide a task management system. Therefore, a flexible communication mechanism is required between the workflow core service and the workflow client application to support workflow systems composed of different operating systems. In the workflow model, the client application interacts with the workflow engine through an interface, which uses the concept of work queue. A queue with a workflow engine assigned to a specific user's work unit. In the simplest case, a work queue can be accessed by the workflow engine to grant users a work unit to be processed and obtain user processing results. The interaction between work queues is also implemented by different products. Activating a work unit from a work queue may be performed under the control of the workflow client application or user. A set of processes are defined between the workflow client application and the workflow core service, it can be used to add a work unit to the queue, remove the completed work unit from the queue, or suspend the active work unit. The work queue handler also processes application calls, either directly or with user participation. Applications directly called by the work queue processing program should be placed in the local environment, although there is no mandatory constraint. In a work queue, some activity-related data can help the work queue processing program call the application. If the data type of an application is very fixed, an association is stored in the work queue. In other cases, a complete (Application name and Path) Exchange is required between the workflow processing program and the workflow engine, the workflow client application can call APIs (Interface 3) to implement some functions to obtain necessary information. A work queue may contain multiple active instances, which may come from different processing processes. (According to different product implementation methods, each type of processing process uses a separate physical work queue, or, the work queue processing program expresses the units of different work queues to the user in a unified form .) Therefore, the interface between the client workflow application and the workflow engine must be flexible in the following aspects: process and activity identifier resource name and location data reference and data structure optional communication mechanism § 2-2 workflow client application interface meets the above requirements the path contains multiple standard API set (WAPI ), these APIs are accessed by applications, workflow engines, and work queues in a unified manner, regardless of how the actual product is implemented. These APIs and their parameters are mapped to different communication mechanisms to adapt to different workflow implementation mechanisms. (In email-based communication, the work queue processor can directly access the inbox through the local mailbox access interface, instead of calling through WAPI. In this case, the work queue processor will be responsible for filtering all non-work unit emails and performing appropriate processing. Similarly, commands or responses to the workflow engine can be directly stored in the sender. In this way, a simple interaction is realized through the mail exchange format, instead of using WAPI completely .) All the implementation methods of the client application API. The API specification is published in another WfMC document. The following only provides an overview of the APIs used by client applications. Together with the commands for operating the process or activity instance and operating the work queue. Session Creation
Create/disconnect sessions between participating systems workflow definition operations
Obtains or queries the name or attribute of a workflow processing process definition.
Create/start/end a processing instance
Suspend/wake up a processing instance
Forced state conversion within a processing instance or an active instance
Modifies or queries the attributes (such as priority) of a processing or activity instance.
Enable/disable a query for a processing or activity instance, and set filtering criteria
Obtain detailed information about the processing process or activity instance and filter the information according to the specified conditions.
Obtain detailed information about a specified processing process or activity instance.
Enable/disable a work queue query and set filtering criteria
Obtains the work queue units and filters them according to specified conditions.
Notification of selecting/re-assigning/completing a work unit
Super User Function for modifying or querying the attribute processing process of a work unit
The following functions are intended for all processing or activity instances and can be obtained under the privilege of a Super User. You may need to log on to a specific application or user .)
Changes the definition of a running Workflow Processing Process and Its instances.
Changes the status of all processing or activity instances of the specified type.
Changes the attributes of all processing or activity instances of the specified type.
Terminate the data processing function of all process instances
Obtains or returns workflow-related data or application data management.
You can use a client application to implement additional management functions supported by WAPI. Application call
The basic application calling support is achieved through the functions of the work queue processing program (such as providing access to the processing process/activity/work unit attributes and workflow-related data. Some of the application call functions are related to the client application environment. However, many workflow systems limit the scope of applications they can process. The data of these applications must be strongly typed and directly accessible (such as through directories ), for example, word processing or spreadsheet programs. In other cases, applications, such as the osi tp protocol or x.400, can be called through a standard goldmine mechanism. Some systems use the "application proxy" concept, which separates the calling method of an application from the core service of the workflow. You can also use standard APIs to develop workflow application tools for workflow core service communication (receiving application data, sending or receiving Activity events ). These APIs may be directly used by application tools or application proxies as a front-end for developers without workflow knowledge. Some interface types that can be used for application calls
| Interface Type |
Workflow-related data access |
References |
| Local process call |
Local file |
No |
| Shell script |
Local file |
XML/xpdl? |
| Orb call |
By referencing (calling parameters) |
Yes |
| Remote Invocation |
By referencing (calling parameters) |
Yes |
| Message transmission |
Built-in or by referencing |
Yes |
| Transaction |
Built-in or by referencing |
Yes |
Further discuss all possible scopes that will involve application calls. The initial work of WfMC focuses on developing a set of Interface Types and APIs for future workflow-specific applications. § 2-3 The application call interface shows the interface framework, applicable to application proxy and workflow applications.
In simple cases, application calls occur locally, and information in the processing program definition (application type and related data) is used ). The called application may be local or accessible from other locations on the network. The processing process definition contains sufficient application type and location information (required by the workflow engine ). In this case, the application name and address are local to the process definition and workflow engine. The syntax for an application to call an API will be studied by WfMC and used as a standard revenue document. The operation will be performed through several interfaces (including the above table), some of which are synchronous and some are asynchronous. The following provides the command sets that may be used by application calls. Application call interface session Creation
Establishes/disconnects application (or application proxy) Session Activity management.
(Workflow engine to Application)
Start activity (workflow engine to Application)
Suspend/wake-up/terminate an activity (used for asynchronous application interfaces)
(Application to workflow engine)
Notification of activity completion
Generate events (such as synchronization)
Query activity attribute data processing
Provides workflow-related data (the application's first and subsequent activities)
Given application data or data addresses, in more complex cases, including interaction between different types of workflow engines, application call information may need to be passed between workflow engines, it can be obtained through exchange at runtime or during the definition of the import process. § 2-4 collaboration capability abstraction specification 1. This is a WfMC standard. It provides an abstract specification to define collaboration capabilities between different workflow engines. One of the main objectives of WfMC is to develop standards for workflow systems so that different workflow products can smoothly exchange work units. The features of workflow products are diverse. When developing collaboration capability standards, WfMC does not require workflow product suppliers to discard the unique functionality of the product to provide interaction capabilities. Therefore, WfMC is committed to developing a series of interaction solutions to meet different levels of interaction (from simple task transfer to process definition, workflow-related data exchange, and complete workflow application interaction ). In this case, the initial requirement is to support simple interaction. As the situation becomes more complicated, more work is being done. Although we can consider developing complex interaction solutions to enable the collaboration between engines provided by different vendors and provide unified core services, this does not seem to be feasible yet, this requires that all engines can interpret common processing process definitions and share workflow control data between them to maintain a process state view shared between different workflow control engines. The current realistic goal is to achieve the transfer and processing process between different core services. 2. Some basic concepts of workflow collaboration: communication and collaboration between two or more workflow engines. The purpose is to organize and execute workflow instances through these engines.
Workflow Engine: A Software Service (ENGINE) that provides runtime execution environments for workflow instances ).
A workflow Flow Definition instance: An Instance defined by a workflow flow, including its automation part, is created and managed by the workflow management system.
A Workflow Management System: complete definition, management, and execution of workflow processes through software execution. The software commands executed here are driven by a computer representation of the workflow flow logic.
A workflow management system is composed of one or more workflow Configuration Services.
A workflow Configuration Service is composed of one or more workflow engines. Business Group: set of business executors that execute the same business action/activity during business flow (persons/Systems) III. Collaboration capability model WfMC defines a large number of cooperative working capability models, for example:
(1) Two or more workflow engines directly collaborate with the workflow engine (2) two or more workflow engines operate the workflow setting service in the same set service (3) two or more workflows within the scope of a workflow management system set the Service's collaborative workflow group setting Service (4) the collaboration capability of two software tools is generally achieved through the following methods:
Direct interaction between tools
Message Passing:
Workflow collaboration message transmission intermediary (in the form of encapsulation, conversion, and gateway)
The application of this method in work collaboration:
Intermediary applications for workflow collaboration
Shared storage data
Shared data storage between tools 4. Different chained processes executed in two cooperative Engines
Chained process nesting subprocess
Nested sub-process synchronization parallel cross-execution
Cross-execution § 2-5 WfMC audit data specification I. Overview the final goal of WfMC is to standardize an interface standard for management and monitoring functions. Through this interface, business Management applications can work with other engines. In this way, several workflow services can share management and system monitoring functions within a certain range. This interface attempts to provide a global view that includes the complete status information of all work flows within the Organization. This interface also includes a complete set of functions related to management, this includes security, control, and authorization considerations. Interface implementation.
System management and monitoring interface 2. audit data: information captured and recorded from various events that occur during a workflow setting service period. This information is called general workflow audit data (cwad ).
By defining the semantic specification of such data, interface 5 can be standardized to work with different workflow products. III. The name of the cwad naming convention follows the standard description in the Wapi naming convention of WfMC. In addition, the new naming convention on attributes proposes to consider the abstract specification of attributes. Iv. cwad data information cwad audit data consists of three types of information: basic data, free data, and private data. Basic data is recorded and valid for all audit functions. In this information, some defined elements are specified as mandatory or optional. If an event is recorded, mandatory elements are mandatory. Due to different product operations of workflow merchants, some audit information is not applicable and will be considered as free data. In addition to some required information, private data information is not defined and is useful to sellers and users themselves. It can include complex forms.
