# Business Process Source Code

As you design business processes using the graphical tools in WebLogic Workshop, WebLogic Workshop writes source code to a business process file (a JPD file), in keeping with your work in the Design View. A JPD file is a Java file in that it contains code for a Java class. However, because a file with a JPD extension contains the implementation code intended specifically for a business process class, the extension gives it special meaning to the WebLogic Workshop compiler.

You can access the source code for business processes you are creating in the Design View, by clicking the Source View tab.

This section describes the source code in a business process (JPD) file, and how it is related to the work you do while creating your business process graphically in the Design View. It includes the following topics:

- Overview
- Business Process Language
- Variables
- Control Declarations
- Client Operations and Control Communication Methods
- Perform Methods
- XQuery Statements

## Overview

To organize the source code in a JPD file, the code generated for you as you work in the Design View is hidden in collapsible regions in the Source View. Methods that you write for conditions in Decision, For Each, While nodes, and so on, are shown inside the Business Process Designer generated code region—each inside their own collapsible regions in the JPD file in the Source View. Methods you create for Perform nodes are created outside the Business Process Designer generated code region.

Specific regions in the Source View represent variable declarations, control declarations, XQuery annotations, and methods associated with client operations and communication with controls. In the Source View, you can expand these collapsed regions of code to add or edit the contained code. The WebLogic Workshop environment supports two-way editing of your business process (Java) class—the extent to which you can add code or change the code generated by WebLogic Workshop is indicated by comments in the source code and described in the following sections.

## Business Process Language

To view the business process annotation that describes the business process you created in the Design View, expand the region of code indicated with .

This annotation contains the business process definition, created for you as you add nodes to your business process in the Design View. The Java methods and variables defined in this JPD file can be referenced by the flow logic described in annotation.

The <process> element is the top-level container for the business process logic. A business process is composed of a set of activities with defined ordering. The business process element contains a name attribute, which specifies the name of your business process. Lines of XML describe the nodes in your business process. A line of XML is written in this area of code for each node you add to your business process in the Design View.

Two-way editing is supported for the process language. In other words, changes you make to the code in this region of the JPD file appear in the Design View. For example, you can:

- Create a new line of XML to describe a node in your business process. In the Design View, the business process is updated with the new node, in keeping with your work in the Source View. If the XML you add is not well formed, a new node is not added in the Design View. Instead, WebLogic Workshop displays a compiler error.
- Write a line of process language that references a method. However, the method is not created automatically; you must create it in the JPD file.
- Edit the process language that was already created for you. Your changes are reflected in the Design View.
- Delete lines that correspond to a business process node. The business process in the Design View is updated accordingly.

If the line of process language you delete references a method, which is already written in the file, the method is not deleted. You can leave the method in your file—if it is not referenced in the process language at run time, it is ignored by the run-time engine. Delete only methods that you are sure are not referenced in your process language. If you delete referenced methods, errors will be generated in your application.

Note: WebLogic Workshop flags errors you make in the process language with red, wavy underlines and error messages visible in mouseover text.

Warning: If you add any text within XML comment tags, or comment out sections of code, those lines of comments will disappear from the Source View the next time you make changes in the Design View. This only applies to comments, any other code changes remains.

## Variables

Business process variables are defined within the region of code in the Source View shown in the following figure.

Two-way editing is supported for variables. In other words, changes you make to the code in this region of the JPD file appear in the Design View, specifically the Variables tab on the Data Palette.

You can create, edit, or delete a business process variable in the Source View. The Variables tab on the Data Palette, is updated to reflect your changes. If the variable is not declared correctly, the error is identified in the Source View with red, wavy, underlines, and the variable does not appear on the Variables tab.

Warning: Ensure that you update a given variable in all locations where it is used. If you do not, changes you make to the business process variable generates errors in your application.

## Control Declarations

Declarations for controls are defined in the region of code in the Source View shown in the following figure.

Two-way editing is supported for control declarations. In other words, changes you make to the code in this region of the JPD file appear in the Design View.

You can create, edit, or delete a control declaration in the Source View. The Design View, specifically the Controls tab on the Data Palette, is updated to reflect your changes. If the control is not declared correctly, the error is identified in the Source View with red, wavy, underlines, and the control does not appear on the Controls tab.

Warning: Changing declarations for controls already in use by your application generates errors in your application if you do not remove or update references to the control.

To learn about working with controls in the Design View, see Interacting With Resources Using Controls.

## Client Operations and Control Communication Methods

Every client operation and communication method associated with a control is defined in its own collapsed region of code in the Source View. Code in these regions is generated automatically. Comments in the code, within these methods, identify the protected sections of code.

### Can You Edit Code in Protected Sections?

In the Source View, you can add and edit the code before and after the protected sections within the blocks of code that specify client operations and control methods.

After you add or edit the code before or after the protected sections, the following icon is associated with the appropriate node (Client Request, Client Response, Control Send, Control Receive, Control Send with Return) in the Design View: . Two-way editing is still supported. In other words, you can continue to design the node in either the Source View or the Design View. The icon ( ) in the Design View is a visual reminder that you edited the code in the Source View.

If you try to edit the code within the protected sections, you are prompted with a warning message and a question whether you want to continue with your edit, which in effect removes the protected sections. If you edit the code in the protected sections, the node builders in the Design View can no longer interpret the code. Consequently, the node appears unconfigured in the Design View.

For example your business process can include a Client Receive node that you configured using the Client Receive node builder. In the Design View, the node is displayed as shown in the following figure:

If you right-click the node and select View Code from the drop-down menu, your view is switched to the Source View at the appropriate method. In this case, your source code resembles that in the following figure:

The protected sections of code are clearly marked. You can add any valid code you want. For example, say you add a validate() method to validate the incoming XML document against an XML schema, as shown in the following figure:

After you add your custom code, you can open the Design View by clicking the Design View tab. Note that the representation of the node associated with this code changed from:

You can make subsequent changes to the design of the node using either the Design View or the Source View. To learn about designing client and control operations in the Design View, see Interacting With Clients and Interacting With Resources Using Controls.

## Perform Methods

Methods you create for Perform nodes and methods you write for conditions in Decision, For Each, or While nodes are shown outside (and below) the collapsed regions of code in the JPD file in the Source View.

    public void perform() throws Exception {
    }

You can write code (perform methods) in the Source View to perform any logic you want. The Design View for your business process is not updated in keeping with your work on such perform methods until you create a reference to the methods in the Business Process Language.

To learn about creating Perform nodes in the Design View, see To Create a Perform Node in Your Business Process.

## XQuery Statements

XQuery statements are written to the JPD file in the region of code in the Source View shown in the following figure.

The XQuery statements are preceded by the following annotation:

    @jpd:xquery prologue::

For example, when you select a repeating XML node using the For Each node builder, as described in Designing For Each Nodes, an XQuery expression is created in your JPD file. The expression returns the set of XML elements over which the For Each node iterates. XQuery expressions are also written in your JPD file when you create conditions on Decision nodes. XQuery expressions also define the transformations you create between disparate data types using the mapping tool.

For more information about XQuery, see XQuery Reference.

To learn more about For Each nodes, Decision nodes, and data transformations, see the following topics:

- Looping Through Items in a List
- Defining Conditions For Branching
- Guide to Data Transformations
- Tutorial: Building Your First Data Transformation

Related Topics

Jpd Context Interface

ControlContext Interface

@jpd:xquery Annotation