Using Integration Controls

Process Control

The Process control is used to send requests to and receive callbacks from another business process. The Process control is typically used to call a subprocess (child process) from a parent process.

For information on how to add control instances to business processes, see Using Controls in Business Processes.

Topics Included in This Section

Overview: Process Control

Creating a New Process Control

Process Control Methods

Process Control Design Time Considerations

Process Control Run-Time Considerations

Maintaining Process Controls

Using Dynamic Binding

Notes on Process Controls Annotations

Overview: Process Control

The Process control allows a Web service, business process, or pageflow to send requests to, and receive callbacks from, a business process. Process control invocations are Java Remote Method Invocation (RMI) calls.

The target business process must be hosted on the same WebLogic Server domain as the caller. The Process control is typically used to call a subprocess (child process) from a parent business process.

The first step in using a Process control is creating a Java file. The control java file can be automatically generated from a target business process using BEA WorkSpace Studio, or can be created using the control wizard. The methods and callbacks on the control java file correspond to the operations and callbacks of the target business process. An instance of this java file is used by a parent process to call the target process. Process control java files can have selector annotations only on start methods or, for stateless target services, on any method.

To learn about creating a Process control, see Creating a New Process Control.

Creating a New Process Control

This topic describes how to create a new Process control.

You can create a Process control in two different ways, which are described in the following sections:

Creating a New Process Control Using the Control Wizard

You can use the Insert Process dialog to create a new Process control and add it to your business process. If you are not in the Design view, click the Design tab.

To create a new Process control:

Generating a Process Control from a Process File

You can create a new Process control from an existing Process.java file.

To generate a Process control from a Process file:

Alternatively, you may create a Process control file manually. For example, you may copy an existing Process control file and modify the copy.

Notes on XQueries

When you are using XQuery expressions and the XQuery Builder, it is important to remember:

Process Control Methods

To learn about the methods available on a Process control, see the Interface ProcessControl.

Example: Process Control Declaration

When you create a new Process control using the control wizard and drag a method from the control onto a business process, its declaration appears in the process.java file. The following code snippet is an example of what the declaration looks like:

@org.apache.beehive.controls.api.bean.Control

	private proc2Control proc2Control1;

Setting Process Control Properties

The Process control possesses the capability of dynamically binding some properties of the control. Dynamic binding of properties can be achieved:

To retrieve the current property settings, except for username and password, use the getProperties() method.

Starting with the method with the highest precedence, the hierarchy of property settings is:

The ProcessControlProperties type is an XML Beans class that is generated out of the corresponding schema element defined in DynamicProperties.xsd. The DynamicProperties.xsd file is located in the schemas/system folder or in the utility folder of new Process Applications.

The setProperties() method uses this XML Bean class to set properties on a control instance. A selector on a Process control method returns an XML document that conforms to the ProcessControlProperties element. The following sample shows how to programmatically set the username property for a control. You add the bold code lines to the code generated when the control is created, overriding properties set using dynamic binding and static annotations:

import com.bea.wli.control.dynamicProperties.
ProcessControlPropertiesDocument;

