I use JCA File Adapter in a clustered environment, both nodes of the cluster processes the same file, causing duplicate records in final system. The simple answer is to use "HAFileAdapter" instead of "FileAdapter". In your .jca file:
<adapter-config name="JcaFileCopy" adapter="File Adapter"
wsdlLocation="JcaFileCopy.wsdl"
xmlns="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<connection-factory location="eis/HAFileAdapter"...
HAFileAdapter uses database behind the scene to create mutex to make sure only one node will process one file.
Ideally, that's all you need to do. However, I use this JCA file adapter inside my OSB. Simply changing to "HAFileAdatper" is not good enough. By default, HAFileAdapter uses SOADataSource for the behind scene locking mechanism. By default SOADataSource deployment target contains SOA server only ("soa_server1" in my case or whatever your SOA server name happens to be), so you need to re-configure SOADataSource, add your OSB server (osb_server1) to the deployment target list of the data source. Otherwise, you may scratch your head forever.
Tuesday, February 21, 2012
Friday, February 17, 2012
SOA deployment plan with JCA properties
Configuration/Deployment plan has a section for JCA, somehow i can't get this to work (11.1.1.4)
<reference name="JcaCopyFile">
<!-- ################### can't get this section to work, so add <wsdlAndSchema name="JcaCopyFile_file.jca"> at the bottom
<binding type="jca">
<property name="TargetPhysicalDirectory">
<replace>/test</replace>
</property>
<property name="TargetDirectory">
<replace>/test</replace>
</property>
</binding>
-->
</reference>
it works with this:
<wsdlAndSchema name="JcaCopyFile_file.jca" xmlns:jca="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<jca:property name="TargetPhysicalDirectory">
<replace>/test</replace>
</jca:property>
</wsdlAndSchema>
<reference name="JcaCopyFile">
<!-- ################### can't get this section to work, so add <wsdlAndSchema name="JcaCopyFile_file.jca"> at the bottom
<binding type="jca">
<property name="TargetPhysicalDirectory">
<replace>/test</replace>
</property>
<property name="TargetDirectory">
<replace>/test</replace>
</property>
</binding>
-->
</reference>
it works with this:
<wsdlAndSchema name="JcaCopyFile_file.jca" xmlns:jca="http://platform.integration.oracle/blocks/adapter/fw/metadata">
<jca:property name="TargetPhysicalDirectory">
<replace>/test</replace>
</jca:property>
</wsdlAndSchema>
Friday, January 13, 2012
OSB Import JCA Binding and Generate the Proxy Service with Eclipse
This is trivial, except I had to spend a while to re-discover it. So let me post it here.
You generate your JCA stuff from JDeveloper normally.
From OSB console, under project, select "create resource", under "bulk", select "URL or zip".
Remember if you select URL, then OSB can only find the resource from the server that OSB runs on (you may scratch your head for a long time if you are confused).
If you zip, you need to zip yourXYZ.jca and yourXYZ.wsdl.
After it's imported, find the little square and arrow icon towards the right of "JCA Binding", click that to continue.
From Eclipse, the import is similar, right click on your project, select import (except you are most likely on your local file system), so the URL will look like file:///c:/myjca/mytest.jca, remember to select JCA Binding as your type.
After import is complete, then right click on the JCA file, then select "Oracle Service Bus" (down the list, it took me a while to re-discover this :( ), then "Generate Service".
that's it.
You generate your JCA stuff from JDeveloper normally.
From OSB console, under project, select "create resource", under "bulk", select "URL or zip".
Remember if you select URL, then OSB can only find the resource from the server that OSB runs on (you may scratch your head for a long time if you are confused).
If you zip, you need to zip yourXYZ.jca and yourXYZ.wsdl.
After it's imported, find the little square and arrow icon towards the right of "JCA Binding", click that to continue.
From Eclipse, the import is similar, right click on your project, select import (except you are most likely on your local file system), so the URL will look like file:///c:/myjca/mytest.jca, remember to select JCA Binding as your type.
After import is complete, then right click on the JCA file, then select "Oracle Service Bus" (down the list, it took me a while to re-discover this :( ), then "Generate Service".
that's it.
Friday, December 16, 2011
A couple minor XML parsing tricks with SOA/OSB
Mostly for my own memory before I forget them, don't want to re-learn these little things every 6 months.
1. sometimes you just need to ship a full XML payload to somewhere, but at the shipping point (where you need to hand it off) you don't really care about the actual structure (schema). For example, publishing various messages to a queue. You can define a simple input schema that takes a string.
...<element name="in" type="string"/>...
In BPEL editor, when you need to transform some source variable (say "src") with a structured schema, e.g.
<src>
<foo>..
<bar>...</bar>
<car>...</car>
</foo>
</src>
your initial XSLT edit comes up that you can only drag one value from the "src" to the target "in" element.
Well, go ahead map that. Then open XSLT in source view, just type in your entire mapping like:
<in>
<src>
<foo>
<bar> map bar's value</bar>
<car> car's value</car>
</foo>
</src>
</in>
now you can map a full complex XML payload under "in". The only drawback is that you can't use the map editor to do this (it won't even open), because it doesn't know what to do with it (you are stuffing an entire XML structure inside one string element).
This is almost like an assignment operation in a "typeless" programing language.
2. Along the same line, you can stick an array of element into "in". That's what I actually did. But initially, I created a real "array" type, like:
<element name="srcList">
....
<element name="srcElems" type="src" maxOccurs="unbounded"/>
...
</element>
I first mapped the incoming payload (from another structure) into this, then I assign (append) the resulting array into "in". It's unnecessary. Just go ahead stick the mapping from the source into an array of "src" direct into "in". Saves the trouble of creating an intermediate type.
3. Finally, when I get my "in" variable sent into OSB (with varies XML elements), I have a requirement to strip off all namespaces (change namespace is the same thing).
If I do assignment like this:
$body/jms2:Publish/in/*
the result variable will retain all the namespaces from whatever contained in that "*". It may look something like:
<src xmlns:a="a.com" xmlns="blah.com" xmlns:b="bar.com">
<foo xmlns="">...</foo> </src>
It may even come out more weird than this anyway.
The cheap way (without doing full fledge XSLT with schemas) is like:
<src>
<foo>
<bar>{$body/jms2:Publish/in/evt:foo/evt:bar/text()}</bar>
<car>{$body/jms2:Publish/in/evt:foo/evt:car/text()}</car>
</foo>
</src>
4. for next one, i should do a java callout, it has been a while, i should document the detailed steps
1. sometimes you just need to ship a full XML payload to somewhere, but at the shipping point (where you need to hand it off) you don't really care about the actual structure (schema). For example, publishing various messages to a queue. You can define a simple input schema that takes a string.
...<element name="in" type="string"/>...
In BPEL editor, when you need to transform some source variable (say "src") with a structured schema, e.g.
<src>
<foo>..
<bar>...</bar>
<car>...</car>
</foo>
</src>
your initial XSLT edit comes up that you can only drag one value from the "src" to the target "in" element.
Well, go ahead map that. Then open XSLT in source view, just type in your entire mapping like:
<in>
<src>
<foo>
<bar> map bar's value</bar>
<car> car's value</car>
</foo>
</src>
</in>
now you can map a full complex XML payload under "in". The only drawback is that you can't use the map editor to do this (it won't even open), because it doesn't know what to do with it (you are stuffing an entire XML structure inside one string element).
This is almost like an assignment operation in a "typeless" programing language.
2. Along the same line, you can stick an array of element into "in". That's what I actually did. But initially, I created a real "array" type, like:
<element name="srcList">
....
<element name="srcElems" type="src" maxOccurs="unbounded"/>
...
</element>
I first mapped the incoming payload (from another structure) into this, then I assign (append) the resulting array into "in". It's unnecessary. Just go ahead stick the mapping from the source into an array of "src" direct into "in". Saves the trouble of creating an intermediate type.
3. Finally, when I get my "in" variable sent into OSB (with varies XML elements), I have a requirement to strip off all namespaces (change namespace is the same thing).
If I do assignment like this:
$body/jms2:Publish/in/*
the result variable will retain all the namespaces from whatever contained in that "*". It may look something like:
<src xmlns:a="a.com" xmlns="blah.com" xmlns:b="bar.com">
<foo xmlns="">...</foo> </src>
It may even come out more weird than this anyway.
The cheap way (without doing full fledge XSLT with schemas) is like:
<src>
<foo>
<bar>{$body/jms2:Publish/in/evt:foo/evt:bar/text()}</bar>
<car>{$body/jms2:Publish/in/evt:foo/evt:car/text()}</car>
</foo>
</src>
4. for next one, i should do a java callout, it has been a while, i should document the detailed steps
Wednesday, November 23, 2011
Eclipse: Failed to load the JNI shared library ... vm.dll
I managed to install OSB 11.1.1.4 with OEPE 11.1.16 (oepe-helios-all-in-one-11.1.1.6.1.201010012100-win32.zip) on win7 64-bit. My default JDK is 64-bit. When I fire up Eclipse, I'm getting this "Failed to load the JNI shared library ... vm.dll" error.
Solution is to install JDK 32-bit, then update eclipse.ini to point to your 32-bit JDK. here is the snippet of the .ini file. Keep in mind "-vm option needs to split on 2 lines, and appears before vmargs" (see http://wiki.eclipse.org/Eclipse.ini)
...
--launcher.defaultAction
openFile
-vm
c:\progra~2\java\jdk1.6.0_27\bin\javaw.exe
-vmargs
-Xms256m
-Xmx768m
....
Solution is to install JDK 32-bit, then update eclipse.ini to point to your 32-bit JDK. here is the snippet of the .ini file. Keep in mind "-vm option needs to split on 2 lines, and appears before vmargs" (see http://wiki.eclipse.org/Eclipse.ini)
...
--launcher.defaultAction
openFile
-vm
c:\progra~2\java\jdk1.6.0_27\bin\javaw.exe
-vmargs
-Xms256m
-Xmx768m
....
OSB 11.1.1.4 install error: Specified oepe location is not a valid location
I'm re-installing SOA suite 11.1.1.4.
The OSB I have is 11.1.1.4. (ofm_osb_generic_11.1.1.4.0_disk1_1of1.zip)
While installing OSB I encountered this "specified oepe location is not a valid location". However, the location I point to is the matching version 11.1.1.4 OEPE (oepe-galileo-all-in-one-11.1.1.4.0.201001281326-win32).
After struggling for a long time, I downloaded oepe-helios-all-in-one-11.1.1.6.1.201010012100-win32.zip, that did the trick.
I am not sure you see the irony, the matching verion OEPE doesn't work with OSB. I had to use a higher version OEPE 11.1.1.6. oh, well :-(
The OSB I have is 11.1.1.4. (ofm_osb_generic_11.1.1.4.0_disk1_1of1.zip)
While installing OSB I encountered this "specified oepe location is not a valid location". However, the location I point to is the matching version 11.1.1.4 OEPE (oepe-galileo-all-in-one-11.1.1.4.0.201001281326-win32).
After struggling for a long time, I downloaded oepe-helios-all-in-one-11.1.1.6.1.201010012100-win32.zip, that did the trick.
I am not sure you see the irony, the matching verion OEPE doesn't work with OSB. I had to use a higher version OEPE 11.1.1.6. oh, well :-(
Jdeveloper extension update
I always ran into issues when updating jdeveloper extensions after a fresh install. The standard steps are: Jdeveloper -> help -> check for udpates, then select the extensions you need.
Although I don't have proxy, but a popup always asks me to use this proxy "emeacache.uk.oracle.com", I uncheck proxy, the update ended up doing nothing.
It didn't help, their "official" extension center (http://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/131167.xml) doesn't even have the SOA composite editor :(
Well, for today, this is how it is "working" for me: like I said, I do not use proxy from my network to internet, but after numerous failed attempts, i finally logged onto a VPN. It beats me that within the VPN, the update actually worked! Go figure! I'm logging it here, in case, I have to go through the same thing in 6 month again...
Although I don't have proxy, but a popup always asks me to use this proxy "emeacache.uk.oracle.com", I uncheck proxy, the update ended up doing nothing.
It didn't help, their "official" extension center (http://www.oracle.com/ocom/groups/public/@otn/documents/webcontent/131167.xml) doesn't even have the SOA composite editor :(
Well, for today, this is how it is "working" for me: like I said, I do not use proxy from my network to internet, but after numerous failed attempts, i finally logged onto a VPN. It beats me that within the VPN, the update actually worked! Go figure! I'm logging it here, in case, I have to go through the same thing in 6 month again...
Subscribe to:
Posts (Atom)