2012.xsl (431 bytes)
<update>closure in this developerWorks DataPower forum posting</update>
This is how section 2.7 of the XSLT 1.0 spec begins:
"Normally an XSLT stylesheet is a complete XML document with the
While embedding stylesheets is part of the spec it is not supported by all browsers.
Especially Internet Exploerer 6/7/8 browsers do not support it.
I found a solution on how to enable Internet Explorer browsers for embedded stylesheet processing.
The first solution had the drawback that now stylesheet embedding was possible for FF and IE, but the solution broke the ability of the other big5 browsers to process embedded stylesheets although they could process them natively.
One year ago I was able to improve the solution to work for all big5 browsers, see table and this posting on XSL-list:
The solution was to have two xml-stylesheet processing instructions in the XML document -- all browsers but Firefox take the first, and Firefox takes the second.
To give you an idea of an embedded stylesheet find listing of supportALL.xml (generates the table on the right) below:
HermannSW 2700006U54 Identificações:  amp dp:soap-call datapower stylesheet xslt management xml soma 6 Comentários 6.841 Visitas
This posting is a complete walk-through of the steps needed to issue calls against the XML management interface from within DataPower stylesheets.
As precondition we have already enabled XML Management interface on dp3-l3:5550.
Also we have created user "soma" in group "developer" with password "secret" not restricted to a domain.
We make use of dp:soap-call() extension function.
Because the XML Management interface is accessed over SSL normally we have to provide an SSL-Proxy-Profile in that call.
Therefore steps A-D show how to create a SSL-Proxy-Profile from scratch via WebGUI.
A) Administration-->Miscellaneous-->Crypto Tools, "Generate Key" (this is just an example)
This results in the following message:
Action completed successfully.
B) Objects-->Crypto Configuration-->Crypto Identification Credentials
C) Objects-->Crypto Configuration-->CryptoProfile
This results in:
D) Objects-->Crypto Configuration-->SSL Proxy Profile
Now we are prepared for the stylesheet work.
This is the syntax of dp:soap-call():
dp:soap-call(URL, message, SSL-Proxy-Profile, flags, SOAP-action, HTTP-headers, process-faults, timeout)
We take the default for process-faults (false()) and no timeout.
Since the stylesheet is executed on the box the URL is just 'https://127.0.0.1:5550/service/mgmt/current'.
As message we pass in the SOMA call -- in the example here the "FirmwareVersion" SOMA call.
As SSL-Proxy-Profile we just pass "xslt-ssl", that is what we created by above steps.
A "0" is passed for flags as described in documentation.
We do not need a SOAP-action, passing the empty string suppresses the addition of this header.
Last we have to pass the HTTP headers
So find here the complete stylesheet (it is attached in this developerWorks posting):
Of course I worked on the stylesheet remotely with coproc2 ...
HermannSW 2700006U54 Identificações:  test xslt development sleep datapower latency 5.185 Visitas
During development sometimes the real backend service a DataPower service should connect to might not be available.
In this case we could set variable var://service/mpgw/skip-backside to 1 for a Multi-Protocol Gateway service.
This makes the MPGW service a loopback service and we could provide dummy backend response data.
The difference to connecting to a real backend is just the latency -- no real backend has 0 latency.
While there is no specific DataPower command to add latency to a service or stylesheet (like Unix "sleep" command)
we can use a simple workaround I learned from a colleague yesterday.
Just try to open a network connection to a non-existent IP address with <dp:url-open ...> and specify the timeout you are interested in:
This has the big advantage that it does not affect CPU-usage (non-active wait).
Today I learned that non-existant IP adresses must be chosen carefully, don't use 10.0.1.0 for that.
Find the details in this developerWork Forum thread:
HermannSW 2700006U54 Identificações:  sleep development xslt latency datapower delay 2 Comentários 3.207 Visitas
With 18.104.22.168 fixpack availability last week we do have DataPower XC10 URL Opener support:
Yesterday I took part in an internal education session and heard "... one of the few locations in DataPower with milli-second resolution ...".
I immediately thought on my posting Adding latency during service development for backend simulation from 2/2011.
The solution from that posting to add eg. a delay of 5 seconds was to make use of <dp:url-open> timeout attribute for "http" protocol:
Now the XC10 URL Opener can be "misused" (for development, see previous posting on this) to provide sub-second latencies.
And you do not have to possess a XC10 for doing so ;-)
So how is it done?
First we have to define a "XC10 Grid" -- lets name it "delay".
Lets fill in 300 (milliseconds) for Timeout, Grid Name "g", User "u" and Password "p",
Then create a new "Collective" named "c", switch to "Members" tab, and add a new member with "Actual Host" as "22.214.171.124".
Clicking two times "Apply" we are done on the configuration side.
Now a 300ms delay can be simply achieved by this "xc10:" <dp:url-open> call, see InfoCenter on format:
Doing some measurements with stylesheet xc10.xsl listed further below shows that timing is pretty accurate.
Of course we have to measure "inside" the stylesheet -- we could do by "stylesheet profiling" and <dp:region>.
Here the simpler approach based on "dp:time-value()" is used.
As can be seen here we see 16ms-23ms for 10ms configured (this is minimal value),
106ms-114ms for 100ms configured and 308ms-310ms for 300ms configured in "delay" XC10 grid object:
And this is stylesheet xc10.xsl used:
Just learned this from a colleague:
"I have seen some environments where this trick does not work, because even for unreachable addresses on the network,
their networking equipment responds immediately failing the request"
While working on verbose output for coproc2 Eclipse integration I searched for an interesting reject.xsl example HTTP return code.
I ended up with HTTP 418 and could first not believe having read right: 418 I'm a teapot
Find the details and why this HTTP code matches today's April's Fools' Day here:
Yesterday's posting "Arrows in function names: func:b64⇉hex() and func:bin┈⇢dec()"
demonstrated that arrows from Unicode "Arrows" range 2190-21FF as well as other Unicode characters can be part of function names.
The attached and described stylesheet povides useful conversion functions in addition to dp:radix-convert() (see
Here a conversion of type "...
while a conversion of type "...
b64 (base64), hex, bin (01-strings) and dec (number) can be converted by these function calls:
End of 2012 I did blog posting BMP.xsl.html (Basic Multilingual Plane) in which I described stylesheet BMP.xsl that created nice 16x16 table with each cell containing a 16x16 table containing a single unicode character, that spans the complete Basic Multilangual Plane (BMP, Unicodes 0-65535).
In this xml-dev posting John Cowan pointed to two BMP videos and an A0 .pdf poster.
I replied to that posting and criticized that the A0 poster does not show any BMP structure.
I wanted to have BMP.xq.html A0 poster, but the biggest paper format our printers do provide is A3.
Since today his A0 = 8 x A3 BMP poster covers the outside wall of my Boeblingen lab office ;-)
HermannSW 2700006U54 Identificações:  xg45 dataglue binary xs40 datapower license non-xml xslt 3.771 Visitas
As you may know binary or Non-XML data processing requires "DataGlue" license shown for "show license" CLI command.
XS40 as well as new XG45 (without DIM feature) do not have "DataGlue" license and allow for very limited Non-XML processing capabilities.
One Non-XML feature which is present is "" action.
It converts Non-XML CGI-encoded input (an HTTP POST of HTML form or URI parameters) into equivalent XML message.
In last year's 2nd WSTE Webcast on "Non-XML processing in DataPower stylesheets" slides 15+16 dealt with (very limited) "Non-XML data processing on XS40":
Last week I joined "German DataPower User group" meeting in Frankfurt and gave a talk on "DataPower attachment processing, Soap With Attachments (SWA) and MTOM".
I plan to make a new WSTE webcast on that later this year.
What I wanted to show today is a "sneak preview" on a cool sample application for attachment processing.
Until Thursday two weeks ago I would have said "IMPOSSIBLE" -- but it is possible!
In fact you can process arbitrary binary data on DataPower boxes without DataGlue license.
These are the restrictive conditions:
* you do not get "Transform Binary" action
* you cannot do WTX mappings
* you cannot use Contivo FFD dp:input-mapping or dp:output-mapping
* you have to pay a performance penalty for the attachment processing overhead compared to a single "Transform Binary" action.
OK, so what is the secret on how to do binary data processing without DataGlue?
It is DataPower attachment processing and the cool features of DataPower Attachment protocol described in Infocenter:
The details will follow in WSTE webcast, but you can already play with this service export (from a 126.96.36.199 box, verified on 4.0.2 box):
This is a demonstration of complete sample application "binary-reverse" -- it just reverses any (binary) input data and returns that.
This works on boxes without DataGlue license like XS40, but on other boxes as well.
The 0x00 bytes at begin, in the middle and at the end of sample input file are only present "to make it more difficult" ...
This is sample output from 2nd service in export presented last Monday in Frankfurt.
Here you can see how to convert binary input data to base64 or hexbin encoded representation for "normal"
stylesheet processing, as well as how to return arbitrary binary data from a stylesheet generated base64 string:
Here I tried to show the flow of "binary-reverse" sample application together with ALL intermedite contexts -- follow the arrows to follow the flow.
Please click on the image to open the BIG screenshot showing all the details!
The most important setting to make above service work is to enable "Non-XML Processing" for the rule(!) -- click for BIG screenshot:
HermannSW 2700006U54 Identificações:  xa35 non-xml dataglue xg45 binary xslt xs40 request size datapower 1.971 Visitas
DataPower service variable "var://service/mpgw/request-size"
sometimes has value 0 because the size cannot be determined,
Slide 10 of this 2010 WSTE webcast provided a solution on how to determine the request size of a (Non-XML) request based on a FFD stylesheet.
FFD binary processing is only possible with DataGlue license which is not available on XA35, XS40 and XG45(without DIM option) appliances.
Posting Binary data processing without DataGlue license! provided a general solution on how to do binary data processing (in a stylesheet) without DataGlue license.
This posting is based on a XG45 customer question, and the solution is simply:
That's it, and here is a sample execution:
I was asked how to "just appened" some "binary" string to Non-XML input received by DataPower before sending to backened.
Based on the techniques from first Webcast on "Non-XML Data Processing in DataPower Stylesheets"
stylesheet binary-append.xsl does exactly this:
This is just a short demonstration (that it works and can easily deal with "00" bytes):
HermannSW 2700006U54 Identificações:  xslt non-xml remove datapower binary append 2 Comentários 3.592 Visitas
Today I got asked whether it is possible to remove the first 8 bytes of an incoming Non-XML binary message before sending to the backend.
I said yes, and the solution is stylesheet binary-remove.xsl shown below.
In fact this is only a slight modification of stylesheet binary-append.xsl posted 4 weeks ago.
This time DataPower extension function dp:substring-base64() is used to make it happen.
HermannSW 2700006U54 Identificações:  datapower unicode big5 browser xslt bmp 1 Comentário 6.741 Visitas
Unicode character set is BIG.
Most of its characters can be found in Basic Multilingual Plane (BMP).
I wanted to view ALL 2^16=65536 characters of BMP in a BIG HTML table in my browser like this:
I created stylesheet BMP.xsl (size 2.5KB) to generate that HTML page (size 1.2MB).
Since XPATH 2 function fn:codepoints-to-string() is not available in browser XSLT
BMP.xsl.html had to be created offline by "xsltproc BMP.xsl BMP.xsl" (see "<!-- single codepoint to string -->" on how).
The generated HTML page displays fine in all BIG5 browsers, here are some observations:
If you change the xsl:output method to "html" then this stylesheet can be used in a DataPower loopback XML Firewall
and returns the HTML page to a browser correctly (if option "Process Messages Whose Body Is Empty" is set to "On").
HermannSW 2700006U54 Identificações:  include datapower service xslt import coproc2 2.401 Visitas
Based on a request on developerWorks DataPower forum on support for include/import handling for coproc2 tool I found a really simple solution.
Find the details and a complete sample in this developerWorks forum posting:
This is stylesheet boot.xsl used to execute stylesheet toBase64f.xsl on my Thinkpad, which references file base64Binary.ffd also on my Thinkpad:
And this is a simple sample execution, boot.xsl is sent together with (Non-XML) input to DataPower box.
The box then retrieves all files needed for execution -- useful and neat !
I already twittered on this last Friday, just remembered now to post it here, too.
HermannSW 2700006U54 Identificações:  cron datapower script xslt version features shell 1 Comentário 2.608 Visitas
Today I want to show a little tool we use in Böblingen Lab to keep track of our DataPower boxes (Level 2 and Level 3 support, as well as some Techsales boxes).
This tool is most useful if you have often changing firmware versions on different boxes (like in development or support).
Also boxes with different hardware features can easily be tracked with this.
Here I only have selected my Level-3 support boxes to restrict the screenshot size.
As you can see you get a timestamp, and then for every box (clickable) all of its version information in the left section.
In the right section all feature information is provided (Y/N means that the feature is licensed, but the installed firmware does not provide support for it).
Click on the picture to see the details!
Here is the screenshot of all Boeblingen boxes (nearly full rack):
The solution is intentionally not installed on one of our boxes, but on a normal Linux server.
Our boxesBB page gets updated every ten minutes automatically by a cron job, see the output of "crontab -l":
This is the shell script executed to generate the updated view.
Since this solution is outside a DataPower box "xsltproc" is used for the stylesheet processing.
The solution allows to configure which boxes should be tracked.
For each box you specify its name, the password of the admin user (may be any user with XML mgmt access rights), opionally the port of the XML management interface if different to default 5550.
The gport entry specifies the port on the serial console the box can be accessed by.
This stylesheet generates a bash script with version and feature XML mgmt requests for the boxes specified.
This is the XML mgmt command to query a boxes version information.
This is the XML mgmt command to query a boxes feature information.
And this is the stylesheet to create the complete status page based on the results retrieved for all the boxes by the generated bash script.
The shell script is necessary because xsltproc does not allow for dp:url-open() calls ... ;-)
The generated HTML page does not know on the intervals the page gets refreshed by crontab.
To keep the display current it refreshes itself every minute.
Perhaps this is useful for you and your boxes, too.