This section describes how to use the BPEL Import tool in BEA Workshop for WebLogic® to import a BPEL 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 import tool is a design-time aid to help convert a BPEL file into a JPD file.
You can use the BPEL Import tool to import a BPEL file into a JPD file, where it can be used in the BEA Workshop for WebLogic design environment. While the main orchestration logic of the BPEL file is imported into a JPD file, it is not expected that the imported JPD file will be immediately executable in BEA Workshop for WebLogic. You will need to manipulate the JPD file in BEA Workshop for WebLogic to get the imported process to run.
In certain cases, runtime semantics are not guaranteed, due to the functional mismatches between the JPD and BPEL languages, or between various expression languages including differences between XQuery, Xpath, and XSLT. Runtime semantics are also not guaranteed when they involve vendor extensions, external artifacts, or environment settings. For the above reasons, the imported JPD file should be reviewed and tested with any required changes that were made to ensure that it runs properly.
In general, the BPEL Import tool expects complete BPEL and WSDL artifacts as input. To some extent, the tool also handles incomplete BPEL and WSDL artifacts, so that in-progress BPEL files can be imported as JPD, and then completed in the WebLogic Integration environment. Incomplete cases are numerous and may include missing WSDL files, missing type definitions, missing port type definitions, or incomplete constructs of
<throw>, as well as other cases. If the BPEL Import is not able to import the input artifacts into a JPD file, error messages appear that enable you to correct the input artifacts for future imports.
|Note:||The BPEL Import tool does not support importing to Schemas/Project root directories. If you try to import into a root directory, you get the following error message (Figure 1-2).|
If you try and import into a directory which is not in the source path, you get the following error message (Figure 1-3).
The import begins and you can view the progress of the import as shown in Figure 1-8.
|Note:||The Build pane below the Design pane displays diagnostic messages about the schema import process as shown in Figure 1-10. The log files are stored in the workspace/.metadata folder (workspace indicates your Weblogic Process Application workspace).|
|Note:||A log file for the import process, named
This completes the import process and your new JPD file is located in the folder specified in step 2.
This section details some known limitations and issues of the BPEL Import tool. The majority of these issues exist because of the inherent differences between the JPD and BPEL languages.
It is very important that you confirm that the generated JPD file corresponds semantically with the input BPEL file.
eventHandleris not supported. If it is included in the BPEL file, it is ignored during the conversion process and the following message appears:
EventHandlers are not supported, hence ignored.
onAlarmfor which the duration is specified using the
untilattribute is not supported. If the
untilattribute is contained in the BPEL file, a warning appears stating that it is not supported and is ignored in the generated JPD file. The conversion process will continue after this warning is displayed.
|Note:||Both attributes (
flowis not supported. You cannot convert a BPEL file that has a
flowconstruct as a first logical child. In this instance, logical activity refers to any activity other than sequence and scope.
flowis not supported. If
linksare present in the BPEL file that you want to convert, a warning appears stating that the generated JPD file may be erroneous as it contains
target. The conversion process will continue and will ignore these unsupported activities.
replyactivity is used to return normal output/outcome is not supported. In order to qualify for conversion, a BPEL file must only contain one
replyactivity to return a normal outcome. This is due to the fact that in a JPD file, there can only be one
returnMethodfor any synchronous
clientReceive. However, in a BPEL file, there can be several
replyactivities for a single
receive. There is no direct way to map one
replynodes to a single
pickactivity with more than one
OnAlarmactivity is not supported for conversion. This is due to the fact that
pickgets converted to
eventChoicecan have at most one
timeoutEventnode, which is generated for an
bpws:getVariableData(..)is not supported. When a
forattribute is specified using
bpws:getVariableData(..), the imported code produces a syntax error.
WARNING: Failed to parse input XSD & WSDL files. Please see logs for detail, and the log file contains the following error message:
Duplicate global type, you should specify that multiple definitions of the namespace are ignored.
The log file for the import process, named
BpelImport.log, is stored in
%BEA_HOME% is the directory where you installed BEA Workshop for WebLogic. This log file provides information about the import process.
To specify that multiple definitions of the namespace are ignored, select Schema Project PropertiesBuild and list the namespaces to be ignored in the ignore multiple definitions in following namespaces field.
assignactivities are imported. Therefore, the generated XQuery expressions might not always be syntactically correct. Make sure that you check to verify the correctness of any generated XQuery expressions.
XSD file in the WSDL directory when importing through BEA Workshop for WebLogic.
assignis converted to a variable, the resultant XQuery file may contain the following "PARSE ERROR" in the Design view:
The main XML element does not match the root node of the target schema. However, you can ignore this message as the correct value is generated in runtime. This error is due to the fact that the Design view of XML Mapper has limitations and might not always be able to parse even correct XQuery expressions.
eventHandlersin the onMessage branch, a dummy Timer method may be generated for the
eventHandleronMessage path. JPD specification mandates that
onTimeoutpaths can only be associated with process nodes (or block of nodes) that do not run automatically. To handle this constraint, a dummy Timer node with a 1 second timeout is created if an
eventHandleris associated with a scope that does not contain any
elementFormDefault="qualified"and then using the qualified query string.
replyactivities on multiple partner links. This is not supported in a JPD file. Only one such partner link will be converted as
clientRequestWithReturnthat matches the reply semantics.
replyactivities on other partner links will be converted into an asynchronous interface.
onMessagepaths which have slightly different semantics. In the imported JPD file, once the event is received and the
onMessagepath is executing, the block (corresponding to the BPEL scope) does not continue executing until the
onMessagepath completes. This also means that only one instance of an Event Handler can be active at any one time.
invokeactivities to Web Service
controlSendcalls. It generates a Web Service control for the specified partner service and the JPD file invokes the corresponding method on the control. This release has some limitations in its capability to generate a Web Service control (a JCX file) in certain situations. You should carefully examine the contents of the generated JCX file to ensure that you can compile it.
<reply>in Switch, Case, o Otherwise nodes may not be logically correct. This is because the matching
receiveand reply of the synchronous operation are not present at the same level.
<receive> - <reply>block. In such a scenario, the generated JPD may not compile.