Installing OSB 11.1.1.6 with OSB IDE on windows 7 64 bit

Installing OSB on windows 7 64 bit:

It is not very straight forward to install OSB server, OSB IDE ,weblogic on windows 7 64 bit. For 32 bit we get OEPE with weblogic which is quite easy to install, but on 64 bit you don't have OEPE with weblogic. You need to install weblogic separately then install OEPE . Here selecting the OEPE version is tricky. If weblogic version is 11.1.1.6 , it does not mean you have to select OEPE version of 11.1.1.6. It will not work. Infact the correct version of OEPE is 11.1.1.8. Now what about OSB? which version should be selected? OSB should be of version 11.1.1.6 . So in summary

weblogic: 11.1.1.6

OEPE: 11.1.1.8

OSB 11.1.1.6

Important points

1)Weblogic and OSB versions should be same if you want OSB IDE to be installed.

So weblogic is 11.1.1.4 , then OSB should be 11.1.1.4.

Incase if they don’t match then while installing OSB (from osb_generic_11.1.1.4) you may get error as “weblogic is not suited for this version of IDE” at step 4 (Typical/Custom step)

2)OEPE should be compatible with the OSB version.

Here are the list of compatible OEPE with OSB . There is no document for this though

OSB Weblogic Server OEPE

11.1.1.6.0 10.3.6 11.1.1.8.0

11.1.1.5.0 10.3.5 11.1.1.7.2

11.1.1.4.0 10.3.4 11.1.1.6.1

11.1.1.3.0 10.3.3 11.1.1.5

STEP1: Install JDK

Install JDK (Jrockit can be preferred)

jrockit-jdk1.6.0_26-R28.1.4-4.0.1-windows-x64(1) should be installed .Always prefer Jrockit over JDK as Jrocking has very good performance

STEP2: Install Weblogic

1. Open a terminal and go to the folder where wls1036_generic file is.

2. Execute the following command:

Double click on the file

3. When the oracle weblogic installer starts, click next and enter the folder you want to use as Middleware Home Directory, for example:

E:\InstalledSoftwares\oracle\fmw11116

4. Choose the typical installation (or customise if you need). Better to select customize as you can install examples also

5. On the JDK installer screen, the installer should automatically recognise the JDK installed during step 1. If not, click on “Browse” button and point to JDK directory (e.g. /jrocking).

6. Finish the installation.

STEP 3 – Install Oracle Enterprise Pack for Eclipse

Download from

http://www.oracle.com/technetwork/developer-tools/eclipse/downloads/index.html

Just extract the oepe-indigo-all-in-one-11.1.1.8.0.201110211138-win32-x86_64

content into a folder named “oepe” in you middleware home directory, for example:

E:\InstalledSoftwares\oracle\fmw11116\oepe-indigo11.1.1.8.0_64

STEP 4 – Install OSB

Download from :http://www.oracle.com/technetwork/middleware/service-bus/downloads/index.html

1. Extract the downloaded zip file (ofm_osb_generic_11.1.1.6.0_disk1_1of1) into a any folder. Go to that “Disk 1” directory under the extracted folder and run the following command:

E:\softwares\OSB\ofm_osb_generic_11.1.1.6.0_disk1_1of1\Disk1>setup -jreLoc E:\InstalledSoftwares\jrockit

2. we have provided the JDK location in the above command

3. During the rest of the installation used the settings below

Installation location:

Oracle Middleware Home :E:\InstalledSoftwares\oracle\fmw11116\

Oracle Home Directory: Oracle_OSB1

Installation Type: Custom (ensure that ORACLE BUS IDE is selected).

Note the following in “Typical”. If the version is not matched it would say weblogic version is not compatible with OSB IDE. Then in “CUSTOM” you won’t be able to select the ORACLE BUS IDE. This means that weblogic which is selected is of different version say 11.1.1.4 and OSB_GENERIC is of different version say 11.1.1.6

Prerequisite Checks – This stage passes

Product Home Location:

Weblogic Server Location: / E:\InstalledSoftwares\oracle\fmw11116\wlserver_10.3

OEPE Location E:\InstalledSoftwares\oracle\fmw11116\oepe-indigo11.1.1.8.0_64

Note the following: The OEPE location is automatically taken. Suppose if OEPE version is not compatible with OSB , then OEPE will not get recognized. You will get message as “OEPE” location is invalid even if you manually select the OEPE. So in this example OEPE should be 11.1.1.8 and OSB should be 11.1.1.6

