Section 2.1. Designing a Solution


2.1. Designing a Solution

To design a good BPM solution, you must first step back and examine the project's environment: understanding the problem, noting the local and larger-scale perspectives, and only then creating a design and testing your solution.

2.1.1. Understanding the Problem

To understand what a good solution looks like, you must first understand the scope of the problem to solve. The main requirement of a BPM application is the ability to design, run, and monitor and administer business processes that incorporate human and system interactions, described as follows:


Design

The design of a business process is intuitively a flowchart that outlines the steps performed over time in the resolution of a business problem. Unlike most object-oriented designs, whose audience is the technical team of a project, a process design is crafted and comprehended by both business and technical analysts . Business analysts are involved because they understand the business aspects of the process best; the design is simply a rigorous expression of what they frequently draw on paper or on a whiteboard. The level of rigor, plus the anticipation of implementing a software solution to the design, draws in technical analysts. Thus, business and technical designers require a common design notation that is at once business-oriented and amenable to computer processing. They also require a graphical editor in which to sketch their design.


Run

The early workflow engines that were actually able to run designed processes, and thus to automate the execution of formerly manual procedures, must have been perceived as miraculous. Today, this miracle is a core requirement: "Run what I just drew!" But conceived more dispassionately, the executability of a process is a matter of having a runtime engine and an executable language that the engine knows how to run. Moreover, a mapping is required between the design notation and the executable language, enabling the automated generation of executable code from the design. The manual coding of a process is undesirable because it slows the development cycle and ensures gaps between the design and the execution.


Monitor and administer

Monitoring, the ability to watch the progress of running processes, is crucial for production applications for two reasons: the detection of exceptions (ensuring processes are progressing as expected and not getting stuck), and real-time ad hoc querying (e.g., finding all active processes for customers in a particular account range). Administration is the management of, and the ability to effect changes on, processes on the runtime engine. It includes the ability to install, shut off, or turn on process designs, and to suspend, resume, or terminate running processes. Monitoring and administration require a management language and a graphical management console that can watch and modify the BPM system.

The model architecture must also smoothly accommodate both human and computer interaction:


Human interaction

A manual task is a step in a process that is meant to be executed by either a specific person, or a person in a specific role, within the company. For example, in an insurance claims process, the approval of a claim is a manual step that can be completed by any claims adjuster. To support manual processing, the architecture requires a role-based security model (which maps users to roles), a graphical worklist console (to show the user a list of assigned manual activities and enable completion of an activity), and a corresponding worklist programming interface for the exchange of information between the console and the runtime engine.


System interaction

Other steps in a process must be able to call or be called by software components that are not built into the engine. These components can be external participants (e.g., a request for price quote from another's company's process in a buyer-seller relationship), internal systems (e.g., send email, query database, perform mainframe transaction), or simple inline code snippets (e.g., perform calculation, parse data). The architecture should support incoming and outgoing integration interfaces for a variety of technologiesweb services, MQ/Series, JDBC, J2EE (EJB, JMS), Java, C#, and COM. The architecture should also be conversant in XML, the dominant message language of enterprise computing.

2.1.2. The Local Perspective Guided by the Global Contract

The job of a BPM architecture is to describe the local perspective of one company, not the global view of all partner interactions. True, the designers must be aware of the nature of partner interactions but only to ensure that the company is compliant with interprocess protocols. As Figure 2-1 illustrates, a company that is a Seller must know the rules of interaction with Buyer, Inventory, and Credit card company partners, but its main concern is the construction of its own Seller processes.

Figure 2-1. Isolate the client company from its partners


On the other hand, how can the designers be certain that their local processes interact exactly as they should with partners? Several years ago, the "global contract" governing this communication would have been documented in writing by a third-party body. As they modeled their processes, the designers would have kept a close eye on the documentation to ensure that their communications were compliant. But with the advent of web services choreography languages, notably WS-CDL, the contract can be coded in a formal language, around which a tool (considered in greater detail in the section "Local View of Choreography: WS-CDL Toolkit") can be built to generate, or to validate the compliance of, local processes.

The first cut of the Seller process, for example, can begin as code generated by a tool that interprets the choreography covering Seller, Buyer, Inventory, and Credit card company. Or, supposing the first cut had been written manually, at any subsequent stage of development, the code can be run through the tool to validate that Seller interfaces correctly with Buyer, Inventory, and Credit card company. Such a tool simplifies process design, and eliminates the eyeball approach.

2.1.3. Components of a Good Design

Figure 2-2 shows the main pieces of the BPM architecture and their relationships.

Figure 2-2. A good BPM architecture


In the centerand at the heartof the system is the runtime engine, which executes processes written in BPEL. Business and technical analysts design the processes using a graphical editor that supports BPMN. The editor includes an exporter that generates BPEL XML code from BPMN diagrams.

Human and computer interactions drive the execution of processes in the engine. The people who participate in the process use a human workflow graphical application that connects to the engine through a programmatic worklist interface. The interface allows the user to view and execute pending manual activities. There are two types of computer interactions: internal and external . Internal applications, which reside on the company's network but are outside of the engine's address space, are accessed by integration technologies such as web services, J2EE, or COM, with XML as the probable message format; internal interactions can also be more lightweight inline code snippets written in programming languages such as Java or C#. External interactions are typically web service-based communications, governed by choreographies or business-to-business collaborations, with the processes of other companies. BPM system administrators use a graphical administration and monitoring console to maintain and track the state of the engine's processes. The console uses a management language to interface with the engine. The runtime engine maintains persistance of a process state to a database; the console hits the database directly, rather than using the management language, to perform ad hoc process queries.

For applications involving complex interactions with external participants (e.g., a B2B process), a WS-CDL choreography toolkit generates a basic BPMN model that captures the communications required of the local process; it can perform a validation, or choreography compliance check, of that model.

2.1.4. Run It on an Application Server

Never build a BPM application from scratch. Instead, run it on an application server, to leverage built-in application server facilities such as security, transactions, system management, and the pooling of client connections and resources. Table 2-1 summarizes a possible J2EE application server implementation of the BPM architecture.

Table 2-1. BPM on J2EE

Component

J2EE implementation

Engine

Enterprise JavaBeans

Human worklist application

Java Server Pages? (JSP) web application

Worklist interface

EJB or web service façade to engine

Internal interactions

EJB, Java Messaging Service? (JMS), Java Connector Architecture? (JCA, also known as J2C), Java Database Connectivity? (JDBC), web services via servlets

External interactions

Web services via servlets

Administration and monitoring console

JSP web application

Management interface

Java Management Extensions? (JMX)

Process database

JDBC access

Graphical editor

Offline Windows program

Exporter

Offline utility

WS-CDL toolkit

Offline utility


This solution is a combination of out-of-the-box product functionality and custom development, as shown in Figure 2-3. The application server layer, for example, might require custom EJBs to provide functions to call from processes and custom JSPs to use in custom management consoles. The BPM layer might require extensions to the process data model and the development of reusable processes.

Figure 2-3. BPM on an application server




    Essential Business Process Modeling
    Essential Business Process Modeling
    ISBN: 0596008430
    EAN: 2147483647
    Year: 2003
    Pages: 122
    Authors: Michael Havey

    flylib.com © 2008-2017.
    If you may any questions please contact us: flylib@qtcs.net