Using the Application Integration Design Console
|
 |
 |
|
|
 |
 |
This section presents the following topics:
After you create all the application view services and events that are required for your enterprise, you can use the resulting application views to execute your business processes. The simplest way to do this is by using WebLogic Workshop to design business processes that use your application view services and events.
WebLogic Workshop provides a graphical user interface (GUI) for designing business processes as well as web services. These business processes can include application view services and events defined using the Application Integration Design Console.
Business Processes are integrated with application views through the Application View control. The Application View control allows a business process engineer to browse the hierarchy of application views, invoke a service as a business process action, and to start a new business process when an event occurs. For details, see the Application View Control topic in the WebLogic Workshop Help at the following URL:
http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/integration/controls/controlsAppView.html
Before you can invoke an application view service or receive an application view event in a business process, you must make sure the following prerequisites have been met:
The Application View control allows users of WebLogic Integration, WebLogic Workshop, and WebLogic Portal to invoke functions within enterprise applications using simple Java APIs or XML documents. This allows users who are not experts in the use of a given enterprise system to use its capabilities in a manner a Java programmer can understand.
The Application View control provides a means for a business process developer to invoke application view services both synchronously and asynchronously. Synchronous services are represented as simple methods with a single parameter and a non-void return value. Asynchronous services are represented as both a method with a single parameter (the request), and a callback method with a single parameter (the response).
Application view events are delivered through the Message Broker. To receive application view events, use a Message Broker Subscription control or static subscription (from business processes only). For more information on handling events, see Receiving Events.
Perform the following steps to use an application view from within a business process:
Any WebLogic Workshop application which uses the application integration capabilities of WebLogic Integration must contain a project explicitly named Schemas. The Schemas project is used to store the wlai.channel file and application view schemas (published as XML Bean classes). If the Schemas project does not exist in the application, you must create it before publishing application views.
The published application view EJB is added to the Modules list in the WebLogic Workshop application tree. This deploys the application view EJB and, in turn, the application view.
Note: When you publish an application view, schemas are published to the WebLogic Workshop application. Publishing an application view and opening WebLogic Workshop may cause the Schema project to be rebuilt. If you edit a business process (for example, to define a start node) before the Schemas project has finished rebuilding, you may see an error message similar to the following:
The type for the variable could not be resolved. This may be due to not entering fully qualified type name. Please go to source to correct errors.
Make sure that the Schema project has completed its rebuild before editing the business process.
When you create an Application View control, you specify or select the following:
Application View control instances are stored as JCX files. Each Application View control instance is a Java interface that extends the base Application View control interface (com.bea.wlai.control.ApplicationViewControl).
The following code shows the base Application View control interface.
Listing 3-1 Application Control Base Interface
package com.bea.wlai.control;
import com.bea.control.XMLControl;
import com.bea.control.Extensible;
import com.bea.xml.XmlObject;
/**
* ApplicationView Control base interface
*/
public interface ApplicationViewControl
extends XMLControl
{
// -------------------------
// Async methods
// -------------------------
/**
* Is this control instance currently processing an async request?
*/
public boolean isAsyncRequestActive();
/**
* Return the ID of the active asynchronous request being processed by
* this control instance, or null if no async request is active.
*/
public String getActiveAsyncRequestID();
// -------------------------
// Local transaction methods
// -------------------------
/**
* Begin a local transaction on this control. This will begin a local
* transaction on the underlying ApplicationView instance. All work done
* by this control instance between this call, and a call to
* commitLocalTransaction() or rollbackLocalTransaction() will be
* committed or rolled back, respectively, as a unit. If the underlying
* adapter used by the ApplicationView for this control does not support
* local transactions, an exception is thrown.
*/
public void beginLocalTransaction()
throws Exception;
/**
* Commit the active local transaction for this control. All work done
* since the last call to beginLocalTransaction() will be committed into
* the EIS's permanent state. If the underlying
* adapter used by the ApplicationView for this control does not support
* local transactions, an exception is thrown.
*/
public void commitLocalTransaction()
throws Exception;
/**
* Rollback the active local transaction for this control. All work done
* since the last call to beginLocalTransaction() will be discarded.
* If the underlying adapter used by the ApplicationView for this control does not support local transactions, an exception is thrown.
*/
public void rollbackLocalTransaction()
throws Exception;
/**
* Callback interface that defines the generic events that can be delivered
* to any ApplicationView control instance. Note, no client-visible events
* are defined here. They see only those events defined in the control
* interface (JCX file).
*/
public interface Callback
{
/**
* Private/internal callback handler for handling async responses.
* Clients of ApplicationViewControl should NOT implement this type
* of handler.
* @exclude
*/
public void internalCallbackMethod(Object asrObj)
throws Exception;
}
}
For sample Application View controls and business processes, use WebLogic Workshop to open the sample application located in:
SAMPLES_HOME/integration/sampleApp/sampleApp.work
For instructions on running the samples, use WebLogic Workshop to open the following HTML file:
SAMPLES_HOME/integration/sampleApp/docs/index.html
The JCX file for an Application View control instance does not represent events from the associated application view. Business processes receive events from application views by using an instance of the Subscribe Control for the Message Broker. When an application view which has events is published to WebLogic Workshop, a wlai.channel file is automatically generated. The channel file defines the channels available for subscription by business processes.
For more information on Message Broker Subscription controls, see the Message Broker Subscription Control topic in the WebLogic Workshop Help at the following URL:
http://download.oracle.com/docs/cd/E13226_01/workshop/docs81/doc/en/integration/controls/controlsBrokerSubscribe.html
The following in an example of a wlai.channel file., consisting of subscriptions for two events.
Listing 3-2 Sample wlai.channel File
<?xml version="1.0" encoding="UTF-8"?>
<mb:channels channelPrefix="/wlai"
xmlns:mb="http://www.bea.com/wli/broker/channelfile">
<mb:channel messageType="none"
name="InsertBasedEvents">
<mb:channel messageType="xml"
name="CustomerInsertEvent"
qualifiedMessageType="et:CUSTOMER_TABLE.insert"
xmlns:et="wlai/CustomerInsertEvent_CUSTOMER_TABLE_insert"/>
</mb:channel>
<mb:channel messageType="none"
name="FunctionDemo">
<mb:channel messageType="none"
name="CustomerMgmt">
<mb:channel messageType="xml"
name="CustomerUpdated"
qualifiedMessageType="et:CUSTOMER_TABLE.update"
xmlns:et="wlai/FunctionDemo/CustomerMgmt_CustomerUpdated_event"/>
</mb:channel>
</mb:channel>
</mb:channels>
To enable a business process to receive events from an application view, create an instance of a Message Broker Subscription control as follows:
wlai, indication that the channels are defined in the generated wlai.channel file.When you select a channel, the associated message type and, if specified, metadata type are displayed.
The control is created using the name supplied in step 5.
Once the control is created, you can use the Property Editor to define a filter at either the class or method level.
Note: You can start a business process on receiving an event. This feature is available from the process Start node, where you can select Subscribe to Message Broker Channel and select your event from the Channel Name drop-down list..
The LocalTransaction interface is exposed to adapter clients via the Common Client Interface (CCI) Connection class. Currently the application view interface does not use the CCI LocalTransaction interface. To manage a local transaction, a user must first acquire a LocalTransaction from the Connection object.
A local transaction management contract is created when an adapter implements the javax.resource.spi.LocalTransaction interface to provide support for local transactions that are performed on the system's underlying resource manager. This type of contract enables an application server to provide the infrastructure and run-time environment for transaction management. Application components rely on this transaction infrastructure to support their component-level transaction model.
For more information about transaction demarcation support, see:
http://java.sun.com/blueprints/guidelines/designing_enterprise_applications/transaction_management/platform/index.html
The following is a scenario for supporting application view local transactions within WebLogic Workshop. This scenario is similar to TX_REQUIRES_NEW for EJB transactions because the connector supports only local transactions.
In this scenario, the Connector supports only local transactions and the BPM designer does not explicitly demarcate the start and end of a local transaction. WebLogic Integration allows the Connector to participate in the global transaction by providing an XA Wrapper around the LocalTransaction object. The XA Wrapper no-ops all methods on the XAResource interface that can not be delegated to the LocalTransaction instance. WebLogic Integration allows only one non XA resource in the transaction chain. As a result, a user can have only one application view LocalTransaction within a business process.
In this scenario, application view services are not called within a local transaction. Each service invocation is automatically enlisted in the Global XA transaction because the resource adapter supports XA.
|
|
|