This chapter describes issues associated with Oracle BPEL Process Manager. It includes the following topic:
Note:
For details about restrictions on using non-ASCII characters in BPEL monitor metric names, see Section 17.1.24, "BPEL Monitor Metric Names in Non-ASCII Characters Causes Deployment Error, Missing Data Object on Oracle BAM Server."This section describes general issue and workarounds. It includes the following topics:
Section 16.1.1, "No Restriction on Adding a Compensate Activity to any Part of a BPEL Process Flow"
Section 16.1.2, "Exception in Switch Activity Evaluation Returns an Error"
Section 16.1.3, "Use a Wait Activity Instead of thread.sleep() in a Java Embedding Activity"
Section 16.1.6, "Oracle JDeveloper May Hang When Using the Expression Builder"
Section 16.1.7, "Cannot Format the Body of an E-mail Message as HTML with the processXSLT Function"
Section 16.1.10, "Selecting the Key for an Entity Variable in the Browse Entity Variable Dialog"
Section 16.1.11, "BPEL Project Customization Does Not Support DVM and XREF Files"
Section 16.1.12, "MIME Type for Voice Notification in BPEL Voice Activity Requires Modification"
Section 16.1.16, "Parsing of MIME Attachments is Not Supported"
As described in section "Using Compensation After Undoing a Series of Operations" of the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite, the compensate activity is only called in the fault handler or compensate handler of the area immediately encompassing a scope activity.
However, you are not restricted from adding a compensate activity to any other part of your BPEL process flow in the BPEL Process Designer of Oracle JDeveloper. If you add a compensate activity outside of a scope, a null pointer exception error is displayed during project compilation. Note that this error message does not clearly indicate that the problem is that you added the compensate activity outside of a scope activity.
Only use a compensate activity in a fault handler or compensate handler of a scope activity.
If you use a selectionFailure or an XPath expression in a switch case evaluation and an exception error occurs, the default behavior is to return an exception error to the client. This behavior is in compliance with the Business Process Execution Language for Web Services Specification. For example, the following switch activity condition returns an exception error, as expected.
<switch name="SwitchWhatIf">
<case
condition="bpws:getVariableData('inputVariable','payload','/client:BPELBulkImp
ortProcessRequest/client:action') != 'PREIMPORT'">
This condition is only false, and therefore does not return an exception, when action='PREIMPORT'.
If you create and deploy a BPEL process that uses thread.sleep() in a Java Embedding activity, the executing thread is blocked and the transaction associated with that thread is prevented from committing. This causes BPEL instances to show up only after the wait is over, which is the expected behavior.
Instead, use a wait activity, which releases the resource upon entering the activity and enables the ongoing transaction to commit and the BPEL instance data to hydrate into the data store.
If the HTML for the message content of an email activity is generated dynamically, (as with XSLT, file read, and so on), it must be wrapped in a CDATA function. This prevents conflicts between the XML/HTML content of the message body and BPEL's internal XML data structures.
For example, assume you use the following append operation for the message content inside the email activity:
<bpelx:append>
<bpelx:from
expression="ora:processXSLT('xsl/email.xslt',bpws:getVariableData('Variable_1'
))"/>
<bpelx:to variable="varNotificationReq" part="EmailPayload"
query="/EmailPayload/ns1:Content/ns1:ContentBody/ns1:MultiPart/ns1:BodyPart[1]
/ns1:ContentBody"/>
</bpelx:append>
For this to work correctly, you must pass the output of the processXSLT() function to the CDATA() function.
<%ora:toCDATA(xdk:processXSLT('xsl/email.xslt',
bpws:getVariableData('inputVariable','payload','/client:process/client:input')
))%>
Tables H-1 and H-2 of Appendix H, "Normalized Message Properties" of the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite describe the Oracle BPEL Process Manager and Oracle Web Services Addressing properties.To use these properties correctly with the bpelx:property in activities such as a receive activity, ensure that you do not include the wsa. or bpel. prefixes. For example:
<receive name="receiveInput" partnerLink="bpelprocessb_client"
portType="client:BPELProcessB" operation="process" variable="inputVariable"
createInstance="yes">
<bpelx:property name="action" variable="v1"/>
<bpelx:property name="messageId" variable="v2"/>
<bpelx:property name="relatesTo" variable="v3"/>
<bpelx:property name="replyToAddress" variable="v4"/>
<bpelx:property name="replyToPortType" variable="v5"/>
<bpelx:property name="replyToService" variable="v6"/>
</receive>
Using the Expression Builder to build XPath expressions may cause Oracle JDeveloper to hang. If that happens, perform the following steps:
Kill the Oracle JDeveloper process.
Restart Oracle JDeveloper.
Select Tools > Preferences > SOA, and deselect the Validate Expression checkbox.
After performing these steps, Oracle JDeveloper should no longer hang.
You cannot use the BPEL XPath extension function processXSLT to format the body of an e-mail message as HTML. For example, assume you use the append operation for the content body and the processXSLT function to get the content in HTML format inside an e-mail activity:
<bpelx:append>
<bpelx:from
expression="ora:processXSLT('xsl/email.xslt',bpws:getVariableData('Variable_1'
))"/>
<bpelx:to variable="varNotificationReq" part="EmailPayload"
query="/EmailPayload/ns1:Content/ns1:ContentBody/ns1:MultiPart/ns1:BodyPart[1]
/ns1:ContentBody"/>
</bpelx:append>
The Oracle Enterprise Manager Fusion Middleware Control Console audit trail indicates that the payload is passed to the notification service, but the e-mail that is sent contains no content.
According to the Business Process Execution Language for Web Services Specification, if the the locationPath argument of the bpws:getVariableData() function selects a node set of a size other than one during execution, the standard fault bpws:selectionFailure must be thrown by a compliant implementation.
For example, the following count() function does not work if there are multiple entries of product elements under StoreRequest, which would cause a selectionFailure fault to be thrown.
count(bpws:getVariableData('inputVariable',
'payload','/ns2:StoreRequest/ns2:product'))
To make this work, change the syntax to the following:
"count($inputVariable.payload/ns2:product)"
Oracle JDeveloper hangs when you manually enter nested expressions in the Expression field of the Expression Builder dialog.
As a workaround, manually edit the BPEL project in Source view.
When selecting the local part of an entity key by browsing entity variables, entity icons display in the expanded element tree. These icons are identified by a blue x inside parentheses, and indicate which elements include entity keys. Selecting these elements does not update the Key Local Part or Key Namespace URI fields in the Specify Key dialog. Instead, you must expand these elements to select the actual key to get the key's local part and namespace. For example:
In the Bind Entity dialog, click the Add icon to invoke the Specify Key dialog.
To the right of the Key Local Part field, click the Browse Entity Variable icon.
Note that a blue x inside parentheses indicates which elements include entity keys. Do not select these elements.
Expand these elements to display the entity keys available for selection.
Select an entity key, and click OK.
The Key Local Part and Key Namespace URI fields of the Specify Key dialog are populated with information about your selection.
Domain value map (DVM) and cross reference (XREF) files are not supported in a SOA composite application that is enabled for customization.
For more information about customization of BPEL projects, see Chapter 15, "Customizing SOA Composite Applications" of Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
In a BPEL voice activity, the MIME type for message content generated in the source code is in text/vxml format. However, the message sent from the composite to the voice XML driver must be in text/plain format. This is because the voice XML driver adds the voice XML wrapper to the message before sending it to the destination point.
If the message content sent to the driver is in text/vxml format for the MIME type, a message delivery failure occurs. Therefore, manually change the MIME type for the voice payload content to be text/plain in Source mode in Oracle JDeveloper.
<scope name="VoiceApproval">
. . .
. . .
<copy>
<from expression="string('text/plain')"/>
<to variable="varNotificationReq" part="VoicePayload"
query="/VoicePayload/ns1:Content/ns1:MimeType"/>
</copy>
. . .
. . .
</scope>
A BPEL process does not receive a callback when two asynchronous methods are invoked on an external stateless web service using the same partner link definition.
As a workaround, perform one of the following tasks:
Create a separate partner link for each invoke and receive pair in the BPEL process when calling this type of web service. The callback is received and the BPEL process completes successfully when you have more than one method invoked on the same partner link.
Add the extension attribute bpelx:conversationId to an invoke activity, receive activity, or onMessage branch of a pick activity. This enables you to programmatically set the conversation ID and have multiple conversations on one partner link. For example:
<invoke name="Invoke_1" inputVariable="Variable_1"
partnerLink="BPELProcess2.bpelprocess2_client"
portType="ns4:BPELProcess2" operation="process"
bpelx:conversationId="bpws:getVariableData('convId1')"/>
<invoke name="Invoke_2" inputVariable="Variable_1"
partnerLink="BPELProcess2.bpelprocess2_client"
portType="ns4:BPELProcess2" operation="process"
bpelx:conversationId="bpws:getVariableData('convId2')"/>
<receive name="Receive_1" createInstance="no"
variable="Variable_2"
partnerLink="BPELProcess2.bpelprocess2_client"
portType="ns4:BPELProcess2Callback"
operation="processResponse"
bpelx:conversationId="bpws:getVariableData('convId1')"/>
<receive name="Receive_2" createInstance="no"
variable="Variable_2"
partnerLink="BPELProcess2.bpelprocess2_client"
portType="ns4:BPELProcess2Callback"
operation="processResponse"
bpelx:conversationId="bpws:getVariableData('convId2')"/>
Custom applications coded with the Oracle BPEL Process Manager 10.1.3 Client Java API cannot currently be upgraded to the 11g Release 1 Client Java API. As a workaround, you can use the Infrastructure Management API that is shipped with Release 1. However, note that this API is currently being rationalized and reworked. Periodic updates to the Infrastructure Management JavaDoc are being made available on the Oracle Technology Network. Visit the following URL for details:
http://www.oracle.com/technology/products/soa/bpel/collateral/documentation.html
This occurs because the caller does not provide information about the composite instance ID in a subsequent call. Therefore, the Service Infrastructure creates a new composite instance, although the call is routed to an already-created composite instance.
A BPEL process can receive a MIME attachment along with the payload. The attachment can be in any format (for example, doc, PDF, JPEG, XML, text, and so on). If the BPEL process receives an XML attachment and must parse the XML to get an element value, you cannot do it using a single XPath function. This task must be performed in two steps:
Use the ora:writeBinaryToFile XPath function.
<copy>
<from expression="ora:writeBinaryToFile('input2','bin',
'file:///tmp/out/attachment.xml')"/>
<to variable="input2" part="bin"/>
</copy>
Use the doc XPath function to read the XML element from the above file.
<copy>
<from expression="ora:doc('file:///tmp/out/Input.xml')"/>
<to variable="DecodedAttachment" query="/ns1:discountandshipping"/>
</copy>
When you modify the name of an activity sensor or variable sensor in monitor view in Oracle BPEL Designer, the sensorAction.xml file is not correctly updated. Old sensor names still exist and must be removed manually from the sensorAction.xml file before deploying the SOA composite application. For example, assume you change a sensor name from ActivitySensor_1 to MyActivitySensor_1. If you save your changes and look in the sensorAction.xml file, both the old and new names are displayed:
<?xml version = '1.0' encoding = 'UTF-8'?>
<actions
@ targetNamespace="http://xmlns.oracle.com/TryUpdateSensorApp_jws/TryUpdateSenso
@ rApp/TryUpdateSensorApp" xmlns="http://xmlns.oracle.com/bpel/sensor"
@ xmlns:tns="http://xmlns.oracle.com/TryUpdateSensorApp_jws/TryUpdateSensorApp/T
@ ryUpdateSensorApp" xmlns:pc="http://xmlns.oracle.com/bpel/sensor">
<action name="SensorAction_1" publishName=""
publishType="BpelReportsSchema" enabled="true" filter="" publishTarget="">
<sensorName>ActivitySensor_1</sensorName>
<sensorName>MyActivitySensor_1</sensorName>
</action>
</actions>
Open the file in Source view in Oracle BPEL Designer and remove the line with the old name, then save the file.
<sensorName>ActivitySensor_1</sensorName>