Oracle SOA Suite - Changing the state and mode of a composite through JAVA.

Oracle SOA Suite - Changing the state and mode of a composite through JAVA:

Some scenario's we may required to change the state and mode of the composite the below java code snippet will help you to change the same.

Change the SOA server details and the composite details accordingly.

package changecompositestate;

import java.util.Hashtable;
import java.util.Set;
import javax.management.MBeanServerConnection;
import javax.management.ObjectName;
import javax.management.remote.JMXConnector;
import javax.management.remote.JMXConnectorFactory;
import javax.management.remote.JMXServiceURL;

import javax.naming.Context;

public class ChangeCompositeStateAndMode {
static MBeanServerConnection m_connection=null;
public static void changeCompositeStateAndMode()
{
String jndiroot = "/jndi/";
String revision=null;
try
{
Hashtable jndiProps = new Hashtable();
jndiProps.put(Context.SECURITY_PRINCIPAL,"weblogic");
jndiProps.put(Context.SECURITY_CREDENTIALS,"xxxxx");
jndiProps.put(JMXConnectorFactory.PROTOCOL_PROVIDER_PACKAGES,"weblogic.management.remote");
JMXServiceURL serviceURL = new JMXServiceURL("t3","eaidev2",8000,jndiroot + "weblogic.management.mbeanservers.runtime");
JMXConnector m_connector = JMXConnectorFactory.newJMXConnector(serviceURL,jndiProps);
m_connector.connect();
m_connection = m_connector.getMBeanServerConnection();
ObjectName compositeLifeCycleMBean = null;
Set queryResult = m_connection.queryNames(new ObjectName("*:j2eeType=CompositeLifecycleConfig,*"), null);
if (!queryResult.isEmpty()) {
compositeLifeCycleMBean = (ObjectName)queryResult.iterator().next();
}
//CompositeDN - DomainName/CompositeName
String compositeDN = "default" + "/" + "GetDomainID!1.0";
setCompositeModeAndState(compositeLifeCycleMBean, compositeDN);
}catch(Exception e)
{
e.printStackTrace();
}
}
public static void setCompositeModeAndState(ObjectName compositeLifeCycleMBean, String compositeDN)
throws Exception {
m_connection.invoke(compositeLifeCycleMBean,"setCompositeMode", new Object[] { compositeDN,"retired" }, new String[] { String.class.getName() ,String.class.getName()});
m_connection.invoke(compositeLifeCycleMBean,"setCompositeState", new Object[] { compositeDN ,"off"}, new String[] { String.class.getName(),String.class.getName() });
}

public static void main(String args[]) {
changeCompositeStateAndMode();
}

}

Logout and login to EM console to see the changes,the component will be down now as shown below.

In Oracle SOA 11g:

In Oracle SOA 12c:

Oracle SOA Suite – Enabling the JDBC logging through EM Console.

Oracle SOA Suite – Enabling the JDBC logging through EM Console:

Some scenarios we may required to monitor the JDBC logs generated by server for debugging the issues. The JDBC logging for the weblogic server in SOA Suite 11g  or Oracle SOA 12c can be enabled or disabled through EM console by changing the attribute value of the corresponding MBean.

Oracle SOA 11g:

Steps to Enable the JDBC Logging:

Login to EM Console.

From the navigation pane, expand the farm and SOA folders then right click on soa-infra and then select Administration and System MBean browser.

 Expand the folder Application Defined MBeans then com.oracle.jdbc then expand the Server folder for that the JDBC logging should be changed. Expand diagnosablity folder and click on the MBean available. Change the property value of LoggingEnabled to “true” and click on Apply.

Oracle SOA 12c:

Login to em console and click on Target Navigation.

Click on the server

Click on Weblogic Server and System MBean Server

 Expand the folder Application Defined MBeans then com.oracle.jdbc then expand the Server folder for that the JDBC logging should be changed. Expand diagnosablity folder and click on the MBean available. Change the property value of LoggingEnabled to “true” and click on Apply.

Oracle SOA Suite - Setting Timeouts for Receive activities.

Oracle SOA Suite - Setting Timeouts for Receive activities:

Oracle SOA Suite 11g introduced a new feature setting the timeout for receive activity.
We can specify timeout duration for partner callbacks using this property. This property can be used in Oracle SOA Suite 12c to set the timeout in receive activity.

Timeout Settings Relative from When the Activity is invoked:

