Introduction to Using Application Integration

 

This document is Using Application Integration, the manual for using adapters built using the BEA WebLogic Integration ADK (Adapter Development Kit). This document explains how to define application view services and events and use them in your business processes in the WebLogic Integration environment.

The instructions in this document are general instructions. Because each adapter and application is different, the instructions do not cover any information specific to any particular adapter or application. If you are looking for a tour of specific adapters included with the ADK, see the following two sections in Developing Adapters:

• "The E-mail Adapter" in Developing Adapters.

• "The DBMS Adapter" in Developing Adapters.

This section provides information on the following subjects:

• Before You Begin

• Concepts

 

---

Before You Begin

Before you can begin using adapters to integrate your enterprise, make sure the following prerequisites are satisfied:

• You have installed WebLogic Server, including Service Pack 1.

• You have installed JDK 1.3.1. The JDK 1.3 development kit is automatically installed when you install WebLogic Server 6.1, although you may want to install your own version, as long as it is 1.3.1-compliant.

• You have installed BEA WebLogic Integration.

• Deploy each adapter for which you will define application views.

Note: For a complete list of prerequisites, see the release notes.

 

---

Concepts

This section describes important concepts with which you should familiarize yourself before you work with adapters and application views. The following concepts are discussed in detail in Defining an Application View and Using Application Views in Business Process Management. For a broad overview of application integration, see Introducing Application Integration.

When to Use an Application View and When to Write Custom Code

To support service invocation and events, you can define application views, or you can write custom code that accomplishes the same functions. Application views provide the most convenient interface to an adapter's resources, but there are other ways to access an adapter. Normally, for each adapter, you will define application views to expose the application functions. However, for those who require more control, you may also write custom code to access the resources of an adapter. For your enterprise, you must decide whether to define application views or write your own code.

When to Define an Application View

You can define application views to easily integrate most enterprise information system (EIS) applications. In general, define application views in the following situations:

• You have more than one EIS in your enterprise, and you lack developers who have detailed, thorough knowledge of all of the systems.

• You want to construct business processes using WebLogic Integration Studio.

• You may need to update the parameters of the adapter or one of its processes.

When to Write Custom Code Instead of Defining an Application View

In general, write custom code as an interface to an adapter only in the following situations:

• You have only one EIS in your enterprise

• You have access to a developer who has thorough, detailed knowledge of each EIS involved in the business processes being coded.

• You do not need to use the coded functions in BPM.

• Your code will never change.

"Defining" Versus "Using" an Application View

There are two initial steps in the life cycle of an application view:

• Defining the application view.

• Using the application view.

Defining: Configuring an Application View and Adding Events and Services

When you define an application view, you configure the communication parameters, then add services and/or events. The application view's services and events expose specific functions of the application. The communication parameters of the application view govern how the application view will connect to the target EIS.

Defining an application view includes the following tasks:

• Entering a unique name for the application view.

• Configuring parameters that establish the network connection between the application view and the application itself.

• Configuring parameters specific to the application.

• Configuring parameters used for load balancing by the application view.

• Configuring parameters used to manage the pool of connections available to the application view.

• Defining security privileges for users of the application view.

Using an Application View in a Business Processes

After you define an application view, you can deploy it on WebLogic Server. You can use deployed application views to implement your enterprise's business processes in a business process workflow.

After using an application view in a business process workflow, the end result is a deployed electronic representation of your enterprise's business process. The workflow specifies how your applications will interact with each other to accomplish the business processes. The application views perform the transactions themselves.

Defining an Application View

When you define an application view for an adapter, you are creating an XML-based interface between WebLogic Server and a particular EIS application. For detailed steps for defining application views for adapters, see Defining an Application View.

Defining an application view involves these basic steps:

1. Naming and Configuring Connection Parameters for an Application View.

2. Adding Services and Events to an Application View.

3. Testing Services and Events.

Naming and Configuring Connection Parameters for an Application View

The first step in defining an application view for an adapter is to log on to the Application View Console, select a folder where the application view will reside, and configure its EIS connection parameters. For details on creating and configuring an application view, see the following topics:

• Logging On to the WebLogic Integration Application View Console.

• Defining an Application View.

Adding Services and Events to an Application View

After defining the EIS connection parameters of the application view, the next step is to add services and events. Services and events support a subset of an application's business processes by allowing other WebLogic Server clients to interact with the application functions you specify. The application view services and events allow specific types of transactions between WebLogic Server and the EIS application. For details on adding services and events to an application view, see the following topics:

• Adding a Service to an Application View.

• Testing an Application View's Events.

Testing Services and Events

After adding a service or event to an application view, you must make sure the service or event interacts properly with the EIS application. For details on testing services and events, see the following topics:

• Testing an Application View's Services

• Testing an Application View's Events

Using an Application View in Business Processes

Once you define an application view in your WebLogic Integration environment, you can use the application view in your enterprise's business processes. There are two ways to use application views in business processes:

• By designing business process workflows in BPM.

• By writing custom code.

Using an Application View in BPM

The most common way to use an application view in your enterprise's business processes is to design a workflow in BPM. BPM provides a GUI-based environment for designing business process workflows. These workflows can include application view services and events defined using application integration.

There are four ways to use an application view in a workflow using BPM:

• Scenario 1: Setting Up a Task Node to Call an Application View Service

• Scenario 2: Setting Up an Event Node to Wait for a Response from an Asynchronous Application View Service

• Scenario 3: Creating a Workflow Started by an Application View Event

• Scenario 4: Setting Up an Event Node to Wait for an Application View Event

For detailed information on each method, see Using Application Views in Business Process Management.

Using an Application View by Writing Custom Code

If you do not use BPM, the alternate way to use an application view in your enterprise is to write custom Java code to implement a business process.

For detailed steps for custom coding business processes, see Using Application Views by Writing Custom Code.

Deciding Which of the Two Methods to Use

For each business process you implement, you will need to decide which of the two implementation methods to use. You can implement any business processes as a workflow by using BPM, but you should only attempt to custom code a business process if it is extremely simple and specialized. In this document, custom coding is offered only as an alternate method for those who require it.

When to Use BPM

In general, use BPM to implement a business process in the following situations:

• When implementing the required business processes would require complicated error management, persistent processes, and sophisticated conditional branching.

  For example, if a business process receives events, selects only a subset of the events, performs complex branched actions, then generates many complex messages and sends the messages to a variety of WebLogic Server clients, then you should use BPM to implement the business process.

• When you will have to make occasional changes to the business process.

  BPM reduces the number of compile/test/debug cycles.

• When, like most organizations, your developers are valuable and scarce.

When to Write Custom Java Code

In general, write custom code to implement a business process only in the following situations:

• When the business process is simple. A simple business process is one that includes no complicated error recovery, long-lived processes, conditional branching, or joining of the process flow.

  For example, if a business process performs a limited set of actions on an incoming message, then routes the minimally transformed message to a small number of client applications, then the business process is simple enough to express by writing custom code.

• When you will not need to update the business process very often.

  When you update custom code, the change requires a full compile/test/debug cycle, which can be costly.

• When your organization can afford to dedicate developers to implement the business processes in code.