Monday, December 17, 2012

Updating the BPEL Component preference value from JAVA – Oracle SOA 11g

Written By Archit Bhardwaj

Sometimes we may need to update the preference value for the BPEL component, the below java code will help us to update the preference value.

This update is not a cluster-aware,remember that you must repeat the same process for each managed server of your environment.
Before executing the code change the mbeanName accordingly.
   String mBeanName ="*:*,j2eeType=SCAComposite.SCAComponent,revision=*,SCAComposite=\"Preference\",name=Preference";




import java.util.*;
import javax.management.*;
import javax.management.openmbean.CompositeDataSupport;
import javax.management.remote.*;
import javax.naming.Context;

public class UpdatePreferenceValue {  

    public static MBeanServerConnection getMbeanServerConnection(String host,
                                                                 int port,
                                                                 String userName,
                                                                 String password) throws Exception {
        String jndiroot = "/jndi/";
        MBeanServerConnection m_connection = null;
        try {
            Hashtable jndiProps = new Hashtable();
            jndiProps.put(Context.SECURITY_PRINCIPAL, userName);
            jndiProps.put(Context.SECURITY_CREDENTIALS, password);
            jndiProps.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,"weblogic.management.remote");

            JMXServiceURL serviceURL =new JMXServiceURL("t3", host, port, jndiroot +"weblogic.management.mbeanservers.runtime");
            JMXConnector m_connector =JMXConnectorFactory.newJMXConnector(serviceURL, jndiProps);
            m_connector.connect();
            m_connection = m_connector.getMBeanServerConnection();

        } catch (Exception e) {

            e.printStackTrace();
        }
        return m_connection;
    }


    private static CompositeDataSupport UpdatePreferenceData(CompositeDataSupport cds,String[] keys,String[] newValues) throws Exception {
        Map<String, Object> items =new HashMap<String, Object>(cds.getCompositeType().keySet().size());

        for (String key : cds.getCompositeType().keySet()) {
            boolean matched = false;
            int i = 0;

            for (; i < keys.length; i++) {
                String searchKey = keys[i];

                if (searchKey.equalsIgnoreCase(key)) {
                    items.put(key, newValues[i]);
                    matched = true;
                    break;
                }
            }       

            if (!matched) {             
                    items.put(key, cds.get(key));
            }
         
        }
    

        return new CompositeDataSupport(cds.getCompositeType(), items);
    }
  
    public static void updatePreference(String host,String port,String userName,String password, String  preferenceName,String value) {
 
        String mBeanName ="*:*,j2eeType=SCAComposite.SCAComponent,revision=*,SCAComposite=\"Preference\",name=Preference";

        MBeanServerConnection mbsc;
        try {
            mbsc =getMbeanServerConnection(host, Integer.parseInt(port),userName,password);
            Set<ObjectName> mbeans=mbsc.queryNames(new ObjectName(mBeanName), null);
            ObjectName mbean=(ObjectName)mbeans.iterator().next();
           javax.management.openmbean.CompositeData[] properties =
               (javax.management.openmbean.CompositeData[])mbsc.getAttribute(mbean,"Properties");
         
            for (int i = 0; i < properties.length; i++) {
                CompositeDataSupport cds = (CompositeDataSupport)properties[i];

                if (preferenceName.equalsIgnoreCase((String)cds.get("name"))) {

                    properties[i] =UpdatePreferenceData((CompositeDataSupport)properties[i],new String[] { "value" },new String[] { value });
                    mbsc.setAttribute(mbean,new Attribute("Properties", properties));
                }
            }

        } catch (Exception e) {
            e.printStackTrace();
        }
    }
   
    public static void main(String[] args) {
        updatePreference("localhost", "8000","weblogic", "password","preference.password","password");
        }
    }

Add the weblogic.jar file to the class.

########

Migrating the Metadata from SOA 10g to 11g and sharing the common artifacts to MDS Repository.

Migrating the Metadata from SOA 10g to 11g and sharing the common artifacts to Repository:
If we use the Domain Value Maps (DVMs) or Cross References in Oracle BPEL Process Manager 10g or Oracle Enterprise Service Bus 10g project, the Xpath functions used to access the domain value maps or cross references will be upgraded automatically when the projects are upgraded in Oracle JDeveloper 11g.
However, a manual upgrade task has to be performed to upgrade the domain value maps and cross references that are saved in the Oracle Enterprise Service Bus repository. Also, if we use the common schemas or WSDLs in 10g project the same should be migrated to MDS repository; in 11g all the common artifacts will be stored in MDS repository.
There is a lot of information for the same topic but thought of sharing my experience.
Below are the steps for migrating the DVMs and XREFs to 11g and also to create the project that will have all the common artifacts like DVM, XREF, WSDL and SCHEMAs that can be stored to MDS repository.
Export the DVM and XREF metadata from 10g server: (Steps should be executed on 10 g server)
  1. Log on to your Oracle SOA Suite 10g server.
  2. cd $ORACLE_HOME/integration/esb/bin
  3. Set the environment - ./ esbsetenv.sh
  4. Run the export.sh script to export the entire ESB metadata - ./export.sh metadata10g.zip.
  5. Copy the metadata10g.zip file from $ORACLE_HOME\integration\esb\bin to the Oracle SOA 11g server.
