Oracle Service Bus 12c (12.2.1) Native REST: Bug in HTTP GET in Pipeline?

While working on an Oracle tech presentation to be posted here, I discovered the following issue with native REST and Oracle Service Bus.


SOA Quickstart / 12.2.1 OSB, running on RedHat derivative with Oracle JDK 8.


OSB 12.2.1 Native REST pipelines don’t work with GET parameters.

Creating a native REST business services works fine, also adding a REST proxy service.
Once you insert a pipeline HTTP stops working correctly (since the URL parameters aren’t forwarded, a list will be returned by the backend service according to REST semantics), since URL parameters are not forwarded.

Steps to reproduce:

  • Use REST tech adapter to create a REST business service for an existing REST backend.
  • Define GET and POST methods. WADL will be created.
  • Test business service from WADL: both GET and POST will work.
  • Create proxy service from REST business service
  • Test proxy service, again GET and POST methods will work from OSB test client.
  • In JDev, drop a pipeline on the line connecting proxy and business service.
  • In JDev verify the pipeline configuration. it will display correct values.
  • Test the proxy service again, only POST will work. GET does not work anymore (now returns a whole list), since the URL parameters are not forwarded. Even an empty OSB pipeline will swallow the GET URL parameters.


IMHO this is a bug. I am currently in discussion with Oracle about it.

What is next?

I will let you know about updates / fixes or workarounds. Note, you could set the URL parameters as routing options to circumnavigate the issue for a particular use case.

Quick Tip: Change OSB 12c Domain Value Maps (DVM) in Service Bus Console

Other people have written and explained the usage of Domain Value Maps (DVMs) in Oracle Service Bus already: They can be generated easily within JDeveloper and shared with SCA components of SOA Suite. Previously SOA Composer could be used to modify them.

Here is quick tip: You can now change (or even create!) them within service bus console easily at runtime. So open your service bus console, e.g. from http://localhost:7101/servicebus. Note that the previous /sbconsole is now /servicebus and comes with a fresh look. The old URL is still working but deprecated and should not be used anymore.


Btw there were other XQuery based approaches that also allowed DVM to be used and changed at runtime, but the built-in DVMs are easiest and most convenient.

Oracle Service Bus (OSB) and OEPE Versions on 64-bit Systems

If you are installing Oracle Service Bus (OSB)  – which is the newest version as of this writing – based on WebLogic 10.3.6 you are required to use the Oracle Enterprise Pack for Eclipse (OEPE) (supported with Java 6).

Note that OSB 11g won’t run on WLS 12c. Although WLS 10.3.6 supports JDK 7, at the end I decided to run my WLS installation on the same JDK 6 version used for the OEPE IDE.

Typically matching OSB, WLS and OEPE versions is a no-brainer when downloading the bundle that contains WebLogic with Eclipse and OEPE for a particular 32-bit environment. The real fun starts with systems running 64-bit JVMs.

For my 64-bit CentOS 6.4 system I downloaded all the individual components separately with matching version numbers:

  • Supported Oracle DB 11gR2 (XE works but not officially supported)
  • WebLogic 10.3.6
  • Generic Patch 13573621
  • Eclipse with OEPE
  • OSB Installer
  • RCU (when OSB is used with reporting or OWSM)



You can get all the different OEPE versions from here:

The important thing to understand about the OEPE download is that it contains already ORACLE enterprise funtionality but not the OSB functionality.

Still there exists no separate OSB plugin. When running the OSB installer after the WLS installation, you specify the directory containing Eclipse with OEPE and the functionality will be added.

oui osb

This is the location where you would get an error message telling you that you are using the wrong version of OEPE. If you version matches, OEPE will be updated for OSB functionality.


A good summary for other matching versions of previous product releases can be found in this OTN posting.

WebLogic JMS with SAF and JMS bridges or SQS : Legacy Integration in the Cloud with Oracle WebLogic, WebSphere and OSB / Apache Camel

An interesting question popped up on my Oracle Middleware and Cloud Computing book site which I like to answer here for the benefits of all the others puzzling at similar integration questions. In the context of using JMS as an integration technology I’d like to summarize the usage scenarios for Oracle WebLogic JMS Store-and-Forward and JMS-bridges (both are included in WebLogic server).

Hi Frank – [ …] We have a requirement to build 2-way asynchronous integration between an application running on WLS in AWS and a legacy J2EE app running on IBM WebSphere in our Data Centre. From your excepts my understanding is that SQS is intended for use only between AWS apps – is this correct ? I think we need to be looking at a full JMS solution for our integration – perhaps using WLS JMS Store-And-Forward – Thanks, Peter D

Hi Peter,

Based on your comment I cannot go into great detail or even provide a solid architecture that anwsers you question (one that will save you from more reading) but here are some important points to consider:

– Amazon’s SQS is not restricted to be only used from AWS instances. SQS is purely based on web services (or language bindings that encapsulate those WS calls) so you can use it from any computer. E.g. you can read or write to SQS queues from remote.

WLS Store-and-Forward (SAF) can only couple WLS instances of the same version and does not bridge to other JMS providers. You cannot use SAF to transfer from WLS JMS to IBM MQSeries (or whatever Websphere might use). JMS is a pretty bad integration technology which requires to have the right messaging classes in your classpath. E.g. when writing messages from Websphere to a WebLogic JMS queue you are required to have the WLS JMS classes in Websphere classpath.

–  You can use the WebLogic’s JMS bridge to solve the somehow messy classpath issues. WLS JMS bridge has to be deployed as JCA adapter (still the jar file from the other provider is required but it is not used in custom code). The bridge will automatically forward from e.g. WLS JMS to MQSeries and even supports transcations. However there is no support to bridge between WLS JMS and AWS SQS.

– Unlike let’s say Oracle Service Bus, if you are looking at Apache Camel there is support to convert incoming JMS messages to outgoing SQS. Note to Oracle’s product manager of OSB: we would appreciate to have SQS as a supported transport protocol or possibly as an SOA Suite JCA adapter. Thanks for considering it 🙂