You can specify a timeout setting relative from when the activity is invoked.
This type uses the bpelx:for attribute to specify a static value or an XPath expression that must evaluate to an XML schema type duration.

Timeout Settings as an Absolute Date Time:

You can specify a timeout setting as an absolute deadline for receive activities.

The expected expiration time for the bpelx:until attribute must be at least two seconds ahead of the current time. Otherwise, the timer scheduling is ignored and skipped, just as if the timer was never specified. The bpelx:until attribute specifies a static value or an XPath expression that must evaluate to an XML schema type datetime or date.

Oracle SOA Suite 10g to 11g Migration – Migrating XREF Runtime Data.

Oracle SOA Suite 10g to 11g Migration – Migrating XREF Runtime Data:

If you have Oracle SOA Suite 10g cross reference (XREF) runtime data in an Oracle database (oraesb.XREF_DATA) then the same needs to be migrated to Oracle SOA Suite 11g (SOAINFRA.XREF_DATA).

The utility is required, as the XREF database schema table (XREF_DATA) has changed for Oracle Fusion Middleware 11g.

We had around 12 million records in our 10g environment and used the utility 

Upgrade10gXrefTo11gXref.sql provided by oracle to migrate the data.

This utility is using the DBLINK to get the data from 10g database because of this the migration was taking more time and could not able to complete.

We have done some modification to the SQL utility based our requirement and we were able to migrate the data successfully within 9hrs of time.

Instead of using the DBLIINK, we have used the Oracle DataPump Utility to transfer the data from Oracle SOA 10g database to Oracle SOA 11g database schema(SOAINFRA –Where the 11g XREF data is available ) and used the local table in the utility script.

The steps to execute the script:

- Using Oracle DataPump Utility, transfer the data from the table oraesb.XREF_DATA of SOA 10g source database to SOA 11g destination database table SOAINFRA.XREF_DATA_MIGRATION (the schema where the 11g XREF data is available).

- Change the MDS location 'oramds: /apps/EAIMetaData/Xref/' in the script, location where the XREF meta data has stored, with your value.

- Log in to Oracle database that hosts the Oracle SOA 11g XREF data as the SOAINFRA user and execute the script.

@Upgrade10gXrefTo11gXref.sql

All the corrupted/duplicated data will be inserted into the table XREF_DATA_CORRUPTED.

Refer the script attached with this blog

Upgrade10gXrefTo11gXref.sql

Oracle SOA Suite - Abstract WSDL - Resolving the composite dependency issue during deployment and server restart.

Oracle SOA Suite - Abstract WSDL - Resolving the composite dependency issue during deployment and server restart:

Dependency order is not recorded in SOA Suite for composites. So, during server start-up, there might be multiple retries before all composites are loaded to the server if a wrong dependency order is followed by the server.

This does not necessarily mean the composites are not loaded at all, but server may end up trying to load a composite multiple times before it is finally succeeds after restart. This results in multiple errors in logs and also overall time taken for restart. E.g., as seen in the diagram below, if the server tries to load A before B and C are deployed then the composite loading fails. This can also happen during deployment time if there is a circular dependency between composites.

Solution to this problem is isolating design time and runtime dependencies. This can be done by moving WSDL dependencies to abstract WSDL’s. We can store the abstract copies of all such WSDL’s in MDS.

Consider the XML snippets below which can be found in composite.xml.

<reference name="SubmitOrderToCOMPASSRS" ui:wsdlLocation="http://eaidev2:8004/soa-infra/services/MEDIATOR/CSOM_SubmitOrderToCOMPASS/CSOM_SubmitOrderToCOMPASSRS.wsdl">

<binding.ws port="******" location="http://eaidev2:8004/soa-infra/services/MEDIATOR/CSOM_SubmitOrderToCOMPASS/CSOM.SubmitOrderToCOMPASSRS_ep?WSDL" soapVersion="1.1">

ui:wsdlLocation signifies design time and binding.ws stands for runtime.

So, we need to change the value in ui: wsdlLocation, so that it refers to MDS rather than the deployed component through http. The changed value should look something similar as below to point it to MDS.

oramds:/apps/EAIMetaData/Abstract/WSDL/MEDIATOR/CSOM_SubmitOrderToCOMPASS/CSOM_SubmitOrderToCOMPASSRS.wsdl

By following the approach, during compile time the compiler finds all the references it needs and the runtime engine does not bother about the abstract WSDL’s once it is loaded. So for both initial deployment and subsequent server restarts this approach helps in avoiding design time dependencies.