Convert the ZIP file to an Oracle SOA Suite 11g archive file (Steps should be executed on 11g server) :
  1. Log on to your Oracle SOA 11g server
  2. Set your environment:
export DomainHome=<<Weblogic DomainHome>>
export OracleHome=<<OracleHome>>
cd $DomainHome/bin
. setDomainEnv.sh
  1. Execute the below comments to convert the 10g metadata to 11g format.
cd $OracleHome/bin
ant -f ant-sca-upgrade.xml upgrade-xrefdvm -Dsource=<<Path to metadata10g.zip>> -Dtarget= <<Target path>>
  1. Copy the archive sca_XrefDvmFiles10g_rev1.0.jar generated in target path to local machine.
Create the Metadata project:
  • Create a new Generic Application (e.g. MetaDataApp) in JDeveloper 11g.
  • Click “Next” and Give a Project Name e.g. Metadata.
  • From the Oracle JDeveloper 11g “File” menu, select “Import”, then “SOA Archive into SOA Project”. In the Import Composite Archive Dialog Box, click Browse and locate the sca_XrefDvmFiles10g_rev1.0.jar file that you created previously.
  • Make sure that the Project Name and Composite Name in the Create SOA Project from SOA Archive dialog box and Import Composite Archive Dialog Box have the same name.
  • Click Finish to create the new SOA project. The new project consists of an empty composite, along with the upgraded Xref and DVM files.
  • Crete new folders with the name Xref, dvm, faultpolicy, schemas and WSDL under SOAContent of the project folder based on the different type of artifacts needs to be stored in MDS.



  • Group the dvm’s to dvm folder and the xref’s to Xref folder. By default all content is grouped in the project folder in the file system.


  • Copy the common schemas from 10g to the schemas folder of Metadata project.


  • Copy the common WSDL’s from 10g to the WSDL folder of Metadata project.



  • Copy the fault Policy and fault binding files to faultpolices folder of MeatDataProject.

  • Remove the folders those are not required like xsl, xsd, classes and testsuites from the Metadata project.


Now the metadata application is ready with all the common artifacts, create a metadata archive file and deploy the project to the server, the metadata can be referred in the Composite with the help of oramds protocol.

########

Oracle SOA 11g - Configure transaction timeout for BPEL.

The timeouts should be configured based on the below condition

SyncMaxWaitTime < BPEL EJB's transaction timeout < Global Transaction Timeout

Setting the SyncMaxWaitTime : 

 This is the maximum time a synchronous BPEL process waits before it times out to get the response from another BPEL or a web service.


  •  Login to EM console
  • Expand SOA and right click on "soa-infra"
  • From context menu, select SOA Administration –> BPEL properties
  • Click on "More BPEL Configuration properties"
  • Enter the appropriate value for the SyncMaxWaitTime
Setting the global transaction timeout at Weblogic Domain Level:

This property controls the transaction timeout seconds for active transactions. If the transaction is still in the "active" state after this time, it is automatically rolled back.
  • Log into Oracle Weblogic Administration Console.
  • Click Services -> JTA.
  • Change the value of Timeout Seconds to the required value (the default is 30).
  • Click Save.
  • Restart Oracle Weblogic Server.

Overriding the transaction timeout setting for BPEL EJB's:

The timeout properties for the EJB's control the particular timeout setting for the SOA application, overriding the global setting specified by the JTA timeout
  • Log into Oracle Weblogic Administration Console.
  • Click Deployments.
  • Expand soa-infra -> EJBs.
  • Click on the configuration tab for the timeout setting for each of EJB’s listed below and the change the time out values as required.
  • Following EJBs need to be updated:
BPELActivityManagerBean
BPELDeliveryBean
BPELDispatcherBean
BPELEngineBean
BPELFinderBean
BPELInstanceManagerBean
BPELProcessManagerBean
BPELSensorValuesBean
BPELServerManagerBean
  • Click Save.
  • Restart Oracle Weblogic Server.

########

Oracle SOA Suite 11g – Advanced Configurations for Database Adapter.

This blog give the insight on the new features in Database Adapter configuration in SOA 11g.

