Deployment plan file to replace the JCA Adapters properties – Oracle SOA Suite

Deployment plan file to replace the JCA Adapters properties – Oracle SOA Suite 11g

This post will explain how to use deployment plan file to replace the JCA Adapters properties in Oracle SOA Suite 11g and Oracle SOA Suite 12c.

We can create and edit a configuration plan file in which we can replace the following attributes and properties:

•  Any composite, service component, reference, service, and binding properties in the SOA composite application file (composite.xml)
• Attribute values for bindings (for example, the location for binding.ws)
• schemaLocation attribute of an import in a WSDL file
• location attribute of an include in a WSDL file
• schemaLocation attribute of an include, import, and redefine in an XSD file
• Any properties in JCA adapter files

The configuration plan does not alter XSLT artifacts in the SOA composite application. If you want to modify any XSL, do so in the XSLT Mapper. Using a configuration plan is not useful. For example, you cannot change references in XSL using the configuration plan file. Instead, they must be changed manually in the XSLT Mapper in Oracle JDeveloper when moving to and from test, development, and production environments.

The same steps will work in Oracle SOA Suite 12c but the screens will be little different.

Generate the Plan file:

The plan file can be generated through JDeveloper or through ANT script.

Generating Plan file through JDeveloper:

Right Click on Composite.xml and click on generate config Plan.

File/FTP Adapter Threading Model – Oracle SOA Suite

File/FTP Adapter Threading Model – Oracle SOA Suite

The Oracle File and FTP Adapters use the following threading models:

• Default Threading Model
• Modified Threading Model

Default Threading Model:

In the default threading model, a poller is created for each inbound Oracle File or FTP Adapter endpoint. The poller enqueues file metadata into an in-memory queue, which is processed by a global pool of processor threads. We can set the thread count of global processor through the oracle.tip.adapter.file.numProcessorThreads property at the pc.properties file. Create pc.properties file with this property and copy it to server and then reference it in the WLS classpath in setDomainEnv.sh.

The following steps highlight the functioning of the default threading model:

• The poller periodically looks for files in the input directory. The interval at which the poller looks for files is specified using the PollingFrequency parameter in the inbound JCA file.
• For each new file that the poller detects in the configured inbound directory, the poller enqueues information such as file name, file directory, modified time, and file size into an internal in-memory queue.
• A global pool of processor worker threads waits to process from the in-memory queue.
• Processor worker threads pick up files from the internal queue, and perform the following actions:
• Stream the file content to an appropriate translator (for example, a translator for reading text, binary, XML, or opaque data.)
• Publishes the XML result from the translator to the SCA infrastructure.
• Performs the required post processing, such as deletion or archival after the file is processed.

Modified Threading Model:

We can modify the default threading behavior of Oracle File and FTP Adapters. Modifying the threading model results in a modified throttling behavior of Oracle File and FTP Adapters. The following sections describe the modified threading behavior of the Oracle File and FTP Adapters:

• Single Threaded Model
• Partitioned Threaded Model

Single Threaded Model:

The single threaded model is a modified threaded model that enables the poller to assume the role of a processor. The poller thread processes the files in the same thread. The global pool of processor threads is not used in this model. You can define the property for a single threaded model in the inbound JCA file as follows:
<activation-spec className="oracle.tip.adapter.file.inbound.FileActivationSpec">
   <property../>
   <property name="SingleThreadModel" value="true"/>
   <property../>
</activation-spec>

Partitioned Threaded Model:

The partitioned threaded model is a modified threaded model in which the in-memory queue is partitioned and each composite application receives its own in-memory queue. The Oracle File and FTP Adapters are enabled to create their own processor threads rather than depend on the global pool of processor worker threads for processing the enqueued files. You can define the property for a partitioned model in the inbound JCA file as follows:
<activation-spec className="oracle.tip.adapter.file.inbound.FileActivationSpec">
  <property../>
  <property name="ThreadCount" value="4"/>
  <property../>
</activation-spec>
In the preceding example for defining the property for a partitioned model:

• If the ThreadCount property is set to 0, then the threading behavior is like that of the single threaded model.
• If the ThreadCount property is set to -1, then the global thread pool is used, as in the default threading model.
• The maximum value for the ThreadCount property is 40.

Socket Adapter issue with the JCA property EncByteOrderCheckBox – Oracle SOA Suite 11g

Socket Adapter issue with the JCA property EncByteOrderCheckBox – Oracle SOA Suite 11g:

While testing the Socket Adapter project in runtime the following exception has thrown in em console.

<summary>Exception occured when binding was invoked. Exception occured during invocation of JCA binding: "JCA Binding execute of Reference operation 'OutboundRequestReply' failed due to: Exception occured when binding was invoked. Exception occured during invocation of JCA binding: "Could not instantiate InteractionSpec oracle.tip.adapter.socket.SocketInteractionSpec due to: Cannot set JCA WSDL Property. Error while setting JCA WSDL Property. Property setEncByteOrderCheckBox is not defined for oracle.tip.adapter.socket.SocketInteractionSpec Please verify the spelling of the property. ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution. ". The invoked JCA adapter raised a resource exception. Please examine the above error message carefully to determine a resolution. </summary>

