This section describes how to use the BPEL Export tool in BEA Workshop for WebLogic®, to export BPEL 1.1 compliant code from a JPD file.
BPEL4WS (Business Process Execution Language for Web Services, commonly referred to as "BPEL") defines a language for the formal specification of automated business processes. Processes written in BPEL can orchestrate interactions between Web services using XML documents in a standardized manner. These processes can be executed on any platform or product that complies with the BPEL specification. BPEL therefore enables customers to protect their investment in process automation by allowing them to move these process definitions between a wide variety of authoring tools and execution platforms. While there have been previous attempts to standardize business process definitions, BPEL has attracted an unprecedented level of interest and is the first to gain critical mass among software vendors.
BPEL4WS 1.1 is the latest published specification from BEA, Microsoft®, and IBM®, but it does not reflect the upcoming BPEL standard, which is still under development by the OASIS standards organization. It is important to bear in mind that the final standard will be different from BPEL4WS 1.1, and therefore this tool is provided largely to enable design-time interoperability with other tools that support the 1.1 specification.
For more information on the BPEL language, refer to the BPEL4WS specification v1.1, published by BEA, IBM, and Microsoft and submitted to OASIS for standardization, which is available at:
and the official Home page for the BPEL standardization effort, hosted by OASIS at:
In BEA WebLogic Integration™, a business process is defined using BEA Process Definition for Java (JPD). The BPEL export tool is a design-time aid to help convert a JPD file into a BPEL file.
You can use the BPEL Export tool to export the semantics of a JPD file into BPEL where it can be used in a BPEL design environment. BPEL code that is exported using the BPEL Export tool is BPEL 1.1 compliant and can be used in design environments compliant with BPEL 1.1. While the main orchestration logic of the JPD is exported to BPEL, it is not expected that the exported BPEL will be immediately executable in the target environment. You will need to manipulate the BPEL in the target environment to get the exported process to run, or to get close to the run-time semantics.
This is due to the fact that some executable call-outs from the JPDs will be opaque to the exported BPEL code. These executable units generally include controls, code written in perform nodes, and XQuery transformations. The BPEL Export tool copies the Java code and the XQuery code as extension nodes in BPEL. As a result, you must re-implement the logic in the target BPEL environment, since JPD provides a superset of the functionality provided by BPEL.
One Web Service Definition Language (WSDL) file defines the WSDL interface of the business process and defines a partner-link type for the interface. The other file defines the WSDL interface and partner-link types of the partners. Partners are the artifacts interacting with the business process. These artifacts are either consumers or providers of services to the business process.
These WSDL files are not the same as the WSDL that BEA Workshop for WebLogic would generate for the corresponding JPD or JCX files. The differences are described in detail in.
The relevant XSD schema files (which must be located in a schema folder in the WebLogic Integration application) are needed in the target environment, along with the WSDL and BPEL files.
workspacerefers to where the WebLogic Process application resides.
This section provides some notes on the export process and details some known limitations of the BPEL Export tool.
|Notes:||The section details information that you should remember when using the BPEL Export tool.|
XQuery expressions in the JPD file are copied `as is' into the expression attributes of the corresponding BPEL activity. XQuery code referenced in a Data Transformation control is copied into the JPD namespace xqueryCode element. The Java code is copied into the <
jpd:javacode> node as a BPEL extension. AquaLogic Business Process Management does not validate these elements.
receive name="Client-Request" jpd:name="Client Request" .../> which fail to get validated in AquaLogic Business Process Management.
scope/> to be the first activity in a BPEL process.
This section details some of the known JPD export limitations.
java.util.Calendarare converted to the corresponding schema built-in types. XMLBean types are converted to the corresponding XML Schema type. A wrapper element type is introduced for complex types, BPEL variables cannot have a complex type as their type. Any other types (including temporary transform variables) are converted to an element type with no type attribute.
parameters, since a method has a single return type with no name.
receivemessages are exported to assign activities before or after the corresponding
Table 2-1 details how various JPD file attributes, nodes, and so on are converted to a BPEL file.
xsd:includeelement. If the types used are in a WSDL file, it is exported using
ArrayListor another Collection class's
add()method, a non-standard JPD namespace attribute
jpd:appendToCollectionis generated with its value set to
MFL types are not supported for export. Creating an empty element type for <type>.
afterExecute=resumeis not supported for the following paths:
persistentare not supported.
executeOnRollbackis not supported for
<jpd:xquerycode>node as a BPEL extension.
<jpd:javacode>node as a BPEL extension.
.dtf, .jcs), control method names, parameters used in control methods, variable names defined for controls, and
.jpdfile names that contain special character like
$are exported to
bpelfiles, these names are used as is in the "name" attribute of "variable" and "variable" attribute of "to". Since BPEL schema defines these attributes as NCName type, these special characters become invalid in the generated
bpelfile. However, this limitation is no longer valid for the
$character. For any other special character (that is not valid NCName or QName type), althought the .bpel file is generated, schema validation of the file fails.