A workflow has a clearly defined start point, a set of one or more activities and a clearly defined end point. A workflow can be initiated by an employee, a business application (such as an electronic form from an Electronic Data Interchange system), an event (such as the time of year, a stock market event), or another workflow. Workflow management is the definition and automated control of business processes according to a set of rules.

AdminFlow is based on an object model compliant with the Object Management Group Common Object Request Broker Association (OMG CORBA) specification for a distributed object environment. It utilizes a fully recoverable, relational database running the AdminFlow Engine as a state machine built for speed and reliability.

Within AdminFlow, the Process Engine decides what action needs to be completed as a result of workflow process definition and the Resource Executive decides who (or what) completes the action. In other words, the Resource Executive identifies the process participant. The Resource Executive makes this decision using the information about your organization that you provide to it, plus the rules that define how to obtain the information. These rules are referenced within the process definition. Having allocated a resource to an action, the Resource Executive returns the resource information to the Process Engine and the Process Engine sends the work item to the process participant.

Separating the what activities from the who activities provides for maximum flexibility in the workflow system. For example, you can have multiple Resource Executives if one becomes a bottleneck for the Engine.

AdminFlow supports more than the simple concept of a "role" and extends this to an organizational management hierarchy enabling rules such as "send this to the first person above the sender who is authorized to sign off $10,000." By employing both role and organizational services, AdminFlow allows the complete decoupling of the process from the people who do the work.

AdminFlow also provides two types of client interfaces for users: a web client interface and an electronic mail client interface.

AdminFlow can be considered as following a four-tier architecture, where the tiers are:

This is an Oracle database and holds information relating to the Engine, Data Dereferencer, Audit Logger and Engine. A schema defining the data for these components is provided as part of your AdminFlow system. Typically, an AdminFlow implementation has one AdminFlow Server, one or more Worklist Servers, each on a separate system, and/or a number of e-mail users accessing the AdminFlow system through an E-mail Feeder.

The following sections describe the AdminFlow components in more detail.

The Engine stores and manages all the information about the work in progress within your workflow system. It executes workflow definitions, identifying the activities that need to be completed. The Engine has the master store of the work items that are being processed in the system, therefore if a work item is lost for any reason it can be resubmitted by the Engine.

Early workflow systems combined activity-related data, resource information and the processes, as one unit. Within AdminFlow:

Many simple workflow systems are based on messaging systems combined with electronic forms packages. The AdminFlow model using an Engine and Resource Executive in combination with e-mail systems and Web servers, provides a far more reliable and flexible system than the simple messaging-based workflow systems. This is because messaging-based workflow systems cannot use organizational services in the same way as AdminFlow does; they rely on specific e-mail addresses directly related to individuals to route work items. Therefore any changes in the organization require modifications to the e-mail addresses within the electronic form, making the system potentially unreliable and costly to administrate. In addition, you cannot collect status information from an e-mail-based workflow system, which means the system cannot recover from a failure, nor can it guarantee information is not lost.

Having an Engine allows you to record events and statistical information about your workflows and as a result improve the workflow processes that you have designed.

In order to execute workflow processes, AdminFlow first needs the processes to be defined. You can enter process definitions using ProcessWise WorkBench. ProcessWise WorkBench provides a graphical interface that you can use to create and modify your process definitions. Process definitions must be in a form that the Engine understands, so by using a tool, such as ProcessWise WorkBench, you make sure that your process definitions are correct before they are loaded into the Engine and executed.

A process definition can be a simple, single path, definition, or a more complex multi-path definition, which has decision points. When you create a process map, you define the data flow within the process, that is, the data items that you want to use for the process. You must define all the data items that are required to complete each activity. These data items and their characteristics are collectively known as a Case Packet. The fields shown in the figure below are items found in the Case Packet.

The process definition also contains information about the resource that is responsible for completing each activity within the process. Resource Rules are used to identify suitable resources for an activity. For example, if an activity requires a resource of Manager, there should be a Resource Rule called manager to define how to find an employee’s manager. Some rules are provided with AdminFlow, and you can also define your own.