The root cause of this issue is when you design a Socket adapter project (both Inbound and Outbound) or edit and save the existing project, the EncByteOrderCheckBox property is added to the JCA file irrespective of whether we have selected the same in the designer.

 

Workaround to resolve this issue

Remove the property EncByteOrderCheckBox from the .jca file and redeploy the composite.

 The SOA Suite version, we have observed this issue is 11.1.1.5.0

Webservice invocation failed, Unable to access the following endpoint(s) – Oracle SOA Suite 11g

Webservice invocation failed, Unable to access the following endpoint(s) – Oracle SOA Suite 11g:

Some of the time we used to receive the following exception while invoking the webservice endpoints in Oracle SOA 11g. There could be a multiple reason behind this exception.

This blog explains the different ways to narrow down the issue and to fix the issue.

An exception occured while invoking the webservice operation. Please see logs for more details.

oracle.sysman.emSDK.webservices.wsdlapi.SoapTestException: Unable to access the following endpoint(s): http://hostname:50000/XISOAPAdapter/MessageServlet?channel=:SalesForce:CC_Out_Soap_SFDC_order

Steps:

Ping the host name: 

• If the host is alive then the connectivity looks fine

•  If we received Unknown host error then verify whether the host entry is available in the server host  file for the host.

Policy Attachments and Local Optimization in Composite-to-Composite Invocations in Oracle SOA Suite

Policy Attachments and Local Optimization in Composite-to-Composite Invocations in Oracle SOA Suite:

OWSM supports an Oracle SOA Suite local optimization feature for composite-to-composite invocations in which the reference of one composite specifies a web service binding to a second composite. Local optimization enables you to bypass the HTTP stack and SOAP/normalized message conversions during runtime. Local optimization is not used if the composites are in different containers. If a policy is attached to the web service binding, the policy may not be invoked if local optimization is used.

By default, an OWSM security policy includes a local-optimization property that identifies if the policy supports local optimization. You can view the setting for a policy in Oracle Enterprise Manager Fusion Middleware Control.

To view the local optimization setting for policies:

• Login to EM console.
• In the navigator, expand the WebLogic Domain folder.
• Right-click on the Domain, and select Web Services > Policies.

Overriding or Forcing Local Optimization in Oracle SOA Suite

Overriding or Forcing Local Optimization in Oracle SOA Suite:

Two configuration properties are provided for either overriding or forcing local optimization.

By default, Oracle SOA Suite prefers local optimization. However, you can override this behavior with the oracle.webservices.local.optimization binding property in the composite.xml file. When this property is set to false, local optimization is not performed and cross-composite calls are performed through SOAP and HTTP. 

You can override the oracle.webservices.local.optimization property and force optimization to be performed by setting the oracle.soa.local.optimization.force property to true. Use this property in the following scenarios:

• The server configuration is sufficiently complicated (for example, there are fire wall or proxy settings in an intranet), which may cause the co-location checks to not deliver the correct result.
• You clearly understand the semantics of local optimization, the system setup qualifies for local optimization, and local optimization is absolutely preferred.

If oracle.webservices.local.optimization is set to false and oracle.soa.local.optimization.force is set to false, local optimization is not performed.
 

The oracle.soa.local.optimization.force property has a default value of false. When this property is set to true, Oracle SOA Suite skips the condition checks.

Another important note about this property is that Oracle SOA Suite always honors the setting of this property (if policy checks allow the optimization). However, if local invocation fails due to non application faults or exceptions (that is, runtime errors mostly related to the direct Java invocation), the value of this setting is ignored for subsequent invocations on the configured endpoint and for all the valid endpoint addresses configured on the endpoint.

To enable the oracle.soa.local.optimization.force property:

Add oracle.soa.local.optimization.force as a binding component level property in the reference section of the composite being invoked. For example, if composite comp_comp2 invokes comp_comp1, then define this property in the reference section of the composite.xml file of comp_comp2.

Configuring Local Optimization in Oracle SOA Suite

Configuring Local Optimization in Oracle SOA Suite:

Local optimization is the process of one SOA composite application invoking another SOA composite application through direct Java invocations in an environment in which both composites are on the same SOA server (JVM).

Direct Java invocations are generally more efficient than SOAP over HTTP calls. Therefore, whenever the conditions are met for direct Java invocations, Oracle SOA Suite optimizes the service calls for the co-located composites.

In 10.1.x releases, we manually configured SOAP optimization with the optSoapShortcut property. For release 11g, SOAP optimization is automatically configured.

Condition Checks for Using Local Optimization:

Oracle SOA Suite performs the following condition checks to determine if local optimization is possible.

