Process Integration

The process integration functionality of WLI enables you to model, test, deploy, and maintain complex business processes that integrate diverse enterprise systems, cross-enterprise applications, and end-user decision makers.

From the BPM perspective, the enterprise is a set of business services that are accessed through controls and can be orchestrated to model a business process. WLI supports synchronous and asynchronous communications, and stateless and stateful processes.

As you design business processes using the graphical tools (Design view), Workshop generates the source code automatically in a process file. When you need to write and edit Java code, you can switch to the Source view with a single click.

Table 2-1 Process Integration Features
Feature	Benefits
Unified access to resources through Controls	Developers can view business activities as services and orchestrate them using a process. Processes interact seamlessly with users, applications, back-end resources, and resources within and outside the firewall.
Simplified and structured business processes	The flow is based on XML and the operations are Java-based.
Graphical editing of processes for high-level integration scenarios	Developers can model complex business logic quickly by dragging and dropping icons into a flow (see Figure 2-1). They can focus on defining the overall business logic rather than on implementation details. Processes are created as Java classes. The process files contain the metadata describing the business logic.
Support for Java code in process nodes	Developers can, with just one click, switch from the Design (graphical) view to the Source (code) view, and then add or change Java code within process nodes.
Process implementation optimized for performance	WLI supports: Stateless synchronous processes Stateless asynchronous processes Stateful asynchronous processes

Web Services as Process Resources

WLI leverages web services, asynchronous communication, and XML messaging at the platform level. These services can be used across internal and external integrations, giving application developers the tools to simplify development and integration of loosely coupled and asynchronous applications.

WLI provides native support for web services, including security and reliable messaging. Web services can be invoked from within a WLI process, and processes can be exposed as a web service and made available as resources to other applications and application components.

Synchronous and Asynchronous Processes

A business process can be designed to be synchronous or asynchronous based on the method that is used to invoke the process.

A synchronous process is invoked by a synchronous method; it returns a response to the client after the process is executed.

Note:

A synchronous process can also contain asynchronous operations, but these must be added after the starting event in the process flow, so that, at run time, the asynchronous processes are executed after the synchronous starting event is completed.

An asynchronous process is invoked by an asynchronous method. The starting event in such a process is represented by an asynchronous node. An asynchronous process can call synchronous or asynchronous methods without additional configuration.

You can also enable synchronous clients to interact with processes that have asynchronous interactions with resources. A synchronous Workshop client such as a JSP or portal page that uses a Java control might, for example, need to invoke a process and then wait for a response (block). While the client is blocked, the process may perform asynchronous activities such as queueing a JMS message and waiting for a JMS receive, and then return the response to the client, after which the client is unblocked.

Stateless and Stateful Processes

Stateless processes provide high performance because there is no overhead for maintaining the state in a database during the transaction.
For a stateful process, the state of the process is persisted in a database. Stateful processes are used when data reliability and recovery are essential. However, persisting the state could affect performance of the process. Nonpersistent stateful processes can be defined at design time to minimize the effect on performance.

When you set the properties of the process, the following types of persistence can be defined:

Always: The state is always persisted in a database.
Never: The state is stored only in memory (and never in a database) and lasts only for the duration of the current session.
On overflow: The state is persisted only after a number (specified in the Max Bean in Cache deployment descriptor file) is reached.

Process Calls

Processes can expose their functions to clients in several ways, including through WSDL files, process controls, service broker controls, and JPD proxies.

Process controls can be used for invoking other processes over an optimized transport. The service broker control must be used for invoking other processes and WebLogic Workshop 8.1-based web services over HTTP or JMS transport. The invoked processes and web services may be deployed on the same domain or on a different domain.

Any Java client – including standalone Java applications, EJBs, JSPs, and servlets – can communicate with any process by using JPD proxies. When the clients use JPD proxies, they make Java method calls using Remote Method Invocation (RMI).

Overview of WebLogic Integration

Process Integration

Web Services as Process Resources

Synchronous and Asynchronous Processes

Stateless and Stateful Processes

Process Calls