Query by Example:
A new Operation type 'Query by Example' has been introduced in Database Adapter Configuration. Query By Example does not require a selection criteria to be specified at design time like SELECT Operation. A selection criteria is inferred from an exemplary input XML record for each invoke. Use queryByExample when you do not want to create a query using the visual query builder and want the flexibility of allowing the input record to share the same XML schema as the output records. The queryByExample operation is will take little more time compared to SELECT operation because a new SELECT must be prepared for each execution.
Doing Synchronous Post to BPEL (Allow In-Order Delivery):
In this feature, the entire invocation is in a single thread and global transaction. By default, initiation is asynchronous and the BPEL process is invoked in a separate global transaction. With Oracle Mediator, it is generally a synchronous invoke so this is only specific to an Oracle BPEL process.
Advanced Options:
A new screen in Adapter configuration wizard for advanced options is added. This screen shows different options based on the type of operation selected. The below are the some of the advanced configurations.
Auto-Retries:
We can set options like no. of retry attempts, interval between retries back-off factor and max interval values.
JDBC Options: This includes options like Query timeout value to specify the timeout for query execution.
Interaction Options: This includes various interaction options. Get Active UnitOfWork ( advanced setting that forces all invoke activities in the same global transaction to use the same SQL connection if going to the same database), Detect Omissions (allows the MERGE and INSERT operations to ignore empty or missing XML elements in the input payload), Optimize Merge (should always be set to true, as it is a general enhancement to MERGE performance)
Native Sequencing (Oracle only):
Allows specifying that the primary key will be assigned from a sequence on any insert.
Polling Options:
For Polling Options the below are the two new configuration parameters added.
Enable Streaming: This option is used to enable support to stream the payload. The payload is streamed to a database instead of getting manipulated in SOA run time as in a memory DOM. This feature is used while handling large payloads.
Schema Validation: When set to true, all XML files produced by the polling Oracle Database Adapter (for Receive activities) is validated against the XSD file. On failure, the XML record is rejected but still marked as processed by the Oracle Database Adapter.
More detailed SQL queries display with sections for Polling SQL and After Read SQL

########

Oracle SOA 11g - Changing the service endpoint URL dynamically through EM console

Sometimes we may need to change the default endpoint location of the service through the EM console.

The below steps help us to change the endpoint URL’s of the references through the EM console.
  • In EM console click on the Composite
  • Scroll down to Service and References section

  • Click on Reference link and properties tab
  • Change Endpoint Address to the desired location and click apply

The new request will be send to the new endpoint location configured through the EM console.
The new endpoint configuration can be removed to send the request to the default endpoint location configured in the WSDL.

########

weblogic.socket.MaxMessageSizeExceededException appearing when Managed Server Attempting To Send larger message to Admin Server.

We used to get the following exception in the managed servers log file frequently

 ####<Mar 20, 2012 12:22:47 PM EST> <Error> <Socket> <ifappc105p> <AdminServer> <ExecuteThread: '2' for queue: 'weblogic.socket.Muxer'> <> <> <a33374ea6b7bab0f:17f6d3b7:1343f18f4ea:-8000-000000000000008a> <1323912167710> <BEA-000403> <IOException occurred on socket: Socket[addr=ifappc105p-vip1/172.105.200.105,port=8000,localport=55103]
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size: '10000480' bytes exceeds the configured maximum of: '10000000' bytes for protocol: 't3'.
weblogic.socket.MaxMessageSizeExceededException: Incoming message of size: '10000480' bytes exceeds the configured maximum of: '10000000' bytes for protocol: 't3'
at weblogic.socket.BaseAbstractMuxableSocket.incrementBufferOffset(BaseAbstractMuxableSocket.java:174)
at weblogic.rjvm.t3.MuxableSocketT3.incrementBufferOffset(MuxableSocketT3.java:351)


The reason is the managed server tries to send the message size more than 10 MB and failing with the following exception. It is observed that every single time this message is observed in the logs, it is followed by the respective managed server who is sending that message, losing connectivity with the admin server.
The root cause is the RJVM messages used to get piled up due to default watches trap events that’s comes installed and it used to grow in larger size causing the broken communication between managed servers and AdminServer
The solution to resolve this is to disable the default WLDF configured in the server.

Follow the below steps to disable the default WLDF configured in the server.
  • Login into admin console with weblogic user.
  • Click Lock & Edit
  • Expand Diagnostics tab 

  • Click on Diagnostic Modules


  • Click on Module-FMWDFW


  • Click on Watches and Notifications


  • Click on Deadlock


  • Uncheck the below highlighted (Enable Watch)

  • Save the changes and continue the same for remaining 2 components as well. 
               StuckThread  and UncheckedException 
  • Save the changes.
  • Restart all servers (admin and managed)
The default message size of all the servers can also be increased. The configure can be changed in the protocol section of the server configuration from the weblogic console as shown below



This stabilized the connectivity issue between the managed servers and the Admin Server.

########

Cluster Constraint for the deployment in weblogic server

luster constraint specifies that deployments targeted to a cluster succeed only if all servers in the cluster are running.

When this option is enabled, WebLogic Server enforces a strict two-phase deployment policy for all Managed Servers in a domain—ensuring that application deployment to a cluster succeeds only if all Managed Servers in the cluster are reachable and can deploy the application. If any server instance in the cluster is unreachable, the application is not deployed to any of the Managed Servers.

If you do not enable this option, WebLogic Server allows deployment to a partial cluster. When the unreachable Managed Server becomes available, deployment to that server instance will be initiated.

By default, cluster constraints are disabled and deployment is attempted only on the servers that are reachable at the time of deployment from the Administration Server.

To Enable Cluster Constraint:


  • Login to Weblogic Admin Console
  • Click on the domain name
  • Select the Check box against “Enable Cluster Constraint”

########