You can also assign log levels within a process definition. These log levels specify the granularity at which activities are logged in the events database. The information logged provides the basis of the administration and monitoring tools supplied with AdminFlow.

The Data Dereferencer provides two functions within AdminFlow.

The first is to remove data not required by the Engine for processing work items before the work items are passed to the Engine. The Data Dereferencer then replaces this data when the Engine sends a work item out to be addressed.

The second is to manage the custom forms required for particular activities, such as initiating a process.

The application specific data and custom forms are stored in a repository. The Data Dereferencer provides the interfaces between the Engine and the repository. The following diagram shows the logical division between the application specific data and the custom forms. Both the application data and the custom forms are stored in the same database, but they are completely independent of each other.

When a user is sent a work item, resulting from an activity, which needs a custom form, the Data Dereferencer adds the custom form for the activity. These custom forms are taken from the forms repository, where they were placed as part of defining the process.

Work items are routed to each of the users, systems or applications that need to action them. The Data Dereferencer adds forms and attachments to and removes attachments from these work items. The Data Dereferencer removes the attachments before the work item is handed over to the Engine and replaces the attachments when the work item is routed from the Engine to the next participant in the workflow. This maximizes the efficiency of the Engine by removing all information not required by the Engine when processing work items. This also allows users to participate in workflows when they are off line as the work item is always complete, that is, all related forms and attachments are part of the work item.

The Resource Executive is the AdminFlow component used by the Engine to assign resources to activities. These activities are specified when the process is defined, as part of the process definition.

The activity definition includes information about the type of resource that should complete it. The Engine gives this information to the Resource Executive. From this information, the Resource Executive selects a Resource Rule, which can be used to identify a suitable resource. In the example of a Travel Request, the request might need to be sent to a manager who has authority to sign off the $5000 request. In this case, there is a Resource Rule to define how to identify this resource. The Resource Rule specifies which Resource Agents are responsible for resolving the function. These Agents then identify the traveler and their manager (who might need to be at a particular level to authorize the request) using organizational information in the Resource Repository. The Agents then identify the manager’s mail address from the Mail Directory and gives this information back to the Resource Executive.

To summarize, rules specify which Resource Agents the Resource Executive should use to assign resources, and what those agents will do. What the agents are able to do is determined by the functions they provide. Through rules, the Resource Executive makes function calls to Resource Agents, which then perform the work defined in that function and return resource information to the Resource Executive. A function is a type of query on an information source, for example, mapping an employee number to an employee name.

The figure below shows the web page that the appropriate manager would see:

In order to make decisions about who, or what, should complete an activity, the Resource Executive and the Resource Agents need access to information about your organization, such as, employee numbers, employee names, organizational hierarchy information and contact addresses (for example, e-mail addresses). You need to decide how you are going to make this information available. You might decide to enter all your resource information, including the information that you have in your own organizational database, into the Repository Schema, or you might decide to split your resource information across the Resource Repository and your own database. This decision is based on the amount of data and how often it changes.

As an example, if you have a small amount of static data, you would probably maintain this data in the Resource Repository, where it is automatically available to AdminFlow. However, if you have a large amount of data, or your data changes frequently, you can choose to keep it in your own repository, and supply your own Resource Agent functions to access the data in your organizational database. You can do this by modifying the Resource Agent functions supplied with AdminFlow. The Resource Repository and tools for entering information into the Resource Repository, are supplied with AdminFlow.

Resource Agents are used by the Resource Executive to access specific repositories and manipulate resource information. The Resource Executive selects a resource (or resources) to complete an activity by executing rules. These rules contain a series of calls to functions, which are supplied by Resource Agents. You can provide rules, which specify the Resource Agent to use to resolve you own resource queries. Rules are also supplied with AdminFlow.

Resource Agents interface to specific types of information source, for example, the Oracle Resource Agent uses the Oracle directory. The Oracle Agent is an example of an external agent. External agents are used to access data repositories that are external to the AdminFlow system.

