Play Java

Abstract WSDL vs. Concrete WSDL

2012-02-10T08:19:00.000-08:00

Abstract WSDL(definitions )

An Abstract WSDL contains only Messages, PortTypes, and Operations
Abstract WSDL consists of the structure of the message that is like what operation, what is the input, what is the ouput and what is the fault message used by each operation to communicate with the web service, and their format.
An abstract WSDL document describes what the web service does, but not how it does it or how to contact it. An abstract WSDL document defines: the operations provided by the web service.

Concrete WSDL(implementation)
Concrete WSDL has all the things that the abstract wsdl has in addition it has transport(http,jms) details to tell how the web service communicates and where you can reach it. A concrete WSDL document contains the abstract WSDL definitions, and also defines: the communication protocols and data encodings used by the web service, the port address that must be used to contact the web service. SOAP clients must retrieve the concrete WSDL file before sending a SOAP request to the service.

Abstract WSDL:- Used on server side,contains request,response and type of operation performed.
Concrete WSDL:- Used on client side,contains abstract wsdl and transport used.

BPEL - How to handle an embeded XML message in a fault

2012-02-09T21:24:00.000-08:00

In the development, the third part service returns a fault with a XML as a fault detail.

In order to get the real error message, I have to parse this XML to get the error code and error message.

In SOA Suite, there is a function named as parseXML.

parseXML
This function parses a string to a DOM element.
Signature:
oratext:parseXML(contentString)
Arguments:
contentString - The string that this function parses to a DOM element.
Property IDs:
namespace-uri: http://schemas.oracle.com/xpath/extension
namespace-prefix: oratext

First, I need to get the XML message in the element <WL_FAULT_DETAIL>. The code is the follow. By this, I will be able to get a XML element <WL_FAULT_DETAIL>, which contains a XML string.
oraext:parseXML($RuntimeFault.detail)

The follow code will parse the XML string held by element <WL_FAULT_DETAIL> to a XML.
oraext:parseXML(oraext:parseXML($RuntimeFault.detail))

The above expression means:
1. Parse the detail to a XML and this XML contains another XML string like the follow.
<ser:ServiceFault xmlns:ser="http://rci.rogers.com/schemas/ServiceFault"><ser:Error id="1" lang="en"><ser:ErrorCode>SYSTEM FAILURE</ser:ErrorCode><ser:Description>[com.bea.nonxml.common.MFLException.create(MFLException.java:221) at com.bea.nonxml.common.MFLException.create(MFLException.java:344) at com.bea.nonxml.readers.NonXMLReaderVisitor.nextToken(NonXMLReaderVisitor.java:155) at com.bea.nonxml.readers.TokenNonXMLReader.nextToken(TokenNonXMLReader.java:44) at com.bea.wli.variables.util.ProcessXMLTokenReader.next(ProcessXMLTokenReader.java:56) at com.bea.wli.variables.util.TokenSourceSerializer.process(TokenSourceSerializer.java:284) at com.bea.wli.variables.ProcessXML.storeXML(ProcessXML.java:338) at com.bea.wli.variables.ProcessXML.storeTokenSource(ProcessXML.java:349) at com.bea.wli.variables.ProcessXML.<init>(ProcessXML.java:124) at com.bea.wli.variables.XmlObjectVariableFactory.createProxy(XmlObjectVariableFactory.java:332) at com.bea.wli.variables.XmlObjectVariableFactory.createProxy(XmlObjectVariableFactory.java:298) at com.bea.wli.variables.MflObject.convertToXmlObject(MflObject.java:299)
...
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) a...]</ser:Description><ser:Value>RSSP</ser:Value></ser:Error></ser:ServiceFault>.

2. Pass the above text as a string to parseXML to get another XML and the root element will be <ser:ServiceFault>.

Then, it will be very esay to get the error code and error message by getChildElement function.
Error Code is
ora:getChildElement(ora:getChildElement(oraext:parseXML(oraext:parseXML($RuntimeFault.detail)),1),1)
Error Message is
ora:getChildElement(ora:getChildElement(oraext:parseXML(oraext:parseXML($RuntimeFault.detail)),1),2)

OSB - System Error Code - BEA-380001

2012-02-07T14:29:00.000-08:00

When the OSB got some exception from the routing, a fault with error code BEA-380000 and message Internal Server Error will be created and save in fault. The exception returned by a service will be saved in the message body. If we just log out the falut, we will not know what exactly happen in the process. In order to get the real reason, we need to get the falut from message body and return these exception info to the client side. That will be help on the problem investigation.

The follow message will be help on the problem investigation.
fn-bea:inlinedXML($body/soap-env:Fault/detail)

OSB - System Error Code - BEA-380000

2012-02-07T13:04:00.000-08:00

Server found but service not available, a BEA-380000 error code will be got with Not Found in description:

<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-380000</con:errorCode>
<con:reason>Not Found</con:reason>
<con:location>
<con:node>RouteNode1</con:node>
<con:path>response-pipeline</con:path>
</con:location>
</con:fault>

Server not running on same port, a BEA-380000 error code will be got with Socket Closed in description:

<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-380000</con:errorCode>
<con:reason>General runtime error: Socket Closed</con:reason>
<con:location>
<con:node>RouteNode1</con:node>
<con:path>request-pipeline</con:path>
</con:location>
</con:fault>

Timeout set on Business Service triggering (Target service still processing and Socket gets closed because of preconfigured timeout value on BS), a BEA-380000 error code will be got with SocketTimeOut exception stacktrace in Description.

<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-380000</con:errorCode>
<con:reason>
[WliSbTransports:381304]Exception in HttpOutboundMessageContext.RetrieveHttpResponseWork.run: java.net.SocketTimeoutException
java.net.SocketTimeoutException
at weblogic.net.http.AsyncResponseHandler$MuxableSocketHTTPAsyncResponse$SocketTimeoutNotification.<clinit>(AsyncResponseHandler.java:551)
at weblogic.net.http.AsyncResponseHandler$MuxableSocketHTTPAsyncResponse.handleTimeout(AsyncResponseHandler.java:396)
at weblogic.net.http.AsyncResponseHandler$MuxableSocketHTTPAsyncResponse.timeout(AsyncResponseHandler.java:502)
at weblogic.socket.SocketMuxer$TimerListenerImpl.timerExpired(SocketMuxer.java:1052)
at weblogic.timers.internal.TimerImpl.run(TimerImpl.java:273)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:528)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:207)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:176)
</con:reason>
<con:location>
<con:node>RouteNode1</con:node>
<con:path>response-pipeline</con:path>
</con:location>
</con:fault>

Timeout while obtaining connection to remote server, a BEA-380000 error code will be got with Connect Timed Out in Description.

<con:fault xmlns:con="http://www.bea.com/wli/sb/context">
<con:errorCode>BEA-380000</con:errorCode>
<con:reason>General runtime error: connect timed out</con:reason>
<con:location>
<con:node>RouteNode1</con:node>
<con:path>request-pipeline</con:path>
</con:location>
</con:fault>

Subversion for Oracle WebLogic workshop.

2012-02-02T14:10:00.000-08:00

Reference http://blogs.oracle.com/simonthorpe/entry/subversion_source_control_in_o

Now that the server is up and running, I want to enable my development environment to use it. I have installed on my workstation the 10g release of Workshop for Weblogic. You have two choices for this environment, Subclipse and Subversive. I decided on Subclipse for no other reason than it was listed first :)

Before we do anything with Workshop, I actually ran into a bug which limits the ability to install Subclipse via the "Software Updates" mechanism directly in the IDE. There is a workaround for this problem detailed below.

Comment out the com.* import lines in your %BEA_HOME%\wlportal_10.3\eclipse\features\com.bea.wlp_10.3.0\feature.xml, like this:

<requires>
<import plugin="org.eclipse.core.runtime" version="3.3" match="compatible"/>
<import plugin="org.eclipse.ui" version="3.3" match="compatible"/>

</requires>

Then restart Workshop
Once you've done this follow these instructions to download and install the subversion client.
Start Workshop for WebLogic and go to "Help > Software Updates > Find and Install..." then select Search for new features to install. Click on New Remote Site and enter;

Name = subclipse 1.6
URL = http://subclipse.tigris.org/update_1.6.x

Once added, ensure that this site is the only one checked in the sites to include in the search and hit Finish. You will be presented with a tree to choose the components, I selected the following;

Agree to the licenses

Accept the optional component;

Finally hit finish to install everything. Note these are not signed packages so you'll need to agree also to install the unsigned components. At the end you'll be asked to restart Workshop.

Checkout test project from subversion in Workshop for WebLogic

Ok, nearly there. Now its time to checkout that test repository I created during the server setup.
In Workshop go to "File > New > Other" and in the resulting dialog find the SVN section and choose Checkout Projects from SVN.

Select Create a new repository location. It now asks for the URL to the server, remember this is in the format SVN://servername/respository my example is shown below. The client will attempt to connect after which you can select the URL to get to the Check Out As dialog.

The check out dialog now asks what you want to do with the project. If you want you can create a new project using the Workshop's wizard. However I just wanted to add a vanilla project so selected Check out as a project in the workspace, like below and hit Finish. It also warns me that i'm checking out the entire root which is fine for this test.

You will now have an empty project folder in Workshop. You can take a look at all the version control options now by right clicking on the project and selecting the Team menu. Here you have access to all the branching, merging etc features.

OSB - How to change the logging level

2012-01-26T11:35:00.000-08:00

Problem:
I created a proxy service and added a Log action to log out the message body, but I didn't see the log on WebLogic console.

Solution:
The problem is related with log level as the default level is higher than info level. Change the log level will solve it.

1. Enter the WSL admin console
2. Click on Environment->Servers
3. Click on Admin Server (or the appropriate server name of yours)
4. Select Logging tab
5. Click Advanced
6. Set Severity Level of Standard Out to Debug.
7. Click Save

After that, maybe a restart is needed.

OSB - XQuery expression validation failed.

2012-01-26T11:22:00.000-08:00

Problem:
OSB fault cannot be used directly in exception hanlder and got an error message as "Xquery expression validation failed: The variable "fault" cannot be used here. "

Solution:
In the exception handler, first use "Assign" to assign the $fault to a variable, e.g. $myFault, then you can use the variable as what you need.

BPEL - Handle array with a varaible as index

2012-01-20T07:59:00.000-08:00

Recently, I worked on a project and used array to save all of exceptions catched in a loop. I set the value to the array used a variable as index, but it doesn't work. I tested it with a number directly, it works well. By the colleague help, I eventually fixed this issue and make the array work with a variable as index.

The tricky thing is the table on the edit assign supports right click and can pop up a menu. The menu is the magic.

From the menu, select the insertMissingToData, then the array setting will work.

The change to the element is

Using Preference in Oracle SOA 11g

2011-11-21T13:34:00.000-08:00

In the Oracle SOA 11g, how can we config the timeout of a callback service at runtime? Where can we put these property? A preferences in composite.xml will solve these questions in BPEL process.

Where to add?
In the composite.xml, locate the component element.

<component name="SubmitOrder" version="2.0">
  <implementation.bpel src="SubmitOrder.bpel"/>
  <property name="bpel.preference.timeout">PT90S</property>
  </component>

Then we can use the function ora:getPreference(preferenceName) in a bpel process.

Note: The preference have a prefix and you doesn't need it when you reference it. The prefix is 'bpel.preference'.

How to config it in production?
In Oracle SOA Suite 11g, we can change the value of prefences with Enterprise Manager, which url is http://hostname:port/em.

1. Find the SOA domain, in my example, it is Farm_soa_domain\Weblogic Domain\soa_domain
2. Right click on the domain name and select ‘System MBean Browser’ from the popup menu.

4. From the right frame, locate your component. The navigate path is

Application Defined MBeans\oracle.soa.config\Server:{server name}\SCAComposite\{project name}\SCAComposite.SCAComponent\{component name}.

5. Click on the Attribute 'Properties', the preference will be displayed.

You can modified it and apply the new value to that property.

What does BPM/BPMN add to SOA Suite?

2011-10-17T07:18:00.000-07:00

Oracle has just released Oracle SOA Suite and Oracle BPM Suite 11.1.1.4 (often referred to as ‘Patch Set 3,’) the second release that includes comprehensive support for both Business Process Modeling Notation (BPMN) and Business Process Execution Language (BPEL) for modeling and executing business processes.

For the detail, you can find at http://redstack.wordpress.com/2011/01/15/what-bpm-adds-to-soa-suite/.

Calling Java Classes from SOA Suite 11g

2011-10-13T10:23:00.000-07:00