Step5: Verify the OSB IDE

Check if OSB IDE has been installed or not

Open the eclipse ide from the below location

E:\InstalledSoftwares\oracle\fmw11116\oepe-indigo11.1.1.8.0_64

Set the workspace to any folder

Check the following

Window->open perspective->other->Oracle Service bus

You should be able to see the Oracle Service bus

Step6)Configuring the OSB SERVER or creating the domain

a) Go to E:\InstalledSoftwares\oracle\fmw11116\Oracle_OSB1\common\bin

b) Config.cmd

c) Select new domain creation.

d) Select the configuration as shown below so that we get OWSM,EM etc

e) give the domain name as osb_domain

f) Give username as weblogic/welcome1

g) Select development mode

h) Give the databse details for OWSM MDS schema(ignore the failure test) and OSB JMS reporting provider

i) Proceed to next step(by pass the DB connection if it asks),

Step 7)Access the sbconsole

Go to the following location:

E:\InstalledSoftwares\oracle\fmw11116\user_projects\domains\osb_domain

And type the following

startWeblogic.cmd

Now access the sbconsole

http//localhost:7001/sbconsole

enter weblogic/welcome1

you should be able the see the screen

for more info. http://aleemkhan09.blogspot.in/2012/04/installing-osb-11116-with-osb-ide-on.html

RESTful Services with Oracle Service Bus

