Designing Your Application

You build your application in WebLogic Workshop by adding projects to an application. A project contains components of your application such as business processes, Web services, control files, and XML files.

Creating a Business Process Application

To quickly get started designing business processes, you can create an application that contains a basic business process file, which you can customize with your business process logic. To do so, complete the following procedure:

To Create a New Application

Choose File —> New —> Application from the WebLogic Workshop menu to display a New Application dialog box.
To create a business process application, select Process in the left pane in the dialog box. In the right pane, select Process Application.

This creates an application that contains a basic business process project, which includes a business process file that contains only a Start and Finish node (process.jpd).

Note: If you select Tutorial: Process Application instead of Process Application, WebLogic Workshop creates an application containing components for the Business Process and Data Transformation tutorials. To learn about taking the tutorial, see Tutorial: Building Your First Business Process, and Tutorial: Building Your First Data Transformation. You can also build an ebXML or RosettaNet participant business process in WebLogic Workshop by using specially created templates. For more information about how to create these participant processes, see Building ebXML Participant Business Processes and Building RosettaNet Participant Business Processes.

Specify the directory in which to create the Application folder.
Specify a name for your new application.
In the Server field, select the sample integration domain or any other WebLogic Integration domain in which your application runs. Click Browse to browse the file system to find a WebLogic Server configuration file.
Click Create.

Your application is displayed on the Application tab in WebLogic Workshop, as shown in the following figure:

The How Do I: Use the Design View? topic briefly describes the components and tools you use to design your business process in the WebLogic Workshop graphical design environment.

Subsequent topics in this guide describe in detail how to design specific business process patterns, including tasks such as:

Adding methods and callbacks to client nodes in your business process to create the interface between your business process and its clients.
Adding controls to represent the interfaces with resources such as Web services, databases, and EJBs.
Mapping disparate data types in your business process, using XML Schemas, and constructing sequences of XML elements over which your business process can iterate to perform specified activities.
Viewing and editing the JPD file in the Source View.

To learn about these tasks and others, see Topics Included in This Section.

Setting the Business Process Properties

There are several properties which you can view and configure for your business process in the Property Editor of your business process start node.

To Set the Business Process Properties

Select the Start node of the business process for which you want to configure the properties.
If the Property Editor is not visible in WebLogic Workshop, choose View —> Property Editor from the menu bar.

In the Property Editor, the following properties are displayed: general, process, and version.

general

name—This is the name of your business process, which is displayed throughout the WebLogic Workshop application, including the WebLogic Integration Administration Console. You can change the name to anything you would like by clicking this property and entering a new name.
notes—Enter any notes that you want associated with your business process by clicking this property and then clicking to open the Property Text Editor. Notes entered in the editor will be also be displayed in the WebLogic Integration Administration Console.

process

freeze on failure—When a business process fails and there is no exception handler configured to handle the exception thrown, the business process is placed into an aborted state and no recovery is possible. However, if the business process is configured to freeze on failure, the business process rolls back to the last commit point and the state is persisted if it fails. The process can then be restarted from the WebLogic Integration Administration Console. To configure a business process to freeze on failure: select true from the freeze on failure drop-down menu.

For more information about business process exception handlers, see Handling Exceptions. For more information about how to unfreeze business processes in the WebLogic Integration Administration Console, see Process Instance Monitoring in Managing WebLogic Integration Solutions at the following URL:

http://download.oracle.com/docs/cd/E13214_01/wli/docs81/manage/processmonitoring.html

persistence—This property sets how a stateful business process is persisted. More specifically, it determines whether a conversation is maintained in memory or stored in a database repository. Normally, stateful processes are persisted to a database. However, you may want to use non-persistent stateful processes for the following:

When the native communication mechanism requires it.
When multiple send-receive operations need to be done in parallel.
When the performance of a stateful process using a database does not meet performance goals.

To set the type of persistence, from the persistent drop-down menu:

Select always when you want your process conversations saved in the database repository. These conversations can be recovered in the event of an abnormal shutdown or crash. This setting is the WebLogic Integration default.
Select never when you do not want your process conversations saved in the database repository. These conversations cannot be recovered in the event of an abnormal shutdown or crash.
Select on overflow when you want your process conversations saved in the database repository after reaching a certain number. Until this number is reached, conversations are non-persistent. To set the overflow, set the Max Beans in Cache deployment descriptor. To learn more about configuring deployment descriptors, see EJB->Configuration->Descriptors in the WebLogic Server Administration Console Online Help at the following URL:

http://download.oracle.com/docs/cd/E13222_01/wls/docs81/ConsoleHelp/domain_ejbcomponent_config_descriptors.htm

on sync failure—This property only applies to your process if it is configured to be a synchronous subprocess, it is ignored for any other business processes. If a synchronous subprocess fails, the default behavior is to mark it as rollback, which causes both the subprocess and the parent process to rollback. However, if the on sync failure property is set to rethrow, only the subprocess is rolled back. To learn more about synchronous subprocesses and the on sync failure property, see Working with Subprocesses.
retry count—Specify how many times, after the first attempt, the process engine should try to execute the business process.

If your business process contains an asynchronous Client Request node or multiple Client Request nodes, any one of which is asynchronous, then you can set the retry count for the business process. You cannot set the retry count property for business processes that contain only synchronous Client Request nodes (that is, Client Request with Return nodes).

retry delay—Specify the amount of time (in seconds) you want to pass before a retry is attempted.

If your business process contains an asynchronous Client Request node or multiple Client Request nodes, any one of which is asynchronous, then you can set the retry delay for the business process. You cannot set the retry delay property for business processes that contain only synchronous Client Request nodes (that is, Client Request with Return nodes).

stateless—This property is for viewing only, it cannot be edited. It displays whether your business process is stateless (property displays true) or stateful (property displays false). To learn more about stateless and stateful business processes, see Building Stateless and Stateful Business Processes.
binding—This property specifies whether the business process uses the Web service, ebXML, or RosettaNet protocol. The default value is webservice. If your business process is an ebXML or a RosettaNet process, select ebxml or rosettanet. In keeping with your selection in the Property Editor, an attribute is written to the @jpd: process annotation in the source code. For example:

@jpd:process binding="rosettanet" process::

To learn about ebXML and RosettaNet business processes, see Building ebXML Participant Business Processes and Building RosettaNet Participant Business Processes.

version

strategy—This describes how to invoke sub processes when different versions of the parent process exists. From the strategy drop-down menu:

Select loosely-coupled if you want the subprocess version to be set at the time that the sub process is invoked.
Select tightly-coupled if you want the subprocess version to be set at the time the parent process is invoked.

For more detailed information about the version strategy property, see Configuring the New Versions of Your Business Process.

ebxml

For information about ebXML properties, see @jpd:ebxml Annotation.

rosettanet

For information about RosettaNet properties, see @jpd:rosettanet Annotation.