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.
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 Oracle 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 Oracle Workshop for WebLogic, 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.
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:
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:
Note: | If the Data Palette view is not visible in Oracle Workshop for WebLogic, click Window > Show View > Data Palette from the menu bar. |
The Insert control: Process dialog box appears (see Figure 12-1).
If you invoked the Dynamic Selector query builder, perform the following steps to build and test a query:
TPM
to bind lookup values to properties in the TPM repository. Choose LookupControl to bind lookup values to dynamic properties specified in a domain-wide DynamicProperties.xml
file. You should only edit the DynamicProperties.xml
file to bind lookup values to dynamic properties if the domain is inactive. If the domain is active, it is recommended that you use the Oracle WebLogic Integration Administration Console to bind lookup values. For more information on binding lookup values to dynamic properties using the Oracle WebLogic Integration Administration Console, see “Adding or Changing Dynamic Control Selectors” in Process Configuration.
The Process control is created and displayed in the Package Explorer pane. An instance of the control is also created and is added to the Data Palette.
For more information, see “Step 6: Invoke a Business Process Using a Process Control” in Tutorial: Building Your First Business Process.
You can create a new Process control from an existing Process.java file.
Note: | If the Package Explorer pane is not visible in Oracle Workshop for WebLogic, click Window > Show View > Other > Java > Package Explorer from the menu bar. |
To generate a Process control from a Process file:
A menu appears displaying a list of options.
The Save As dialog box appears.
RequestQuote.java
, the resulting java file is named RequestQuotePControl.java
.Double-click the Process control java file in the Package Explorer pane to display the control in Design view.
Alternatively, you may create a Process control file manually. For example, you may copy an existing Process control file and modify the copy.
When you are using XQuery expressions and the XQuery Builder, it is important to remember:
To learn about the methods available on a Process control, see the Interface ProcessControl.
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;
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:
com.bea.wli.common.control.Selector
tag and the DynamicProperties.xml
filesetProperties()
method or other setter methods inherited from the Process control (setConversationID
, setTargetURI
, setPassword
, and setUsername
)
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 Oracle WebLogic Integration Administration Console to perform dynamic binding. For more information on binding lookup values to dynamic properties using the Oracle 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.
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:
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:
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:
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.
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.
Note: | If the JPD Configuration pane is not visible in Oracle Workshop for WebLogic, click Window > Show View > JPD Configuration from the menu bar. |
To view the location of the Process control:
The Process control is displayed in the Design view and the JPD Configuration pane displays the properties of the Process control.
The location of the Process control is displayed in the location section of the JPD Configuration, in the uri field. The location is not an actual HTTP address, though it may appear that it is. The uri actually displays the location of the object within the Java Naming and Directory Interface (JNDI) tree.
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:
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:
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:
com.bea.control JwsContext
interface provides access to container services that support Web services (JWS files). For more information, see “com.bea.control JwsContext Interface” in
com.bea.control Package. The setCallbackLocation()
method is not supported for Process control callbacks.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.
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.
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.
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 Oracle Workshop for WebLogic while the administrator specifies look-up values using the Oracle 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.
This section outlines some rules that you should adhere to when using the following Process control annotations:
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.
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.