Recently I was asked about REST (see http://en.wikipedia.org/wiki/Representational_State_Transfer)
support in Oracle Service Bus. OSB 10gR3 has full support for REST and
implementing a REST approach in a proxy service is very simple. In this
example, we will create a proxy service that provides a REST interface to a
product catalog.

Why use OSB for REST?

Using the Oracle Service Bus to provide an interface as
simple as REST may seem odd at first. There are several good reasons for this
approach though.

1. You automatically get all of the monitoring, reporting, security and more provided
   by OSB for your RESTful services


2. You keep the benefits of mediation. For example, of our company in this example
   purchased another company that provided different products, you could use the
   OSB to act as a façade over both product catalogs while providing a single,
   unchanged REST interface.


3. You
   can REST-ify existing, non-service enabled assets like EJBs

The Products Proxy Service

Let's get started. First we will create a new OSB
Configuration Project to house our REST services. I named the configuration
project RESTConfig in the sample source code. You can download
the sample source code here.
Inside of the RESTConfig project I then
created a standard OSB project named SimpleREST. Once the OSB
project was created, I was ready to start creating my REST project.
Next I created a proxy service named Products.
I used the default endpoint URI of SimpleREST/Products but in a
production environment you'll most likely want to customize that. Be sure to
define your proxy service as an Any XML Service so you can accept
and return XML of any flavor.
Now it is time to create our message flow. Here is where
it gets interesting. One of the fundamental concepts in REST is the use of the
native HTTP methods to allow the service consumer to express their intent. The
specific HTTP methods that we are interested in are: GET, POST, PUT, HEAD,
OPTIONS and DELETE. In this example I don't make use of the TRACE method.
However, you will be able to add that to your projects easily after reading
this.
The handling of each of those methods is different, so we
begin our message flow with a Conditional Branch node (see figure 1). I added a
branch for each of the methods I was interested in. In the Conditional Branch
node I set the XPath field to ./ctx:transport/ctx:request/http:http-method/text()
and theIn Variable field to inbound. This is the equivalent to the XPath
expression $inbound/ctx:transport/ctx:request/http:http-method/text().
The text() operation at the end is important because I
want to deal with the method in its plain text form and not as an XML
expression.


Figure 1 Standard OSB REST Pattern
When adding the branches it is important to enclose the
contents of the Value field in single quotes (Figure 2) to denote it is a
string value. If you forget this, you will get an error about an unbound XML
node when you run the proxy service because OSB will treat the contents of the
Value field as a variable instead of a string literal.


Figure 2 Don't forget the quotes!
For each branch, add a pipeline pair and name it
appropriately, as shown in figure 1. Before we fill in the GET Pipeline with
the necessary logic, let's take a moment to decide how we want the HTTP GET method
to be handled. Ideally, we want to be able to point a web browser or other REST
service consumer to a URL like: http://localhost:7001/SimpleREST/Products/id=# to
retrieve a product representation by its ID. Since the proxy service is
listening at http://localhost:7001/SimpleREST/Products,
the remainder of the URL (i.e. the id=#) will be accessible in the message
flow as the relative-URI part of the $inbound variable.

The GET Method

Now that we know what the URL should look like for a GET,
we can fill in the logic. In the GET Pipeline (Figure 3) we will add two Assign
actions. The first Assign action will get the first part of the relative URL
(i.e. the id part). We won't do anything
with this part in this example, but you can use this technique to ensure that
the URL used had the correct format. The expression to use in the first Assign
statement is as follows:
fn:tokenize(data($inbound/ctx:transport/ctx:request/http:relative-URI),
'=')[1]
This expression will take the relative-URL value and
tokenize it using the '=' character, returning the first token. So if the
relative-URI is "id=27" this expression will return the "id" string. Why XPath
counts from 1 instead of 0 I don't know. Set the Variable field to attr and you are
done with the first Assign statement.
The second Assign statement is very similar to the first,
except we are retrieving the second part of the relative-URI. Its expression is
as follows:
fn:tokenize(data($inbound/ctx:transport/ctx:request/http:relative-URI),
'=')[2]
Set the Variable field to productID. In the sample code I include
a Log statement to output the contents of these variables to the console


Figure 3 The GET Pipeline
In the Response Pipeline we will construct our response
message for the GET. We will just mock up a product document for this tutorial.
The following code snippet (which you will put into the Expression field
of the Replace action) shows the value that the Replace action will put into
the $body
variable, which is then returned to the caller.
<Product>
<ID>{$productID}</ID>
<Name>Foobar</Name>
<Price>19.99</Price>
</Product>
Listing 1 Constructing the response document
Set the XPath field to just a period (.) and be
sure to select the Replace Node Contents  radio button. If you deploy
the project you can test it using your web browser. Assuming your OSB server is
running on the default port 7001, you can use the following URL:
http://localhost:7001/SimpleREST/Products/id=2
Your web browser should show you the following:
<Product>
<ID>2</ID>
<Name>Foobar</Name>
<Price>19.99</Price>
</Product>
Note: Capitalization counts even with REST
Alternatively, you can use the OSB Test Console instead of
a web browser. I recommend using the Test Console (Figure 4) because it gives
you more control over the service call and visibility into the message flow. To
test the GET method, right-click on the Products.proxy file in the
Workshop IDE and select Debug As -> Debug on Server.... When the Test
Console appears, click on the down-arrow icon in the Transport section. This
will allow you to set the relative-URI and http-method fields directly.


Figure 4 The Transport section of the Test Console
When you are happy with your settings, press the Execute
button to run the test. The Test Console (Figure 5) will return the results and
provide you with the response metadata and the invocation trace, which is
useful when debugging your proxy services.

Figure 5 The Test Console response
Now that we have the GET branch taken care of. Let's take
a quick look at the other HTTP methods that we are supporting.

The POST Method

The HTTP POST method is traditionally used with REST to
create new entities. The message content that is POSTed can be in XML format, or
in the format used by HTML forms, which is still the most common mechanism for
submitting data to a web site in use today. However,, I highly recommend that
you keep your information in XML format instead of the HTML Form format simply
because the HTML Form only  supports the GET and POST verbs, whereas with REST
we also want to use the other verbs, like PUT and DELETE.
The POST Pipeline shows how to handle the POST method. It's
pretty simple in that it extracts the specific information it wants from the
$body and then creates and returns an XML representation, simulating the
creation of a product. You can use the OSB Test Console to test this method by
setting the http-method field to post and then typing in the payload as
follows:
<Product>
<Name>Widget</Name>
<Price>99.99</Price>
</Product>
The two Assign statements in the POST Pipeline simply
extract the name and price information and return a representation of the new
product, with a hard-coded ID of 777

The PUT Method

The PUT method is used to update an entity. It operates
very much like the POST method does, except this method will expect to see the
ID in the submitted product representation. You can test this operation in
pretty much the same way that you tested the POST, just change the http-method
to PUT and use the following as your payload:
<Product>
<ID>999</ID>
<Name>Widget</Name>
<Price>99.99</Price>
</Product>
Here we will add a little error checking to ensure that
the ID for the product has been specified. The If-Then action (Figure 6) uses
the expression: exists($body/Product/ID) to test
for the presence of the ID element.


Figure 6 The PUT Pipeline
If the ID element is defined, we then use a single Assign
statement to create our entire response document as follows:
<Product>
<ID>{$body/Product/ID/text()}</ID>
   <Name>{$body/Product/Name/text()}</Name>
   <Price>{$body/Product/Price/text()}</Price>
</Product>
If the ID element is missing from the $body, then we throw
an error to alert the service consumer of the problem. In the response pipeline
we simply set $body
to the value of $responseDoc, what was created in our Assign statement.

The HEAD Method

The HEAD method is used to return metadata about a
representation to the caller. It's called the HEAD method because the metadata
is returned in the HTTP headers. This metadata can be anything you want it to
be, but a good place to start is the standard HTTP headers used by the
Inbound-Response to the Inbound-Request. Figure 6 shows the message flow for
HEAD Pipeline (Figure 7). All we do is populate the data of a single Transport
Header action in the response pipeline.

Figure 7 Implementing the HEAD method
Its up to you and your specific needs to define which
headers you want to send back for the HEAD method, but I recommend sending at
least the HTTP Content-Type header with a value along the lines of 'text/xml; charset=utf-8'.
This will help the HTTP clients know how to parse the text that is returned.
Setting the Connection header to 'keep-alive' is also generally a good idea.

The OPTIONS Method

Finally, the OPTIONS method is used to convey to the
caller which HTTP methods are appropriate for the Products entity. In this
case, all we need to do is to specify a Transport Header for the outbound
response (see figure 8).

Figure 8 Implementing the OPTIONS Pipeline
Configure the Transport Header as shown in figure 9.

Figure 9 Transport Header Settings
The expression for the header is 'GET, HEAD, PUT, DELETE, OPTIONS'. It
may not be necessary to add the OPTIONS clause, since you have to call it in order to get
the response in the first place, but I show it for completeness. That covers
the basics of using OSB to implement RESTful service patterns. As you can see,
it's quick and simple to do. Using this technique you can wrap any
functionality in your enterprise using a REST service interface.

The DELETE Method

The DELETE method is very straight forward. It expects to
have a product ID specified on the URI and it simply deletes the product with
that ID. Due to its trivial nature, it is not implemented in the sample code.

Calling RESTful Services from OSB

In addition to providing a REST interface, OSB can also
invoke REST services. For this part of the exercise we will provide a standard
SOAP interface to OSB. OSB will then take those SOAP calls and invoke the REST
services accordingly. The WSDL for our SOAP interface defines the following
operations:
getProductDetail(productID)
createProduct(name)
updateProduct(productID)
deleteProduct(productID)
Each of these operations will be performed by the REST
services we created earlier in this tutorial.
We begin by creating a proxy service named CallREST based
on the Products.wsdl file (in the WSDL folder of the SimpleREST project). Since
the WSDL defines several SOAP operations, we start the message flow with an
Operational Branch node, and create branches for each of the operations we want
to handle. Once that is done, add a Pipeline Pair to the getProductDetail
branch, as show in Figure 10.


Figure 10 The basic structure for the CallREST message flow
The getProduct Pipeline consists of a single Stage
node, as shown in Figure 11. The initial Assign statement is used to extract
the product ID from the request document and store it in the $productID
variable. The next node is a Service Callout


Figure 11 The getProduct Pipeline stage
The Service Callout (Figure 12) is where most of the work
is done. To configure the Service Callout, be sure to check the Configure
Payload Document radio button since REST does not use a SOAP format. Set the Request
Variable field to requestBodyDocument
and the Response Variable field to responseBodyDocument. That's all you need to do for the Service Callout action.


Figure 12 Service Callout contents
The first action is a Transport Header. Configuring this
action is simple. Set the Direction field to Outbound Request.
Also, be sure to check the Pass all Headers checkbox.
Immediately after the Transport Header action are two
Insert actions. The first insert action (Figure 13) is used to specify the HTTP
GET method. Configure it as shown in Figure 13


Figure 13 Specifying the HTTP GET method
The second and last Insert action (Figure 14) in the
request pipeline shows how to specify the relative-URI of the request. The expression:
<http:relative-URI>id={$productID}</http:relative-URI>
is used to create the value of the relative-URI of the outbound request
variable.


Figure 14 Specifying the Relative-URI of the request
At this point our request of the REST service is properly
formatted. Once the REST service is invoked, the response will be returned to
our message flow in the responseBodyDocument
variable. In the Response Action pipeline of the service callout, we add a
single Replace action (see Figure 15) to take the response document from the
REST service and format it to meet the needs of our SOAP operation.


Figure 15 Formatting the <body> that our operation returns
The remaining branches follow a similar pattern so there
is no need to document them here. If you want to see the sample code for this
blog entry, you can download it from here:
Download Source

Conclusion

As you can see from this sample, it is very easy to use
Oracle Service Bus to both call existing REST services, and to have OSB provide
a REST interface to existing SOAP services. The benefit of REST is the
simplicity of the interface design. By marrying OSB and REST, you get the
simplicity of REST, while maintaining the ability to define SLA's on each
service or operation, maintain visibility over these operations using OSBs
built in monitoring and reporting, and still retaining the necessary agility by
being able to quickly alter the OSB message flows and aggregating/orchestrating,
multiple services in the "backend" without the implicit knowledge of the
service consumer.


Reference  : https://blogs.oracle.com/jeffdavies/entry/restful_services_with_oracle_s_1

If A call B and B call C and Response would be in Reverse manner. i.e. C respond to B and B respond to A, So how you will respod to A from C without responsding B

Oracle BPEL Correlation Exemplified
Correlation is one of the important & tricky technique available within Oracle BPEL PM. In this blog, I have taken a simple route to explain the correlation technique.

Synchronous & Asynchronous web services:

Whenever a synchronous web service is invoked from Oracle BPEL via a partnerlink, only one port is established for communication with the exposed web service which is used by both request & response messages.
However, when an asynchronous web service is invoked, two ports are opened for communcation: one for request & one for response messages.

How does Oracle BPEL identify asynchronous responses?

As response from an asynchronous web service is not guaranteed to be received within a specified time frame, and many instances of the same service might be invoked before even a response can be obtained, how does Oracle BPEL identify and relate the responses to the appropriate requests and proceed for completion of further activities that may be scheduled? The answer is "WS-Addressing".

What is WS-Addressing?

WS-Addressing is a transport-neutral mechanism by which web services communicate addressing information. SOAP envelopes & headers used within web services for transporting data throught transport layers like HTTP does not possess intelligence to specify unique addressing information. Hence, WS-Addressing evolved which contained endpoint references (EPR) and message information headers for identification. This information is processed independently of the transport mechanism or application.
For reference on WS-Addressing click here

By default, Oracle BPEL PM implements WS-Addressing for all asynchronous web service calls, hence we don't have to explicitly implement identification relationship between the incoming & outgoing messages.

Correlation:

In short, Correlation is a BPEL technique which provides correlation of asynchronous messages based on the content of the message.

Why & Where Correlation?

The following are few scenarios in which we would be required to implement Correlation to identify & relate message communication;
1. When the external web service called doesn't have WS-Addressing capability
2. When the message travels through several services and response is solicited by the initial service from the last service directly
For instance, request flow pro1 -> pro2 -> pro3 and response is received from pro3 ->pro1

Implementing Correlation:

a.) Creating Correlation Sets:

In Structure Window of the JDeveloper IDE, right click on the Correlation Sets and choose 'Create Correlation Set'
Provide a name for your correlation set being created.
In the properties section, select 'Add' to display the property chooser window
Choose 'Create' to create a property on which the correlation has to be initiated. Provide a name and type for the property.

b.) Associating the Correlation set on receive/invoke, pick activities

