Sharing common XSD's between OSB and SOA using MDS

Assume you have a collection of XSD's (canonical) need be shared between OSB and SOA.

Oracle recommends placing common artifacts in MDS. However, that syntax "oramds:/..." doesn't work for OSB.

I can think of two solutions:

1. Deploy your XSDs in MDS under "apps/xsd". The trick is make these XSD's accessible from OSB. Assume you have a SOA process "foo" deployed to SOA server, then you can access the above XSD like http://yourhost:8001/soa-infra/services/your-parition/foo/apps/xsd/myschema.xsd

Please note, "foo" can be a process that has nothing to do with your XSD file collections! In other words, you can use any surrogate SOA process to access MDS artifacts. All of the XSDs in MDS can be accessed this way.

2. place XSD's in OSB only, SOA access the XSDs with something like "http://your-host:your-port/sbresource?SCHEMA/your-proj-name/xsd-folder-name/xsd-resource-name". e.g. http://localhost:8011/sbresource?SCHEMA/canonical/xsd/Account

This approach works, keep in mind, the access to the following might be disabled via OSB configuration
   http://localhost:8011/sbresource?SCHEMA/...
   http://localhost:8011/sbresource?WSDL/...
if "sbresource?SCHEMA" access is disabled, then you may need to create a surrogate proxy that references these XSDs, then expose the XSDs via the proxy WSDL.

Another way to do it (not recommended) is to put the XSD file in both MDS and in OSB, There are many problems with this approach, duplicate files in two places can get out of synch. Additionally,you may run into problems with the following scenario:
 You have a BPEL process "foo" uses "oramds:/apps/xsd/myschema.xsd",
  and an OSB proxy "bar" uses the same XSD within OSB locally.
  SOA "foo" process invokes OSB "bar" proxy.
Now your "foo" process will "see" the "myschema.xsd" twice. Once via "oramds:/...", once via "bar" WSDL from OSB, which reference the same schema using  http://localhost/8011/sbresource?SCHEMA/testProj/xsd/myschema.xsd. Jdeveloper will complain about the duplicates and won't compile.

XSLT accessing DVM

While I'm at it, let me record it here. This is again a "re-learn" that cost me many hours.

I need to access DVM in my XSLT inside my BPEL process. I have created my DVM file (myfile.dvm) inside the project, so "myfile.dvm" sits in the project folder. The correct way to access the file in xslt is:

 <xsl:value-of select='dvm:lookupValue("myfile.dvm","column1-title", "value1","column2-title","default-for-column2")'/>

Here are the two things that cost me several hours to "re-learn":

1. JDEV UI has that tool you can test XSLT locally, it works great most of the time, but it DOES NOT work with DVM. So don't waste your time testing DVM in jdev locally. You have to deploy it to the server to run your test!

2. I thought my XSLT file sits in "xsl" subfolder, so I tried to access it as "../myfile.dvm" in my XSLT code. Well, that turned out to be wrong. After searching through my old code, I found out that you should access the file as "./myfile.dvm". That's it.

AIA Error Handler Email Config Tricks

I had to chase down a problem with an AIA error handler failing to send email today. Boy, it has been a few months since I last touched it. Everything got blurry. I had to relearn quite a bit. Let me document the tricks before I forget again.

1.      First of all, .under {AIA instance home}/AIAMetaData/config (e.g. /app/oracle/product/fmw/AIACCB/aia_instances/AIACCB/AIAMetaData/config)

make sure the two XML files are configured correctly.

2.      Follow this link to update the AIA config: http://docs.oracle.com/cd/E17904_01/doc.1111/e17364/bldgintflows.htm#BACEGBEJ

(1)    Browse to the folder at $AIA_HOME/aia_instances/$INSTANCE_NAME/bin.

(2)    Source the file aiaenv.sh by executing the following command:

source aiaenv.sh

(3)    Browse to the folder at $AIA_HOME/aia_instances/$INSTANCE_NAME/config and open the deployment plan file, UpdateMetaDataDP.xml.

