Oracle SOA Suite - Configure transaction timeout for BPEL.

Oracle SOA Suite - 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 - Abort the running composite instances through JAVA API

Abort the running Oracle SOA Suite composite instances through JAVA API:

Sometimes we may required to abort the running composite instances, the JAVA APIs can be used to abort the running instances of a composite. To abort the instance, we have to identify the running composite instances based on the instance state and the same can be aborted by using the abort method available in the CompositeInstance class.

The below code snippet will help us to abort the running instance of the particular composite, the filter condition can be changed accordingly to abort the running composite instances with different matching criteria.

try
{
String compositeName="GetDomainID";
Hashtable jndiProps = new Hashtable();
jndiProps.put(Context.PROVIDER_URL,"t3://soahost:soaport");
jndiProps.put(Context.INITIAL_CONTEXT_FACTORY,"weblogic.jndi.WLInitialContextFactory");
jndiProps.put(Context.SECURITY_PRINCIPAL,"weblogic");
jndiProps.put(Context.SECURITY_CREDENTIALS,"xxxxx");
jndiProps.put("dedicated.connection","true");
Locator locator = LocatorFactory.createLocator(jndiProps);
CompositeInstanceFilter filter =new CompositeInstanceFilter();
filter.setState(CompositeInstance.STATE_RUNNING);
filter.setCompositeName(compositeName);
// filter.setId("670002");
List<CompositeInstance> compositeInstances = locator.getCompositeInstances(filter);
for(int i=0;i<compositeInstances.size();i++)
((CompositeInstance)compositeInstances.get(i)).abort();
}catch(Exception e)
{
e.printStackTrace();
}

Execution of this code will abort all the running instances of a specified composite.

Jar files - 

$Middleware_Home\Oracle_Home\oracle_common\modules\internal\features\jrf_wlsFmw_oracle.jrf.wls.classpath.jar
$Middleware_Home\Oracle_Home\soa\soa\modules\oracle.soa.fabric_11.1.1\oracle.soa.fabric.jar
$Middleware_Home\Oracle_Home\wlserver\server\lib\weblogic.jar

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

Migrating the Metadata from Oracle  SOA Suite 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

3. 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>>

4. 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.

Steps to migrate the JAVA web services from Oracle SOA Suite 10g to 11g.

Steps to migrate the JAVA web services from Oracle SOA Suite 10g to 11g:

Because of the container change from 10g to 11g, the web services developed in 10g has to be migrated to latest format.

The main step for the migration is changing the deployment descriptors created for OC4J to vendor specific descriptor format.

Steps to migrate the JAVA web services from Oracle SOA Suite 10g to 11g:

1. Change the Web.xml (<Webservice Home>/public_html/WEB-INF) contents:-

Replace the below contents in the web.xml.

<web-app xmlns="http://java.sun.com/xml/ns/j2ee" xmlns: xsi=http://www.w3.org/2001/XMLSchema-instance xsi: schemaLocation=http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd version="2.4">

With the following contents

<web-app xmlns="http://java.sun.com/xml/ns/javaee" xmlns: xsi=http://www.w3.org/2001/XMLSchema-instance xsi: schemaLocation=http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd version="2.5">

In 10g:-

In 11g:-

Oracle SOA Suite 11g - Purging Metadata Version History for SOA-INFRA

Oracle SOA Suite 11g - Purging Metadata Version History for SOA-INFRA:

For database-based MDS repositories, you can purge the metadata version history from a partition. (File-based MDS repositories do not maintain version history.) This operation purges version history of unlabeled documents from the application's repository partition. The tip version (the latest version) is not purged, even if it is unlabeled.

To purge labeled documents, you must first delete the label.

Consider purging metadata version history on a regular basis as part of MDS Repository maintenance, when you suspect that the database is running out of space or performance is becoming slower. This operation may be performance intensive, so plan to do it in a maintenance window or when the system is not busy.

To use WLST to purge metadata version history, use the purgeMetadata command. You specify the documents to be purged by using the older than parameter, specifying the number of seconds.

The following example purges all documents older than 100 seconds:

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> purgeMetadata(application='soa-infra', server='SOA1', olderThan=100)

Executing operation: purgeMetadata.

Metadata purged:Total number of versions: 3925.

Number of versions purged: 0.

wls:/SOACoreDomain/serverConfig>

To use Fusion Middleware Control to purge the metadata version history:

1. From the navigation pane, expand the farm, expand SOA and then right click on soa-infra.
2. From the menu, choose Administration then choose MDS Configuration.