Go the the correlations tab on the activity (invoke/receive/pick) on which you need to set & validate the correlation
Add the created correlation set to the activity

Initiate Attribute: (Value Set - yes, no)
When set to yes, correlation set is initiated with the values of the properties available in the message being transferred
When set to no, correlation set validates the value of the property available in the message

Pattern Attribute: (Value Set - in, out, in-out)
When the value is 'in', it means that the correlation property is set/validated on the incoming message
When the value is 'out', it means that the correlation property is set/validated on the message going out of BPEL
In case of 'in-out', the property will be set/validated on both incoming & outgoing messages

c.) Creating Propery Alias:

In the Structure Window of the JDeveloper, right click on the 'Property Aliases' and select 'Create Propery Alias'
Select the message type that you want to set to the correlation propery (already created)

Now, correlation design is complete. However, correlation will not be established unless we reference the correlations on the WSDL file of the BPEL process. To do this, import the correlation WSDL file (created under the project) in the BPEL process main WSDL.

soa project migration from 10g to 11g

Do the following:

First create a soa project, give the same name as the project you are going to migrate.

Use ant script that comes with jdeveloper i.e. in  "jdeveloper\bin"  directory use ant-sca-upgrade.xml to upgrade the 10g project.


This is the syntax "ant -f ant-sca-upgrade.xml -Dsource sourceDir -Dtarget targetDir -DappName app_name"

