|
|
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:
http://dev2dev.bea.com/webservices/BPEL4WS.csp
and the official Home page for the BPEL standardization effort, hosted by OASIS at:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel
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 <while>, <switch>, <invoke>, <receive>, <reply>, <onMessage>, <onAlarm>, <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.
Web ProjectSrcImport to import the BPEL file, as shown in Figure 1-1. The Import pane appears.| 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). |
.jpg)
If you try and import into a directory which is not in the source path, you get the following error message (Figure 1-3).
.jpg)
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 BpelImport.log, is stored in %BEA_HOME%\weblogic81\workshop where %BEA_HOME% is the directory in which you installed BEA Workshop for WebLogic. This log file provides information about the import process. |
The new JPD file appears in the folder specified in step 2 and the WSDL files are copied and placed in the Schemas folder, as shown in Figure 1-11.
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.
eventHandler is not supported. If it is included in the BPEL file, it is ignored during the conversion process and the following message appears: Global EventHandlers are not supported, hence ignored.wait and onAlarm for which the duration is specified using the until attribute is not supported. If the until attribute 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 (for and until) cannot be specified in a valid BPEL file. |
flow is not supported. You cannot convert a BPEL file that has a flow construct as a first logical child. In this instance, logical activity refers to any activity other than sequence and scope.links from activity flow is not supported. If links are 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 links, source, target. The conversion process will continue and will ignore these unsupported activities.reply activity is used to return normal output/outcome is not supported. In order to qualify for conversion, a BPEL file must only contain one reply activity to return a normal outcome. This is due to the fact that in a JPD file, there can only be one returnMethod for any synchronous clientReceive. However, in a BPEL file, there can be several reply activities for a single receive. There is no direct way to map one receive and several reply nodes to a single clientRequestWithReturn.pick activity with more than one OnAlarm activity is not supported for conversion. This is due to the fact that pick gets converted to eventChoice. Each eventChoice can have at most one timeoutEvent node, which is generated for an onAlarm activity. for attribute of onAlarm activity using bpws:getVariableData(..) is not supported. When a for attribute 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%\\weblogic81\workshop where %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.
assign activities 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.assign is 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.eventHandlers in the onMessage branch, a dummy Timer method may be generated for the eventHandler onMessage path. JPD specification mandates that onMessage and onTimeout paths 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 eventHandler is associated with a scope that does not contain any receive, onMessage, flow, or wait activity.attributeFormDefault="qualified" and elementFormDefault="qualified" and then using the qualified query string.reply activities on multiple partner links. This is not supported in a JPD file. Only one such partner link will be converted as clientRequestWithReturn that matches the reply semantics. reply activities on other partner links will be converted into an asynchronous interface.onMessage paths which have slightly different semantics. In the imported JPD file, once the event is received and the onMessage path is executing, the block (corresponding to the BPEL scope) does not continue executing until the onMessage path completes. This also means that only one instance of an Event Handler can be active at any one time.invoke activities to Web Service controlSend calls. 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 receive and 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.
|