Back to Articles Page
Every exchange that comes into play in a Business-to-Business architecture forms part of a business process that can be highly automated using workflow technology. The Gartner Group leaves little room for doubt when it affirms that "By 2003, more than 90% of e-business will be exploiting process automation technology."
In this article, we aim to provide a simple definition of the workflow technology, to look at the role of workflow within e-business architectures, and to highlight the key factors for successful implementation. The final section gives a practical illustration of the concepts discussed, presenting a new generation workflow engine, BEA WebLogic Process Integrator.
- Workflow: definition and history
Workflow is a concept that links together technologies and tools able to automatically
route events and tasks with programs or users. The automation of a workflow
requires it to be represented electronically; the elements involved are as
- Routes: These define the path taken by the set of objects making up the workflow. The routes of a workflow may be linear, circular or parallel.
- Rules: These define the conditions that must be met in order to move to the next stage of the workflow. They determine the route to be followed.
- Roles: These define the function of the people or programs involved in the workflow.
- Tasks: These are the actions which are guided by the workflow. Tasks can be carried out by users or programs with a defined role in the workflow.
Workflow representing business process modeling
There are two different workflow models, as follows:
- Process-oriented workflows used to automate processes whose structure is well defined and stable over time, which often coordinate sub-processes executed by machines and which only require minor user involvement (often only in specific cases). A loan request is an example of a well-defined process, with few hidden surprises. Certain process-oriented workflows may have transactional properties.
- Specific workflows are less directive and are used more to coordinate tasks between users. Their structure is harder to master and may change over time.
In this article we shall be looking most closely at process-oriented workflows, which feature in e-business applications.
The emergence of workflow technology is very closely linked to the history of the electronic imaging industry and computer aided production management. Very early on, this industrial sector realized the advantages that could be gained from automating processes which were hitherto carried out manually and using paper documents. It was the golden age of tools like FileNet or Wang (now Eastman software). But despite the fact that these tools were able to process complex, heavy workflows, market penetration was hindered by their high price tag and complexity, along with the major disruption they caused to the organization of the companies that implemented them. When it came to meeting companies' needs in terms of workflow within e-business architectures, the constraints were simply too great.
- The role of workflow in B2B architectures
The business process is a fundamental notion in e-business architecture. A task (sending a document, triggering a transaction, filling a form…) forms part of the business process with which a workflow is associated, whether the issue is the management of the logistics chain, the marketplace or the exchange of documents between partners. The workflow is made up of tasks which follow routes, with checkpoints represented by rules.
Today, most business processes are automated, but often only partially so. The automation of certain sector-specific processes has been facilitated thanks to the diversity of systems (packaged products, specific developments…) and companies' histories. However, this has made automation of general processes more difficult. Things become even trickier in a B2B context, where integration and security problems are heightened. Overall management of business processes is therefore sometimes carried out manually, which translates into high overheads, slowness, and poor reliability.
There are many workflow tools around, but these are relatively immature when it comes to automating B2B processes. Standards are on the whole stable, whether for infrastructures (J2EE, COM…), middleware (SOAP…), or exchange vocabularies such as RosettaNet or Biztalk.
Process automation can become the focus of specific development, but it is preferable for a tool to be used. Below is a list of important criteria, which must be met by any B2B process automation tool.
Most of these standards are still young and will evolve, and it is not impossible that some may disappear, giving way to a more reduced number of formats. The choice of exchange standard is very closely linked to the functional domain into which the processes fall, and it is important for the workflow manager to integrate the chosen format.
- Integration in third-party applications
A business process is never isolated and is often part of a general application. From the user angle, the process is managed within an application context of security and navigation. It is therefore essential to ensure the workflow tool integrates with the existing architecture, by opening up its operation in the form of an API.
- Integration with components and middleware
The workflow tool for a B2B architecture coordinates existing sub-processes, which may be components (COM, EJB…) or middleware (MOM, SMTP for message sending, SOAP or RMI type RPCs…). It must therefore be able to integrate existing processes.
The underlying architecture for workflow tools is often an application server (such as WebLogic Process Integrator, which runs on WebLogic Server), which is at the forefront of B2B application management.
EAI tools may also form a suitable basis for workflow tools. Their integration capacities give workflow tools excellent potential for designing back-office-oriented processes (e.g.: NEON — acquired by Sybase — EIP, built on a message broker from NEON).
However, the issue of "EAI tool versus application server" for the basic workflow architecture will become less and less valid, since the growing tendency is for application servers to integrate their own EAI tools.
- Visual process development
Before a process can be automated, modeling must be carried out. For a workflow tool to be worthy of its title, it must offer a graphical modeling environment to facilitate development and maintenance of workflows by users who are not computer experts. Modeling potential is also a key factor.
- Management of workflow instances
The workflow manager must offer a solid environment for deploying and managing workflow instances. The state of a workflow must be persistent in order to handle long-term processes. The workflow manager is subject to the same performance and availability constraints as B2B applications, and reliance on an application server featuring cluster mode is a bonus when it comes to supporting increased workloads and offering good availability. It is also essential to be able to act on workflow instances in order to manage particular cases.
- Management of exchange vocabulary
Setting up a workflow engine is the first step in managing B2B processes, so it is important to standardize the vocabulary used for the communication engaged during the process. While XML format would seem to be the most appropriate solution, the choice of definition of XML files (DTD or Schemas) is much more delicate. The alternative solution — defining a proprietary format with one's partners — should be avoided, since it leads to a high level of dependency. The nature of the functional domain concerned is an important focus area if one is to know where to situate the workflow tool. There are a number of initiatives which aim to standardize XML vocabularies so as to prevent too-tight coupling between e-business players. These include:
- RosettaNet, eCO and Biztalk, for industry
- xCBL, for financial transactions and marketplaces
- OBI for purchase management
- A modern workflow tool: BEA WebLogic Process Integrator
BEA WLPI (WebLogic Process Integrator) is one example of a workflow tool. Workflows are managed by a process engine, which runs on the J2EE application server WebLogic server. WLPI is a tool capable of managing complex processes with varying durations. The chief functionalities of WLPI are as follows:
- Process creation: The WLPI Studio environment visually models the workflow and the different objects constituting it (routes, conditions, tasks and roles).
- Process management: The WLPI engine manages the execution of process instances modeled in WLPI Studio.
- Process administration: WLPI offers the possibility of operating on a process to modify its state, should a problem arise. Statistics are also available to highlight any bottlenecks.
The chief advantage of WLPI lies in its integration with WebLogic, and its openness. A J2EE application operating with WebLogic can use an API to call on the process engine, and a process can call a WebLogic component (EJB or java class). Sending and receiving of XML files or e-mails can be workflow tasks. WLPI operates with a database, which acts as a repository for process models, and as a persistence facility for process instances.
WLPI does not incorporate any XML vocabulary; however, it is part of the BEA WebLogic Collaborate offering, which is compatible with the RosettaNet standard.
Internet standards are opening up some excellent opportunities for automating processes for B2B exchanges. The majority of the major players in the middleware market are seeking to offer solutions: MQSeries Workflow for IBM, Versata, WebLogic Process Integrator for BEA, Biztalk Server for Microsoft…
It is still not easy to set up this type of solution, given the relative maturity of business exchange standards on the one hand, and the maturity of the products themselves on the other. Considerable efforts are required for the technical integration of information systems, if efficient and cost-effective management of inter-enterprise communication processes is to be achieved.
Back to Articles Page