Here sourceDir is the 10g project directory, targetDir is the project directory that you have created in step 1 and appName is the name of the composite.

Custome XQuery in OSB.

Custom XQuery Functions in OSB 11g
-----------------------------------
Oracle Service  Bus 11g version, offers an extensible framework for writing your own
XQuery functions and allows to use them in the OSB Message Flows

You can also specify the scope of these custom XQuery functions and where these
functions should be available in OSB - for example in Pipeline and Split-Join or only
under Pipeline

Steps for implementing the custom functions

1. Create an XML file
2. Create a properties file(optional). Keys wrapped in % symbols in the XML file gets
    the values from this properties file
3. Create your custom Java class and package it as a jar file

I have implemented the XQuery custom functions and you can find the following
resource files

1. osbCustomFunctions.xml
2. osbCustomFunctions.properties
3. customXPathFunc.jar

These three resources should be placed under "%OSB_HOME%\config\xpath-functions"
for the OSB to recognize the XQuery functions.

For example, in Windows OSB installation,
files are copied to "C:\beaplatforms\11g\wls1033\osb11g\config\xpath-functions"

Remember that for a Clustered Installation spanning multiple hosts, you should copy
these files to the location on each host machine

1. osbCustomFunctions.xml
--------------------------
<?xml version="1.0" encoding="UTF-8"?>
<xpf:xpathFunctions xmlns:xpf="http://www.bea.com/wli/sb/xpath/config">
 <xpf:category id="%OSB_CUSTOM_XQUERY_FUNCTIONS%">
  <xpf:function>
   <xpf:name>customConcat</xpf:name>
   <xpf:comment>%FUNCTION_CUSTOM_CONCAT_COMMENT%</xpf:comment>
   <xpf:namespaceURI>http://test.org/osb/custom/functions/CustomXpathFunc
   </xpf:namespaceURI>
   <xpf:className>org.test.custom.CustomXpathFunc</xpf:className>
   <xpf:method>java.lang.String customConcat(java.lang.String, java.lang.String)
   </xpf:method>
   <xpf:isDeterministic>false</xpf:isDeterministic>
   <xpf:scope>Pipeline</xpf:scope>
   <xpf:scope>SplitJoin</xpf:scope>
  </xpf:function>
 </xpf:category>