import com.bea.wli.control.dynamicProperties.
ProcessControlPropertiesDocument.ProcessControlProperties;

    ProcessControlPropertiesDocument props= null;
    ProcessControlProperties sprops = null;

    public void sBC8InvokeSetProperties() throws Exception

    {

        props = ProcessControlPropertiesDocument.Factory.newInstance();
        sprops = props.addNewProcessControlProperties();

        sprops.setUsername("smith");

You construct the ProcessControlPropertiesDocument instance in the above section of code through a Data Transformation method or through XMLBean APIs. For more information on Data Transformations, see Guide to Data Transformation.

The following code provides a sample of a ProcessControlPropertiesDocument instance:

this.pcp = ProcessControlPropertiesDocument.Factory.newInstance();

this.pcp.addNewProcessControlProperties();

this.pcp.getProcessControlProperties().setUsername("uname");

this.pcp.getProcessControlProperties().setPassword("pword");

this.pcp.getProcessControlProperties().setTargetURI("http://localhost:7001/";);

Some control properties can be specified dynamically or in annotations (statically) on the control file. For example, the Process control allows you to specify the target process in the @com.bea.wli.common.control.Location(uri = <URL>)annotation at the top of the java control file or dynamically using the TargetURI element in DynamicProperties.xml. In all such cases, a dynamically bound value for the property takes precedence over the static annotation.

If the domain is active, it is recommended that you use the WebLogic Integration Administration Console to perform dynamic binding. For more information on binding lookup values to dynamic properties using the WebLogic Integration Administration Console, see “Adding or Changing Dynamic Control Selectors” in Process Configuration.

Dynamic properties can also be specified by calling setProperties on the control, or by calling one of the setter methods, such as ProcessControl.setUsername().

Properties applied using selectors remained bound until one of the following conditions occurs:

ProcessControl.reset() resets all configured selector values.

Process Control Design Time Considerations

This section outlines some of the issues you must consider when you are designing a process control for your business process. The issues covered in this section are:

Using a Process Control in Stateless and Stateful Business Processes

The number of transactions contained in a business process determines whether the process is stateless or stateful. For more information, see Building Stateless and Stateful Processes. This section covers some of the issues you should consider when designing a Process control for stateless and stateful business processes.

When designing your Process control, adhere to the following rules:

Using Process Controls in Synchronous and Asynchronous Business Processes

Business processes can have both synchronous or asynchronous request methods. For more information, see Building Synchronous and Asynchronous Business Processes. This section covers some of the issues you should consider when designing a Process control for synchronous and asynchronous business processes.

When designing your Process control, remember:

Using a Process Control from the Parent Process

The Process control is typically used to call a subprocess from a parent business process. When the Process control is invoked from the parent process, the control is invoked normally if the subprocess is in the same application.

If the subprocess control is in a different application, you must copy the subprocess control into the parent process control and change the location of the subprocess control so that it is the same as the location of the parent process control, if you want the call to invoke normally.

Process Control Location

When you create a Process control, it is displayed in the Package Explorer pane and an instance of the control is added to the Data Palette. The location of the Process control is displayed in the JPD Configuration pane.

To view the location of the Process control:

Process Control Run-Time Considerations

This section outlines some of the run-time issues you must consider when you are invoking a Process control in your business process. When you are invoking a Process control from a parent business process, you are making a Java Remote Method Invocation (RMI) to the subprocess. The transfer of information is governed by RMI rules and not by serialization rules.

The topics covered in this section are:

Run-Time Rules for Process Controls in Stateless and Stateful Business Processes

The number of transactions contained in a business process determines whether the process is stateless or stateful. For more information, see Building Stateless and Stateful Processes. This section covers some of the run-time issues you should consider when using a Process control in stateless and stateful business processes.

The following rules govern the run-time operation of Process controls in stateless and stateful business processes:

Run-Time Rules for Process Controls in Synchronous and Asynchronous Business Processes

Business processes can have both synchronous or asynchronous request methods. For more information, see Building Synchronous and Asynchronous Business Processes. This section covers some of the run-time issues you should consider when using a Process control in synchronous and asynchronous business processes.

The following rules govern the run-time operation of Process controls in synchronous and asynchronous business processes:

Security

The Process control conforms to all standard security checks associated with Java Remote Method Invocation (RMI). SSL is not supported. For more security information, see Security.

Maintaining Process Controls

In general, Process controls are utilized in situations where the parent process and subprocess are in the same application, or in situations where the parent process and subprocess are in different applications.

In both situations, if the Process control is changed on the subprocess side of the transaction, you must regenerate the control on the parent side to insure that the control will operate normally. If the subprocess and parent process are in different applications, and the Process control is changed in any way (i.e. request/response removed, etc.), backward compatibility may be compromised. If this happens, you must merge the Process control on the subprocess side and repropagate the control back to the parent business process.

JAX-RPC Handlers

JPDs implicitly inherit all behavior from JWSs. This allows you to add JAX-RPC handlers to a JPD to "intercept" messages sent to requests and responses before and/or after the request.

However, these handlers are not executed for JPD requests that come in via a Process control execution. In other words, handlers are not executed for requests to/from Process control invocations.

Using Dynamic Binding

In many cases, control attributes are statically defined using annotations. Some controls provide a Java API to dynamically change certain attributes. Dynamic controls, including the Service Broker and Process controls, provide the means to dynamically set control attributes. Attributes are determined at runtime using a combination of lookup rules and lookup values, a process called dynamic binding. Controls that support dynamic binding are called dynamic controls. The business process developer specifies lookup rules using WebLogic Workshop while the administrator specifies look-up values using the WebLogic Integration Administration Console. This powerful feature means that control attributes can be completely decoupled from the application and can be reconfigured for a running application, without redeployment.

To learn more about dynamic binding, see How the Service Broker Control Uses Dynamic Binding.

Notes on Process Controls Annotations

This section outlines some rules that you should adhere to when using the following Process control annotations:

@com.bea.control.annotations.MessageBuffer

The @com.bea.control.annotations.MessageBuffer annotation specifies that there should be a queue between the component’s implementation code and the message transport wire for the specified method or callback. For more information, see “@MessageBuffer Annotation” in Java Control Annotations.

@com.bea.wli.common.Conversation

The @com.bea.wli.common.Conversation annotation specifies the role that a control’s methods or callbacks play in a conversation. For more information, see “@com.bea.wli.common.Conversation annotation” in Java Control Annotations.