The Oracle Agent is used by the Resource Executive to obtain resource-related information from an Oracle database. This resource information might be, employee badge numbers, employee’s name, contact information or organizational hierarchy information. AdminFlow provides a basic schema for an Oracle database. The schema defines the data required for a typical AdminFlow system, and is used for the example processes provided with AdminFlow.

Using the Resource Repository schema optimizes the communication between the source of information and the Resource Executive. Your organization’s existing databases will be optimized for its own applications, and might not provide all the information required by AdminFlow. However, if you think the information that you have in your existing database is suitable, you can use your own database by modifying the functions of the Oracle agent. You can also write your own SQL procedures for the Oracle agent and add them to the Oracle agent function table.

Before AdminFlow can execute the processes you define, it must be able to access the resource data required for these processes. This is necessary as the Resource Executive needs to access resource information when it assigns a resource(s) to a role. You must make sure that your resource data is available to AdminFlow. The Resource Repository schema defines a basic set of resource information, which is used in the example processes provided with AdminFlow.

Note that it is very likely that your organization will need additional resource information for the processes that you define. The Resource Repository schema has some scope for being extended, but you might need to use your own information source as a repository for your resource information. The Resource Repository schema is not intended as an enterprise-wide information source.

The Resource Repository schema is designed for a relational database. The advantages of using a relational database, such as Oracle, are that it allows you to upload from existing data sources, provides easy data replication to a central repository and easy access for management from HTML and Java.

For AdminFlow, a workflow client is a component that you can use to interface with AdminFlow to action your work items. There are other clients that you use to monitor and manage the AdminFlow system.

AdminFlow provides two workflow client interfaces:

Work items are sent from AdminFlow to your client. This is either to a queue at the Worklist Server, or a mail folder for an e-mail client. You can then request your current list of work items from your client as required. When you have completed a particular work item, it is returned to AdminFlow for processing.

In order to start a process at your workflow client, you need a template for the process. You therefore need to have a copy of the templates for all the processes that you want to initiate locally at your workflow client. Updates to these templates are automatically sent to the workflow clients.

You have the option of building your own AdminFlow clients or extending the functions of the clients supplied with AdminFlow. As an example, you could add a function to your client that allows you to suspend, or hold, a workflow and start a secondary workflow. You might want to do this if you have been asked to sign off a large amount of money as part an activity, and you want to obtain comments and votes from other people.

The following web page would be presented to the appropriate travel agent:

The same information does not have to be presented to each user. Fields in the form (case packet data) can be individually set to read-only or modifiable at any activity in the process. It is also possible to provide a different subset of the case packet data at each activity of the process and merge them together before completing the process. This allows process participants to focus on information that is relevant to them. The following figure shows the final result of the process. The initiator of the process would see this web page.

The Worklist Server provides the Web interface to AdminFlow and gives you direct access to AdminFlow from your Web client. If no user-defined forms are supplied, the Worklist Server dynamically generates forms, referred to as META forms, to present the user. The Worklist Server stores work items for users in work lists and provides the framework for supporting and managing multiple users. In particular using the Worklist Server you can:

You can have more than one Worklist Server in your organization; for example, you could have a Worklist Server for an individual building, or business function. In order to keep network activity to a minimum, each Worklist Server holds a copy of the template work items for all the workflows that its users will want to initiate. These template work items are requested by the Administrator on behalf of the users of the AdminFlow system and processed by the Template Server.

The Administrator for the Worklist Server is responsible for making sure that new and updated templates for workflows are always available for their users.

Work items can be sent to a shared work list or a personal work list, and individual users can have both. In the case of a shared work list, any one of a team of users can select individual work items from the shared work list. When the work item is selected, it is moved to the user's personal work list. All work items in a shared work list are visible to other members of the group. However, when a work item is selected from the shared work list, it is locked, so another user cannot access it. Shared work lists are useful for teams who are working on a common business function, for example, dealing with Travel Requests.

This is the e-mail interface to AdminFlow. You use an e-mail client to either access AdminFlow directly, or you can use e-mail when you are off line. For example, if you are using a laptop computer to work away from the office (subject to your e-mail system supporting disconnected clients).