</xpf:xpathFunctions>

2. osbCustomFunctions.properties
--------------------------------
%OSB_CUSTOM_XQUERY_FUNCTIONS%=Test OSB XQuery Custom Functions
%FUNCTION_CUSTOM_CONCAT_COMMENT%=Returns the concatenated string of the two input
string arguments

3. customXPathFunc.jar
-----------------------
Here is a simple Java Class with one method.
Compile the Java class, and create JAR file (customXPathFunc.jar)
The method returns a concatenated string of the two input strings and
appends "from Amsterdam"

package org.test.custom;
public class CustomXpathFunc {
 public CustomXpathFunc() {
 // TODO Auto-generated constructor stub
 }
 public static java.lang.String customConcat(String inputOne, String inputTwo){
 return "You are " + inputOne+ " "+inputTwo+ "from Amsterdam";
 }
}

Testing in Oracle Service Bus- SBConsole
---------------------------------------
Copy all the above files to the location "%OSB_HOME%\config\xpath-functions" and
restart your OSB Server.

Log onto the sbconsole: http://localhost:7001/sbconsole
Create a Proxy Service Message flow, and choose to edit an XQuery Expression

In the XQuery expression editor, you should now see the Custom XQuery function
under the XQuery functions in the Proxy Service Message Flow - XQuery expression editor

OSB XQuery Expression Editor is shown here



You can also test the XQuery function



Reference:
http://download.oracle.com/docs/cd/E17904_01/doc.1111/e15866/custom_xpath.htm