(From http://niallcblogs.blogspot.com/2009/11/calling-java-classes-from-soa-suite-11g.html)

Essentially the same procedure, from a development perspective, as in 10g -
but under the hood we're using the 11g Infrastructure layer.

The Oracle documentation can be found at
http://download.oracle.com/docs/cd/E12839_01/integration.1111/e10224/bp_java.htm#BABCBEJJ

Here's a simple example based on WSDL Java binding, later posts will cover bpel:exec etc. -

1. Create a generic Application/Project in Jdev 11g

1.1. Add 2 classes - Cust & Greeting

Cust -

package cccwsif;

public class Cust {

private String custName1;
private String custName2;
private String custXMASgreeting;

public Cust() {
super();
}

public void setCustName1(String custName1) {
this.custName1 = custName1;
}

public String getCustName1() {
return custName1;
}

public void setCustName2(String custName2) {
this.custName2 = custName2;
}

public String getCustName2() {
return custName2;
}

public void setCustXMASgreeting(String custXMASgreeting) {
this.custXMASgreeting = custXMASgreeting;
}

public String getCustXMASgreeting() {
return custXMASgreeting;
}
}

Greeting -

package cccwsif;

public class Greeting {
public Greeting() {
super();
}

public Cust XMASgreet(Cust c){
String g = "Happy Christmas " + c.getCustName1() + " " +
c.getCustName2();
c.setCustXMASgreeting(g);
return c;
}
}

1.2. expose Greeting as a Web Service
1.2.1. Right-mouse click on Greeting
1.2.2. Then select "Create Web Service..."

1.2.3. Accept defaults for all steps up until step 9.
1.2.4. Additional Classes --> Include "Cust" class

1.2.5. open the wsdl file and set nillable=false

1.2.6. open the GreetingService-java-wsdl-mapping.xml file
1.2.7. check the mapping order

1.3. Add the Java Binding to the WSDL
1.3.1. Open the wsdl in "Design" mode
1.3.2. Click the + by Bindings

1.3.3. Click the Map button
1.3.4. select the Cust class

1.3.5. Amend the Service entry in the WSDL as follows -

1.4. Jar up the project
1.4.1. File --> New --> Deployment Profile --> Jar
1.4.2. Deploy to Jar

2. Create a SOA App in JDev 11g

2.1. Copy the WSDL into the project

2.2. Drop a BPEL service component onto the designer

2.2.1. Set input / output as follows -

2.3. Add a partner Link to the process, pointing to the imported WSDL

2.3.1. Add Assign - Invoke - Assign Activities

2.3.2 Assign input / output vars in the 2 Assigns

2.4. Copy the Jar file from the previous project to the SOA Project sca-inf\lib directory

2.5. Deploy the SOA App

3 Test

SOA Suite 11g - FTP Adapter

2011-10-13T09:05:00.000-07:00

(From http://niallcblogs.blogspot.com/2011/07/soa-suite-11g-ftp-adapter.html)

Here is a simple lab demonstrating use of the FTP adapter.
I'm using FileZilla as my FTP Server.
I created the following directories

FTP Server Configuration

I create a user NiallC/NiallC
and configure the shared folders as follows -

Create FTP Adapter artifacts using WLS Console

Deployments --> FtpAdapter --> Configuration --> Outbound Connection Pools --> New

Edit the properties as follows -

host=localhost
password=NiallC
port=21
username=NiallC
serverType=win

Create a new SOA app

In this example I read in an(GET) order and then write it out (PUT).

Configure the read adapter as follows -

Configure the write adapter as follows -

Add the Mediator and specify the transformation.

That's it.

App at
https://docs.google.com/leaf?id=0B7YrnfO7h717ODc1ZTY2MTgtMTMzNS00ZTM4LWFkM2UtYjcyNjExMWMzOWIy&hl=en_US

Invoking SOA Composite as part of a global transaction

2011-10-13T08:54:00.000-07:00

(From http://niallcblogs.blogspot.com/2011/06/invoking-soa-composite-as-part-of.html)

Scenario: Java client calls SOA Suite composite to process an order as part of a global transaction. The SOA composite is expose as an EJB service. The composite contains 1 BPEL process that itself calls an EJB service to update our Orders DB.

I'm using SCOTT's schema and have already created a datasource on WLS for it.

name: scottDS
jndi: jdbc/scottDS

Step 1. Create DB Table - test
Create table test (id number(2), quantity number(2));
Step 2. Create a stateless session EJB to update this table
create a new application/project in JDev and include a statelsss session EJB 2.1

Step 2.1 - Add the following business method

public String callDB(int id, int quantity) {
Connection connection = null;
DataSource dataSource = null;

try
{
/*
* 1. Create an InitialContext.
* 2. From the initial context, lookup the logical datasource reference that is in the deployment descriptor.
*/
InitialContext initialcontext = new InitialContext();
dataSource = (DataSource)initialcontext.lookup("jdbc.scottDS");

System.out.println("***** Got Datasource...");
// Check to see if the datasource is valid
if(dataSource==null){
System.err.println("*** DataSource retrieved is null, did you add the code?");
throw new ServletException("DataSource retrieved is null");
}
connection = dataSource.getConnection();
Statement stmt = connection.createStatement();
String insert = "insert into test values(" + id + "," + quantity + ")";
System.out.println("INSERT = " + insert);
stmt.executeUpdate(insert);

ResultSet rset = stmt.executeQuery("Select to_char(sysdate) from dual");
while (rset.next()){
System.out.println("*** Date = " + rset.getString(1));
}

}catch (Exception e){

System.err.println("*** init() Exception, " + e.getMessage());
System.err.println(e);
}
return "Ok";
}

Step 3 - Deploy and view the JNDI tree
specify jndi name before deploying -

Step 4 - Create a new SOA App in Jdeveloper
Create a SOA Composite app
Add the ejb jar from the previous project to the apps classpath.
(We really only need the interface!)

Create the following input xsd

Create a synchronous BPEL process

Create an EJB reference

Wire up

Add the Invoke to the BPEL process

Add the required Assigns, before and after

Step 5 - Expose the composite as an EJB Service

Make InputOrder and OrderType serializable

Deploy and view in JNDI tree

Step 6 Create the EJB client in the SOA project
package demoejbtxsoa;

import java.lang.reflect.InvocationHandler;
import java.lang.reflect.Method;
import java.lang.reflect.Proxy;

import java.util.Hashtable;

import javax.naming.Context;
import javax.naming.InitialContext;
import javax.naming.NamingException;

import processorder.demo_ejb_tx_soa.demo_ejb_tx_soa_app.com.oracle.xmlns.InputOrder;
import processorder.demo_ejb_tx_soa.demo_ejb_tx_soa_app.com.oracle.xmlns.OrderType;
import processorder.demo_ejb_tx_soa.demo_ejb_tx_soa_app.com.oracle.xmlns.ProcessOrder;
import processorder.demo_ejb_tx_soa.demo_ejb_tx_soa_app.com.oracle.xmlns.ProcessResponse;

public class MyEJBClient {
public static void main(String [] args) throws Throwable {
try {
final Context context = getInitialContext();

Proxy proxy = (Proxy)context.lookup("ejb/SOAEJBService");

// preparing the method to be called on the remote EJB
Method method =
ProcessOrder.class.getDeclaredMethod("process", new Class[] {InputOrder.class});
InputOrder id = new InputOrder();
id.setId(23);
id.setCustName("NiallC");
id.setQuantity(7);
OrderType ot = new OrderType();
ot.setComments("Good Customer");
ot.setProduct("Oracle SOA Suite 11g");
ot.setProductGroup("FMW");
ot.setProductKey(new Long(12345));

id.setOrder(ot);

InvocationHandler handler = Proxy.getInvocationHandler(proxy);

ProcessResponse response = (ProcessResponse)handler.invoke(proxy, method, new Object[] { id });

} catch (Exception ex) {
ex.printStackTrace();
}
}

private static Context getInitialContext() throws NamingException {
Hashtable env = new Hashtable();
// WebLogic Server 10.x connection details
env.put( Context.INITIAL_CONTEXT_FACTORY, "weblogic.jndi.WLInitialContextFactory" );
env.put(Context.PROVIDER_URL, "t3://127.0.0.1:7001");
env.put(Context.SECURITY_PRINCIPAL, "weblogic");
env.put(Context.SECURITY_CREDENTIALS, "welcome1");

return new InitialContext( env );
}
}

Run the client and check the DB

Step 7 JTA enable...
Add the following code to the EJB Client -

import javax.transaction.UserTransaction;

public final static String JTA_USER_XACT = "javax.transaction.UserTransaction";

UserTransaction ut = (UserTransaction)context.lookup(JTA_USER_XACT);
ut.begin();

//ut.rollback();
ut.commit();

Define BPEL to participate in the global TX.

Add this property to BPEL specification in composite.xml

Test

commit()

rollback()

Composite Status in SOA Suite 11g console

2011-10-07T14:55:00.000-07:00

(From http://niallcblogs.blogspot.com/2009/10/composite-status-in-soa-suite-11g.html)

The Composite instance completes successfully however the state is not updated in the instance list? Then check that you have the following set.

BPEL - Checking input XML for optional elements

2011-10-07T14:38:00.000-07:00

(From http://niallcblogs.blogspot.com/2008/04/checking-input-xml-for-optional.html)

The scenario - Check whether the optional Title element is present in the input XML payload to the BPEL process. If it isn't present, then add it with the default value "DefaultValue".

The XSD -

The input XML -

I created a simple synchronous BPEL process with input and output variable set to outputCustomerData. I added a transform activity.

The following will check whether the element is present and set the default value, if necessary.

BPEL - Debug Logging using Sensors – Part 1

2011-10-07T14:23:00.000-07:00

(From http://technology.amis.nl/blog/3326/debug-logging-in-bpel-using-sensors-part-1)

When developing and/or debugging BPEL processes, the Oracle BPEL Console is your best friend. Every change to every variable, every activity that was executed, everything is right there for you to inspect, whether the instance is still in-flight or already completed. But although this sounds like the ultimate debugging tool, I’m sure you’ve noticed like me that when your processes get really big (which they tend to do rather quickly), there’s two reasons why debugging can be difficult. The first is plain and simple “information overload”. If your audit flow contains hundreds of activities and possibly thousands of variable data changes, finding an individual piece of information is not trivial. I find the second reason, however, to be of even more profound impact: the BPEL console will not show you the execution path through your process flow (which would indicate which parts of the code got executed, and which didn’t), but rather it displays a long, sequential list of Activities that were executed. Especially if you have a lot of switch and/or pick statements, and if your code contains loops (in which case each iteration will add all executed Activities to the list), determining “what happened” during execution of your instance from this long, long audit trail might prove a challenge.

In a “mini-series” of Blog entries, I will share a number of techniques that I have used in situations like this, to extract logging/debug information from a BPEL process instance using BPEL Sensors. This first entry will focus on a simple, straightforward form of logging, using a “Variable Sensor” to provide a sort of “management summary” of the execution of a BPEL process instance.

Using Sensors for Logging and Debugging

BPEL Sensors can be very useful to extract information from the execution of a process. Basically, they come in three flavours: Activity Sensors, Fault Sensors and Variable Sensors. The first type is ideal to have a BPEL process trigger “events”, as you can configure them to “fire” when individual Activities in your process get executed. You even get to specify if they need to fire on activation (i.e. before the Activity is executed), on completion, on faults, when compensation is invoked, or on all these events. Finally, you can pass any amount of process data along to it, allowing the “Sensor Action” associated with the Sensor to use that information, for instance by posting it on a queue, storing it in the database, sending it to a BAM server, or invoking custom Java code with it.

Sometimes I use Activity Sensors for debugging purposes, by adding them to critical activities that determine process behavior, and adding process variables to them so that I can see those bits of information that were crucial at that particular moment in process execution. This is a very powerful method and I will show some examples in future Blog entries, but often, my needs are more simple, and all I really need is a BPEL equivalent of a good old Log4J statement in Java code:

log.debug(‘Entering Order line loop, with ‘+orderlines.size()+’ order lines’);

Simple logging using Variable Sensors

Configure Sensors for Logging purposes

To incorporate Sensor based logging in our process, there are two tasks to perform. The first part is configuration. You only need to do this once for the entire process. In terms of Log4J, it would compare to the code at the top of the class, defining the "log" variable that we can write to.

Log log = LogFactory.getLog(this.getClass());

In fact, this is incredibly similar to what we will do in BPEL! We also start by adding a variable, “LogMessage”, to the process, and then we add a Variable Sensor to it that will process all changes that are made to it. To get started, click on the “Variables” icon on the process diagram (x) (see screenshot below).

For simple logging like this, where the log messages are just simple strings, the “Variable Sensor” comes in handy. This type of Sensor is triggered every time a change is made to a process variable. So, unlike Activity Sensors where you need to specify exactly where in the process flow you want that sensor to fire, with Variable Sensors you only define it once and it fires automatically each and every time in your process when changes are made to the process variable it is assigned to. So basically, to get some simple debug logging going, all you need is to create one “Log” variable, add a Variable Sensor to it, and just by assigning a new value to it anywhere in the process where you need logging, the Sensor fires and processes the value of the variable.

So, how does this work? As an example, let’s take the BPEL process flow below. This is a simple demo flow and, as mentioned before, for simple flows the BPEL Console works perfectly well all by itself. Just imagine this is part of a much bigger process, and you would need to figure out what happened in this part of the flow by inspecting hundreds of audit trail entries.

In the window that pops up, create a new Variable called “LogMessage”, of type xsd:string.

Click “OK” to close this window, then select the newly created “LogMessage” variable and click on the “Edit” button:.

Select the “Sensors” tab, and press the “Create” button to create a Variable Sensor:.

Name the sensor “LogSensor”, and use the little icon on the right of the “Target” field to select the “LogMessage” variable. It’s kinda weird you need to do this since you entered this window from the “Edit Variable – LogMessage” window, but oh well….

A Sensor is like a trigger definition that indicates _when_ it fires. But in order to make it _do_ something, you’ll need to tie it to a “Sensor Action”. In PL/SQL terms, a “Sensor” is like a table trigger that invokes a PL/SQL procedure, and the “Sensor Action” is the procedure that it invokes. The Sensor Action (procedure) can therefore be re-used by many Sensors (triggers).
You can create a Sensor Action within the current dialog, by clicking the “Add” button in the “Sensor Actions” section. In the “Sensor Action Chooser” you can pick previously defined Sensor Actions, but since we have not created one yet, we’ll do that now. Notice that there are two flavors to choose from: BAM Sensor Actions, and regular “Sensor Action”. Choose the latter..

In the dialog that pops up, call the Sensor Action “LogAction”, and leave “Publish Type” to “Database”. This means that the Sensor events (including their data) will be written to a pre-defined database tables in the BPEL dehydration store. In this case (this being a Variable Sensor), that table is “VARIABLE_SENSOR_VALUES”. Unfortunately, you can NOT define your own table. But for debug logging purposes like ours this is ideal, especially since the BPEL console has maintenance facilities to clean up this table. In fact, as you’ll see later, there is not even any need to query this table, as its contents will be shown in the BPEL Console when inspecting the process instance..

Press OK, and see how the newly created LogAction is tied to the LogSensor on the LogMessage variable. Also notice you could have multiple Sensor Actions could be tied to a single LogSensor, allowing you, for instance, to write to the database AND post to a JMS queue..

OK this dialog, and see the summary: You have a LogMessage variable, with a sensor called “LogSensor” on it, which is tied to the “LogAction” Sensor Action (which will publish to the database).

This concluded the configuration part. Although it may seem like a lot of work the first time, I promise that this takes under a minute once you’ve done this a few times. And, remember, you only need to do this once for the entire process. The actual "log statements" are far simpler to create, as we’ll see next.

Adding "Log statements" to your Process

What we have now is a LogMessage variable which is “rigged” so that every change to it will automatically be published to the database (and, as you will see later, is also automatically visible in the BPEL console). All we need to do now is start creating our "log statements" in the BPEL process. This simply means: assigning values to the “LogMessage” variable at places in your process flow that currently interest you.

You can add new Assign activities to your process to do this, or just add Copy Operations to existing Assigns activities in your process. In the “Assign” dialog, select the LogMessage variable on the right (notice the cool “sensor” icon to the left of it), and (typically) the ‘Expression’ type on the left. You could log simple strings by just typing something like ‘Hello, this is debug logging’ (don’t forget the single quotes), or use the Expression Builder to mix your log statements with dynamic values (typically with the ‘concat’ statement, with which you can concatenate an arbitrary number of strings, separated by commas).

Below is the result of adding a simple, static log statement to an existing Assign activity:.

The Result

Now I’m sure you are wondering where this logging turns up after initiating a process instance. Well, our “LogAction” Sensor Action published to the database, but fortunately you won’t have to go to the database and query that table to retrieve the logging information. When looking at the Flow of an individual instance in the BPEL Console, one of the tabs reads “Sensor Values”. Below, you can see the result from adding some log statements to the Process we started out with.

So there you have it. Simple, log4J style logging that requires just a little setting up at Process level, and then simply some Copy rules to a single “LogMessage” variable to create logging that is conveniently accessible from the BPEL console.

Cleaning up

To wrap things up: how to clean things up after you’re done debugging. When you no longer need your log statements, there’s a couple of things to do. First, you can purge all sensor values from the BPEL tables, by going to the “Instances” tab in the BPEL Console and clicking the “Purge All Sensor Data” button. Then, in JDeveloper, have some options. You can:

Disable logging for now (but you might want to turn it back on later)
To do this, simple delete the LogSensor from the LogMessage variable. The LogMessage variable and log statements remain in your code but will take hardly any time during execution, and no sensors will fire (and therefore no database activity to the sensor tables will take place). All you need to do to turn logging on again at a later point is recreate the LogSensor and assign it to the LogAction (which will still be there).
Remove all trace of logging
- Delete the LogMessage variable from the BPEL process.
- Rebuild the process and notice the compilation errors. Clicking on them will lead you to all the Copy operations where you wrote to the LogMessage variable. If this is the only operation in the Assign, remove the assign, otherwise just remove the Copy operation.
- Rebuild the process to make sure you’ve gotten rid of them all.

That it for now. In the next part, I will show how you can use Activity Sensors if using a simple xsd:string as log message does not suffice, and you need more information about the BPEL process state in your log. In the third (and probably final) part, I will show how you can use a custom Java SensorAction, to be able to use the Log4J logging framework to deal with your log messages.

BPEL - Access the variables in embedded Java (2)

2011-10-07T14:06:00.000-07:00

How do you call getVariableData() if you have to accept a string value from the client and process it further in a Java code.

Problem:
I have used the following syntax -
String firstName = ((Element)getVariableData(“inputVariable”, “payload”, “/client:myBPELProcess/client:input”)).getNodeValue();

firstName is always coming out to be a null value even though I pass the input value as string say “test”(after deployment of the BPEL process).

If I am calling getNodeName() instead then it is correctly giving me the right node as “ns1:input”, but it seems getNodeValue() is having some problems.

Anwser:
The payload is a text element and the value is for the text element.

String firstName = ((Element)getVariableData( “inputVariable”, “payload”, "/client:myBPELProcess/client:input”)).getFirstChild().getNodeValue();

Embedding Java in BPEL process

2011-10-07T14:03:00.000-07:00

(From http://technology.amis.nl/blog/2387/embedding-java-in-bpel-process)

Oracle BPEL has a special Activity called "Java Embedding", that allows you to include some "inline" Java code into a BPEL process. Unfortunately, you don’t get Java type-in support in the editor behind the Java Embedding activity, which makes coding a lot more difficult. Furthermore, it is not straightforward to find out what kind of methods are available for you to invoke. When I recently had to use a Java Embedding myself, I found a way to work around this and learned some interesting things about the methods available to you when writing embedded Java code into a BPEL process.

For starters, to find out where my embedded code ends up at runtime, I put the following, simple statement in a "Java Embedding":

System.out.println("Java Embedding superclass: "+this.getClass().getSuperclass().getName());

This told me that the class that the BPEL compiler creates for this Java embedding extends "com.collaxa.cube.engine.ext.BPELXExecLet", which can be found in orabpel.jar. This is an abstract class, with an abstract "execute()" method, and the code in this method is the code that you provide in the Java Embedding editor. Unfortunately, there is no Javadoc available for this class but there is Javadoc for its superclass (BaseBPELExecLet, click on the link to see the Javadoc).

With this knowledge, it is easy to create a temporary Java class where we can create the code for the Java Embedding activity with full type-in support. My advice would be to create it in a separate JDeveloper project. Add the "BPM Workflow" library to it (Project Properties => Libraries), and create a new Java class that extends the BPELXExecLet class. You’ll need to implement the abstract "execute" method, and here you can create your Java code with full type-in support. When you’re done, you can copy-paste the logic inside the execute method to the editor of the Java Embedding in your BPEL process. There is only one caveat: when your typing code you should not use Alt-Enter to create imports in your Java class; you should always use fully qualified class names or the BPEL compilation process will fail later.

Using type-in support (type this. and wait for a while or press CTRL-space if you are in a hurry, or CTRL-ALT-space if you are in a hurry _and_ want only smart suggestions), a number of interesting methods appear which can be invoked from your code. Some especially useful methods that I have used in the past are:

•checkpoint(): forces dehydration.
•setIndex(int i, String s): stores the value of String s in CI_INDEXES, a table in the dehydration store with the current instance id as PK, and six "index" columns in which you can store data. Typically used to enable you to correlate a unique key for the process in the user domain with the technical BPEL instance ID, for track&trace purposes.
•getVariableData(): equivalent of bpws:getVariableData() in BPEL process, gives access to any data in the BPEL process
•setVariableData(): equivalent of bpws:setVariableData() in BPEL process, allows you to change any data in the BPEL process
•addAuditTrailEntry(): puts a log message in the Audit trail
•getInstanceId(): gets the current instance id
•getParentId(): gets the instance id of the BPEL process which invoked the current process
•getRootId(): gets the instance id of the first BPEL process in the calling chain
•getPreference(): gives access to descriptor properties.

But this is just a brief summary, there are many more methods you can invoke. One last method at your disposal that is very powerful is: getLocator(). With the com.oracle.bpel.client.Locator this method returns, you get access to pretty much anything in the BPEL Domain, and one thing you might want to do is to get access to the current BPEL process instance. I ran across this situation where I needed the name of the BPEL process to which the current instance belonged, and although many attributes of the current instance are available through methods in the BPELXExecLet superclass, the ProcessId is not one of them.

The code to obtain a handle to the current BPEL instance using the Locator would look something like this:

String instanceId = Long.toString(this.getInstanceId());
// Define variables to use;
com.oracle.bpel.client.IInstanceHandle instance;
com.oracle.bpel.client.IInstanceHandle[] instances;
com.oracle.bpel.client.util.WhereCondition cond;

// Set the whereclause
cond = new com.oracle.bpel.client.util.WhereCondition( "cikey = ?" );
cond.setLong(1, this.getInstanceId());

// Perform the query using the Locator
instances = this.getLocator().listInstances(cond);
instance = instances[0];

// Store the name of the BPEL process in the CI_INDEXES table
setIndex(1, instance.getProcess().getProcessId().toString());

Unfortunately, the code above will fail to find the instance if it has not yet been persisted to the dehydration store. Of course, a call to this.checkpoint(); at the beginning of this code could easily fix that, but this has performance implications.

While trying to find a solution to this problem, I had a feeling that since so much attributes of the current instance _are_ available through superclass methods, it should be possible to obtain the current process instance without performing a query through the Locator. With this in mind, I came across yet another intriguing method in the BPELXExecLet class: getFromEnvironment(String key). Some debugging code later I had found my answer: when using the key "__cube-instance", I could obtain an instance of com.collaxa.cube.engine.core.ICubeInstance, which allowed me access to the ProcessId I needed:

com.collaxa.cube.engine.core.ICubeInstance instance;
instance = (com.collaxa.cube.engine.core.ICubeInstance)getFromEnvironment("__cube-instance");
setIndex(1,instance.getProcessId());

Shorter, better performance because 1.) no query needed and 2.) no (additional) dehydration needed, so as long as they don’t change that funky key this’ll do nicely ;-)

This last bit was specific to one particular problem I had to solve recently, but I hope that the first part of this post contains some information that might be of value when you create your own Java Embeddings in a BPEL process.

BPEL - Get a value from array of element in a loop.

2011-10-05T14:45:00.000-07:00

In a loop, the counter is a incremental value with the loop.

Directly use the variable to get the value of specific postion in the array in BPEL 2.0.
$inputVariable.payload/client:input[$counter]

Use XML manipulatioin in BPEL2.0.
ora:getElement('inputVariable', 'payload', '/client:process/client:input', $counter)

BPEL - Access the variables in embedded Java

2011-10-05T12:15:00.000-07:00

(From http://niallcblogs.blogspot.com/2008/01/bpel-embedded-java.html)

try{
    String status = "Bronze";
    /* accessing a process variable of type string */
    String country = (String)getVariableData("v_country");

    /* accessing a variable within the complex type - customer */
    Element country1 = (Element)getVariableData("inputVariable", "payload","/ns1:customer/ns1:Country");

    String c1 = country1.getTextContent();

    /* writes to the audit trail - will then be visible in BPEL console at runtime*/
    addAuditTrailEntry("country is: " + country);
    addAuditTrailEntry("country1 is: " + c1);

    if (country.equalsIgnoreCase("Ireland")){
        status = "Gold";
    }

    /* setting the output variable within the complex type - customer */
    setVariableData("outputVariable", "payload", "/ns1:customer/ns1:Status", status);

    addAuditTrailEntry("status is: " + status);
}catch (Exception e) {
    addAuditTrailEntry(e);
}

Add the following line before the bpelx:exec tag to import the Element class
<import location="org.w3c.dom.Element" importType="http://schemas.oracle.com/bpel/extension/java"/>

Calling an external Java class in a Java activity
Jar up the Java class you want to use and copy the jarfile to the BPEL
system\services\lib directory.
In this example, my class is called CustomerStatus

try{
    String status = "Bronze";
    String country = (String)getVariableData("v_country");
    Element country1 = (Element)getVariableData("inputVariable", "payload","/ns1:customer/ns1:Country");
    String c1 = country1.getTextContent();
    addAuditTrailEntry("country is: " + country);
    addAuditTrailEntry("country1 is: " + c1);

    CustomerStatus cs = new CustomerStatus();
    status = cs.getStatus(country);
    setVariableData("outputVariable", "payload", "/ns1:customer/ns1:Status", status);

    addAuditTrailEntry("status is: " + status);
}catch (Exception e) {
    addAuditTrailEntry(e);
}

Add any classes needed to import using <import/>.

Oracle SOA Suite 11g - How to use its native logging mechanism

2011-09-27T08:53:00.000-07:00

(From http://mazanatti.info/index.php?/archives/48-SOA-Suite-11g-how-to-use-its-native-logging-mechanism.html)

If you ever wondered how to generate log messages inside SOA Suite's logging files (diagnostics.log), here are the directions.

From JDeveloper, with a BPEL flow opened, do this:

■Insert some imports at the top of the source (first ones inside process tag):
<bpelx:exec import="java.util.logging.Logger" />
<bpelx:exec import="java.util.logging.Level" />
<bpelx:exec import="oracle.fabric.logging.LogFormatter" />

■Insert a Java Embedding action with the following code:
Logger logger = Logger.getLogger("oracle.soa.Logger");
LogFormatter.configFormatter(logger);

logger.log(Level.INFO, "some message");

That's it, basically. The trick is to configure the logger instance using SOA Fabric's LogFormatter.

To avoid doing these steps every time you need to log something, you can use a class.
■Create a new Java Class inside your composite project, with the code below:
package info.mazanatti.soa;

import java.util.logging.Level;
import java.util.logging.Logger;
import oracle.fabric.logging.LogFormatter;

public class CustomLogger() {

private static final Logger logger = Logger.getLogger("oracle.soa.Logger");

static {
LogFormatter.configFormatter(logger);
}

public static final void log(String message) {
logger.log(Level.INFO, message);
}
}

■Call the function from your Java Embedding actions:
info.mazanatti.soa.CustomLogger.log("some message");

After building, deploying and running your process, this is what you're going to see from Enterprise Manager's Log page.

Here's the JDeveloper project using both methods: LoggingBPEL.zip. This code has "info.mazanatti.Logger" instead of "oracle.soa.Logger" as showed above. If you want to know why, keep reading this post :-)

There's one detail you may have seen that deserves some explanation: I passed a specific package and class (oracle.soa.Logger) in order to retrieve a logger instance. I did this 'cause this package is configured by default when installing the product, and this releases us of some configuration.

But, if you want to use a specific log level for your messages without messing with anything else, the best way to do so is to define a new package and configure it accordingly. Here's how.

Define the package you want to use. I'm going with "info.mazanatti".
Locate the file logging.xml of your server and open it. Inside the domain folder, navigate to /config/fmwconfig/servers/server_name.

Warning: you have to configure the logging.xml file of each SOA instance (server). Not the most cluster-friendly procedure, but that's the way it is.
Include a XML block like this, specifying your package and the lowest log level you want:

</logger>

Start your domain

Meanwhile, go back to JDeveloper and change the getLogger parameter (hint: the class doesn't need to exist, only the package name is actually used):
Logger logger = Logger.getLogger("info.mazanatti.Logger");

LogFormatter.configFormatter(logger);

logger.log(Level.INFO, "some message");
Deploy the process to the server, and it's done.

The odl-handler mentioned above is the one that writes to diagnostics.log. There are other handlers, but I'm not getting into them - if you want, take a look at the log_handlers block inside logging.xml to figure out what the other handlers do ;-)

And here's the list of log levels and its relation to java.util.logging.Level, in case you want to use values other than Level.INFO:

 logging.xml java.util.logging.Level
 INTERNAL_ERROR:1 SEVERE.intValue()+100
 ERROR:1 SEVERE
 WARNING:1 WARNING
 NOTIFICATION:1 INFO
 NOTIFICATION:16 CONFIG
 TRACE:1 FINE
 TRACE:16 FINER
 TRACE:32 FINEST

Since we're here, a little extra bit of information: to view the logging configuration, you must open Enterprise Manager and navigate to "Log Configuration", as showed below.

Then, a page with data from the logging.xml file will be presented.

If you're not seeing your package listed, don't worry. It will not show up here, ever. Can't say why, but know that the configuration is saved and effective. In case you want to change the log level of your custom package, you don't have to edit the xml files again.

At this page, select the option "Loggers with Persistent Log Level State" from the "View" dropdown

At the bottom of the new page, a section called "Specify Loggers" will show up. Type your package name and select the new Level, then click "Apply" at the top of the page

Take a look at your logging.xml file, the new value will be there.
Again, here's the source code: LoggingBPEL.zip.

Oracle SOA Suite Log File Rotation

2011-09-27T08:40:00.000-07:00

(From http://blogs.oracle.com/kavinmehta/entry/soa-suite-log-file-rotation)

In <ORACLE_HOME>/opmn/conf/opmn.xml, apply the following changes for each OC4J you want to modify log file settings

•Add -Dstdstream.filesize=FILE_SIZE_IN_MB -Dstdstream.filenumber=TOTAL_NO_OF_FILES parameters in the <java-options>. For example, if you want to limit log file size to 10MB and total number of files to be created to 10 than add
-Dstdstream.filesize=10 -Dstdstream.filenumber=10

•Add -out and -err parameters to the <oc4j-options> to specify standard output and standard error log files.
-out $ORACLE_HOME/opmn/logs/soa_log.out -err $ORACLE_HOME/opmn/logs/soa_log.err

Apply the changes and restart OC4J. If you are just restarting OC4J make sure to reload opmn before restarting.

After restart you should be able to see log files soa_log_YYYY_MM_DD_HH_MI_SS.out and soa_log_YYYY_MM_DD_HH_MI_SS.err created under $ORACLE_HOME/opmn/logs/<oc4j_name>_<group_name>_<jvm_id> folder

Using Oracle SOA Suite Command-Line Upgrade Tool to merge Multiple BPEL Projects Into a Single Composite

2011-09-27T08:37:00.000-07:00

(From http://blogs.oracle.com/kavinmehta/entry/using_oracle_soa_suite_command)

Most important benefit of using command line tool is the ability to merge multiple projects (BPEL, ESB) in to single composite.
Required ANT build files are located under
<JDEV_HOME>\bin
OR
<FMW_SOA_HOME>\bin
Since my machine has got both, i have used FMW_SOA_HOME as ORACLE_HOME

Set SOA Environment using soaversion.sh (.cmd) located under ORACLE_HOME/bin directory
Run the Ant project from ORACLE_HOME/bin directory, as follows:

ant -f ant-sca-upgrade.xml -Dsource sourceDir -Dtarget targetDir -DappName app_name

To combine multiple BPEL projects into a single composite, provide multiple source directories as part of the -Dsource property on the command line. Use colon (:) or a semicolon (;) as path separators. Also use double quotes to identify the multiple source directories to prevent Ant from parsing the input in an unexpected manner

ant -f ORACLE_HOME/bin/ant-sca-upgrade.xml -Dsource "sourceDir1:sourceDir2" -Dtarget targetDir -DappName app_name

This way you will see your multiple projects created under one composite

Oracle BPEL Fault Policy Framework handling custom business faults

2011-09-27T08:34:00.000-07:00

(From http://www.xenta.nl/blog/2009/02/14/oracle-bpel-fault-policy-framework-handling-custom-business-faults/)

From the Oracle forum and from the comments on my article about Oracle BPEL Fault Policy Management i get a lot of questions about how to let the framework handle my own custom defined ‘business faults’.
In certain situations the default set of faults defined by Oracle aren’t suited enough and you need to define your own faults.
If we look into the examples which got supplied by Oracle we can see an example over here. In this example they defined their own NegativeCredit-fault.
The Oracle BPEL Fault Policy Framework by default only handles the faults which are getting returned on an invoke-activity.
So we have our own custom fault and the knowledge we can only let this fault getting catched by the framework by use of an invoke.
So we need atleast for this testscenario 2 bpel processes. One mainprocess which calls a subprocess, and this subprocess will throw the custom business fault.
This fault will get propogated back to the mainprocess and in here we will be able to let the framework handle the fault.

BPEL Processes
Mainprocess

Subprocess

Just a simple invoke of the subprocess from the mainprocess. The subprocess with throw a fault, and this fault will be catched in the mainprocess.

The fault to be thrown
From the console start the mainprocess and wait till it comes back with a fault message

Click the activity to see the thrown fault

"{http://nl.iteye/integration/faults/business}BusinessFault" has been thrown.

<businessFault xmlns="http://nl.iteye/integration/faults/business">
<part name="payload">
<businessFault xmlns="http://nl.iteye/integration/faults/business">
<faultCode>999</faultCode>
<faultMessage>Something went wrong!</faultMessage>
</businessFault>
</part>
</businessFault>

Ok nice!
So the custom fault we defined in the subprocess reaches the mainprocess.
Now we need to config the fault policy framework so it will get active on our custom business fault.
From the fault we pasted above we need the faultname (BusinessFault) and the namespace (http://nl.iteye/integration/faults/business).
Edit /bpel/domains/default/config/fault-policies/DefaultPolicy.xml and add the next fault :

<faultName xmlns:flt="http://nl.iteye/integration/faults/business" name="flt:BusinessFault">
<condition>
<action ref="ora-human-intervention"/>
</condition>
</faultName>

For testing we will just let this fault getting handled by human-intervention.
Now restart the components
opmnctl stopall
opmnctl startall
Now start the mainprocess again and wait till it fails.
It looks like the framework got active (activity yellow marked) on our custom business fault.

Go to the activities-tab

And click the activity which faulted.

Now we can edit some of the values and let the subprocess get re-invoked.
So, at this moment we’re able to throw our custom business faults and let them getting catched by the framework. Since the fault is only getting catched on the invoke of a partnerlink, we aren’t able to let our custom business fault getting throwned to the process in which we maybe want do something with the data for which we actually throwed the custom business fault. So maybe we want to stay in the subprocess and somehow get the custome business fault thrown inhere, let the framework catch it and update the values of this subprocess with new values an re-execute the subprocess.
The next solution will get this done.
The mainprocess won’t get changed but in the subprocess we will invoke a new process called AllBusinessFaults.
New subprocess 2

AllBusinessFaults

The AllBusinessFaults will throw the custom business fault we ‘request’ back on the invoke in this subprocess. Now it wil get catched by the framework and we will be able to change the values of the subprocess instead of the mainprocess.

By using the AllBusinessFaults bpel service like a sort of composite service, we can add the custom business faults in it and throw the one we would like to get thrown. This will work if the collection of custom business faults isn’t that big. I’m sure there will be better solutions for this, but for the scenario i wanted to describe inhere it was good enough for me.
Question
In the examples i provided i don’t use the fault-part of a synchronous invoke to propegate the soap-fault back to the caller, i just throw the fault. The bpel engine itself throws the fault back to the first-level. Whats best practice on this one ?
Sources
BPEL Sources (First part of article with mainprocess/subprocess)
BPEL Sources (Second part of article with mainprocess/subprocess/allbusinessfaults)
Resources
Oracle BPEL 10.1.3.3 Fault Policy Management

Complete Installation and configuration of Oracle Data Integrator (ODI), ODI Web Services with JDeveloper, BPEL

2011-09-27T08:27:00.000-07:00

(From http://blogs.oracle.com/kavinmehta/entry/complete_installation_and_conf)

Installing Oracle Data Integrator, Oracle Data Profiling, Oracle Data Quality

Click on setup.exe . Click Next

Check "Oracle Data Integrator, Oracle Data Profiling, Oracle Data Quality 10.1.3.5.0" and click next

Check "Complete" and Click next

Specify ODI Home name and location. Click Next

Specify port, click Next

Specify host name and ports, I left them at default ones.

Again left at default one

Check summary and click Install

Configuring Repository

After install is finished execute the script to create master and work repository user. You can use the one I did

-- tablespace for master repository
create tablespace ts_odim
logging
datafile 'C:\oracle\ora10g\database\oradata\orcl\ts_odim.dbf'
size 32m
autoextend on;
-- tablespace for work repository
create tablespace ts_odiw
logging
datafile 'C:\oracle\ora10g\database\oradata\orcl\ts_odiw.dbf'
size 32m
autoextend on;
create temporary tablespace tmp_odi
tempfile 'C:\oracle\ora10g\database\oradata\orcl\tmp_odi.dbf'
size 32m
autoextend on ;
-- USER SQL
CREATE USER snpm IDENTIFIED BY snpm123
DEFAULT TABLESPACE TS_ODIM
TEMPORARY TABLESPACE TMP_ODI;
GRANT CONNECT, RESOURCE TO snpm;
CREATE USER snpw IDENTIFIED BY snpw123
DEFAULT TABLESPACE TS_ODIW
TEMPORARY TABLESPACE TMP_ODI;
GRANT CONNECT, RESOURCE TO snpw;

Launch bin/repcreate.bat or bin/repcreate.sh to create Master Repository. Complete fields and click OK

When prompted, click OK

To connect to the Master repository launch the Topology Manager script (bin/topology.bat or bin/topology.sh)
Click on the button New

Click on Test to check the connection is working. Validate by OK, then OK. Topology Manager opens.

The default password of the SUPERVISOR is SUNOPSIS.

In the icon list Topology -> Repositories -> Work repositories, click with the right button,
then choose Insert work repository.

In the connection window, complete the parameters and click OK

Click JDBC tab

New Work Repository can be seen in topology manager now

To connect to a work repository and launch the Designer module

Click on the button New

Complete the fields, test connection and click ok

Now connect to work rep using SUPERVISOR/SUNOPSIS

New Designer window will open up for current repository

Deploying ODI Web Applications - Lightweight Designer

Open Enterprise Manager console
Click oc4j_odi - Applications - Deploy
Browse to location <ODI_DOWNLOAD_DIR>\setup\Manual and select oracledilwd.war file (Lightweight Designer)

Click Next

Accept default values, click Next

Click Deploy

Check deployment report for any errors and click Return.

Test Application at http://oc4j_host:oc4j_port/oracledilwd/

Configuring Repository Connections

Lightweight Designer connects the repositories though JDBC datasource. Update data-sources.xml to have connection pool and datasources configured as below.

<managed-data-source user="snpm" password="snpm123" connection-pool-name="ODI_CONNECTION_POOL" jndi-name="jdbc/ORACLE_MASTER" name="ODI_MASTER_DS"/>
<managed-data-source user="snpw" password="snpw123" connection-pool-name="ODI_CONNECTION_POOL" jndi-name="jdbc/ORACLE_WORK" name="ODI_WORK_DS"/>
<connection-pool name="ODI_CONNECTION_POOL">
<connection-factory factory-class="oracle.jdbc.pool.OracleDataSource" url="jdbc:oracle:thin:@//localhost:1521/orcl"/>
</connection-pool>

Add the entries to link the datasource in the application context. Edit web.xml located under <OC4J_ODI>\applications\oracledilwd\oracledilwd\WEB-INF\web.xml

<resource-ref>
<description>Oracle Datasource for the Master Repository</description>
<res-ref-name>jdbc/ORACLE_MASTER</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Unshareable</res-sharing-scope>
</resource-ref>
<resource-ref>
<description>Oracle Datasource for the Work Repository</description>
<res-ref-name>jdbc/ORACLE_WORK</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
<res-sharing-scope>Unshareable</res-sharing-scope>
</resource-ref>

Define the Lightweight Designer login information to the work repositories. Edit repositories.xml located under <OC4J_ODI\applications\oracledilwd\oracledilwd\

<login name="My Work Repository"> <master name="jdbc/ORACLE_MASTER" masterDriver="oracle.jdbc.OracleDriver"/>
<work name="jdbc/ORACLE_WORK" workName="WORKREP"/>
</login>

Deploying ODI Web Applications - Metadata Navigator

Click oc4j_odi - Applications - Deploy

Browse to location <ODI_DOWNLOAD_DIR>\setup\Manual and select oracledimn.war file (Metadata Navigator). Click Next

Accept defaults, click Next

Click Deploy

Check deployment report for any errors and click Return.

Test Application at http://oc4j_host:oc4j_port/oracledimn/

Configuring Repository Connections

To configure the connections to your repositories in the web application, we need to follow two steps.

Configure the connection to the work repository in Designer.
Copy the snps_login_work.xml file from <ODI_HOME>\oracledi\bin directory into <OC4J_ODI>\applications\oracledimn\oracledimn\WEB-INF/WEB_INF

Configuring Apache Axis 2 (ver 1.2)

Download Axis 1.2 WAR file from http://ws.apache.org/axis2/download/1_2/download.cgi. It would be a zip file download, simply rename it to axis2.war
Click oc4j_odi - Applications - Deploy

Provide WAR file location and click next

Provide WAR file location and click next

Provide WAR file location and click next

Provide WAR file location and click next

Provide WAR file location and click next

Access Axis application at http://oc4j_host:oc4j_port/axis2/axis2-web/index.jsp

Click on the Validate button, the happy axis page will appear: http://oc4j_host:oc4j_port/axis2/axis2-web/HappyAxis.js
Click on the Administration link will take you to http://oc4j_host:oc4j_port/axis2/axis2-admin the default username/password are: admin/axis2

Deploy odi-public-ws.aar located under <ODI_DOWNLOAD_DIR>\oracledi\tools\web_services using the "Upload Service" link or drop into webapps/axis2/web-inf/services directory

Deployment confirmation page showing success (or in cases will show errors)

Copy odiInvoke.wsil from <ODI_DOWNLOAD_DIR>\oracledi\tools\web_services to <OC4J_ODI>\applications\axis2\axis2\axis2-web\OdiInvoke.wsil

Change Location attribute from
location="./services/OdiInvoke?wsdl"
to
location="/axis2/services/OdiInvoke?wsdl"

Configuring JDeveloper

To show local WSIL registry uncomment External Source for WSIL lcoated under <JDEV_HOME>\integration\bpm\designer\config\serviceexplorer_plugin.xml

Create inspection.wsil manually to the same directory where serviceexplorer_plugin.xml is located. <JDEV_HOME>\integration\bpm\designer\config\inspection.wsil

<?xml version="1.0"?>
<inspection xmlns="http://schemas.xmlsoap.org/ws/2001/10/inspection/"
xmlns:wsilwsdl="http://schemas.xmlsoap.org/ws/2001/10/inspection/wsdl/">
<link referencedNamespace="http://schemas.xmlsoap.org/ws/2001/10/inspection/"
location=:/axis2/axis2-web/OdiInvoke.wsil">:/axis2/axis2-web/OdiInvoke.wsil">:/axis2/axis2-web/OdiInvoke.wsil">:/axis2/axis2-web/OdiInvoke.wsil">:/axis2/axis2-web/OdiInvoke.wsil">:/axis2/axis2-web/OdiInvoke.wsil">http://<host>:<port>/axis2/axis2-web/OdiInvoke.wsil>
<abstract>Oracle Data Integrator Public Web Service</abstract>
</link>
</inspection>

Restart JDeveloper and you should be able to see service in "Service Explorer". You can now use it with BPEL, AIA, OSB or any other service aware application.

WLI Database Event Generator and the Oracle Database Adapter

2011-09-08T08:55:00.000-07:00

WLI Database Event Generator and the Oracle Database Adapter

WLI File Control and the Oracle File Adapter

2011-09-08T08:52:00.000-07:00

WLI File Control and the Oracle File Adapter

Configure a SOAScheduler for a Composite in SOA Suite 11g

2011-09-08T08:50:00.000-07:00

http://www.oracle.com/technetwork/middleware/soasuite/learnmore/soascheduler-186798.pdf

Working with Transactions

2011-09-08T08:42:00.000-07:00

(From http://www.oracle.com/technetwork/articles/soa/wli-bpel-transactions-088255.html)

Introduction

Transactions have always been the center of the universe when designing any application. Transactions were easier to define and manage back when developers could to control them through code. The options may have been limited, but developers knew what to expect.
Over the last decade, through the advent of Java 2 Enterprise Edition (J2EE) and other technologies, developers were encouraged to leave transactions to the container. But for developers with a limited understanding of container-based services, this can present an obstacle.
Things can get even worse when transaction demarcations are created automatically within the container, leaving developers with a very limited understanding of what is happening.
This article is an effort to unlock the mysteries of the container-managed and container-defined transactions within WebLogic Integration (WLI) and Oracle BPEL Process Manager (BPEL PM).
A common misconception about Oracle BPEL Process Manager is that it does not support global XA transaction groups. The likely cause of this misconception is that unlike WLI, BPEL PM includes no activity specifically labeled "start transaction" or "stop transaction." Instead, a transaction group is implicitly delineated, based on the types of activities involved.
Let's start with a very simple WLI transaction example to see how it can be implemented in BPEL PM. After that we'll deal with more advanced topics, such as compensating transactions.

A simple transactional process

In this example, a process performs an update to three databases and enqueues a JMS message. All resources are XA-enabled and the process forms a global transaction.

Implementing the process in WLI

Similar to BPEL PM, business processes in WLI are transactional in nature. Every step of a process is executed within the context of a JTA transaction. A transaction ensures that one or more operations execute as an atomic unit of work. If one of the operations within a transaction fails, all operations are rolled-back so that the application is returned to its prior state. Depending on whether the business process logic is defined such that it is stateful or stateless, there may be one or more transactions within the context of a given business process.
When starting a business process, the process participates in the caller's transaction or starts a new transaction if none exists. If there are no implicit or explicit transaction boundaries, the process executes within a single transaction.
In the first example, our business process invokes four synchronous XA calls. The process is synchronous and stateless. The container manages this transaction.

Because no implicit or explicit transaction boundaries are defined, WLI will automatically make the entire process run in a single XA transaction. If there is a problem with any of the data sources (for example, if a database is down, or the JMS queue is unreachable), and no exception handler has been defined, the whole transaction will roll back.
When building a business process in WLI, implicit transaction boundaries are formed, based on where blocking elements are placed in the process. The transaction boundaries within a business process change as nodes are added to the business process.
Implicit transactions are implicit both because their behavior is automatically determined (or implied) by the business process logic and because they are not visible in the process diagram.
Implicit transaction boundaries are formed based on where blocking elements are placed in the process. These boundaries change as process nodes are added to the business process. Additionally, a business process is stateless by default, and blocking elements that change transaction boundaries can change the process to be stateful.
The following nodes change the transactional behavior in business processes in WLI:

Any receive (blocking) nodes (Client Request or Control Receive nodes)
A Parallel group node
An Event Choice node
Existing transaction boundaries are unaffected by adding one or more nodes (within those boundaries) that do not themselves force a transaction boundary.

Illustrated below is an example of a business process with an implicit transaction. The Control Receive node is a blocking element in the business process and therefore creates a new transaction

Additionally, WLI provides the ability to explicitly define a transaction by using the "Transaction" node within the WLI palette. This gives developers the ability to group certain nodes in a transaction boundary and have localized roll-back that will not affect the implicit process transaction. By incorporating the "Transaction" node into the simple example above it is possible to perform two distinct transactions instead of one. The diagram below shows the first two database updates in one transaction, and the JMS enqueue and third database update in a separate transaction.

By explicitly specifying a transaction scope within the WLI process, we force WLI to complete the open transaction (the transactions do not nest here) and begin a new, separate transaction. If we were to add additional steps after the explicit end of the transaction scope, they would also begin their own, new, implicit XA transaction. Nested transactions are not supported in WLI.
If the WLI process is a stateless process (sync or async), it will always execute in one and only one implicit transaction. Explicit transactions cannot be defined in synchronous processes or in stateless asynchronous processes. So, referring to the above example, simply adding the transaction node to a stateless process converted it into a stateful process.
Additionally, the following restrictions apply to explicit transactions:

The selected nodes must be contiguous
The selected nodes cannot include a Client Request or Control Receive node
The selected nodes cannot be inside the client request/response nodes of a synchronous process
The selected nodes cannot include a Parallel or Event Choice group node where including them in an explicit transaction would nest the transaction for their branches.
The selected nodes cannot be inside an existing explicit transaction

For more information about transaction handling in WLI, see the documentation covering Transaction Boundaries.

Implementing the process in BPEL PM

In BPEL PM, as in WLI, every BPEL process executes in the context of one or more transactions. When a process starts to execute, the process manager does one of two things with transactions:

It starts a new transaction for the process.
It enlists the process in an already open transaction.

BPEL uses this transaction to update process state in the database (this is called "dehydration") and also to log audit events in the database. Even if all this is turned off, the process manager will still execute processes in a transaction context. When invoked through a Web Service interface, BPEL will use the first option, since no transaction context will be available. When invoked through the Java API in a transactional environment, the process manager may use either option, depending on the parameters used in the call.
BPEL will try to squeeze as many activities into a single transaction as possible. Only a few activities actually cause the process manager to update the process state in the database and commit the transaction. A given activity does not always cause a transaction to be committed: sometimes the process may keep the same transaction context because of the properties associated with the activity.
In our simple scenario the default transactional behavior is similar to that in WLI. When a process is instantiated and there is no current transaction context, a new transaction is created. As in WLI, certain activities in BPEL will naturally delineate XA transactions and will force a transaction to end. These activities cause the state of the BPEL process to be quiesced to the dehydration store. When the process resumes from this type of activity, a new transaction will be started. The diagram below illustrates the same steps as above, as implemented in BPEL as a single, implicit transaction.

To perform the second use case, where we'd like to split our transaction into two separate transactions, in BPEL, we need to deliberately end the first transaction. This can be done explicitly through the use of the "checkpoint" method inside a Java Exec activity, as shown below.

<bpelx:exec name="checkpointJavaExec" language="java" version="1.4">
<![CDATA[
checkpoint();
]]>
</bpelx:exec>

In addition to "wait and receive" and other activities that cause dehydration (writing BPEL process state to the database and committing the transaction), transactions can also be committed after an invoke by setting the idempotent property on the target partner link to false. If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in the dehydration store. This will end the initial transaction and start a new transaction. The diagram below shows how this can be implemented.

View full size image

When BPEL calls an adapter, the ESB, or another process in the same BPEL domain, it has the option to either include the target in the same transaction, or to start a separate transaction. This behavior is controlled by the transaction property in the partner link. If the transaction property value is set to participate, the callee is enlisted in the current transaction. If the transaction property is set to any other value, the callee executes in a separate transaction. This is great for ensuring that multiple database updates are included as part of the same transaction, but be aware that there is a downside.
If any callee rolls back the transaction, the current BPEL process state is also rolled back to the last commit. If there has been no commit and the process was invoked through a synchronous interaction, the process will seem to disappear from the face of the earth. To minimize the impact, the database adapter will throw an error rather than rollback the transaction — if doing so will not affect transactional integrity. (Basically, you can do one DB update without rolling back, but if you do two, an error will cause a rollback.)
One final thing to be aware of is that in BPEL, a flow activity (which is used to designate activities for parallel execution) is actually processed sequentially unless it encounters an activity that will cause the thread to be suspended. This is efficient, but defeats one of the use cases of the flow, which is to perform multiple operations in parallel to reduce service latency. BPEL provides the nonBlockingInvoke=true partner link property to cause invokes to a synchronous service to be treated internally as calls to an asynchronous service. Internally, the process waits for the message on the JMS queue, causing the transaction to be completed. At the same time, a new thread is started to perform the synchronous call and place the result in the queue. This allows the other legs of flow to execute in parallel.

Beyond XA: compensating transactions

The examples above address the behaviors when all of the resources are XA-compliant. When there are activities that are not XA-compliant, compensating transactions must be built into the process. Both WLI and BPEL provide a mechanism to do this through the use of exception handlers.
Also, BPEL includes the concept of an invocable Compensating Transaction. This is similar to an exception handler, and is defined at the scope level. However, it is explicitly invoked only by the "Compensate" activity. Compensation is intended to allow the application of reversing operations to systems that cannot participate in transactions, or when it has been decided that the systems should not operate as part of transactions. For example, a Web Service might allow inventory to be decremented, but an error makes it necessary to roll back the process. In this case, a compensation handler would be defined to call the Web Service to increment the inventory, effectively providing a reversing transaction. This allows you to define rollback activities and associate them with the code that performs the operations that may need to be reversed. This is also very useful in that it allows some exceptions to be handled without undoing all of the work.
If a scope requires a compensation handler, the service that requires compensation should be marked as non-idempotent by setting the "idempotent" property value to "false." This will cause Oracle BPEL Process Manager to start a new transaction after invoking the non-transactional resource.
The following diagram illustrates an example of the use of Compensation Handlers, and an explicit forward-based compensation model. Note the explicit call in the catchAll block of the second scope, invoking .

View full size image

Key Takeaways and Recommendations

Both WLI and BPEL PM manage global XA transactions, both tools initiate an implicit transaction when the process gets instantiated, and similar activities in both WLI and BPEL force the end of transactions. Note, however, that unlike WLI, Oracle BPEL Process Manager not only allows multiple transactions to occur in an asynchronous stateful process, it also allows them to be defined in a synchronous process. With the addition of compensation, BPEL provides a standard and reliable mechanism for providing compensating transactions for non-transactional resources.
BPEL is inherently a stateful language. Oracle BPEL Process Manager uses XA transactions to manage that state, and allows XA transactions to extend beyond the boundaries of the active BPEL process.
The general rules about what causes a commit are straightforward, and the BPEL process will commit the transaction and start a new one after the following activities:

receive - Unless it is the first receive in the process and the process was called with a "transaction=participate" property (possibly by marking it as such in the partner link of a calling process), in which case the process participates in the existing transaction.
checkpoint() - Call in a Java Exec activity
onMessage
wait - For very short waits (up to two or three seconds), the process manager will not commit the transaction.
onAlarm
invoke - Only if the partner link is non-idempotent (can be marked with the "idempotent" partner link property).
End of process flow - Only if the process is not participating in the caller's transaction (the corollary of the receive).

The table below summarizes the transaction status when performing different activities.

Activity	Transaction Status in BPEL Process	Transaction Status in Target Process or Adapter
Receive	New Transaction	N/A
Receive with Property "transaction=participate"	Use Existing Transaction from Caller	N/A
Invoke Synchronous Process	Use Existing Transaction	New Transaction
Invoke Synchronous Process with Partner Link Property "transaction=participate"	Use Existing Transaction	Use Existing BPEL Transaction
Invoke Synchronous Process with Partner Link Property "idempotent=false"	New Transaction	New Transaction
Invoke Synchronous Process with Partner Link Property "nonBlockingInvoke=true"	New Transaction	New Transaction
Invoke Asynchronous Process	Use Existing Transaction	New Transaction
Invoke Asynchronous Process with Partner Link Property "transaction=participate"	Use Existing Transaction	New Transaction
Invoke Synchronous Process with Partner Link Property "idempotent=false"	New Transaction	New Transaction
Wait < a couple of seconds	Use Existing Transaction	N/A
Wait > a couple of seconds	New Transaction	N/A
checkpoint()	New Transaction	N/A
Flow	Use Existing Transaction for all parallel activities	N/A

Setting Web Service and JCA Adapter Endpoints Dynamically in Oracle SOA Suite

2011-09-08T08:24:00.000-07:00

(From http://www.oracle.com/technetwork/topics/soa/dynamic-endpoints-100390.html)

Introduction

Most business processes use some form of integration with external systems. These might be file systems, web services, message queues, databases or backend applications. In many cases, the endpoints for those systems (queue name, URL, file directory, etc.) will be different for development, testing, and production. In other cases the endpoints can change during the application's life cycle.
In these situations, a developer can change the endpoint property in question within the business process, and then recompile, redeploy, retest, and so on. This is obviously a time-consuming and error-prone process. A better strategy is to keep potentially changing endpoints dynamic.
Ideally, an administrator would set the endpoint property values in an administration console. The business process would then read and set values at run-time.
This article describes how dynamic endpoints can be handled in Oracle WebLogic Integration (WLI) and Oracle SOA Suite.

Dynamic Endpoints in WLI

Most controls in WLI allow the specification of dynamic properties, which are passed as an XML variable at run-time. These dynamic properties overwrite the properties that were defined for the control at design-time.
In order to set the dynamic properties, an XML variable has to be created that conforms to the control's dynamic-property schema and is used in thecontrol's setProperties() method. The current property settings can be retrieved using the getProperties() method.
Let's take the email control as an example. The setProperties() method of this control accepts an EmailControlPropertiesDocument parameter. The EmailControlPropertiesDocument type is an XML Beans class that is generated out of the corresponding schema element defined in DynamicProperties.xsd, which is located in the system folder of the Schemas project of the WLI application.
The following is an example of an XML variable used to set dynamic properties for an email control:

<EmailControlProperties>
<smtp-address>myorg.mymailserver.com:25</smtp-address>
<from-name>Joe User</from-name>
<from-address>joe.user@myorg.com</from-address>
<reply-to-address>reply@myorg.com</reply-to-address>
<reply-to-name>Joe User</reply-to-name>
</EmailControlProperties>

The control properties are often retrieved through an XML MetaData Cache control. (see XML MetaData Cache Control).
This control retrieves an XML document at run-time from the WLI cache that was created by an administrator through the WLI admin console. The content of the xml document can be changed at any time without affecting the deployed applications.

Dynamic Endpoints in SOA Suite

Message header properties can be configured for Web service binding components or JCA adapter binding components that are part of a deployed SOA composite application. Oracle JCA Adapters expose the properties specific to underlying back-end operations as header elements and allow the manipulation of these elements within a business process.
(See Using Header Properties for Oracle JCA Adapters)
Oracle JCA Adapters properties can also be added, deleted, or reverted from the Oracle Enterprise Manager Fusion Middleware Control Console (EM). The properties listed below are classified based on adapter behaviour when properties are added, deleted, or updated.

The InteractionSpec or ActivationSpec Properties

Properties in this group require the adapter endpoint to be recycled. The values of properties in this group can be changed from the EM console. However, property-dependency constraint validation requires that Oracle JDeveloper be used to make changes (adding or removing) to the composition of these properties.
(See The InteractionSpec or ActivationSpec Properties)

Endpoint Properties

The adapter is notified of changes to these properties without restarting the endpoint. Properties that belong to this group can be added or removed. The endpoint properties represent auxiliary tuning properties that an adapter might want to expose. The auxiliary tuning properties include various time intervals, thresholds, and other values. These endpoint properties are not exposed through the interactionspec or activationspec properties.
(See Endpoint Properties)

Configuring the End Point Properties for an Adapter

A number of BPEL activities, including invoke, receive, and reply and the onMessage branch of pick activities, provide a Properties tab. Header properties for JCA adapters can be set trough this tab.
In order to use this functionality, the property value is assigned to a string variable. This variable can then be used in the properties tab, as described in the use case sample below.
(See Introduction to BPEL Activities for a description of the properties tab in BPEL activities.)
The Domain Value Maps in SOA Suite are similar in concept to the XML Meta Data cache in WLI. Domain Value Maps can be used to retrieve information at run-time. The use of Domain Value Maps will be addressed in an upcoming article in this series.
Configuring message header properties for Web service binding components or JCA adapters through Enterprise Manager Oracle JCA Adapters and Web Services are either Service or Reference Binding Components within a SOA Suite composite application. Binding components are network protocols and services that connect the SOA platform with the outside world. Message header properties can be configured for Web service binding components or for JCA adapter binding components.
(See Understanding Binding Components) For more information about endpoint properties, see the chapter Configuring Service and Reference Binding Components in the Oracle Fusion Middleware Administrator's Guide for Oracle SOA Suite.
The following adapters support header properties:

Oracle AQ Adapter (see Oracle AQ Adapter Properties)
Oracle Database Adapter (see Oracle Database Adapter Properties)
Oracle File and FTP Adapter (see Oracle File and FTP Adapters Properties)
Oracle JMS Adapter (see Oracle JMS Adapter Properties)
Oracle MQ Series Adapter (see Oracle MQ Series Adapter Properties)
Oracle Socket Adapter (see Oracle Socket Adapter Properties)

For more information about Oracle JCA Adapters properties, see Oracle JCA Adapter Properties.
To configure JCA adapter or Web Services properties, select the Properties tab of the adapter or web service in Enterprise Manager.
(See Configuring Service and Reference Binding Component Properties).
The following section explains this process in more detail.

Configuring the End Point Properties for an Adapter through Oracle Enterprise Manager

A variety of Oracle SOA Suite administration (configuration, monitoring, and management) tasks can be performed from the Enterprise Manager Console. One of these tasks is to configure the end point properties for a JCA adapter.
The properties of an adapter are usually defined in Oracle JDeveloper during design time. However, it is possible to edit or add predefined properties or to create or delete properties at a later stage.

Editing a Predefined Property for an Adapter

To edit a predefined property for an inbound adapter, navigate to the SOA composite application by using either of the following options:
From the SOA Infrastructure Menu:

Click Home.
The SOA Infrastructure page is displayed.
Click the Deployed Composites tab.
The list of deployed composite applications is displayed.
In the Composite section, click a specific SOA composite application.
The SOA composite home page is displayed.
Click the inbound/outbound adapter (service/reference) from the Services and References section in the right panel.
The Service Home page is displayed.

From the SOA Folder in the Navigator:

Under soa-infra, click a specific SOA composite application.
The SOA Composite home page is displayed.
Click the inbound/outbound adapter (service/reference) from the Services and References section in the right panel.
The Service Home page is displayed.

Edit a predefined property

Click Properties to see a list of the currently defined binding properties.
Select the property to be edited.
Edit the value in the Value text box.
Click Save.

Adding Predefined Properties for an Adapter

To add a predefined property for an adapter:

Navigate to the SOA composite application as described above.
Add a predefined property:
1. Click the Properties tab to see a list of the currently defined binding properties.
2. Click the Add button. A new empty row is appended to the existing list of properties.
3. Click the Select Values icon in the Name field of the new row.
  The Properties dialog is displayed.
4. Select a property that is valid for the particular adapter from the list of properties, and then click OK.
5. Click Save.

Creating a New Property for an Adapter

To create a new property for an inbound adapter:

Navigate to the SOA composite application as described above
Create a new property:
1. Click the Properties tab to see the list of the currently defined binding properties.
2. Click the Add button.
  A new empty row is appended to the existing list of properties.
3. Specify the property name and value in the Name and the Value fields of the new row.
4. Click Save.

Deleting a Property for an Adapter

To delete a property for an inbound adapter:

Navigate to the SOA composite application as described above
Delete a property:
1. Click the Properties tab to see a list of the currently defined binding properties.
2. Select the property you want to delete, and then click Delete.
  A message asking you to confirm your action is displayed.
3. Click OK to confirm.
4. Click Save.

Reverting a Property Value for an Adapter

You can revert only those properties that you have changed. Also note that you can perform the revert operation only on the existing property values and not on those that were added from the predefined list of properties or those that you created.
To revert a property value for an inbound adapter:

Navigate to the SOA composite application as described above.
Revert a property value for an inbound adapter:
1. Click the Properties tab to see a list of the currently defined binding properties.
2. Select the property you want to revert, and then click Revert.
  A message asking you to confirm your action is displayed.
3. Click OK to confirm.
4. Click Save.

For more information, please see Configuring the End Point Properties for an Inbound Adapter and Configuring the End Point Properties for an Outbound Adapter.

Use Case Example: Change the file name and directory before writing a file

This example will demonstrate how the endpoints (file name and directory) for a file control (in WLI) and a file adapter (in SOA Suite) can be changed dynamically. In order to keep it simple and to the point, we will create a process that does nothing but write a message to a file. A real-world use case would be much more complicated.

Implementing the use case in WLI

The WLI use case is not described in great detail as it is assumed that the audience knows how to implement a dynamic file control in WLI. The focus area is the implementation of the use case in SOA Suite.
A file control is used to write a file to a local directory. As with many other controls, the file control also provides dynamic properties to dynamically set endpoints:

<?xml version= '1.0' encoding= 'UTF-8' ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"
targetNamespace="http://demo/demoCustomer1"
xmlns:cu="http://demo/demoCustomer1">
<xs:element name="customer">
<xs:complexType>
<xs:sequence>
<xs:element ref="cu:key"/>
<xs:element ref="cu:firstname"/>
<xs:element ref="cu:lastname"/>
<xs:element ref="cu:address"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="key" type="xs:string"/>
<xs:element name="firstname" type="xs:string"/>
<xs:element name="lastname" type="xs:string"/>
<xs:element name="address" type="xs:string"/>
</xs:schema>

In our sample, the WLI process is started by a Client Request Node which expects a customer XML document as input. An XML MetaData Cache control is used to read the file directory and file name values. A transformation control is used to create the properties for the file control. And finally, the properties are set through the the file control's setProperties() method. The file control's write method is then used to write the customer message to the file.
While some of the steps in this process could be consolidated, they are shown as single steps in order to simplify the sample.
The JPD is illustrated in Figure 1.

Figure 1: JPD

Implementing the use case in SOA Suite

This section will describe the same use case, as implemented in SOA Suite.
In this use case, a business process is started via a web service call with a customer xml message. The business process uses a file adapter to write the customer information to a file.
The following section will describe how the process is deployed and tested, and then demonstrate how the adapter endpoint properties can be changed by using the adapter header properties within the process, or through the Enterprise Manager console.

Create a SOA Application and Project

To get started:

Create a new SOA Application in JDeveloper.

Name it SOASuiteWLIEssentials

Create a new Project named DynamicEndpoints.

Click Finish

Create the BPEL Process

In the composite, drag-and-drop a BPEL Process component onto the Components swim lane.

In the Create BPEL Process dialog, specify the following settings:
1. Name: WriteCustomer
2. Template: One Way BPEL Process
3. Service Name: writecustomer_client
4. Expose as a SOAP Service: Checked
5. Input:
  1. Click the flashlight icon to open Type Chooser window.
  2. Click the Import Schema File icon.

Choose the customer XML schema from your local disk.
Check Copy to Project

Click OK
Click OK
Choose the root element of your schema

Click OK

Click OK
The WSDL for this service is created automatically using this information. Note that the input type specified here goes in to the WSDL for this service.

Adding a File Adapter

Drag-and-drop a File Adapter to the External References swim lane. This file adapter will write each customer to a text file.

Name the service WriteCustomerData

Click Next.
Select the option to Define from operation and schema.

This feature allows you to use the file operation and schema to define the WSDL automatically.

Click Next.
Select the Write File operation

Click Next.
Specify the following settings, leaving all others with their default values:
1. Directory for Outgoing Files: c:\temp
2. File Naming Convention: customer_%SEQ%.xml to write the files with increasing sequence numbering. You can see additional options for numbering files in a drop down menu as soon as you enter % in the field

Click Next.
Browse for the schema that represents the content we will write (customer.xsd)

Choose the root element

Click OK.

Click Next, then Finish to complete the File Adapter wizard and return to the composite.

Wire the BPEL Process and the File Adapter

Next, wire the BPEL process and the file adapter and complete the interface definitions.
The wired components resemble the image below:
Wiring the components in the composite automatically creates a partner link reference inside the BPEL process.

Designing the BPEL Process

Double-click the BPEL component to open the BPEL editor.

Notice the WriteCustomerData partnerlink already in the References swim lane because you wired it in the composite. The editors keep the references in sync between the BPEL process and the composite.
Drag-and-drop an Invoke activity from the Component Palette to an insertion point under the receiveInput activity.

Drag the wire from the Invoke activity to the WriteCustomerData partner link. This tells the BPEL process to invoke the file adapter.

In the Edit Invoke dialog, specify the following:
1. Name: WriteCustomerData
2. Input Variable: Click the green plus icon and then click OK to create a new global variable, accepting the default name and type.
  
  The variable designated for the input will contain the data that will be sent to the service when it is invoked. It is automatically created with the correct type expected by the service.

Click OK.

click OK.

Your BPEL process should now resemble the image below:
We've created the variables that will be used when interacting with the WriteCustomerData service, but they haven't been populated. Let's populate the input variable first.
In BPEL, Assign activities are used to assign data to variables. In this case you want to assign the customer information to the WriteCustomerData service.

Drag-and-drop an Assign activity above your Invoke activity.

Double-click the Assign activity to edit it.
Click the General tab and change the name to assignCustomerData

Click the Copy Operation tab
Click the green plus icon and select Copy Operation to open the Create Copy Operation dialog.

Specify the following: In the From side, select Variables > Process > Variables > inputVariable >payload > ns2:customer
In the To side, select Variables > Process > Variables >WriteCustomerData_Write_InputVariable > body > ns2:customer

Click OK.

The Assign dialog should now resemble the image below:

Click OK to return to the BPEL process.
Click the green check button in the upper left of the BPEL process to validate the process.

All the warnings should go away. The process should resemble the image below:
The input variable to WriteCustomerData is now populated.

Save the BPEL process.

Deploying the SOA Composite

Before the BPEL process can be tested, the composite has to be deployed with Oracle JDeveloper.
Before you start the deployment, please make sure that your SOA Server is running.
Please check Deploying SOA Composite Applications to learn how to deploy SOA composite applications with Oracle JDeveloper and scripting tools and create configuration plans that enable you to move SOA composite applications to and from development, test, and production environments.
Please check Deploying SOA Composite Applications to learn how to deploy, redeploy, and undeploy a SOA composite application from Oracle Enterprise Manager Fusion Middleware Control Console (EM).
When deploying the composite from within JDeveloper, the log should look similar to the example below:

[07:32:39 PM] ----  Deployment started.  ----
[07:32:39 PM] Target platform is  (Weblogic 10.3).
[07:32:39 PM] Running dependency analysis...
[07:32:39 PM] Building...
[07:33:06 PM] Deploying profile...
[07:33:06 PM] Updating revision id for the SOA Project
'DynamicEndpoints.jpr' to '1.0'..
[07:33:06 PM] Wrote Archive Module to D:\1WLI\2SOASuiteMigration\testProjects\JDev\11gPS1\
SOASuiteWLIEssentials\DynamicEndpoints\deploy\sca_DynamicEndpoints_rev1.0.jar
[07:33:06 PM] Deploying sca_DynamicEndpoints_rev1.0.jar to AdminServer [SGEIB01.emea.bea.
com:7001] 
[07:33:06 PM] Processing sar=/D:/1WLI/2SOASuiteMigration/testProjects/JDev/11gPS1/SOASuiteWLIE
ssentials/DynamicEndpoints/deploy/sca_DynamicEndpoints_rev1.0.jar
[07:33:06 PM] Adding sar file - D:\1WLI\2SOASuiteMigration\testProjects\JDev\11gPS1\SOASuite
WLIEssentials\DynamicEndpoints\deploy\sca_DynamicEndpoints_rev1.0.jar
[07:33:06 PM] Preparing to send HTTP request for deployment
[07:33:07 PM] Creating HTTP connection to host:SGEIB01.emea.bea.com, 
port:7001
[07:33:08 PM] Sending internal deployment descriptor
[07:33:08 PM] Sending archive - sca_DynamicEndpoints_rev1.0.jar
[07:33:28 PM] Received HTTP response from the server, response code=200
[07:33:28 PM] Successfully deployed archive sca_DynamicEndpoints_rev1.0.jar to AdminServer
 [SGEIB01.emea.bea.com:7001] 
[07:33:28 PM] Elapsed time for deployment:  48 seconds
[07:33:28 PM] ----  Deployment finished.  ----

Testing the BPEL Process

After successful deployment, you can initiate the composite service through Oracle Enterprise Manager Fusion Middleware Control Console (EM).

To log in to Enterprise Manager, use Internet Explorer 7, Mozilla Firefox 2.0.0.2, or Firefox 3.0.x to access the following URL: http://host_name:port/em, where host_name is the name of the host on which Enterprise is installed and port is the port number of your admin server.
Enter weblogic/password and click Login.

(See Getting Started with Administering Oracle SOA Suite for more information.)

Go to SOA - soa_infra, then locate and click DynamicEndpoints composite on the EM dashboard to access the composite homepage

Once on the page, you can test a composite service by clicking on the Test button...

Filling out the payload...

And clicking on the button Test Web Service.

If all goes as planned, a new file customer_1.xml will be created in C:\temp.

Change the File Adapter End point at Run-time Through the Properties Tab of the Invoke Activity

This sample will show how the adapter end-point can be changed at run-time. It's very similar to the WLI use case where the information is retrieved through an XML Meta Data Cache control and set as properties to the control.
As mentioned above, a Domain Value Map would be used to retrieve the values for the adapter properties. In order to keep this article simple, the sample BPEL process will use hard coded values for those properties and the use of Domain Value Pairs will be explained separately
.

Create variables for the properties

If the Structure window (by default on the top left of JDeveloper) is not visible, go to View - Structure.
In the Structure window click on Variables - Process - Variables and click the green plus sign:

In the Create Variable window, define:
1. Name: outputFolder
2. Simple Type: click on the type chooser icon to select the type of the variable

Choose string

Click OK

Click OK

Repeat the process for a second string variable fileName

Assign values to the variables

This is where the Domain Value Maps would be used in a real-life use case. However, for this examples we'll use hard coded values.

Add an assign activity to the BPEL process, between assignCustomerData and WriteCustomerData with Name: setProperties.
In the Copy Operation tab, add two copy operations:
1. Click on the green plus sign and choose Copy Operation.

On the left side, choose Expression.
Enter a new output file directory, e.g. " C:\files\output".
Choose the variable outputFolder on the right side.

Click OK

Repeat these steps to set a new output file name to the variable filename.
The assign activity should now resemble the image below:

Click OK.

Set the properties for the file adapter

Open the invoke activity WriteCustomerData
Go to the Properties tab
1. Scroll down to jca.file.Directory
2. Click the browse button in the Value field

Browse variables

Choose variable outputFolder

Click OK.
Click OK.

Scroll to jca.file.FileName
Choose variable fileName

Click OK

The BPEL process should now resemble the image below:
Re-deploy the composite and test the BPEL process again. There should now be a file with the new name in your newly chosen directory

Change the File Adapter end point in Enterprise Manager

Instead of setting the properties dynamically in the BPEL process, you can also make changes to the JCA adapter and web services properties in Enterprise Manager.

Click on the DynamicEndpoints composite and scroll down to Services and References.

Click on WriteCustomerData (the file adapter)

Click on the Properties tab and change the PhysicalDirectory and FileNameConvention. Make sure the output directory exists.

Click Apply, then Yes, then OK.

Re-deploy the composite and test the BPEL process again. There should now be a file with the new name in your newly chosen directory.

Dynamic Data Lookup in a Business Process

2011-09-08T08:21:00.000-07:00

(From http://www.oracle.com/technetwork/topics/soa/dynamic-data-lookup-endpoints-geib-092046.html)

Meta Data Cache Control in Oracle WebLogic Integration and Domain Value Maps in SOA Suite

Introduction

Many common integration use cases include the lookup of dynamic data at run-time from within a business process. Examples for this include address data, an endpoint for an adapter (for example, the URL for a web service or the location of a file), or the mapping from the vocabulary in one domain to another vocabulary in a different domain.
These data share a common trait: they can change at any time and must not be tied directly to the business process. In an ideal scenario, an administrator can update the information in a console in real-time without having to change any code and re-compile or re-deploy the application. This scenario also offers improved performance and the availability of the data across a cluster.
The retrieval of dynamic data is achieved in Oracle WebLogic Integration (WLI) through an XML MetaData Cache Control, which works on a key-value pair, where the key is a string and the value is an XML document. The value is set by an administrator in the WLI admin console and retrieved at run-time within a business process.
The same can be achieved in Oracle SOA Suite with Domain Value Maps (DVM) where dynamic data retrieval is only one possible use case, but the one that is of specific interest for WLI users.
This article introduces both concepts, and describes the use of Domain Value Maps in SOA Suite 11g in detail.
In order to make this article less theoretical, a sample is used to illustrate the usage of Domain Value Maps from within a BPEL process. This sample explains step-by-step how to look up a file name and location at run-time before a message is written to a file.
The use case builds on a sample that was explained in Setting Web Service and JCA Adapter Endpoints Dynamically in Oracle SOA Suite, another article in the SOA Suite Essentials for WLI Users series. It is highly recommended to work through that article first before going through this use case.

XML MetaData Cache Control in WLI

The WLI XML MetaData Cache Control is used for fast access to a managed set of key-value pairs. The key is of type string and the value contains XML data.
These key-value pairs can be retrieved within a business process from the XML MetaData Cache through the get method of the control, where the key is the input parameter and the value (the XML message) is the return parameter. The corresponding entries can then be extracted from the XML message and used to set dynamic control properties (or other dynamic data).
An administrator manages the entries in the cache ( add, delete, update) through the WLI Administration Console without touching the process.
The XML MetaData Cache is a global, domain-wide cache. Data from the cache is made available on a permanent basis throughout a cluster through file-based storage.
For more information on the WLI XML MetaData Cache, please see XML MetaData Cache Control and XML Cache in Using the WebLogic Integration Administration Console.

Domain Value Maps (DVM) in SOA Suite

The original intent of Domain Value Maps (DVM) in SOA Suite was to map from one vocabulary, used in a given domain, to another vocabulary used in a different domain. For example, one domain might use a long name to represent a city (Boston) while another domain may use a short name to represent the same city (BO). In such cases, you can directly map the values by using DVMs. A direct mapping of values between two or more domains is known as point-to-point mapping.
Each DVM typically holds a specific category of mappings among multiple applications. For example, one DVM might hold mappings for city codes and another might hold mappings for state codes.
Qualifiers are supported in addition to direct mapping. A mapping may not be valid unless qualified with additional information. For example, a DVM containing city code to city name mapping may have multiple mappings from KN to Kensington because Kensington is a city in Canada as well as in the USA. So, this mapping requires a qualifier ( USA or Canada) for validation.
Multiple qualifiers can also be specified. Qualifiers are used only to qualify the mappings and cannot be looked up.
A qualifier order is used to find the best match during lookup at runtime. The order of a qualifier varies from highest to lowest depending on the role of the qualifier in defining a more exact match. A state qualifier, for example, can have a higher order than a country qualifier, as a matching state indicates a more exact match.
DVMs support hierarchical lookup. If a qualifier value is specified during a lookup and no exact match is found, the lookup mechanism tries to find a more generalized match by setting the higher order qualifiers to a "". It proceeds until a match is found, or until a match is not found with all qualifiers set to a "".
One value in a DVM can also be mapped to multiple values ( One-to-Many Mapping Support). For example, a domain value map for Payment Terms can contain mapping of payment terms to three values, such as discount percentage, discount period, and total payment period.
In addition to this vocabulary mapping, Domain Value Maps can also be used to look up data at run-time, for example dynamic properties for a J2EE Connector Architecture (JCA) Adapter.
This lookup can be used within a BPEL process or a Mediator component for example before calling an adapter service.
For additional information on DVMs, please see Working with Domain Value Maps and Editing a Domain Value Map.

JDeveloper and SOA Composer

DVMs can be created and edited in Oracle JDeveloper. For more details on this please see Creating Domain Value Maps, Editing a Domain Value Map, Creating a Domain Value Map Use Case for Hierarchical Lookup and Creating a Domain Value Map Use Case For Multiple Values.
By using JDeveloper, the application has to be recompiled and redeployed every time a change is made to the values in the DVM. In order to avoid this, the SOA Composer offers support for editing DVMs at runtime (starting from SOA Suite 11gR1 PS1).
DVM Metadata can either be associated with one SOA composite, or it can be shared across different composites.
The SOA Composer is an EAR file which is installed as part of SOA installation. It offers complete functionality to manage DVMs at runtime. You can view and edit a DVM in the Composer after it has been created in JDeveloper. The second part of the SOA Suite use case sample below will explain step-by-step how this is done.
For more information, please see Using SOA Composer with Domain Value Maps.

Use Case Example

The following sections will describe how dynamic properties (file name and output directory) are retrieved at run-time in a business process using the XML Meta DataCache Control for a file control in WLI, and using Domain Value Maps for a File Adapter in SOA Suite, .
As mentioned, this can also be done in a Mediator component. But a BPEL process was chosen here to show the similarities to a business process in WLI.
As always, it is assumed that readers are familiar with the WLI concepts, so the WLI use case will not be described in much detail. The focus will be on the implementation in SOA Suite, which will be explained step-by-step.
Please make sure you are familiar with the article Setting Web Service and JCA Adapter Endpoints Dynamically in Oracle SOA Suite, as this sample builds on the one that was implemented in that article.

Implementing the Use Case in WLI

As explained in Setting Web Service and JCA Adapter Endpoints Dynamically in Oracle SOA Suite, a file control is used to write a file to a local directory.
The WLI process is started by a Client Request Node which expects a customer XML document as input. An XML MetaData Cache control ( get file properties in Figure 1) is used to read the file directory and file name values. A transformation control is used to create the properties for the file control. And finally, the properties are set through the file control's setProperties() method. The file control's write method is then used to write the customer message to the file.

The XML MetaData Cache control operates on XML messages. The following schema will be used to retrieve the file control properties:

<?xml version= '1.0' encoding= 'UTF-8' ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" targetNamespace="http://demo/fileInfo"
xmlns:fi="http://demo/fileInfo">
<xs:element name="fileInfo">
<xs:complexType>
<xs:sequence>
<xs:element ref="fi:fileDirectory"/>
<xs:element ref="fi:fileName"/>

</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="fileName" type="xs:string"/>
<xs:element name="fileDirectory" type="xs:string"/>
</xs:schema>

The xml document used in the sample defines the file name and output directory for the file:

<fi:fileInfoxmlns:dem="http://demo/Address">
<fi:fileDirectory>C:/files/output</fi:fileDirectory>
<fi:fileName>customerTest.xml</fi:fileName>
</fi:fileInfo>

The process receives a customer document which includes an element key as part of the message:

<?xml version= '1.0' encoding= 'UTF-8' ?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" targetNamespace="http://demo/demoCustomer1"
xmlns:cu="http://demo/demoCustomer1">
<xs:element name="customer">
<xs:complexType>
<xs:sequence>
<xs:element ref="cu:key"/>
<xs:element ref="cu:firstname"/>
<xs:element ref="cu:lastname"/>
<xs:element ref="cu:address"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="key" type="xs:string"/>
<xs:element name="firstname" type="xs:string"/>
<xs:element name="lastname" type="xs:string"/>
<xs:element name="address" type="xs:string"/>
</xs:schema>

This element is extracted from the message and used as input to the XML MetaDataCache control.

Implementing the Use Case in SOA Suite

Domain Value Maps can be created in a SOA Composite application of Oracle JDeveloper and used to look up dynamic data at run-time.
To create the SOA Application, Project, composite, BPEL process and file adapter for this use case sample, please follow the steps in the "Implementing the use case in SOA Suite" section of the article Setting Web Service and JCA Adapter Endpoints Dynamically in Oracle SOA Suite, including the section "Change the File Adapter end point at run-time through the Properties tab of the Invoke activity".

Create a new Domain Value Map (DVM) in JDeveloper

The DVM is created in JDeveloper initially. It can then be changed at any time in SOA Composer.
The values in the DVM will be the property values for the output directory and file name for a given customer. In order to identify the right values, we will use the key element in the customer schema.
We will only create one set of values for the sample, but you can have any number of rows in the DVM with different key values.
In the Application Navigator, right-click the DynamicEndpoints project and select New.

Expand the SOA Tier node, and then select the Transformations category.

In the Items list, select Domain Value Map(DVM) and click OK.
The Create Domain Value Map(DVM) File dialog is displayed.

In the File Name field, enter the name of the domain value map file: fileProperties.dvm
In the Description field, enter a description for the domain value map
Enter:
- Key for the first Domain Name
- 1 for the first Domain Value
- FileDirectory for the second Domain Name
- C:\files\output or another output directory for the first Domain Value. Please make sure the chosen directory exists

Additional entries are added in the following step.

Click OK
The Domain Value Map(DVM) Editor is displayed:

A file, fileProperties.dvm, gets created and appears in the Application Navigator.

After you have created a DVM, you can edit it and make adjustments to the presentation of data in the Domain Value Map Editor.
All we need to do is add a column for " FileName".
Click on the green "+" to add a new Domain

Enter " FileName", and set the Qualifier to " false"

Click "OK"

Add a new output file name in the Domain Value field.

Save your changes.
This concludes the creation of the initial DVM.

Assign the values from the DVM to the property values

Open the WriteCustomer BPEL process that was created in a previous step. This BPEL process includes an assign activity which hard codes the file adapter properties to the string variables outputFolder and fileName.
Instead of the two existing copy operations, we will create new operations that lookup the values using the previously created DVM and assign it to the property variable.
Open the assign activity assignProperties.

Delete the two copy operations in the activity.
Create a new copy operation.

Choose Expression in the Type dropdown list on the left hand side and open the XPath Expression Builder by clicking on the little icon

Choose DVMFunctions in the Functions drop-down list on the lower right.

Choose the lookupValue1M function and hit Insert Into Expression.
Please note that the usage and syntax of the function is described in the Description window.

The first parameter is the DVM file, enter " fileProperties.dvm"

The second parameter is the name of the source column, please enter " Key"
The third parameter is the name of the source value, which is the key value in our sample. We get the value of this parameter from the element key in the customer variable (which is the input variable).
In the BPEL Variables window, please expand the variable inputVariable and choose the element key.

Click the Insert Into Expression button

The last parameter is the target column name, " FileDirectory" in our case.

You can also choose more than one target column. The output will be an XML fragment that includes all those values. But as we want to assign one value to a string variable, we split this into two copy operations.
The DVM function now looks like this:

dvm:lookupValue1M("fileProperties.dvm", "Key",
bpws:getVariableData('inputVariable','payload','/ns2:customer/ns2:key
'), "FileDirectory")

Click OK.
Choose the property variable outputFolder on the right hand side.

Click OK.
If you see an error regarding the DVM function, it should go away once you click OK.
Repeat these steps to assign a value to the variable fileName
The DVM function looks like this:

dvm:lookupValue1M("fileProperties.dvm", "Key",
bpws:getVariableData('inputVariable','payload','/ns2:customer/ns2:key
'), "FileName")

The assign activity should now look like this:

Click OK.
That's all you have to do to create the DVM lookup.
The BPEL process looks like this:

Re-deploy the composite and test the BPEL process again. Make sure the value of the key element is 1.
Check if the output directory and file name are the ones you defined in the DVM and not the ones originally defined in the file adapter.

Change the Domain Value Map at runtime.

You might have to target the SOA Composer first as it is not targeted in development environments by default.
To check if you can use the Composer, please log into Enterprise Manager (EM) at http://host_name:port/em where host_name is the name of the host on which Enterprise Manager is installed and port is the port number of your admin server. Enter weblogic/ password and click Login.
Open the Application Deployments under Farm_soaDomain.
If you don't see composer (serverName) as a deployed component, please follow the steps in the next section. If you can see it, please skip the next section.

Target SOA Composer in WebLogic Server administration console

Log into WLS console at http://host_name:port/console where host_name is the name of the host and port is the port number of your admin server.
The console application is deployed on first access, which might take a few minutes.
Click on Deployments in the Domain Structure on the left hand side.

The composer will be in state Installed. You have to target it and start it

Click on composer and choose the tab Targets.
Check the box left of composer and hit the Change Targets button.

Check AdminServer and click Yes.

Go back to the deployments by clicking on Deployments in the Domain Structure on the left.
Check the box in front of composer and click Start - Servicing all requests.

After a while, the state will change to Active.

Go back to Enterprise Manager and make sure the composer is now available under Application Deployment.

View the previously created DVM in SOA Composer

Log into SOA Composer at http://host_name:port/soa/composer where host_name is the name of the host and port is the port number of your admin server.
If there is a problem opening the Composer, make sure it's properly deployed and targeted (see previous step).
Select Open DVM from the Open menu.

The Select a DVM to open dialog appears.

Choose fileProperties.dvm and click Open.
The selected DVM opens in view mode.

Edit the DVM in SOA Composer

By default, DVMs open in the view mode. For editing a DVM, you need to change the mode to edit session by clicking the Edit menu item.

The DVM opens in edit session.

Now you can:

Add rows
Edit rows
Delete rows

Add a new row to the DVM

Click Add Domain Values.

The Add Domain Values dialog is displayed.

Enter the values using a different key than 1.

Click OK.
The entered values are added to the DVM.

Edit a row in the DVM

Select the row that you want to edit.
Click Edit Domain Values.

The Edit Domain Values dialog is displayed.

Edit the values as required and click OK.

Save the DVM

Every time a DVM is opened in edit session, a sandbox is created per DVM, per user. If you save your changes, the changes are saved in your sandbox. For saving the changes, you must click the Save menu item.

If your changes are saved successfully, you get a notification.

You can also revert a DVM to the last saved state by clicking the Revert menu item.

A confirmation dialog is displayed.

Click Yes to revert your changes.

Committing Changes at Runtime

You must commit the changes in order to save them permanently. Once you commit the changes, runtime picks up the changes and saves them in the MDS repository. In a session, you can save your changes without committing them too. In such a case, the DVM remains in the Saved state. You can reopen the DVM and commit the changes later.
Click the Commit menu option.

A confirmation dialog is displayed.

Click Yes to commit your changes.
After you've saved your changes, test the BPEL process again to make sure the changed values are used.

Delete a row in DVM

Select the rows that you want to delete and click Delete Domain Values.

Conflict Detection

SOA Composer detects the conflicts that can occur among concurrent users. You will see a warning if you open a DVM that is being edited by another user.
However, if you still want to edit the DVM, click Yes and make the modifications.
If the other user makes changes to the DVM and commits the changes, you will see a warning if you attempt to commit your changes:

If you click Yes and commit your changes, your changes will overwrite the changes made by the other user.

Key Takeaways and Recommendations

The sample above illustrates how Domain Value Maps can be used within a BPEL process or Mediator to look up dynamic data at run-time and how the data can easily be changed by an administrator without the need to move through the complete, rigorous IT re-deployment process.
Although this was not originally the intended use-case for DVM, it provides a compelling and complete solution to the challenge of migrating dynamic WLI behaviour.
Domain Value Maps are simple to setup in JDeveloper initially and to manage in production using Composer. Furthermore, the administrator has simple production tooling for dynamically changing application behaviour without the need for knowledge of XML.
Key Takeaways:

SOA Suite provides complete and integrated support for all WLI use cases and techniques
SOA Suite provides a mechanism for achieving dynamic lookup for applications that is analogous to that provided in WLI
- Qualifiers enhance the power of dynamic lookup of runtime values
- DVM integration reduces code complexity by enabling cleaner process models
- SOA Composer enables lower operation cost allowing operations to focus on what to change, not on how to change XML
SOA Suite and DVM enable systematic reuse of dynamic data across applications with DVM in SOA Suite composites (including mediator and BPEL PM).

Oracle WebLogic Integration's Custom Control and SOA Suite Spring Component

2011-09-08T07:51:00.000-07:00

(From http://www.oracle.com/technetwork/topics/soa/wli-custom-control-spring-component-091819.html)

Introduction

Custom Java code is an essential part of every Oracle WebLogic Integration (WLI) business process (JPD). Although most components of Oracle SOA Suite are XML-centric, Oracle is adding support for Spring components to give the developer full Java support and a powerful IOC container. The Spring components are available since SOA Suite 11g PS2.
This article explains how a Spring component in SOA Suite provides the same functionality as a Custom control in WLI. It uses the example of a logger component to describe step-by-step how the Spring component is implemented and deployed.
This article is intended for WLI developers and architects who want to get started with SOA Suite 11g.

Custom Control in WLI

WLI uses a custom control to encapsulate Java code (e.g. access to a resource or application functionality) which can then be used in a WLI process (JPD) by dragging-and-dropping the control method into the process.
Users can build their own custom controls that are based on the same framework on which system controls are based. A user designs a custom control from the ground up, designing its interface and implementation, and adding other controls as needed.

Spring Component in SOA Suite

Oracle SOA Suite uses its Spring Java component to implement specific business logic in Java, without ever worrying about XML.
Spring (see SpringSource) is an IOC container (Inversion of Control; see Inversion of Control Containers and the Dependency Injection by Martin Fowler) that allows dependency injection via configuration. So while it presents a little overhead when exposing one JavaBean without any dependencies, the more external components are needed, the easier it becomes to use.
While the main components of Oracle SOA Suite are based on XML as data-exchange format, the goal of this component is to allow seamless Java integration and hence the reuse of Java components and skills. Once a component is implemented, it can be subsequently exposed as service, and invoked from other components such as BPEL.
Using Java classes in a composite can be easily achieved through following a few steps.
a) Create a Java interface, and expose the methods that should be publicly available.

public interface IInternalPartnerSupplier
{
    /**
     * Get a price for a list of orderItems
     * @param pOrderItems the list of orderitems
     * @return the price
     */
    public double getPriceForOrderItemList(List pOrderItems)
        throws InternalSupplierException;
}

b) Create an implementation of this interface.

public class InternalSupplierMediator implements IInternalPartnerSupplier
{
    /**
     * Get the price for a list of orderItems and write the quote via
     * injected reference
     * @param pOrderItems the list of orderItems
     * @return the price for the list of orderItems
     */
    @Override
    public double getPriceForOrderItemList(List pOrderItems)
        throws InternalSupplierException
    {
        // just return a default price - or do something else ..
        return 0.0;
    }
}

c) Create a spring component, which also gives you a spring context, and create a bean, which describes the class created in Step b). Give it a name (so it can be referenced) and declare the class.

d) Create an that exposes a bean as a service. A component must have a service declared, in order to be usable by other components' references.

Once a spring component, including a service, is created, it can be wired to any other component, as illustrated in Figure 1, below.

Figure 1

Use case example: a simple logging component

A very common example of a WLI Custom Control is a custom logger which is used at certain points in a process. In this case, we will log the name of the process, the instance ID and a log message.

Implementing the use case in WLI

This use case is not described in great detail as it is assumed that the audience knows how to create and use custom controls in WLI. The focus area is the Spring component in SOA Suite.
The logger control in WLI consists of two java files:
The interface class LoggerControl.java

package sample.oracle.otn.soaessentials.javainteg.controls;
/**
 * Simple logger interface
 * @author simone.geib@oracle.com
 * @author clemens.utschig@oracle.com
 */
import org.apache.beehive.controls.api.bean.ControlInterface;

@ControlInterface
public interface LoggerControl {

    /**
     * Implementation of the log method
     * @param pProcessName the name of the originating process
     * @param pInstanceId the instanceID
     * @param pMessage the message to be logged to std.out
     * @see sample.oracle.otn.soaessentials.javainteg.ILoggerComponent#log
     */
    public void log (String pProcessName, String pInstanceId, String pMessage);

}

The implementation LoggerControlImpl.java

package sample.oracle.otn.soaessentials.javainteg.controls;
import org.apache.beehive.controls.api.bean.ControlImplementation;
import java.io.Serializable;
/**
 * Implementation of a simple logger component
 * @see sample.oracle.otn.soaessentials.javainteg.ILoggerComponent
 * @author simone.geib@oracle.com
 * @author clemens.utschig@oracle.com
 */
@ControlImplementation
public class LoggerControlImpl implements LoggerControl, Serializable {
 private static final long serialVersionUID = 1L;
 
    /**
     * Implementation of the log method
     * @param pProcessName the name of the originating process
     * @param pInstanceId the instanceID
     * @param pMessage the message to be logged to std.out
     * @see sample.oracle.otn.soaessentials.javainteg.ILoggerComponent#log
     */
    public void log(String pProcessName, String pInstanceId, String pMessage)
    {  
       StringBuffer logBuffer = new StringBuffer ();
       logBuffer.append("[").append(pProcessName).append("] [Instance: ").
        append(pInstanceId).append("] ").append(pMessage);
 
       System.out.println(logBuffer.toString());
    }
}

Figure 2 shows the logging control in a JPD Data Palette.

Figure 2

Figure 3 shows the use of the logging control in a JPD

Figure 3

Implementing the use case in SOA Suite

In this section, we will create a simple logging component that can be used from other components, such as BPEL Process Manager or Mediator, to log messages, including the originating instance ID, to standard out.

Creating the Spring Component

To get started, create a new Application in JDeveloper, name it " SOASuiteWLIEssentials"...

Figure 4

And create a new Project named " JavaIntegration".

Figure 5

Click " Finish."
Create a new Java Package " sample.oracle.otn.soaessentials.javainteg" (this requires several steps).

Figure 6

Create a new Java Interface, named " ILoggerComponent" in the " sample.oracle.otn.soaessentials.javainteg" package.

Figure 7

Figure 8

Add a new method to the interface, named " log", with parameters for the originating component, the instance ID, and the message.

package sample.oracle.otn.soaessentials.javainteg;

/**
 * Simple logger interface
 * @author simone.geib@oracle.com
 * @author clemens.utschig@oracle.com
 */
public interface ILoggerComponent
{
   
    /**
     * Log a message, including the originating component, its instance id and
     * a message.
     * @param pComponentName the name of the component that sends this log msg
     * @param pInstanceId the instanceId of the component instance
     * @param pMessage the message to be logged
     */
    public void log (String pComponentName,
                     String pInstanceId, String pMessage);
}

Figure 9

Create a Java class (" LoggerComponentImpl") from the interface " ILoggerComponent".

Figure 10

Name the class and click on the plus sign to find the interface on which to base the class.

Figure 11

Figure 12

Figure 13

This is the implementation of the logging component:

package sample.oracle.otn.soaessentials.javainteg.impl;

import sample.oracle.otn.soaessentials.javainteg.ILoggerComponent;

package sample.oracle.otn.soaessentials.javainteg.impl;

import sample.oracle.otn.soaessentials.javainteg.ILoggerComponent;

/**
 * Implementation of a simple logger component
 * @see sample.oracle.otn.soaessentials.javainteg.ILoggerComponent
 * @author simone.geib@oracle.com
 * @author clemens.utschig@oracle.com
 */
public class LoggerComponentImpl implements ILoggerComponent
{

    /**
     * Implementation of the log method
     * @param pComponentName the name of the orginating component
     * @param pInstanceId the instanceid
     * @param pMessage the message to be logged to std.out
     * @see sample.oracle.otn.soaessentials.javainteg.ILoggerComponent#log
     */
    @Override
    public void log(String pComponentName, String pInstanceId,
                    String pMessage)
    {
        StringBuffer logBuffer = new StringBuffer ();
        logBuffer.append("[").append(pComponentName).append("] [Instance: ").
            append(pInstanceId).append("] ").append(pMessage);
        
        System.out.println(logBuffer.toString());
    }
}

In the next few steps, we will create a new Spring context ("logger-context.xml"), define a Spring bean ("logger"), and expose the bean as a service ("logService").

Figure 14

Figure 15

Next, drag a bean from the Component Palette...

Figure 16

Onto the the spring context canvas.

Figure 17

Name it "logger" and declare a class attribute pointing to the implementation.

Figure 18

Now the bean can be exposed as an SCA service.
To do so, change the drop-down in the component palette to " Spring 2.5 SCA" and drag a " service" onto the canvas.

Figure 19

Give the service the name " logService". Its target will be the " logger" bean.

Figure 20

Finally, pick the type, which is the interface of the LoggerComponent class (" sample.oracle.otn.soaessentials.javainteg.ILoggerComponent").

Figure 21

Figure 22

The completed spring context looks like this:

<?xml version="1.0" encoding="windows-1252" ?>
<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:util="http://www.springframework.org/schema/util"
       xmlns:jee="http://www.springframework.org/schema/jee"
       xmlns:lang="http://www.springframework.org/schema/lang"
       xmlns:aop="http://www.springframework.org/schema/aop"
       xmlns:tx="http://www.springframework.org/schema/tx"
       xmlns:sca="http://xmlns.oracle.com/weblogic/weblogic-sca">
  <!-- expose the logger bean as service -->
  <sca:service name="logService" target="logger"
               type="sample.oracle.otn.soaessentials.javainteg.ILoggerComponent"/>
  <!-- declaration of the logger bean -->
  <bean name="logger"
    class="sample.oracle.otn.soaessentials.javainteg.impl.LoggerComponentImpl"/>
</beans>

Create a new composite and name it " JavaIntegration".

Figure 23

Use the "create with BPEL Process" option and name the process " BPELProcessWithLogger". Leave the rest with default settings.

Figure 24

Figure 25

Figure 26, below, shows the newly created BPEL process with a receive and a callback activity.

Figure 26

Switch back to the composite view, and drag a " Spring Context" onto the composite canvas. Name it " logger-context" and pick the spring context you created earlier.

Figure 27

Figure 28

Compile the Java classes so you can create a valid WSDL definition that can be used from within a BPEL process.

Figure 29

Drag the service of the spring component over to the BPEL process. This will create a wsdl and a partnerlink in the process.

Figure 30

Figure 31

Next, drag an invoke activity from the component palette onto the BPEL canvas. This will be used to invoke the log() method on the log service created earlier.

Figure 32

Wire invoke to the partnerlink for the logger service.

Figure 33

Create input and output variables. They will be used later to assign the values for component name, component instance id and a log message.

Figure 34

With the finished invoke activity, the process should resemble Figure 35, below.

Figure 35

In order to populate the created variables, drag an assign activity from the palette onto the BPEL process.

Figure 36

In the next three steps you will create the necessary copy rules to populate the input variable.
Double-click the assign activity and add a copy operation to assign the component name to the first parameter.

Figure 37

Add another copy operation to assign the process instance id to the second parameter.

Figure 38

Add a third copy operation to assign a message to the third parameter.

Figure 39

Make sure the assign activity contains all three copy rules.

Figure 40

Once all the copy rules have been built, the process should resemble Figure 41, below, with an initial receive, the assign for the log message values, followed by an invoke of the log service's log method, and finally, a callback, implemented via invoke.

Figure 41

Deploying the SOA Composite

The next step is to deploy the composite with Oracle JDeveloper. Please make sure that your SOA server is running.
Please check Section 43 in Deploying SOA Composite Applications to learn how to deploy SOA composite applications with Oracle JDeveloper and scripting tools and create configuration plans that enable you to move SOA composite applications to and from development, test, and production environments.
Please check Section 5 in Deploying SOA Composite Applications to learn how to deploy, redeploy, and undeploy a SOA composite application from Oracle Enterprise Manager Fusion Middleware Control Console.
When deploying the composite from within JDeveloper, the log should look similar to the one below:

[06:15:55 AM] ----  Deployment started.  ----
[06:15:55 AM] Target platform is  (Weblogic 10.3).
[06:15:55 AM] Running dependency analysis...
[06:15:55 AM] Building...
[06:16:11 AM] Deploying profile...
[06:16:11 AM] Updating revision id for the SOA Project 'JavaIntegration.jpr' to '1.0'..
[06:16:12 AM] Wrote Archive Module to C:\JDeveloper\mywork\SDOStuff\JavaIntegration\
              deploy\sca_JavaIntegration_rev1.0.jar
[06:16:12 AM] Deploying sca_JavaIntegration_rev1.0.jar to soa_server1 
              [sta00251.us.oracle.com:8001] 
[06:16:12 AM] Processing sar=/C:/JDeveloper/mywork/SDOStuff/JavaIntegration/deploy/
              sca_JavaIntegration_rev1.0.jar
[06:16:12 AM] Adding sar file - C:\JDeveloper\mywork\SDOStuff\JavaIntegration\deploy\
              sca_JavaIntegration_rev1.0.jar
[06:16:12 AM] Preparing to send HTTP request for deployment
[06:16:12 AM] Creating HTTP connection to host:sta00251.us.oracle.com, port:8001
[06:16:13 AM] Sending internal deployment descriptor
[06:16:13 AM] Sending archive - sca_JavaIntegration_rev1.0.jar
[06:16:41 AM] Received HTTP response from the server, response code=200
[06:16:41 AM] Successfully deployed archive sca_JavaIntegration_rev1.0.jar to 
              soa_server1 [sta00251.us.oracle.com:8001] 
[06:16:41 AM] Elapsed time for deployment:  46 seconds
[06:16:41 AM] ----  Deployment finished.  ----

Testing the BPEL Process

After successful deployment, you can initiate the composite service through Oracle Enterprise Manager Fusion Middleware Control Console (Enterprise Manager).
To log in to Enterprise Manager, use Internet Explorer 7, Mozilla Firefox 2.0.0.2, or Firefox 3.0.x to access the following URL: http://host_name:port/em. (Where host_name is the name of the host on which Enterprise Manager is installed and port is a number that is dynamically set during installation.)
Enter weblogic/password and click Login.
Please check Getting Started with Administering Oracle SOA Suite for more information.

Figure 42

Locate the JavaIntegration composite on the EM dashboard and click on it. This will get you to the composite homepage:

Figure 43

Once on the page, you can test a composite service.

Figure 44

Fill in " clemens" as input and click " Test Web Service"

Figure 45

Once the instance is created, you can click on the Launch Message Flow Trace which will get you to the composite instance:

Figure 46

You can check the BPEL instance flow as well, which will show you the actual message that was passed to the spring component:

Figure 47

Check the standard output of the server, that hosts the soa suite. It should show an entry similar to the one below:

==> CubeEngine deploy BPELProcessWithLogger took 4 seconds
INFO: DeploymentEventPublisher.invoke Publishing deploy event for 
default/JavaIntegration!1.0*c39dc7a2-5031-424e-9ae0-aeec949769b3
[BPELProcessWithLogger] [Instance: 20009] Got input: clemens

Download the complete project

A zip file contiaining the complete project, including the java sources and the composite, is available for download: wli-soaessentials-JavaIntegration-source.zip. To open it in JDeveloper, create a new Application, and then open the project file (JavaIntegration.jpr)

Key Takeaways and Recommendations

Java can be seamlessly embedded into the composite / xml based world.
Multiple Java beans can be easily exposed as services, or get external references injected - just by declaring, and later wiring them.
No need to code around XML, inside the Spring component - it's POJOs.

In order to create reusable entities and beans, a spring context can be packaged and deployed itself, without composite, into the WebLogic Server, and beans can be exposed as EJBs / webservices.
This makes it very easy to create reusable Java components that can be used from within a BPEL process or a Mediator component in the same way as a WLI JPD uses custom controls.

Clustered Caching with Tangosol Coherence

2011-09-07T12:59:00.000-07:00

(From http://mdavey.wordpress.com/2007/01/16/clustered-caching-with-tangosol-coherence/)
Below, in no particular order are a few items worth noting about Tangosol:

When installing Tangosol, make sure all the nodes are running the same version
Don’t use any classes in the component.net packages – Coherence was build with its own development environment, compiler etc. component.net contains these internal components.
BetFair a few years ago had 80 nodes running Tangosol Coherence. The largest installation today is around 1000 nodes.
Coherence uses TCMP (UDP based) protocol for data movement
From an installation perspective, 5 machines is probably the minimum requirement. Lots of RAM for each machine, installed across different racks to reduce the risk. The more machines the Coherence cluster contains, the lower the risk.
All machines in the cluster should be configured with identical config files, network settings, NIC’s (full/half duplex) etc.
Multi-cast disconnect issues can be as simple as a miss-configured router.
Production checklist
Near Topology (near-*)
During development set TTL=0 and changing the group address and port.
Client that come/go from the Coherence cluster should set local storage=false, while cluster servers should set local storage=true
NamedCache.putAll is far more efficient that put since it can reduce network hops.
Prior to cluster usage, run the multicast test for 24 hours.
Use Ethereal or similar to monitor the network to help identify unreliable sockets and NIC configuration issues.
Java serialization can be a performance bottleneck, consider using Coherence’s ExternalizableLite and its helper, ExternalizableHelper. Externalizable offers reduced GC and ~6x speed improvement.
High ticking volumns can cause problems for any application. In the case of Tangosol, and caching ticks, one possible solution is to queue the incoming ticks, and use a thread pool to insert the ticks into the cache.

Tangosol Coherence as its simplest:

import java.io.IOException;

import java.util.Date;
import com.tangosol.net.CacheFactory;
import com.tangosol.net.Cluster;
import com.tangosol.net.NamedCache;

public class firstExample {
public static void main(String[] args) throws IOException {
    try {
      Cluster cluster = CacheFactory.ensureCluster();
      System.out.println(cluster);

      NamedCache myCache = CacheFactory.getCache(“test”);
      Object existingVale = myCache.put(“message”, “someMesasge “ + new Date());

      System.out.println(“Existing Val :” + existingVale);

      Object val = myCache.get(“message”);
      System.out.println(“Val :” + val);
      System.out.println(“Press any key”);
      System.in.read();
    }finally {
      CacheFactory.shutdown();
    }
}
}

Getting started with Tangosol Coherence

2011-09-07T12:27:00.000-07:00

(From http://www.javalobby.org/java/forums/t78008.html)

This tip will get you started with Coherence so you can see how easy it is to begin to use in your applications for caching data within a cluster.

Grab a download of Coherence and unzip it, say into a directory called tangosol

Run the cache-server.cmd located in the tangosol/bin directory (replace the .cmd with .sh if you're running on *NIX). This starts a cache server which is storage enabled - the storage enabled bit simply means that this member within the cluster will store data.

Compile and run the below little program, it puts a couple of entries into a cache. It then gets their values out, along with a couple entries which don't currently exist in the cache.

The only JARs you need to reference are tangosol.jar and coherence.jar in the tangosol/lib directory.

import com.tangosol.net.CacheFactory;
import com.tangosol.net.NamedCache;

public class Tip1 {
public static void main(String[] args) {
    NamedCache cache = CacheFactory.getCache("people");

    String key1 = "dave";
    cache.put(key1, new Long(36));
    String key2 = "jenny";
    cache.put(key2, new Long(25));

    String key3 = "stan";
    String key4 = "jane";

    System.out.println(key1 + "=" + cache.get(key1));
    System.out.println(key2 + "=" + cache.get(key2));
    System.out.println(key3 + "=" + cache.get(key3));
    System.out.println(key4 + "=" + cache.get(key4));
}
}

Next run coherence.cmd in the tangosol/bin . This starts a nice little command-line application which allows you to explore some of Coherence's functionality without writing any programs.

At the Coherence command-line application's prompt type cache people - this just tells the command-line application that we want to manipulate the people cache. Some XML should have been displayed for the default distributed cache. The distributed cache is nowadays referred to as a 'partitioned cache' to better describe what it is actually doing with the data within the cluster.

Type get dave and press enter, you should see the value for Dave.
Next type put stan 55 and press enter, then put jane 40 . This will put two new entries into the cache using the Coherence command-line application.
Run the Tip1 application again and you should now see values for Stan and Jane.
From the Coherence command-line application, type remove stan .
Running the Tip1 application will show that Stan no longer has an entry.

To remove an entry using Java code simply use cache.remove(key) . As you might have noticed by now, it all seems very Map like - it is, because Coherence's NamedCache interface extends from interfaces which extend from java.util.Map.

For a bit of fun, start another cache-server.cmd and from Coherence command-line application type: get jane . You'll see no difference from before, the value will be displayed.

Now, kill the first instance of the cache-server.cmd and from the Coherence command-line application type get jane . Yep - still no difference, Coherence has automatically failed over without any loss of data. The data had been partitioned (split) across the two cache servers, when one of them was killed, the other simply promoted the 'backups' it was storing to be the primary copies ensuring all of the data was still accessible. If you start the first instance again, then Coherence will seamlessly 'fail back'.

Hope this gets you going with Coherence. If you want to explore the Coherence command-line application a little more then type help to see the valid commands and their syntax. The following link has descriptions for many of the commands: http://forums.tangosol.com/thread.jspa?threadID=51&tstart=0

Don't forget to check out the Wiki as well: http://wiki.tangosol.com

Using Shared Object in Soa Suite 11g with MDS

2011-09-01T20:39:00.000-07:00

(From http://biemond.blogspot.com/search/label/MDS)

Inspired by Eric Elzinga , who was wondering how MDS can work in Soa Suite 11g , I made some screenshots how you can use a XSD from a central MDS repository in your composite application. Clemens already blogged about re-using common metadata and he made a great ant utility to import or delete MDS files. For 11G R1 PS1 or higher use this instead of the Clemens utility

First I make a local MDS repository. If you install the Soa plugin you already have a seed folder in the integration folder. Under this folder create an new folder called apps. ( this have has to be apps else you will get a permission denied error ) . Under this apps folder we can create our own definitions.

To use my local SOA-MDS repository I create a new MDS File Connection

I want to re-use these common objects in every Soa project so I choose for the resource palette option

select the seed folder in the integration folder

Here we can see our common application objects.

Open the application resources window and open the adf-config.xml

Here we define a new metadata namespace with apps as path. And use the integration folder as metadata-path value.

We are ready to use these common objects in a mediator.. Here I will use a schema from the local MDS as input parameter for the mediator.

Import a new schema

Select the resource browser and here we can select our schema from the local MDS

I uncheck the Copy to project option, because this XSD already exists in the MDS

Our Project is ready but If we want to deploy this Soa project, we will receive a error, it can't find the schema. So we need to export the local MDS files to the SOA Suite database MDS.

To do this we have 2 options , the first option is to create a MAR deployment ( Application properties ) or do this with Ant.

I stripped the Clemens ant project so this ant build file has only two tasks , add and delete. It uses the adf-config.xml ( config folder) for the location of the target MDS and I use the local MDS as source.

Here is the target adf-config.xml which is located in the config folder

Change the build.properties so it matches your environment

This will import your local MDS object to the remote MDS. After this you can deploy your Soa Suite project.

Here you can download my ant project. Thanks to Clemens.

Active the installed adapters in Oracle SOA suite.

2011-09-01T15:36:00.000-07:00

Recently, I installed the latest version of Oracle SOA Suite, but I found there are some adapters' status is not active, such as SocketApdater and OracleAppsAdapter. Googled on the internet and found somebody said these adapters weren't deployed to a target server. I checked the setting of these adapters on targets tab and it is true. By selecting the target server, the adapter becomes active and then the configuration works.

Re-using common metadata (wsdl / xsd / edl) in SOA Suite 11g

2011-08-31T12:14:00.000-07:00

(From http://blogs.oracle.com/soabpm/entry/reusing_common_metadata_wsdl_x)

As promised here is the first of a set of tips for the brand new SOA Suite 11g.

Managing dependencies between services at development as well as runtime is a challenging task when people implement Service-Providers and -Consumers.

There are a few approaches that worked well in the past and will continue to work well on 11g - yet there are a few notable differences between the releases that should make dependency mgmt way easier in 11g.

Preface:
In the 10.1.3. BPEL world we used to have one global cache for wsdls and schemas. Hence having twice the same (with possible differences) would get you one that overwrites the other.

In 11g SOA Suite, each composite (and revision) has its own store for artifacts, so they don't clash.

Four approaches are in use today (in 10.1.3.x)

a. not preferred at all) Don't bother much and have copies of concrete wsdls in your consuming artifacts. Well that is not sharing, and if the provider changes you need to redeploy the consumer

b. and still not a good approach) Reference the deployed concrete wsdl of a Service Provider. Problem here: Provider not deployed, consumer can't compile or be deployed

c. and the first step to reuse) Introduce a common directory of abstract wsdls and copy them around from project to project. Use wsdlRuntimeLocation on the partnerlink to point to the concrete implementation. Eventually change that during deployment time with the deployment plan.

d. and the next step to reuse) Store abstract wsdls on a centrally accessible endpoint (that might be a war or just an http server) employ the same approach from (c). Problem here - we cache them, you need to refresh the wsdl cache on the BPEL Server.

In SOA Suite 11g we introduced a set of changes that helps you sharing, notable the biggest being the introduction of MDS (MetaData Service) that backs your application (and hence your composites) at designtime as well as runtime.

Think of MDS like a version management system that is used all accross the platform, that you can use to share common artifacts at design and runtime.

So where is your mds located, and how does an application know which one to take?

The configuration sits in $application_home/.adf/META-INF/adf-config.xml and by default points to your local - JDeveloper file system based mds.

Let's examine mine used for fusion order demo

The first important thing to note is the store type. By default this is file based - described with oracle.mds.persistence.stores.file.FileMetadataStore. Now the base path to your mds is described with the property called metadata-path. From here on you can have multiple partitions, but usually one per application. In our case, the partition is called seed. From here, namespaces are used that map to directory structures. These are defined in the section, and by default you get the one that points to internally shared artifacts for your SOA projects, called /soa/shared.

How is mds used in your SOA project then? For example if you create a business rule (yup and that is one of the new features on the JDeveloper UI side) we create you a bunch of artifacts, but the common ones are imported from mds.

An example is
<xsd:import namespace=http://xmlns.oracle.com/bpel
schemaLocation="oramds:/soa/shared/rules/BpelProcess.xsd"/>

Note the namespace being used. If you follow the directory structure based on your adf-config.xml you find this schema. In my case the BpelProcess.xsd is located in C:\JDeveloper\JDev_11.1.1.0\jdeveloper\integration\seed\soa\shared\rules.

A few thoughts here to consider (and succeed):
a) this default namespace is reserved for soa suite infrastructure, and something you should NOT use

b) if you add stuff to the local mds and use it through oramds:/, you need to transfer those artifacts to the server MDS, so the deployment does work.

c) the namespace you should use, that is known to the soa server as well is called apps. To use it - add another namespace to, as I did above in my adf config that says , and create an apps directory under the seed folder. On the server this directory is already there.

Using the shared artifacts:

If you expand the resource browser, there is a section called soa mds connections. Create one for your local environment by picking file as type and specify $ORACLE_HOME\jdeveloper\integration\seed. Whatever you pick now in the resource browser when you work on your composite will be automatically based on the right urls.

Last but not least - create a mar deployment profile on the application level with those shared artifacts, and deploy them to the server.

Oracle SOA 11g MDS

2011-08-24T20:34:00.000-07:00

(From http://markchensblog.blogspot.com/2011/08/oracle-soa-mds.html)

A metadata repository is the centralized store for the metadata used for the applications in Oracle SOA. It is very useful since most organizations and companies have their own common data models defined as XML schema and WSDL files. These files are organized in some hierarchies and there are dependencies among them. Obviously it is not wise to have local copies of these files for each SOA application. The metadata repository: MDS – Metadata Store in Oracle SOA provides to share these common metadata among the various SOA applications.

In Oracle SOA there are two types of MDS: file-based and database-based. File-based MDS uses the file system to store all these metadata and database-based uses the database. File-based MDS is only used for the development purpose. If the application is deployed on sever the database-based MDS must be used.

File-based MDS

Normally when you do the SOA application development using JDeveloper you usually uses file-based MDS. It is much easier to use file-based MDS for the development purpose. For each application there is one adf-config.xml located in YourAppFolder/.adf/META-INF folder.

In the adf-config.xml the element defines the metadata-namespace and metadata-store-usage from which we know where the shared artefacts. In this example the wsdl and schema files are located in the folder:

D:\Oracle\Middleware\jdeveloper\integration\seed\apps\SOInterfaces-2.3.9.8

where D:\Oracle\Middleware\jdeveloper\integration is the metadata-path and seed is partition-name and apps\SOInterfaces-2.3.9.8 is the namespace-path.

After the artefacts are put into the right file folder specified in adf-config.xml you can create one MDS connection in JDeveloper to view all the wsdl and schema files in the MDS.

From JDeveloper right click on Applic ation Resources->Connections and then select SOA-MDS from New Connection menu item. Then in the popup window: Create SOA-MDS Connection type in the Connection Name and choose File Based MDS as the Connection Type and type in the MDS Root Folder as: D:\Oracle\Middleware\jdeveloper\integration\seed. You can test the connection by clicking on Test Connection button. If the test is su ccessful click on OK button.

After the MDS connection is created you can see it from IDE Connections in JDeveloper.

Once the MDS is created you use it in your development. For example in your BPEL application you can choose one WSDL from MDS as the service interface of the BPEL process.

In the application one artefact such as wsdl or xsd is referenced it will be referred using oramds protocol. The below is one example from a wrapper wsdl.

location="oramds:/apps/SOInterfaces-2.3.9.8/BSC/OrderAndActivation/Activation/ServiceProvisioning-v1.wsdl"

logging.xml	java.util.logging.Level
INTERNAL_ERROR:1	SEVERE.intValue()+100
ERROR:1	SEVERE
WARNING:1	WARNING
NOTIFICATION:1	INFO
NOTIFICATION:16	CONFIG
TRACE:1	FINE
TRACE:16	FINER
TRACE:32	FINEST