Work items are delivered to your e-mail client’s incoming mail folder, in box, or filing cabinet. Templates for workflows that you want to initiate are also delivered to your incoming mail folder; these templates are delivered to you automatically. When you open an e-mail message containing a work item and then open the work item attachment, the AdminFlow E-mail Plug-in is run to present you with the work item. When you have completed the work item, it is sent back through the e-mail system to AdminFlow. If you are working off line, the work item is sent to AdminFlow when you next connect to the network.

The E-mail Plug-in:

There are several management client interfaces to AdminFlow, which enable you to manage all aspects of your AdminFlow system. These interfaces allow you to:

There is a web-based AdminFlow System Administration interface, which you can use for managing the AdminFlow system. Using this interface you can:

AdminFlow provides three interfaces to monitoring your workflows. These are graphical interfaces and you can display monitoring information as a bar chart or in the form of a process map. All the monitoring interfaces are Web-based. This means that you have the flexibility to modify the HTML files, and therefore the interfaces, to suit your own requirements. The AdminFlow Audit Logger maintains information about workflows. The audit information is divided into personal, process and system information as follows:

This allows you to track individual processes that you have initiated and are involved in. As an example, you might have two Travel Requests being processed. A summary of these processes is displayed to you on request. The Process Tracker is designed for particular users to track what is happening with their workflows. Tracking information is also accessible through the Worklist Server.

This allows you find out everything about a particular process. For example, these might be all instances of a Travel Request processes, or all instances of an Expense Claim processes. You can also obtain statistics relating to the status of processes from this interface, for example information about backlogs.

The Business Process Monitor is designed for use by the person who is responsible for the individual processes, and making sure that they fulfill the requirements they were designed to meet.

This allows you to get performance statistics about the Engine. These enable you to determine how heavily the Engine is loaded. The System Monitor is designed for the person who is responsible for making sure that the AdminFlow system is operating smoothly.

Each interface provides access to particular views, although there is deliberately some overlap between the interfaces and the views they provide.

The Audit Logger records current and past AdminFlow events; AdminFlow provides a schema that defines the structure of these events. The level of logging information you require is specified when you define your processes.

The Audit Logger stores event information in an Audit Logger database. Understanding the structure of the event database means that you can access it and, if you want to, generate your own reports based on the information in the database. The Process Monitor interfaces use the information stored by the Audit Logger to present information about the AdminFlow system.

There is a buffer between the Audit Logger and the Engine. This is so the Audit Logger does not impact the performance of the Engine when writing event logs to the database. The buffer also means that events are not lost if the Audit Logger fails.

Be aware that the Audit Logger might not be able to record events as fast as the Engine creates them, so there might be a delay between the event and when it is displayed in one of the monitoring interfaces.

The Audit Logger stores the following information:

A Transport Feeder transports work items between the CORBA transport used by AdminFlow and another transport. The Transport Feeder passes these work items between transports without any additional processing.

An example of a Transport Feeder is the E-mail Feeder, which provides an interface between the CORBA transport used by AdminFlow and the SMTP mail transport. The E-mail Feeder supports all the protocols in the data; as an example, if the work item is marked as urgent within one transport system, the work item is also urgent within the transport system that it is being sent to. Transport Feeders do not change any information in the AdminFlow work item as they pass the work item between the two transports. The Feeder places a wrapper around the work item making it suitable for the destination transport.

The Resource Executive allocates Transport Feeders based on the address of the process participant. You can have one or more Transport Feeders for each transport. If there you have multiple Transport Feeders for the same transport, the Resource Executive uses load balancing to balance the load across the Feeders.

When setting up your workflow information, you will need to provide "who", "what" and "when" information. For example:

Most of this resource information probably already exists in databases within your organization; for example, e-mail addresses in your e-mail directory. This resource information needs to be made available to AdminFlow.

HP AdminFlow Overview Manual

Send email to Interex or to theWebmaster
©Copyright 1998 Interex. All rights reserved.