Secure Shell, SOA Suite 12c

SSH Tunnel to access a remote server

Recently we started developing an SOA integration with SAP. The problem we were facing was that the servers where the Web Services from SAP were exposed, were only accesible from the machines where the SOA Suite was installed, but not from our local machines. Although we had access to the SOA servers from our computers, running a test was impossible to achieve:


At some point the validation/testing process became really tedious and complicated. That was when we thought about doing an SSH Tunnel. It would basically allow us to access the remote server (SAP) from our local machines through a “tunnel” and then be able to open the WSDL definitions on our browsers, directly test them on SoapUI, or whatever we might needed to do.


The “easiest” way to do this, is with existing software like MobaXterm for Windows, or SSH Tunnel Manager for Mac. We only need to enter the required parameters and they will do it for us.



SSH Tunnel Manager



In both cases the information to be completed is pretty straightforward, and that’s what makes it so simple. Once the connection is established, we would be able to get access.

The other way to do it is through a terminal. This is basically an ssh command, with a few more parameters to set. On windows it can be done from a local MobaXterm tab, or the Linux Bash Shell added on the Windows 10’s Anniversary Update, and from the regular terminal on OS X o Linux. The structure of the command would be something like the following:

ssh -N -p [ssh-server-port] [user-login]@[ssh-server-host] -L [local-port]:[remote-server-host]:[remote-server-port]

Replacing the text in the brackets with our actual values, it would look like this:

ssh -N -p 22 oracle@ -L 10500:


-N     Do not execute a remote command. Commonly used for port forwarding.

-p     Port to connect to on the ssh server.

-L     Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.

In my case, I’m on OS X, so the way for me to run was on terminal.


We would be asked for the ssh server password, and once it’s on, it would hang in there until we manually close the connection.

In any of the cases, once the connection is established, we would be able to access the remote server (172.x.x.x:50000) from our local browser through localhost and the port specified (10500):


Running a test on SoapUI was possible too:


This actually saved us a lot of time and made things a whole lot easier. Hope it does for you too.

JDeveloper, SOA Suite 12c

Creating WSDL from XSD file (Builder) in JDeveloper 12c

WSDL file construction is an important part of the SOA Design and Development stages. And before version 12c, the construction method was a little bit more complex than the way it can be done now. Here are a couple of great and well explained examples on how this could be accomplished in 11g:

This, among other great features, is an improvement inside the IDE of version 12c.

Now, after hitting “New > From Gallery” (or New > WSDL (builder) if it appears on the list) on a SOA or OSB Project, we can either go to “SOA Tier > Interfaces” or manually type “wsdl” on the search bar to bring “WSDL (builder)” up on the items list.



There you can create the file by providing its basic information like file name, location, namespace, etc. It’s worth noting that only on OSB Projects, the Binding option is given.


I noticed that on SOA Projects it is not there.


But if we get there, at that point we can continue to follow the same old instructions (drag and drop) for the Binding part.



JDeveloper, SOA Suite 12c

JDeveloper 12c won’t start in Mac OS X (El Capitan, Sierra)

I was trying to work on my Mac and found out that JDev (12.2.1) won’t start up. It will try, but eventually will just go away and not open up. I found a very helpful blog post from Ilan about it, but wanted to re post it in a more visual and detailed way.

So this is the only glimpse I could get from my IDE:


I then tried opening it from <ORACLE_HOME>/jdeveloper/jdev/bin/jdev to check the logs and found the following error:

So the only thing that needs to be done is to delete the system_cache folder located in <HOME>/.jdeveloper/system12., in which HOME is where the jdeveloper and mywork folders with all our projects are. This was my case:


Then we can just try to open JDev again and start having fun.