(4)    Update the file UpdateMetaDataDP.xml by inserting include tags for each resource group that you want to add to the MDS:

a.      To upload all the files under "AIAMetaData", add the following:

<include name ="**"/>

b.      To upload the files copied to "AIAComponents/ApplicationObjectLibrary/SEBL/schemas" folder, add the following:

<include name ="AIAComponents/ApplicationObjectLibrary/SEBL/schemas/**"/>

Note:

In the include tag, the folder path must be relative to the folder AIAMetaData.

(5)    Browse to AIA_HOME/Infrastructure/Install/config. Execute the script UpdateMetaData.xml by typing the command:

ant -f UpdateMetaData.xml

3.      (Trick 1) Due to an AIA bug, when you run (5) above, make sure {AIA home}/lib/aia.jar (/app/oracle/product/fmw/AIACCB/aia.jar) is available. HOWEVER, after you finish step (5), make sure you hide that aia.jar (rename to aia.jar.bak), then bounce your SOA server! It’s ironic that you have to hide aia.jar in order for AIA to work! BUT, remember next time when you need to run AIA update again, step (5) above, make sure you unhide your aia.jar in order for the update to work. Also, double check on step (4) carefully, I burned several hours in the past due to a careless file path problem in the XML file on step (4).

4.      (Trick 2) Say, you set up your error tables, for that “Role” column, you enter the user name (e.g. “foo”) that will receive the email notifications. According to AIA doc, you need to configure that user’s email under {your AIA URL}/sdpmessaging/userprefs-ui (if your AIA console is foo.com/AIA, then your link is foo.com/sdpmessaging/userprefs-ui). However, that didn’t quite work for me either.

What you really need do is to go to weblogic console, under security realm, users, set the email for that user  (say “foo”), click “attribute” tab, then find mail (2^nd page), and enter email address over there. That is what worked for me! The only that appears to be working under "sdpmessaging/userprefs-ui " is if you set one user as the default channel (I used AIAIntegrationAdmin). 

5.      (Trick 3), one useful trick to debug your email problem is under “em” console.

Expand “User Messaging Service” (last link on the left panel)

Click on “usermessagingserver (WLS_SOA1)”

On the right panel, look on the top left corner, find the little drop-down menu (under “usermessaingserver” bold letters),

select “Message Status” from the drop-down menu

Hopefully, you’ll see a list of message action entries.

Click on the one you are interested (failed, succeeded)

I have had luck to find out the root cause of email issues from this page. In the case, when it shows failed, I can check the bottom to find out the detailed reason.

Today, I found one showed succeeded; however, we didn’t get any emails. So that prompted me to login to the putty console, and run the mail command, like “mail foo@bar.com”, directly, where “foo@bar.com“ is the address that the server claimed to have sent successfully. However, my putty console test shows the recipient never get the email. As it finally turned out that email “foo@bar.com” happens to be a distribution list and it was not set up properly on the server.

The Mess of XLST 1.0 / 2.0, JDEV and OSB

I ran into some mess with XSLT 1.0 / 2.0, JDEV and OSB. Oh, boy, I just have to blog it.

Let me sum up the lesson I learned before I dive into the details:

• If you crafted your XSLT in JDEV, you tested it, and  it worked fine in JDEV.  Then you port it to OSB, the same XSLT code may blow up!

I have to admit that I didn't just do a "normal" XSLT and ported it OSB. I did something "smart" with XSLT. At first, I was proud of what I did. Then I spent hours to realize there is such a thing as being "too smart".

In JDEV,  the default version of XSLT is "1.0". You can change it to "2.0", so you can take advantage of some of the 2.0 features. I did that in the past. It worked well.

Here is what I did this time:

<xsl:stylesheet version="2.0"

                xmlns:xp20="http://www.oracle.com/XSL/Transform/java/oracle.tip.pc.services.functions.Xpath20"

