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!

Update OSB 12.2.1.3 :

The patch available for previous versions never worked for me, however the issue is fixed now in OSB 12.2.1.3. All good!

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.

WebLogic SNMP UDP Port – Misleading Error Logs

Have you lately tried to use SNMP with WebLogic? I did, because I upgraded an earlier Windows-based domain to WebLogic 12.1.2 running on CentOS Linux.

SNMP Configuration

WebLogic is showing some strange and undesired behaviour here… Firstly, to get started with SNMP basically all you need to do is to enable the SNMP agent.

WebLogic SNMP Agent

 

This is good enough when running under Windows. Then you might specify a trap destination such as localhost 4000 and run the WebLogic command-line tool to listen to the destination and verify if your setup is working.

WebLogic Trap Destination

 

The command line to run the trap listener looks like this

$ java weblogic.diagnostics.snmp.cmdline.Manager SnmpTrapMonitor -p 4000
Listening on port:4000

Now, of course you (well, in this case me) forgot to modify SNMP UDP Listen Port and the Master AgentX Port. For sure you know that you cannot bind to ports less than 1024 in UNIX.

WebLogic Bind Exception

What happens

  • Interesting enough, there is an error message in the Weblogic startup – it is just pointing you to the wrong direction since it complains about port 171 not being available. Now, you might wonder, port 171 is configured nowhere!
  • Apparently WebLogic is trying 161 and the following 10 port numbers, eg. to avoid conflicts when several servers are running on a single machine (nothing to complain about, this behavior is documented, just click on “help”).
  • If all ports are unavailable (or not allowed for non-root users in UNIX), WebLogic does not complain about the configured port not available, but about the last one it tried. Not such a good solution…
  • Looking at the Master AgentX port, the situation is different again. Of course the restriction for binding to ports less than 1024 still applies, but there is no auto-increment on WebLogic. Unfortunately, the error message in the log file does not even mention the port number.

To conclude, when specifying a SNMP port number that you cannot bind to, you might see an error message containing a different port number than the one you configured for SNMP UDP Listen Port.
For the Master AgentX Port you will see a rather generic message, not containing the problematic port number at all.

Both is good to know and leaves some space for improvement.

<Sep 21, 2013 8:53:54 AM CEST> <Error> <SNMP> <BEA-320951> <Failed to initalize the SNMP AgentX master subagent. One possible cause is the failure to bind the Master agentX port. If this is the case, check to see if the specified AgentX port is available, or ensure that the process has permissions to bind to the desired port.
weblogic.diagnostics.snmp.agent.SNMPAgentToolkitException: java.net.BindException: Permission denied
 at weblogic.diagnostics.snmp.agent.monfox.MonfoxToolkit.initializeMasterAgentX(MonfoxToolkit.java:186)