v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
Normal
0
21
false
false
false
FR-BE
X-NONE
X-NONE
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Tableau Normal";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-qformat:yes;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:11.0pt;
font-family:"Calibri","sans-serif";
mso-ascii-font-family:Calibri;
mso-ascii-theme-font:minor-latin;
mso-fareast-font-family:"Times New Roman";
mso-fareast-theme-font:minor-fareast;
mso-hansi-font-family:Calibri;
mso-hansi-theme-font:minor-latin;
mso-bidi-font-family:"Times New Roman";
mso-bidi-theme-font:minor-bidi;}
Reporting
in OSB is useful, it allows you to audit message going through OSB. The service
bus console allows you to view the content that
you reported.
To report
data you simply use the Report action in your proxy. The
action itself is rather straightforward. You specify the content to report
($body for example), an optional key for easier search (for example the id of
the record) and that's it.
Sometimes
though, what you want to is a bit more complicated. I recently had a case where
the key was built from the message type (XML) and the id of the message. Seems
quite simple but the id could be any element anywhere in the message depending on its type.
This could
be handled by 'if' statement but adding new cases would mean changing the proxy service
and if you have lots of message types this can get boring so I wanted the
solution to be as dynamic as possible (read "just change a configuration file and
that's it").
The
following entry details how you can make this dynamic in your proxy
by using XQuery/XSLT.
First step
the XQuery
We're going
to use an XQuery to make the mapping between the XML message type and the
location of the identifier in it.
We assume
here that the message type is the first node of the input XML and use a rather
simple Xpath to find the identifier.
The XQuery looks like this for two messages :
<reportmapping>
<row>
<logical>messageType1</logical>
<type>MT1</type>
<reportingreferencelocation>//customID</reportingreferencelocation>
</row>
<row>
<logical>messageType2</logical>
<type>MT2</type>
<reportingreferencelocation>//theOtherIDLocation</reportingreferencelocation>
</row>
</reportmapping>
Second step
the XSLT
To get the
identifier value of the dynamic path, we're going to use an XSLT
transformation. This XSLT takes an XML parameter as input which contains our
xpath (coming from the previous XQuery).
The XSLT
looks like this :
<xsl:stylesheet
version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:xalan="http://xml.apache.org/xalan">
<xsl:param
name="PathToNode"/>
<xsl:template
match="/">
<IDVALUE>
<xsl:value-of
select="xalan:evaluate($PathToNode/reportingreferencelocation)"/>
</ IDVALUE >
</xsl:template>
</xsl:stylesheet>
(note the use of a xalan function here. Xalan is the XSLT processor used in weblogic
server)
Last step,
the proxy service
We're now
going to wire everything in the proxy service. First we assign the XQuery
to a variable.
We then get
the entry in the XQuery corresponding to the record we're treating.
We're then
extracting the id of the message using the XSLT transformation
Final
assign is to built the final variable that will be used as the reporting key.
The report
action is then called with this variable.
Everything
is setup. We're now ready to test.
Testing the
solution
Using the test
console, we're sending our first XML ...
<messageType1>
<sender>test console
1</sender>
<customID>ID12345</customID
>
<content>
<field1>value
of field 1</field1>
</content>
</messageType1>
... and a second one of another
supported type
<messageType2>
<header>
<theOtherIDLocation
>ID67890</theOtherIDLocation >
</header>
<body>
<data>Test
data</data>
</body>
</messageType2>
Reporting result
is :
Conclusion
Report is
done as expected. Now if a new message type must be supported we only have to
modify the XQuery and nothing at the proxy service level.
Sample
project attached to this entry.sbconfig-dynamicReport.jar
