OSB 12c (12.2.1.2) More Maven Issues and Solutions

Existing Bugs and Issues with Maven and OSB 12.2.1.2 and How to Fix Them

It is a well known fact that Maven in OSB 12.2.1.1 came with glitches that required manual fixes as described in Robert Patrick’s blog posting and in the Oracle support notes Doc ID 2186338.1. However, this article is centered around the latest OSB 12.2.1.2, its particular Maven issues and how to fix them. Same as version OSB 12.2.1.1 also 12.2.1.2 suffers from various maven glitches, however in a more subtle way.

[Note, that I usually don’t post references to MOS, since not everybody has access to it. Anyway, if you cannot access to Doc ID 2186338.1 don’t worry. It basically describes what Robert writes about in his blog. In addition it recommends actually not to fix it manually, but instead wait for a patch. I actually I agree. Also note that as of OSB 12.2.1.2 this issue is not marked as fixed although the behavior of the newest version is different.]

The current situation with OSB 12.2.1.2 and Maven is “interesting”, to put it mildly:

  • mvn with OSB 12.2.1.2 and the maven push plugin only will not work out of the box. This means the official documentation won’t help you in this case. The good news – despite the fact that mvn with OSB 12.2.1.2 is not working correctly – is that it is rather easy to fix manually (see below, Fix 1: Maven with OSB 12.2.1.2 and the mvn push plugin).
  • Also mvn with OSB 12.2.1.2 and maven.oracle.com will not work (as of Jan 7, 2017). Since the required .pom and .jar files are pulled over from maven.oracle.com and several of them are missing it is obviously not easy to fix it yourself.
  • Here comes the crazy part (well, crazy on an IT scale): if you configure both, i.e. first use the OSB Maven plugin to push from an OSB 12.2.1.2 ORACLE_HOME into the .m2 repository, and then in addition configure the maven.oracle.com repository, then it is done twice. Yet then also both issues cancel each other out.

 

Here are the fixes, as promised

Fix 1:Maven with OSB 12.2.1.2 and the mvn push plugin

a) easy manual fix, updating two lines in two files:

After usign the push plugin, in .m2 Repository, e.g. D:\Users\frank\.m2\repository\com\oracle\servicebus\sbar-system-common\12.2.1-2-0 change the file sbar-system-common-12.2.1.2.pom as follows:

under

    <parent>
         <groupId>com.oracle.maven</groupId>
         <artifactId>oracle-common</artifactId>
         <version>12.2.1-1-0</version>
     </parent>

change the version tag to <version>12.2.1-2-0</version>

also for the file sbar-project-common-12.2.1.2.pom in the directory
.m2\repository\com\oracle\servicebus\sbar-project-common\12.2.1-2-0 change the version number the same way.

b.) Install patch 22392646

This is the second, alternative option to fix the issue. Install patch 22392646 from My Oracle Support. After a lengthy and tiring discussion I had with support it is now also applicable to OSB 12.2.1.2. – voilà! Depending on your provisioning approach this might be the easier fix, but actually you could just copy over the files (or even run sed on those two files).

 

Issue 2: Maven with OSB 12.2.1.2 and the maven.oracle.com

There is no known fix at the moment, maven.oracle.com is missing a whole lot of files (again) and also some of those delivered are wrong again. Bug 23698828 describes a very similar issue, yet reports it as fixed for 12.2.1.1. Oracle support knows about it, so let’s hope it will be fixed soon in maven.oracle.com. I will keep you posted, promised.

Update: After the first round with support their “solution” did not work. The issue is still not fixed. If you think about it for a second, how hard can it be to push a patched .m2 repo to maven.oracle.com? Stay tuned 🙂

To conclude

You are lucky if you simply retyped all the instructions available and configured both ways to use Maven with OSB 12.2.1.2 (although I somehow guess you would have not read this article then).

As soon as you follow a clear path and either go for the push plugin on a machine with OSB installed, or maven.oracle.com on a build server without an OSB installation, you will run into issues. It is obvious that Oracle would do good with automatically testing this functionality for future releases. Not being able to browse the maven.oracle.com repo makes it more difficult for customers to debug those issues, so it might be a good idea to use a local proxy / cache.

Let me know your feedback!

 

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

While I was working on an Oracle tech presentation, I discovered the following issue with native REST and Oracle Service Bus 12c.

Version

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

Description

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.

Severity