• It must be a composite-to-composite invocation. This is the most fundamental criteria that makes the direct Java calls possible when both the client and target services are implemented based on the same SOA Infrastructure (that is, the same SOA server).
• The composite implementing the reference (target) service must be active. This condition requires the target composite to be up and running, which in turn ensures that the reference service is available.
• The client and target composites must be co-located on the same server. This is an obvious requirement for direct Java invocations. It is also a critical step in which Oracle SOA Suite compares the server (on which the client composite is deployed) host configuration with the host and port values specified in the reference (target) service endpoint URI. If the host and port values match, it can be concluded that the client and target composites are located on the same server.
• However, the comparison is not necessarily straightforward given that working with both standalone and clustered server setups and potential load balancer configurations is necessary. Therefore, here are the step-by-step condition checks that determine the correct server configuration on all platforms:

•  Checks the Server URL configuration property value on the SOA Infrastructure Common Properties in em console. 

Modifying the DVM’s and Business Rules using SOA Composer

Modifying the DVM’s and Business Rules using SOA Composer

Oracle SOA Suite Composer is a J2EE application deployed into the weblogic server that help us to edit the DVM’s and the Business Rules after the deployment  to the Oracle SOA Suite server during the runtime.

The SOA Composer application can be accessed using the following URL

http://<SOA Server Host>:<SOA Server port>/soa/composer/

To modify the DVM’s or the Business Rules the weblogic user must have the SOADesigner role.

When using Oracle SOA Composer, you can save your customizations in a sandbox environment without applying them to a running instance and later return to the sandbox to make additional customizations. These customizations are only applied to the running instance when you click Commit.

Modify DVM:

• Login to SOA Composer
• Click on open and then click on Open DVM, this will list all the DVM’s deployed to MDS

CodeCache is full. Compiler has been disabled - Oracle SOA Suite 11g

CodeCache is full. Compiler has been disabled - Oracle SOA Suite 11g:

Frequently we used to see the below message in our log file.

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled.
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize=

The code cache is a memory area separate from the JVM heap that is used for compilation and storage of native code.This is where the JIT compiled methods are kept.

The JIT compilier will be disabled when the code cache is full. Once the JIT compiler is switched off due to the Code Cache being full, it does not switch back on.

This will affect the performance of the server in high extend.

We can try to increase the default code cache size to resolve this issue.

Steps to increase the code cache size(we have increased to 64m)

• Login into Admin Server node
• Open $DOMAIN_HOME/bin/setSOADomainEnv.sh file 
• Edit the "DEFAULT_MEM_ARGS" to add the following parameters at the end of line before double quotes: -XX:InitialCodeCacheSize=64m -XX:ReservedCodeCacheSize=64m
• Login into admin console and go to all the servers server start up properties tab and edit the section to add the following parameters at the end of the line  -XX:InitialCodeCacheSize=64m -XX:ReservedCodeCacheSize=64m

• Restart all servers (Admin and Managed)

Storing the Cross reference data to a custom table - Oracle SOA Suite

Storing the Cross reference data to a custom table - Oracle SOA Suite:

Cross references enable you to dynamically map values for equivalent entities created in different applications. Cross references are stored in the form of tables.

Oracle SOA Suite 11g provides the new feature to store the cross reference data to a custom table instead of storing to a standard XREF_DATA table, this feature enable as to manage the data properly.

Different tables can be created based on the data like order data can be stored in XREF_ORDER table and account data can be stored in the XREF_ACCOUNT. This will improve the performance of populating and looking up the data whenever the volume of the data is more.

• Right-click the project and select New.

• Select SOA Tier from the Categories section, and then select Transformations.

• Select Cross Reference (XREF) from the Items section.

The screen is different in Oracle SOA Suite 12c to create the custom XREF.

• Click OK.

• In the File Name field, specify the name of the cross reference file.

• In the End System fields, enter the end system names.

• Click OK.

Difference between BPEL 1.1 and BPEL 2.0 – Oracle SOA Suite

Difference between BPEL 1.1 and BPEL 2.0 – Oracle SOA Suite 11g:

Oracle SOA Suite 11g and Oracle SOA Suite 12c provides the option to use both the BPEL 1.1 and BPEL 2.0 versions.

If we are migrating the BPEL process from 10g to 11g version the BPEL 1.1 version will be used in the migrated process but new processes can be developed in BPEL 2.0.

New Activities 2.0

• <forEach> activity to repeat the set of activities . Replace the FlowN activity in BPEL 1.1 version.
• <repeatUntil> - Use this activity if the body of an activity must be performed at least once. The XPath expression condition in the repeatUntil activity is evaluated after the body of the activity completes.
•  <if>-<elseif>-<else> - Replaces the switch activity in BPEL 2.0 - This activity enables you to define conditional behavior for specific activities to decide between two or more branches. Only one activity is selected for execution from a set of branches.
• Changed <terminate> to <exit>
• <compensateScope>  - to compensate the specified child scope
• A <rethrow> activity has been added to fault handlers this activity enables you to rethrow a fault originally captured by the immediately enclosing fault handler.