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.

Disabling/Enabling the Oracle Service Bus Services from Java

Disabling/Enabling the Oracle Service Bus Services from Java

The status of the OSB services can be changed in different ways like through OSB console, through WLST script and through Java.

This post shows how to use the Java API to enable/disable the OSB Proxy/Business services.

Java Code:

package osbservicestatusupdate;

import com.bea.wli.config.Ref;

import com.bea.wli.sb.management.configuration.*;

import java.io.IOException;

import java.net.MalformedURLException;

import java.util.Hashtable;

import javax.management.*;

import javax.management.remote.*;

import javax.naming.Context;

import weblogic.management.jmx.MBeanServerInvocationHandler;

import weblogic.management.mbeanservers.domainruntime.DomainRuntimeServiceMBean;

public class OSBServiceStatusUpdate {

    private static JMXConnector initConnection(String hostname, int port,String username, String password) throws IOException,MalformedURLException

    {

        JMXServiceURL serviceURL = new JMXServiceURL("t3", hostname, port,"/jndi/" + DomainRuntimeServiceMBean.MBEANSERVER_JNDI_NAME);

        Hashtable<String, String> h = new Hashtable<String, String>();

        h.put(Context.SECURITY_PRINCIPAL, username);

        h.put(Context.SECURITY_CREDENTIALS, password);

        h.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES, "weblogic.management.remote");

        return JMXConnectorFactory.connect(serviceURL, h);

    }

    private static Ref constructRef(String refType,String serviceuri){

        Ref ref = null;

        String[] uriData = serviceuri.split("/");

        ref = new Ref(refType,uriData);       

        return ref;

    }

    public static String changeProxyServiceStatus(String servicetype,boolean status,String serviceURI,String host,int port,String username,String password){

        JMXConnector conn = null;

        SessionManagementMBean sm = null;

        String sessionName = "mysession";

        String statusmsg="";

        try{

            conn = initConnection(host, port, username,password);

            MBeanServerConnection mbconn = conn.getMBeanServerConnection();

            DomainRuntimeServiceMBean domainService = (DomainRuntimeServiceMBean) MBeanServerInvocationHandler.

                newProxyInstance(mbconn, new ObjectName(DomainRuntimeServiceMBean.OBJECT_NAME));

            sm = (SessionManagementMBean) domainService.findService(SessionManagementMBean.NAME,SessionManagementMBean.TYPE, null);

            sm.createSession(sessionName);            

            ALSBConfigurationMBean alsbSession = (ALSBConfigurationMBean) domainService.

                 findService(ALSBConfigurationMBean.NAME + "." + "mysession",ALSBConfigurationMBean.TYPE, null);      

          

            if(servicetype.equals("ProxyService")) {

                Ref ref = constructRef("ProxyService",serviceURI);

                ProxyServiceConfigurationMBean proxyConfigMBean = (ProxyServiceConfigurationMBean) domainService.

                 findService(ProxyServiceConfigurationMBean.NAME + "." + sessionName,ProxyServiceConfigurationMBean.TYPE, null);

                if(status){

                   proxyConfigMBean.enableService(ref);

                   statusmsg="Enabled the Service : " + serviceURI;

                }

                else {            

                    proxyConfigMBean.disableService(ref);   

                    statusmsg="Disabled the Service : " + serviceURI;

                }  

            }else if(servicetype.equals("BusinessService")) {

                Ref ref = constructRef("BusinessService",serviceURI);               

                BusinessServiceConfigurationMBean businessConfigMBean = (BusinessServiceConfigurationMBean) domainService.

                 findService(BusinessServiceConfigurationMBean.NAME + "." + sessionName,BusinessServiceConfigurationMBean.TYPE, null);

                if(status){

                   businessConfigMBean.enableService(ref);

                   statusmsg="Enabled the Service : " + serviceURI;

                }

                else {            

                    businessConfigMBean.disableService(ref);   

                    statusmsg="Disabled the Service : " + serviceURI;

                }  

            }

           sm.activateSession(sessionName, statusmsg);           

           conn.close();

        }catch(Exception ex){

            if(null != sm) {

                try{

                    sm.discardSession(sessionName);

                }catch(Exception e) {

                    System.out.println("able to discard the session");

                  

                }

            }

            statusmsg="Not able to perform the operation";           

            ex.printStackTrace();          

        }finally{

            if(null != conn)

                try{

                    conn.close();

                }catch(Exception e) {

                    e.printStackTrace();

                }

        }

       

        return statusmsg;

    }

      

    public static void main(String[] args) {       

        //changeProxyServiceStatus(servicetype, status, serviceURI, host, port, username, password)       

        System.out.println(changeProxyServiceStatus("BusinessService", false, "OSBServiceAPI/OSBServiceAPIBusiness", "localhost", 8000, "weblogic", "welcome1"));

       

    }

}

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.