| Oracle® Fusion Middleware Release Notes 11g Release 1 (11.1.1) for Microsoft Windows x64 Part Number E14774-05 |
|
|
View PDF |
| Oracle® Fusion Middleware Release Notes 11g Release 1 (11.1.1) for Microsoft Windows x64 Part Number E14774-05 |
|
|
View PDF |
This chapter describes runtime and common functionality issues associated with Oracle SOA Suite. It includes the following topics:
This section describes general issues and workarounds. It includes the following topics
Section 20.1.5, "Best Practice for Starting and Stopping a Managed Server"
Section 20.1.6, "Composite-to-Composite Calls Fail If Audit Level of Second Composite is Set to Off"
Section 20.1.7, "Persisting BPEL Instance Faults into the Database"
Section 20.1.9, "Descriptions for Data Source JNDI Fields are Interchanged"
Section 20.1.10, "Limitations on Viewing XML Data on the Audit Trail Page with Internet Explorer 7"
Section 20.1.11, "Display of XML Content Getting Cut Off with Mozilla Firefox"
Section 20.1.14, "Receiving an Empty Namespace Tag in an Output Message"
Section 20.1.15, "Nonrecoverable BPEL Process Fault Displays as Successfully Recovered"
Section 20.1.16, "Recovered Instances Can Continue to Display as Faulted"
Section 20.1.17, "BPEL Process Messages May Remain Visible in the Recovery Page During Recovery"
Section 20.1.18, "Exception Message to Ignore After a Faulted Instance is Terminated"
Section 20.1.19, "Attributes are not Passed in the <body> Tag of a SOAP Payload"
Section 20.1.21, "Using UTF-8 Native Encoding for Composite Test Case Message Files"
Section 20.1.22, "Non-ASCII Business Event Definition Names Do Not Conform to XML Standards"
Section 20.1.23, "Server URL Logic when HTTP and HTTPS are Enabled"
Section 20.1.24, "Fault Policy Retry Action May Not Execute with Multiple Faults in the Same Flow"
Section 20.1.25, "Faulted Oracle B2B Instances Caused by a Policy Violation Cannot Be Aborted"
Section 20.1.27, "Mediator Instances Can Display as Running After Transaction Completion"
Section 20.1.29, "Manually Map Elements with Nillable Attributes in the XSLT Mapper"
Section 20.1.33, "Handling Business and Remote Faults in the Calling BPEL Processes"
Section 20.1.34, "Recovery of Multiple BPEL Faults Does Not Work on All Selected Faults"
You cannot attach security policies to adapters included in a SOA composite application in Oracle Enterprise Manager Fusion Middleware Control Console. This is the expected behavior. For example, perform the following steps:
From the SOA Infrastructure menu, select a SOA composite application that uses a technology adapter (for example, a file adapter).
In the Service and References section, select the adapter.
Select the Policies tab.
Note that the following message is displayed.
policies can be attached to web service bindings and soa components
If you add an Oracle mediator or BPEL process partner link to your BPEL process in Oracle BPEL Designer and connect either partner link to your BPEL process through an invoke activity, the wiring is not automatically reflected above in the SOA Composite Editor. You must explicitly wire the Oracle mediator or BPEL process service component to your BPEL process again in the SOA Composite Editor.
As a best practice, always create and wire Oracle mediator and BPEL process service components in the SOA Composite Editor, instead of in Oracle BPEL Designer.
Note that this is not an issue with human task or business rule partner links in Oracle BPEL Designer; both are also automatically wired in the SOA Composite Editor.
If you store application artifacts in a source control system that you later want to reuse for deployment with ant, the following changes are required if the application has metadata service (MDS)-based references.
Assume the original Oracle JDeveloper application has file-based MDS references such as the following:
<metadata-store-usage id="mstore-usage_1">
<metadata-store
class-name="oracle.mds.persistence.stores.file.FileMetadataStore">
<property value="${oracle.home}/integration"
name="metadata-path"/>
<property value="seed" name="partition-name"/>
</metadata-store>
Modify this code to use database-based MDS references in the Application_Directory/.adf/META-INF/adf-config.xml file, as shown below:
<metadata-store-usage id="mstore-usage_1">
<metadata-store
class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
<property name="jdbc-userid" value="${mdsuser}"/>
<property name="jdbc-password" value="${mdspassword}"/>
<property name="jdbc-url"
value="jdbc:oracle:thin:@${db.host.name}:${db.host.port}:${db.sid}"/>
<property name="partition-name" value="soa-infra"/>
</metadata-store>
Check the modified application with these adf-config.xml entries into a source control system. The following concrete example of a modified adf-config.xml file is provided.
<metadata-store-usage id="mstore-usage_1">
<metadata-store
class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
<property name="jdbc-userid" value="soainfra_mds"/>
<property name="jdbc-password" value="soainfra_mds"/>
<property name="jdbc-url"
value="jdbc:oracle:thin:@myhost56.us.oracle.com:15739:db2825"/>
<property name="partition-name" value="soa-infra"/>
</metadata-store>
You can use a variable for the user ID and password and replace the values prior to ant deployment in the application.
If the MDS database has a JNDI name, then use the following entries in adf-config.xml:
<metadata-store
class-name="oracle.mds.persistence.stores.db.DBMetadataStore">
<property name="jndi-datasource" value="${db.jndi.name}"/>
<property name="partition-name" value="soa-infra"/>
</metadata-store>
If you select Tools > Preferences > XSL Maps, note that the expansion depth level is set to 6 by default. However, when automapping a nonrecursive schema, the expansion depth level is actually 6 - 2 = 4.
Even if you consider the tree to include the source as a root element, the depth level is -1 (6 - 1 = 5).
As a best practice, it is always recommended that you start and stop a managed server through one, but not both, of the following methods. Do not mix these methods, such as starting the managed server from the command line and stopping it from Oracle Enterprise Manager Fusion Middleware Control Console, or vice versa.
Oracle Enterprise Manager Fusion Middleware Control Console
With this method, the node manager must be up and running. The node manager tracks all managed server startups and shutdowns performed from Oracle Enterprise Manager Fusion Middleware Control Console. With this method, the server state is not an issue.
Command line
With this method, the node manager does not track the server state. Therefore, if you start the server from the command line and shut it down from Oracle Enterprise Manager Fusion Middleware Control Console, the Oracle WebLogic Administration Server accesses the node manager to determine its status, which returns a state of Unknown.
Perform the following steps to stop and start the server from Oracle Enterprise Manager Fusion Middleware Control Console.
Expand the WebLogic domain.
Select the managed server (for example, named soa_server1).
Select Control > Shut Down.
Select Control > Start Up.
For information on starting and stopping managed servers from the command line, see Oracle Fusion Middleware Installation Guide for Oracle SOA Suite.
You can receive a sql.BatchUpdateException error and an instance failure under the following scenario:
SOA composite application A calls SOA composite application B.
Both composites are in the same SOA Infrastructure.
The audit level for composite B is set to Off.
As a workaround, set the audit level for composite B to anther value in Oracle Enterprise Manager Fusion Middleware Control Console, such as Production, Development, Inherit, or Minimal.
You must explicitly add fault handing functionality into your BPEL process service component to catch Oracle Web Service Manager (OWSM) faults, system faults, schema validation faults, JTA faults, and so on, and commit them and the associated BPEL instance to the database. For example:
<faultHandlers>
<catch faultName="bpelx:owsmPolicyFault">
<invoke name="ReplyOnFault" inputVariable="output" partnerLink="client"
portType="tns:FlowCallback" operation="onResult"/>
</catch>
</faultHandlers>
Not adding this functionality results in these faults not being handled. This results in the entire transaction being rolled back, and these faults not being persisted into the database. Subsequent queries do not show these faults.
BPEL processes run in global transactions, while other Oracle SOA Suite components, such as adapters, run in local transactions. This can cause inconsistencies with the information displayed in Oracle Enterprise Manager Fusion Middleware Control Console.
For example, assume you have a main synchronous BPEL process that invokes an asynchronous BPEL process. There is one database adapter insert in the main synchronous BPEL process before the invocation of the asynchronous BPEL process. There is a second database adapter insert in the asynchronous BPEL process, at which point a fault is expected to be thrown.
The expected behavior is as follows:
An initial insert into the database is performed from the main process that completes successfully as expected.
The second insert also executes in the asynchronous process, but after encountering the fault, the BPEL process rolls back the initial insert.
However, in Oracle Enterprise Manager Fusion Middleware Control Console, the second database insert also shows as having completed successfully, instead of the having faulted.
This is because the database adapter invocation is logged (instance tracked) in a local transaction that is not part of the global BPEL JTA transaction. Therefore, the database adapter invocation completes successfully, but the subsequent BPEL process incurs a global rollback.
<invoke name="Invoke_1" inputVariable="Invoke_1_insert_InputVariable" partnerLink="db" portType="ns1:db_ptt" operation="insert"/> . . . . . . <throw name="Throw_2" faultName="bpelx:rollback"/>
At that point, instance tracking has already recorded the outbound invocation as successful (in a local transaction). If the adapter throws an exception, instance tracking logs this as a fault.Also note that some partner links may invoke a file adapter, which cannot be rolled back, even if the BPEL process later throws a bpelx:rollback.
In the SOA Infrastructure Common Properties page of Oracle Enterprise Manager Fusion Middleware Control Console, the descriptions for Server Data Source JNDI and Server Transaction Data Source JNDI are interchanged. However, the Configure links go to the correct locations.
If you are using Internet Explorer 7, and click the view XML document link on the Audit Trail page in Oracle Enterprise Manager Fusion Middleware Control Console, data is not displayed. Instead, you are prompted to save or open the page. If you select to open the file, no data is displayed and you are again prompted to save or open the file. Instead, you must save the XML document and view it separately in a text editor.
As a workaround, use Mozilla FireFox to view the data directly after clicking the view XML document link.
If you are using Mozilla Firefox and click an activity on the Flow tab of a BPEL process service component instance in Oracle Enterprise Manager Fusion Middleware Control Console, the popup window that displays the XML content gets cut off on the right side. You must use the scroll bar at the bottom on this window to move to the right and display all XML content. If you use Internet Explorer, this is not an issue.
If you use Mozilla Firefox to click the view XML document link on the Audit Trail page in Oracle Enterprise Manager Fusion Middleware Control Console, an error message similar to the following can be displayed:
XML Parsing Error: XML or text declaration not at start of entity Location: http://myhost.us.oracle.com:7001/em/faces/ai/sca/share/audit/xmlAuditDetail. jsp?detailId=0&_afrLoop=10355217141136524&_afrWindowMode=0&_afrWindowId=_new Line Number 1, Column 39:<?xml version="1.0" encoding="UTF-8"?><?xml version = '1.0' encoding = 'UTF-8'?>
This error occurs if the XML source already includes an XML declaration (for example, <?xml version = '1.0' encoding = 'UTF-8'?>).
<?xml version = '1.0' encoding = 'UTF-8'?>
<task xmlns="http://xmlns.oracle.com/bpel/workflow/task">
<title>Approve Discount</title>
<payload xmlns="http://xmlns.oracle.com/bpel/workflow/task">
<discountandshipping
xmlns:discountandshipping="http://www.globalcompany.com/ns/OrderBooking/rules"
xmlns="http://www.globalcompany.com/ns/OrderBooking/rules">
<price>5000.0</price>
. . . . .
. . . . .
</task>
During processing, Oracle Enterprise Manager Fusion Middleware Control Console adds a second XML declaration. This results in duplicate XML declarations, which causes Mozilla Firefox to report an error.
As a workaround, use Internet Explorer.
Create a domain with Oracle WebCache and extend it with Oracle SOA Suite.
Associate the Oracle WebCache application with LDAP and grant the admin role to a user (for example, user name test) in Oracle Internet Directory using the WebLogic Scripting Tool (WLST).
Grant the same role (admin role) to the same user again (test).
You expect to see a WLST error message such as the following:
This particular user already has admin role to access your application
Instead, you receive the following message, which is inaccurate:
Command FAILED, Reason: Cannot add principal to application role
The XML representation from an XSL file may differ from that used in a scenario in which a message is passed through with a transformation being performed or in which an assign activity is used, even though the XMLs are syntactically and semantically the same. For example, if you use a mediator service component to map an inbound payload that includes an element without a namespace to an outbound payload, you may receive an empty namespace tag in the output message.
<Country xmlns="">US</Country>
This is the correct behavior. A blank namespace, xmlns="", is automatically added.
If you attempt to recover from a fault and the maximum number of retries is reached without a successful recovery, a nonrecoverable fault occurs. However, the recoverable count in the Component Metrics section of the Dashboard tab of a SOA composite application in Oracle Enterprise Manager Fusion Middleware Control Console is incremented instead of the nonrecoverable count.
If an asynchronous BPEL process encounters a transaction rollback scenario because of any underlying exception error, it rolls back to the last dehydration activity. If this is a new instance, and a receive activity was the first dehydration activity, the BPEL process service engine creates a recoverable invoke. When you click Recover to recover the invoke on the Recovery tab of the BPEL process service engine in Oracle Enterprise Manager Fusion Middleware Control Console, the service engine creates a new instance. This instance may run to completion with no exception error. However, you continue to see the older instance identified as faulted.
Once a message is submitted for recovery, the BPEL process service engine may take time to complete the action. This typically takes less than several seconds. During this time, the message remains visible in the Recovery page. Duplicate attempts to recover the same message in that period are ignored by the server. Refresh the page every few seconds to receive the latest recovery status.
Once a faulted instance is terminated, the status is correctly displayed in Oracle Enterprise Manager Fusion Middleware Control Console. However, an exception error can appear on the SOA Infrastructure side:
The action "abort" cannot be performed on the instance "11106" because of its
current state ("closed.faulted")
This message can be ignored. The exception appears in the SOA Infrastructure logs: soa_server1.out/soa-diagnostic log.
The wsu:Id attributes in SOAP <body> elements are not passed to a SOAP outbound endpoint due to a limitation with converting a SOAP mediator message to a normalized message.
You can receive the following error message when deploying a SOA composite application that includes a human workflow service component from Oracle Enterprise Manager Fusion Middleware Control Console:
oracle.fabric.common.FabricDeploymentException: oracle.fabric.common.FabricException: Deployment Failed: Unable to find a WSDL that has a definition for service
As a workaround, use the following WebLogic Scripting Tool (WLST) commands to enable metadata archive (MAR) deployment:
Obtain the list of metadata labels in the metadata service (MDS) repository:
listMetadataLabels(application='application_name',server='server_name')
Check if the returned list contains a label named preDeployLabelnumber.
If it does, delete the label using the following command:
deleteMetadataLabel(application='application_name',server='server_name',name='predeployed_label_number')
where:
application_name must be soa-infra.
server_name is the managed server name. Note that the default value is soa_server1, which you may have changed during Oracle SOA Suite installation and configuration.
predeployed_label_number is the label that you identified in Step 2.
Restart the managed server (for example, soa_server1).
Oracle recommends that you run Oracle JDeveloper on a UTF-8 native-encoded operating system such as Linux. If this is not the case (for example, you run Oracle JDeveloper on Windows), and you need to save content to XML format, then do not select Save As to save the format as XML.
For example, when defining the contents of test cases to initiate inbound messages or emulate outbound messages, you can generate sample messages and select Save As to save the message as an XML file. You can then use the file to load the message. The saved XML file is in Oracle JDeveloper operating system native encoding. However, at runtime, the XML file is expected to be in UTF-8 encoding, and unreadable payload data is created.
As a workaround, save the sample message in the test case itself.
If you enter a non-ASCII name in the Event Definition Name field of the Event Definition Name dialog, the namespace in the Namespace field automatically uses the event definition name as a suffix. If you click OK, the non-ASCII namespace is created for the event. In the business event's .edl file, you can see the targetNamespace element contains non-ASCII characters. However, this does not conform to the current XML 1.0 specification supported by SOA components, as described in the following excerpt:
In Namespaces in XML 1.0, a namespace is identified by a URI reference defined in RFC 3986, which requires escaping for non-ASCII characters.
In 11g Release 1, you cannot escape non-ASCII characters.
When a SOA server instance has only an HTTP listener port enabled (a nonzero value for the port), the generated server URL used by Oracle SOA Suite (for example, to generate callback URLs, to build the abstract WSDL annotation in an exposed service WSDL, and so on) also has an HTTP scheme.
Similarly, if the SOA server instance has only an HTTPS listener enabled, the server URL also has an HTTPS scheme. However, if both the HTTP and HTTPS listener ports are enabled, the default SOA server URL value has the HTTP scheme. If you use Oracle JDeveloper to create a reference to a composite running on such an instance, the composite <import> has an http URL. If you want the WSDL to be retrieved through HTTPS, edit the resulting composite in Source view. In addition, the default calculated server and callback URLs can be overridden in the soa-infra-config.xml file.
The fault policy retry action may not execute with multiple faults in the same flow. This may be because the retry count has already been reached for any of the previous faults.
For example, assume you define a fault policy with two fault conditions: fault1 and fault2. For both fault conditions, the retry action is specified with a retry count of three. Assume fault1 occurs and the retry action executes three times. You correct the problem for fault1 by modifying the payload, but ensure that fault2 is to be raised when the instance is resubmitted. You then resubmit the faulted instance using Oracle Enterprise Manager Fusion Middleware Control Console. You expect the second fault condition, fault2, to retry three times as per the fault policy specification. However, this does not occur because the maximum number of retries was already executed for the previous fault1 fault condition.
You cannot abort a faulted Oracle B2B instance due to a policy violation. For example:
Set up Oracle B2B for the host and remote trading partners using EDIFACT. In this scenario, you have two SOA composite applications communicating through B2B instances on each side (host trading partner and remote trading partner).
Attach a policy (for example, authorization_denyall_policy) to the EDIFACT inbound composite BPEL service component.
Enqueue the message from an initiator such that the inbound composite in the responding Oracle B2B gets invoked.
The reference binding component of the inbound composite gets called and is successful. However, since authorization_denyall_policy is attached to the BPEL component, this fails with an authorization error.
Go to the Instances tab in Oracle Enterprise Manager Fusion Middleware Control Console and find the faulted instance.
Note that this instance cannot be aborted. However, note that Oracle Enterprise Manager Fusion Middleware Control Console still reports success.
For a SOA composite application with a binding component, a problem occurs in the following scenario:
Stop an inbound composite application in Oracle Enterprise Manager Fusion Middleware Control Console.
Restart the SOA Infrastructure.
Start the composite.
The composite application does not work as intended. For example, in an application that includes Oracle B2B, the inbound composite does not get invoked when you enqueue a message from the outbound side.
As a workaround, perform either of the following steps after Step 3:
Restart the managed server.
Restart the server and redeploy the composite.
A mediator service component relies on a successful commit of a local transaction to know whether an instance is recoverable. Even if a graceful shutdown is correctly implemented, and all transactions are allowed to complete (within the given time out window), there can still be a local transaction that is denied because it fails to occur within the time out window. For example, assume the following:
A database adapter posts a message.
A mediator service component receives the message, sets its state to running, and invokes a BPEL process service component, whose state is also set to running.
A JMS adapter is invoked, and encounters and throws an exception. The reference fault tables are updated.
The BPEL process receives the exception, marks its state as completed with a fault, and rethrows the exception to the mediator.
The BPEL process triggers an asynchronous persistence of its audit information as the global transaction is rolled back.
The mediator receives the exception and persists the fault information in its error tables (in a separate local transaction).
The mediator sets its state to faulted.
If the server is shut down before the transaction can complete (for example, between Steps 5 through 7), the mediator instance can remain in a running state. The corresponding composite instance whose state is inferred from the components also displays as running. As the global transaction is rolled back, the message can be retried and reprocessed by the inbound adapter. Note that in this scenario, no mediator instances are lost.
If Oracle Enterprise Manager Fusion Middleware Control Console is run in a single sign-on (SSO)-enabled environment, you are prompted to re-enter the user name and password credentials as part of the last step of the Deploy SOA Composite, Undeploy SOA Composite, and Redeploy SOA Composite wizards. This information is only requested once per Oracle Enterprise Manager Fusion Middleware Control Console session.
An automapping schema that has elements with nillable attributes maps the nillable attributes, but does not map the elements. For example, mapping the following source:
<?xml version= '1.0' encoding= 'UTF-8' ?>
. . .
. . .
<element name="MovieProcess">
<complexType>
<sequence>
<element name="Director" type="string" nillable="true"/>
<element name="casting" type="string" nillable="true"/>
</sequence>
</complexType>
</element>
</schema>
to the following target:
<?xml version= '1.0' encoding= 'UTF-8' ?>
. . .
. . .
<element name="Movies">
<complexType>
<sequence>
<element name="name" type="string" nillable="true"/>
<element name="starring" type="string" nillable="true"/>
</sequence>
</complexType>
</element>
</schema>
Results in the nillable attributes being mapped, but not the elements.
<xsl:template match="/">
<ns1:Movies>
<ns1:name>
<xsl:attribute name="xsi:nil">
<xsl:value-of select="/ns1:MovieProcess/ns1:Director/@xsi:nil"/>
</xsl:attribute>
</ns1:name>
<ns1:starring>
<xsl:attribute name="xsi:nil">
<xsl:value-of select="/ns1:MovieProcess/ns1:casting/@xsi:nil"/>
</xsl:attribute>
</ns1:starring>
</ns1:Movies>
</xsl:template>
As a workaround, you must manually map elements with the xsi:nil attribute.
Use the Find Node dialog in the XSLT Mapper to search for elements. This dialog is available by right-clicking in the source or target schema and selecting Find.
Drag from the source element to the target element.
At the bottom of the Auto Map Preferences dialog, deselect the Enable Auto Map check box.
This results in the following mapping:
<xsl:template match="/">
<ns1:Movies>
<ns1:name>
<xsl:attribute name="xsi:nil">
<xsl:value-of select="/ns1:MovieProcess/ns1:Director/@xsi:nil"/>
</xsl:attribute>
<xsl:value-of select="/ns1:MovieProcess/ns1:Director"/>
</ns1:name>
<ns1:starring>
<xsl:attribute name="xsi:nil">
<xsl:value-of select="/ns1:MovieProcess/ns1:casting/@xsi:nil"/>
</xsl:attribute>
<xsl:value-of select="/ns1:MovieProcess/ns1:casting"/>
</ns1:starring>
</ns1:Movies>
</xsl:template>
If a SOA composite application with adapter endpoints is in a retired state, the endpoints are not activated if you perform the following actions:
Restart the SOA Infrastructure
Activate the SOA composite application
This is because files, records, and so on are not be picked up by the endpoint adapters. As a workaround, redeploy the SOA composite application after restarting the SOA Infrastructure.
The number of SOA composite application instances may not always match the number of service component instances displaying in Oracle Enterprise Manager Fusion Middleware Control Console.
A SOA composite application instance is first created when the composite is invoked. When the service components within the composite receive a subsequent invocation, a corresponding service component instance is created that refers to the composite instance ID previously created.
There can be scenarios under which the composite instance is created, but the underlining service component instance is not created. For example:
The composite instance is created, but the invocation has not yet reached the service component due to a system failure.
The composite instance is created, but the invocation fails payload validation and is rejected. In this case, invocation does not reach the underlining service components.
You can also have orphaned service component instances for which no SOA composite application instance has been created.
For more information about SOA composite application instances, service component instances, and orphaned instances, see Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.
You can receive a NullPointerException error when changing the state of a faulted instance to human intervention using a fault policy file after it failed to recover by executing the retry action. For example, assume you perform the following tasks:
Create a SOA composite application that includes the following:
An inbound file adapter service binding component
A mediator service component
An outbound file adapter reference binding component
Add a fault policy to the composite with the following settings:
Call the ora-retry action when a fault occurs.
Specify retryFailureAction=ora-human-intervention in the ora-retry action.
Set the audit tracking levels as follows:
| For This Level... | Set Audit Tracking To... |
|---|---|
| SOA Infrastructure | Development |
| SOA composite application | Off |
| Mediator service engine | Production |
| Mediator service component | Development |
Deploy the SOA composite application.
Create an instance of the SOA composite application.
Create a fault.
Note the following details:
The retry action is executed based on the count defined in the fault policy file.
After completing the specified retry count, the faulted instance state changes to human intervention.
During the human intervention state change, a NullPointerException is logged in the server log files.
Note that the instance is recoverable and there is no loss of functionality, even though the NullPointerException occurred.
Oracle recommends that you handle both business and remote faults in BPEL processes during design time. If remote exceptions are not handled in the calling BPEL process, you can see discrepancies in the overall SOA composite application instance state and the server component instance states associated with the composite. For example, a situation may occur in which the composite instance is in a faulted state, while the service component instances are in a completed state. If the caller handles the remote exceptions, then the states of composite and component instances are accurate.
If you select Continue from the Recovery Action list when performing a bulk recovery of faulted instances, and the continue operation fails for any instance, the bulk recovery stops at that point. The remaining instances are not recovered. As a workaround, you must recover the remaining instances separately with a new bulk recovery operation.
This section describes configuration issues and their workarounds. It includes the following topics:
Section 20.2.1, "Order of Precedence for Audit Level Settings"
Section 20.2.2, "Setting the Audit Level at the BPEL Process Service Component Level"
Section 20.2.4, "Increasing Memory to Recover from Compilation Errors"
Section 20.2.5, "Resolving Thread-Blocking and Slow Performance in Composite Applications"
Section 20.2.7, "Oracle SOA Suite Integration with an ADF-BC Service"
Section 20.2.8, "Using ADF Binding to Invoke a Composite Application from a JSP/Java Class"
Section 20.2.9, "Increasing the XA Transaction Timeout Value"
Section 20.2.10, "PermGen Space Out-of-Memory Error when Using the Sun JDK"
Table 20-1 provides examples of the order of precedence for audit level settings.
Table 20-1 Examples of Order of Precedence
| Component | Composite | Service Engine | SOA Infrastructure | Which Setting Takes Precedence? |
|---|---|---|---|---|
|
No property |
Off |
Production |
Development |
Composite. The audit level is set to Off. The service engine and SOA Infrastructure audit levels do not take effect. |
|
No property |
Inherit |
Development |
Production |
Service engine. The audit level is set to Development. The payload is shown in the assign activity. The SOA Infrastructure audit level does not take effect. |
|
No property |
Inherit |
Inherit |
Production |
SOA Infrastructure. The audit level is set to Production. |
|
No property |
Inherit |
Production/Development/Off/Inherit |
Off |
The overall audit is not shown. The composite inherits the audit level from the SOA Infrastructure. The payload is shown in the assign activity based on the service engine audit level setting. |
|
Development |
Off |
Production |
Development |
Composite. Since the composite audit level is set to Off, the overall audit is not shown. The service engine audit level is shown, but the Development setting for the component takes precedence. The payload is shown in the assign activity based on the component audit level setting of Development. |
|
Inherit |
Off |
Production |
Development |
Composite. Since the composite audit level is set to Off, the overall audit is not shown. The service engine audit level is not shown because Off is inherited from the composite. |
Notes:
When the composite audit level is set to Off, there is no audit trail generated for this composite and all service engines used within the composite.
When the composite audit level is set to Inherit, it always inherits from the settings of the SOA Infrastructure.
When the composite audit level is set to Off, the component inherits from the service engine settings.
For more information about audit levels and the order of precedence, see Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.
You can set the audit level for a BPEL process service component. This setting takes precedence over audit level settings at the SOA Infrastructure, service engine, and SOA composite application levels. The service component level setting is only available for BPEL processes and is not supported for the mediator, human workflow, and business rule service components.
There are two ways to set the audit level for BPEL process service components. Supported values are Off, Minimal, Inherit, Development, and Production.
In the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control Console:
In the navigation tree, expand the SOA folder.
Right-click soa-infra, and select Administration > System MBean Browser.
Select Application Defined MBeans > oracle.soa.config > Server: server_name > SCAComposite > Composite_Name > SCAComposite.SCAComponent > BPEL_Service_Component > Properties >
Click the Add icon.
Expand the Element_number folder.
From the many list, select false.
In the name field, enter bpel.config.auditlevel.
In the value field, enter a value.
Click Apply.
In Oracle JDeveloper:
Set the bpel.config.auditLevel property to an appropriate value in the composite.xml file of your SOA project.
<component name="BPELProcess">
<implementation.bpel src="BPELProcess.bpel" />
<property name="bpel.config.auditLevel">Off</property>
</component>
You can receive the following error message because of slow connections to the database.
Exception [TOPLINK-4002] (Oracle TopLink - 11g Release 1 (11.1.1.1.0) (Build 090304)): oracle.toplink.exceptions.DatabaseException Internal Exception: java.sql.SQLException: Internal error: Cannot obtain XAConnection weblogic.common.resourcepool.ResourceDeadException: Pool SOADataSource has been disabled because of hanging connection tests, cannot allocate resources to applications.
As a workaround, perform the following steps:
Open the DOMAIN_HOME\bin\setSOADomainEnv.cmd file.
Uncomment the lines shown in bold.
# 8331492: Value of weblogic.resourcepool.max_test_wait_secs is 10 # seconds. It can be increased by uncommenting line below if your database # connections are slow. See SOA documentation for more details. EXTRA_JAVA_PROPERTIES="${EXTRA_JAVA_PROPERTIES} -Dweblogic.resourcepool.max_test_wait_secs=30" export EXTRA_JAVA_PROPERTIES
Save your changes and restart the managed Oracle WebLogic Server.
If you receive out-of-memory errors during compilation of a SOA composite application, perform the following steps to increase memory.
Open the ant-sca-compile.xml file in the ORACLE_HOME\bin directory.
Under the scac element, increase the memory setting. For example:
<jvmarg value="-Xmx512M"/>
If your thread dumps indicate that threads are being blocked and performance is slow, try setting the following JRocket Java Virtual Machine options in the $DOMAIN_HOME/bin/setSOADomainEnv.sh file.
If your thread dumps indicate that threads are being blocked and performance is slow, try setting the following JRocket Java Virtual Machine options in the DOMAIN_HOME\bin\setSOADomainEnv.cmd file.
-Xmx:1536M –Xms:1536M –Xgc:genpar
where:
-Xmx is the maximum heap size.
-Xms is the minimum heap size.
-Xgc:genpar is the static garbage collector (GC) running generational and parallel collection strategies.
If Oracle SOA Suite pages in Oracle Enterprise Manager Fusion Middleware Control Console take a long time to load, you can improve the load time by disabling the fetching and displaying of instance count information. The improvement is considerable if the load on SOA Infrastructure is high. By default, this option is not set.
Open the BEA_HOME\user_projects\domains\your_domain_name\bin\startWeblogic.cmd file.
Go to the section above the following lines in the file.
# START WEBLOGIC echo "starting weblogic with Java version:"
Add the following line above these lines.
JAVA_OPTIONS="-Dem.soa.disableCounts=true ${JAVA_OPTIONS}"
Restart the Oracle Weblogic Administration Server for the changes to take effect.
This property setting disables the instance and fault count metrics shown in all pages. For example, this setting causes the following sections to not display in the SOA Infrastructure Dashboard page:
The Running and Total headers and values in the Recent Composite Instances section.
The Instances and Faulted Instances columns and values in the Deployed Composites section.
When invoking an ADF-BC service as an external reference from a SOA composite application, enter the ADF-BC application name appended with JBOServiceRegistry in the Registry field of the Create ADF-BC dialog.
For example, if the ADF BC application to invoke is named hrApp, then enter hrApp_JBOServiceRegistry in the Registry field.
The application name to enter is displayed in the Application name field of the Edit EAR Deployment Profile Properties dialog in Oracle JDeveloper. This dialog can be accessed from the Application menu of the application by selecting Application Properties > Deployment > Edit.
Additional configuration tasks must also be performed on the ADF-BC application side. For more information, see Section "Using an ADF-BC Service with the SOA Platform."
If a SOA composite application uses Web service (WS) binding to define an endpoint reference, the composite cannot be invoked from a JSP/Java class. WS binding is defined with the binding.ws port="" location="" tag in the composite.xml file:
<service name="client_ep" ui:wsdlLocation="BPEL.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/Application/Project/
BPEL#wsdl.interface(BPEL)"/>
<binding.ws port="http://xmlns.oracle.com/App/BPELProj/
BPELProcess#wsdl.endpoint(bpel_client_ep/BPELProcess_pt)"/>
</service>
Instead, use ADF binding. After deployment of the composite with ADF binding, invocation from a JSP/Java class is successful.
<service name="client_ep" ui:wsdlLocation="BPEL.wsdl">
<interface.wsdl interface="http://xmlns.oracle.com/Application/Project/
BPEL#wsdl.interface(BPEL)"/>
<binding.adf serviceName="bpel_client" registryName=""/>
</service>
If you send notifications for parallel task assignments in human workflow, you can see the transaction close, SQL exceptions appear, and notification processing take a long time at runtime. If this occurs, increase the XA transaction timeout for an XA data source in Oracle WebLogic Server Administration Console. When set, this value overrides the value of the global transaction timeout.
Click Lock and Edit.
Choose Services > Data Sources.
Click the specific data source.
Click the Transaction tab.
Select Set XA Transaction Timeout.
In the XA Transaction Timeout field, specify the value of the transaction timeout.
Click Save.
Log into SQL*Plus.
Set the distributed_lock_timeout value.
SQL> alter system set distributed_lock_timeout=value scope=spfile;
Oracle recommends that you set distributed_lock_timeout to a value greater than or equal to that set in Step 6.
Shut down and restart your database after running this command.
Verify that the setting has changed.
SQL> show parameter distributed_lock_timeout;
Set this parameter to the same value for all instances in an Oracle Real Application Cluster.
When the Sun JDK is used as the JVM for the SOA managed server, Oracle recommends that the following memory settings be used. If proper memory settings are not used, repeated operations on task detail applications (human workflow) can result in PermGen space out-of-memory errors.
Open the $DOMAIN_HOME/bin/setSOADomainEnv.sh file.
Open the DOMAIN_HOME\bin\setSOADomainEnv.cmd file.
Increase the following values:
if [ "${JAVA_VENDOR}" != "Oracle" ] ; then
DEFAULT_MEM_ARGS="${DEFAULT_MEM_ARGS} -XX:PermSize=128m
-XX:MaxPermSize=256m"
PORT_MEM_ARGS="${PORT_MEM_ARGS} -XX:PermSize=256m -XX:MaxPermSize=512m"
fi
to these values:
if [ "${JAVA_VENDOR}" != "Oracle" ] ; then
DEFAULT_MEM_ARGS="${DEFAULT_MEM_ARGS} -XX:PermSize=512m
-XX:MaxPermSize=1024m"
PORT_MEM_ARGS="${PORT_MEM_ARGS} -XX:PermSize=256m -XX:MaxPermSize=512m"
fi
This section describes documentation errata. It includes the following topics:
Section 20.3.1, "Editing the setSOADomainEnv File for Large Payload Scenarios"
Section 20.3.2, "The Distributed Adapter Property Is Not Supported in 11g"
Section 20.3.4, "Configuring SOA Composite Applications for Two-Way SSL Communication"
Section 20.3.5, "Faults Column of Deployed Composites Section Renamed to Faulted Instances"
Section 20.3.6, "Abort Fault Recovery Action Does Not Terminate the Entire Instance"
Section "53.2.5 Using Correct Settings for Large Payload Scenarios" of Chapter 53, "Processing Large Documents" of the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite incorrectly says to add the following line of syntax to the setDomainEnv.cmd file.
-Dweblogic.resourcepool.max_test_wait_secs=30
Instead, you must uncomment this existing line in the setSOADomainEnv.cmd file.
Chapter 33, "Configuring Service and Reference Binding Components" in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite incorrectly states that the Oracle FTP Adapter and Oracle File Adapter support the Distributed property. The Distributed property is not supported in the 11g release.
Section "A.4 Publishing and Browsing the Oracle Service Registry" in Appendix A, "BPEL Process Activities and Services" of the Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite describes how to use Oracle Service Registry with a SOA composite application. Here is some additional information about this section:
The procedures in this section describe how to configure Oracle Service Registry against a separately installed Oracle SOA Suite runtime, and not against the embedded Oracle WebLogic Server in Oracle JDeveloper.
Oracle Service Registry 10.3 deploys to the 10.3.0.0 version of Oracle WebLogic Server.
Oracle Service Registry 10.3 does not support the 10.3.1.0 version of Oracle WebLogic Server.
After configuring the inquiry URL on the SOA Infrastructure Common Properties page of Oracle Enterprise Manager Fusion Middleware Control Console, ensure that you restart the SOA Infrastructure. See Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite for additional details.
For more information about Oracle Service Registry, visit the following URL:
http://www.oracle.com/technology/goto/regrep
Step 2 of Section "6.2 Configuring SOA Composite Applications for Two-Way SSL Communication" of Chapter 6, "Securing SOA Composite Applications" of Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite mentions that for two-way SSL, the keystore information (location and password) is required. This sentence can be ignored.
In addition, perform the following steps to enable two-way SSL for a SOA composite application to invoke another SOA composite application or another non-SOA application.
Note:
Both the server and client are assumed to have been configured for SSL with mutual authentication.On the client side, provide the keystore location in DOMAIN_HOME\config\soa-infra\configuration\soa-infra-config.xml.
<keystoreLocation>absolute_path_to_the_keystore_location_and_the_file_name
</keystoreLocation>
During design time in Oracle JDeveloper, update the reference section in the composite.xml file with the oracle.soa.two.way.ssl.enabled property.
<reference name="Service1"
ui:wsdlLocation=". . .">
<interface.wsdl interface=". . ."/>
<binding.ws port=". . .">
<property name="oracle.soa.two.way.ssl.enabled">true</property>
</binding.ws>
</reference>
In Oracle Enterprise Manager Fusion Middleware Control Console, select WebLogic Domain > domain_name.
Right-click domain_name and select Security > Credentials.
Click Create Map.
In the Map Name field, enter a name (for example, SOA), and click OK.
Click Create Key.
Enter the following details.
| Field | Description |
|---|---|
| Select Map | Select the map created in Step 6 (for this example, SOA). |
| Key | Enter a key name. |
| Type | Select Password. |
| User Name | Enter the keystore user name |
| Password | Enter the password that you created for the keystore. |
Modify the composite.xml syntax to use https and sslport to invoke a SOA composite application. For example, change the syntax shown in bold:
<?xml version="1.0" encoding="UTF-8" ?> <!-- Generated by Oracle SOA Modeler version 1.0 at [4/1/09 11:01 PM]. --> <composite name="InvokeEchoBPELSync" revision="1.0" label="2009-04-01_23-01-53_994" mode="active" state="on" xmlns="http://xmlns.oracle.com/sca/1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:orawsp="http://schemas.oracle.com/ws/2006/01/policy" xmlns:ui="http://xmlns.oracle.com/soa/designer/"> <import namespace="http://xmlns.oracle.com/CustomApps/InvokeEchoBPELSync/BPELProcess1" location="BPELProcess1.wsdl" importType="wsdl"/> <import namespace="http://xmlns.oracle.com/CustomApps/EchoBPELSync/ BPELProcess1"location="http://hostname:port/soa-infra/services/default/EchoBPEL Sync/BPELProcess1.wsdl" importType="wsdl"/>
to use https and sslport:
location="https://hostname:sslport/soa-infra/services/default/EchoBPELSync /BPELProcess1.wsdl"
Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite includes screen shots of the SOA Infrastructure Dashboard page in Oracle Enterprise Manager Fusion Middleware Control Console. In the Deployed Composites section of the Dashboard page, the Faults column has been renamed to Faulted Instances.
The online help for the Faults tab of the Instance of Composite_Name page states that the abort recovery action aborts the entire instance. The entire instance is not aborted; only the current action in progress is aborted. Because of this, the instance can still be in a completed state. Note that the abort recovery action is different from aborting an instance on the Instances tab of the SOA Infrastructure or a SOA composite application.
|
 Copyright © 2009, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|