In this short post I would like to share some tips and solutions to some common problems while working with the Oracle SOA Suite. These solutions apply to both 10g and 11g installations.
No 1: Using a file adapter to read files from a network location.
There has been a number of occasions on which I needed to use the file adapter to read some files from a disk somewhere in the network. Usually on windows machines and a hidden network path was used with an UNC like this “\\server\d$\data”. Now the issue here is that when deployed, the files would not be read, unlike with a local path which in my experience always works. My attention immediately went to the read/write rights on the folder. I have tried giving the soa server the rights to get access to the server. Never would it work. Now eventually the solution was simple.
Start the soa server as a user with “Domain Admin” rights and you are good to go. This might hold true for any other user with sufficient rights but I have never managed to succeed with any other user.
No2: XML, XPath and namespaces.
How many times have you all created an assign with for instance a copy operation only to find at runtime that your instance has crashed with something like “target cannot be empty at line: 123”. When you look at the audit trail you are sure the data you are trying to assign is there. You now probably have a namespace issue. When working with BPEL it is absolutely neccesary to know how namespaces in xml work. It’s a bit too much to explain it all here but the short version is like this. You can see a namespace as a sort of package (like in coding languages) to uniquely identify a node. BPEL creates a reference to a namespace and uses it in it’s xpath to select a node. Usually these shorthands look like “ns1”, “ns2” etc. Now when you try and select a node with xpath called book with like so: “/ns1:book” this might translate to “/http://www.ns.com/ns/bookshelve:book”. If the xml document you are selecting from has a namespace of “http://www.different.com/ns/bookshelve” the xpath would return a null value. There are a number of ways to fix this.
Solution 1 (preferred): Create the namespace in the BPEL code and create a new prefix for example “ns2” with namespace “http://www.different.com/ns/bookshelve”. Now use the xpath “/ns2:book”.
(You can look at the bpel source at the top to see how to add a new prefix and its full namespace)
Solution 2: Use “//book” to select the node. This method selects nodes in the document from the current node that match the selection no matter where they are. It also ignores namespaces.
No 3: Source documents without Namespaces
What if you have to work with xml documents that do not contain xml namespaces. What now? You could simply use the shorthand “//” in xpath and be done with it. However you would have to modify all the XPath expressions by hand and you would be prone to errors. The solution here is to add the namespace yourself with XSLT. Now this is not too hard. Depending on your enviroment you can use an esb(10g) or mediator(11g) for the job. But first you must create an xsd that matches the xml document but add a namespace of your choosing. Now use the transformation mapper to map the source document to the target document with namespaces. When you check the code you will have to modify the xpath to change the xpath expressions from “/ns1:bookshelve/ns1:book/ns1:name” to “//bookshelve/book/name”. Now you can use this document as the source for the rest of your process and continue working normally.
Now if you are really smart you use your esb or mediator to check whether namespaces need to be added. You can do so by checking a required node for a null value. You can assume that when it is null you have to add the namespace. (because it is not allowed to be null). Otherwise you can use the source document without transformations.
No 4: Do not shy away from creating XSLT transformations without the JDeveloper Mapper.
Do not get me wrong, the Oracle JDeveloper XSLT Mapper is a powerfull tool and gets better with every iteration of JDeveloper. However using XSLT you can do so much more than the basic functions of the JDeveloper mapper. Simply look up some resources on the web on XSLT and you will see what I mean. If you need to do some XSLT mapping that is too complex for the mapper you can still use the mapper to provide a jump start for you. Simply let the mapper create the document and drag a single node from the source to the target. Now enter the source view and you will see the mapper has created the namespaces for you. Now you can remove the comments at the top which are used by the mapper to function properly. (Be removing these comments you are sure the mapper will not work anymore and it will not mess with your code) From now on you are on your own, but you are allowed to do anything you like.
Now most of these solutions and tips are probably know to most of you but I remember when I started out I had a hard time figuring some of these things out.
So here it is! Share and prosper!