IMHO this is a bug. I am currently in discussion with Oracle PM about it. Since I am working on another cloud gig, I cannot file a SR myself.

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.

Update 1 (Oct 2016)

I received no feedback from Oracle unfortunately. Anyway, if you experience the same issue let me know. It is important to share the knowledge here – I receive a lot of positive feedback from people with the same issues. Anyhow, also file a SR with MOS if you can. This is the official way to get it possibly fixed.

Update 2 (Jan-12, 2017)

There is a Patch 25184543 now with a backport to 12.2.1.2, see comments below. Gracias a Juan! Kudos for getting this through MOS and for sharing the knowledge.

Bug: Wrong Message Type and XQuery Expressions in OSB 12.2.1 /servicebus Console for Message Based Pipelines

Environment

I am using the latest download of JDeveloper 12.2.1 with the builtin test domain for SOA Suite 12.2.1 and OSB 12.2.1, all running on Java 1.8.0_65_b17 on a RedHat derivative.

Business Service

I created a message based business service based on a simple XML element definition for an Order via an XSD.

2016-01-21_12-16-15

Testing the business service shows the correct test data. Good. Note, that there is an embracing <ord:order> element containing other element such as version or ID.

2016-01-21_12-07-41

Pipeline

A pipeline is defined based on the same element.

2016-01-21_12-16-36

Interestingly the pipeline shows a different variable structure, missing out the embracing <ord:order> element.

2016-01-21_12-15-21

So any created XQuery expressions, e.g. for a Log action as seen on the screenshot above will be wrong as well and missing the embracing <ord:order> element. So put it more clear, non of the expression will return anything meaningful.

Conclusion / Impact

IMHO this is a severe issue if confirmed. Let’s face it. OSB was never easy but a rock solid product. For almost a decade I solved problems by telling people to stay calm and carefully looking and the test data, the elements, and the namespaces provided by OSB testing console. Now this seems to be broken.

Workaround

You can manually fix your XQuery expression. Possibly this also relates to another OSB 12.2.1 bug I blogged about earlier.

Bug: Typed One Way Pipeline in Oracle Service Bus / OSB 12.2.1

When creating a Service Bus pipeline in JDeveloper 12.2.1 for Oracle Service Bus 12.2.1, based on a typed, one-way business service (either one way WSDL based, or Messaging Service with XML request and XSD type with reply NONE business service) the pipeline won’t correctly use the request message type. It’s annoying because you cannot easily create expressions based on the request type, such as drilling open the $body variable, e.g. for an Order containing a shipping ID. All that is displayed within the pipeline is $body.

This happens although the pipeline configuration displays the correct XSD, eg. OrderType.xsd and the correct Type, eg. OrderType.

2016-01-18_18-13-41

I am quite surprised because this is not a very unusual use case. Anyway I couldn’t find a work around for JDeveloper 12.2.1 (let me know if you know one!). Interestingly, testing a proxy service based on the business service works all right (so maybe the bug slipped in when the pipeline construct was separated from the proxy service? just guessing.)

It is possible to work with the good old Service Bus web console /sbconsole. There everything is fine, i.e. the correct structure of the request message is displayed. The working Service Bus console is another indication that the way JDeveloper does it is broken.

2016-01-18_18-13-56

Don’t get me wrong. IMHO using the web console is not an acceptable solution.

 

Update OSB 12c Bug Fix:

I have seen this severe bug to be fixed with OSB patch 22276364 on a Windows system. So far I could not confirm it myself. Let me know if it works for you!

WebLogic 12.1.2 Per Domain Nodemanger Command Line Arguments

Stepping out of any WebLogic admin training you will know that before WebLogic 12.1.2 we could start the node manager (NM) using its listen address and its port number as command-line arguments overwriting the settings in the nodemanager.properties file.

This is still possible, but doesn’t work OOTB for the per domain NM which was introduced in 12.1.2.

The reason is, that the start script in

DOMAIN_HOME/bin/startNodeManager.sh

is calling

WL_HOME/server/bin/startNodemanager.sh

The script located in WL_HOME is still okay, but the one in DOMAIN_HOME doesn’t forward the command-line parameters. So if you just want to be able to run it as before, then replace

${WL_HOME}/server/bin/startNodeManager.sh

with

${WL_HOME}/server/bin/startNodeManager.sh ${1} ${2}

in the startNodeManager.sh in DOMAIN_HOME/bin.

Have a great day!

ps. Are you observing this 12.1.2 NM bug? Let me know if you don’t.