Oracle SOA Suite 11g - Metadata Labels in the MDS Repository

Oracle SOA Suite 11g - Metadata Labels in the MDS Repository:

A metadata label is a means of selecting a particular version of each object from a metadata repository partition. Document versions belonging to a label are not deleted by automatic purging, unless the label is explicitly deleted. In this way, creating a label guarantees that a view of the metadata as it was at the time the label was created remains available until the label is deleted.

You can use a label to view the metadata as it was at the point in time when the label was created. You can use the commands to support logical backup and recovery of an application's metadata contained in the partition.

Labels are supported only in database-based repositories.

The following topics describe how to manage labels:

· Creating Metadata Labels

· Deleting Metadata Labels

· Listing Metadata Labels

· Promoting Metadata Labels

1. Creating Metadata Labels

To create a label for a particular version of objects in a partition in an MDS Repository, you use the WLST command createMetadataLabel. For example, to create a label named prod1 for the application soa-infra, use the following command:

wls:/offline> connect ()

Please enter your username: weblogic

Please enter your password:

Please enter your server URL [t3://localhost:7001] :t3://soahost:soaport

Connecting to t3://nft-soa-vip1:8004 with userid weblogic...

Successfully connected to managed Server 'SOA1' that belongs to domain 'SOACoreDomain'.

wls:/SOACoreDomain/serverConfig> createMetadataLabel (application='soa-infra', server='SOA1', name='prod1')

Executing operation: createMetadataLabel.

Created metadata label "prod1".

wls:/SOACoreDomain/serverConfig>

If the application has more than one version, you must use the applicationVersion parameter to specify the version.

2. Deleting Metadata Labels

To delete a metadata label, you use the WLST command deleteMetadataLabel. For example, to delete a label named prod1 for the application soa-infra use the following command:

deleteMetadataLabel (application='soa-infra', server='SOA1', name='prod1')

If the application has more than one version, you must use the applicationVersion parameter to specify the version.

3. Listing Metadata Labels

You can list the metadata labels for a particular application. To do so, use the WLST command listMetadataLabel. For example, to list the labels for the application soa-infra, use the following command:

listMetadataLabels(application='soa-infra', server='SOA1')

If the application has more than one version, you must use the applicationVersion parameter to specify the version.

4. Promoting Metadata Labels

You can promote documents associated with a metadata label so that they are now the last version. That is, you can promote them to the tip. Promote a label if you want to roll back to an earlier version of all of the documents captured by the label.

To promote a label to the tip, use the WLST command promoteMetadataLabel. For example to promote the label prod1, use the following command:

promoteMetadataLabel(application='soa-infra', server='SOA1', name='prod1')

If the application has more than one version, you must use the applicationVersion parameter to specify the version.

Oracle SOA Suite - Utility for bulk import of Xref data.

Oracle SOA Suite - Utility for bulk import of Xref data:

In 10g, we had the xrefimport tool to bulk import the data from file to the XREF_DATA table but in Oracle SOA Suite 11g or Oracle SOA Suite 12c, there is no out of box solution to bulk import the data to XREF_DATA table.

We have implemented a utility to bulk import the data to XREF_DATA table and thought of sharing because it may help the people whoever looking for the utility.

The utility will generate the Xref data file (XREFData.LST) based on the data available in the staging table (XREF_STG) and using the java program the file contents are imported to XREF_DATA table.

The steps to import the bulk data:

1. Create the temporary table XREF_STG with the required cross reference columns (as per your requirement).

E.g.: To load cross reference data for ITEM_ No and ASSET_INT_ID

2. Insert all the records to the XREF_STG table (without generating the file using the script the sample file can be modified manually to import the data).

3. Execute the below script sql script(xref_import.sql), this will generate the XREFData.LST file based on the data available in the XREF_STG table; Change the XREF table and the column names before executing the script.

/***************************************************************************

* This script will select records to insert into cross-reference table from XREF_STG table and * * *create the file XREFData.LST

*****************************************************************************/

SET HEADING OFF

SET PAGESIZE 0

SET LINESIZE 100

SET FEEDBACK OFF

SET TRIMSPOOL ON

SET TRIMOUT ON

SET SERVEROUTPUT ON

SPOOL XREFData

SELECT '<xref xmlns="http://xmlns.oracle.com/xref">',

'<table name="oramds:/apps/EAIMetaData/Xref/OM_ASSET_INT_ID_ITEM_NO.xref">',

'<columns>',

'<column name="ASSET_INT_ID"/>',

'<column name="ITEM_NO"/>',

'</columns>',

'<rows>'

FROM DUAL;

SELECT '<row><cell colName="ASSET_INT_ID">'||ASSET_INT_ID||

'</cell><cell colName="ITEM_NO">'||ITEMNO||'</cell></row>'

FROM XREF_STG;

SELECT '</rows>',

'</table>',

'</xref>'

FROM DUAL;

DELETE FROM XREF_STG

/

SPOOL OFF

commit

EXIT

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.