|
|
This section describes the procedures to use BPEL Import tool in Oracle Workshop for WebLogic to import a BPEL file.
WS-BPEL (Web Services Business Process Execution Language, 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.
WS-BPEL 2.0 is now an OASIS standard. For more information on BPEL, download the specification from BPEL4WS specification v1.1, and WS-BPEL specification 2.0. Also, see the official Home page for the BPEL standardization effort, hosted by OASIS. The BPEL import and export tool is provided largely to enable design-time interoperability with other tools that support the 1.1 and 2.0 specifications.
You can use the BPEL Import tool to import a BPEL file into a JPD file, where it can be used in the Oracle 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 Oracle Workshop for WebLogic.
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. Therefore, the imported JPD file should be reviewed and tested with any required changes that are 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 Oracle 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.
| 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. |
.bpel file. Similarly browse to the WSDL and XSD Locations to set the path for Web Services Description Language WSDL and XSD files as shown in Figure 1-3.| Note: | Type an appropriate Package Name in the Package Name Field.. |
| Note: | Select the Util project folder. Preferably the make it point to the Util project created while reacting the Oracle WebLogic Process Application. |
| Note: | A log file for the import process, named BpelImport.log is stored in the workspace/.metadata folder (workspace indicates your Oracle WebLogic Process Application workspace). |
The new JPD file is displayed in the folder specified in step 2 and the WSDL files are copied and placed in the Schemas folder.
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.
| Note: | You need to 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\user_projects\workspaces\bpel_import\.metadatap where %BEA_HOME% is the product home directory. 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. Ensure that you check to verify the correctness of any generated XQuery expressions. XSD file in the WSDL directory when importing through Oracle 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. until and repeatEvery are not supported and will be ignored.suppressJoinFailure and exitOnStandardFault will be ignored.
|