...

  <xsl:template match="/">

  <!-- this only works with 2.0 -->

    <xsl:variable name="v">

      <var name="v1">legal</var>

      <var name="v2">preferred</var>

    </xsl:variable>

     <ns2:employeeElem>

      <ns2:id>

        <xsl:value-of select="/wd:Report_Data/wd:Report_Entry/wd:Employee_ID"/>

      </ns2:id>

      <xsl:for-each select="$v/var">

        <xsl:choose>

          <xsl:when test=".='legal'">

            <ns2:name>

              <ns2:firstName>        

                <xsl:value-of select="/wd:Report_Data/wd:Report_Entry/wd:Legal_First_Name"/>

              </ns2:firstName>

            </ns2:name>

          </xsl:when>

         <xsl:when test=".='preferred'">

            <ns2:name>

              <ns2:firstName>

                <xsl:value-of select="/wd:Report_Data/wd:Report_Entry/wd:Preferred_First_Name"/>

              </ns2:firstName>

            </ns2:name>

          </xsl:when>

        </xsl:choose>

      </xsl:for-each>

    </ns2:employeeElem>

  </xsl:template>

</xsl:stylesheet>

I created an array variable, so I can control a for-each loop to run precisely twice. I call this "smart", because it is packed with two complicated tricks. We know that XSLT doesn't have index-incremented loop. If you change the size of this array, then you can actually emulate an index-incremented loop!

Another trick I am playing is to create the result with multiple <name> elements. If you don't use for-each, and hard code two <name> elements, then you can't edit your XSLT in design view anymore. It complains that you mapped the <name> multiple times. But if you use above for-each loop , you can still use design view!

Well, more traps here, if you manually change your XSLT version to 2.0, and you use design view to make any changes, whenever you save, it switches version back to 1.0. So you have to remember to manually change it to 2.0 again. 

Sounds messy enough?

Anyway, after I finished my 2.0 trick, and tested in JDEV, it worked beautifully. Then I ported it OSB, it blew up. It took me hours to find out that OSB doesn't like that "smart" 2,0 feature. 

Now I have to bite the bullet and manually edit the whoel XSLT script.

sqlplus connects to remote sql server

You can find info on this everywhere, i just want to record how i did it in my case:

sqlplus uname/pass@//your-host:port/your-sid

for example:

sqlplus foo/bar@//soadev.example.com:1521/orcl

OSB Alerts Data File Location

So I won't forget it again, OSB alerts are stored in a binary file

./servers/WLS_OSB1/data/store/diagnostics/WLS_DIAGNOSTICS000000.DAT

when it grows big, the OSB console takes long time to show alerts. You need to purge this file periodically.

A Few BPEL Java Embedding Notes

1. Error: SCAC-50012
    check \SCA-INF\classes\scac.log file to find more details.

    Common issues:

    #1.1) check that you added the proper import at the top of .bpel file
     
     for example (right after <:process ...> element, and before partner links   
     <bpelx:exec import="java.util.*"/>
    <bpelx:exec import="java.lang.*"/>
    <bpelx:exec import="java.math.*"/>
    <bpelx:exec import="org.w3c.dom.Element"/>
    <bpelx:exec import="oracle.xml.parser.v2.*"/>   
    <bpelx:exec import="com.foo.bar.*"/>
    <bpelx:exec import="com.collaxa.cube.ws.wsif.providers.java.*"/>

     #1.2) check your syntax carefully. When in doubt, comment out as much as you can.

2. incorparte your own special classes and jars
    create your class jar file, place it under "SCA-INF/lib" folder

3. get/set your variables
    For simple string variables, it's straight forward. If you need to process the XML payloads, use forms like this:
 oracle.xml.parser.v2.XMLElement targetElem =
    (oracle.xml.parser.v2.XMLElement) getVariableData("myVarName", "payload",  "/ns3:foo/ns3:bar/ns3:car");  where "ns3" is defined precisely as it appears at the top of your .bpel file.

you can manipulate this element with functions, here are a few common functions: "getParentNode, getTextContent, cloneNode, setTextContent, insertBefore" etc.

4. if you need to debug, add some log entries using "addAuditTrailEntry".