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 func:bin⇉hex() for a nice XPath technique). Here a conversion of type "...⇉..." preserves leading '0's, while a conversion of type "...┈⇢..." does not preserve leading '0's (like dp:radix-convert() ).
b64 (base64), hex, bin (01-strings) and dec (number) can be converted by these function calls:
stylesheet classes.xsl which generated that diagram is attached and discussed a little bit.
You might be interested in "graph extraction" from XML data and Depth-First-Search traversal of the extracted graph which was used to generate the "block" hierarchy diagram. Also the simple and nice heuristic which allows
to allocate exactly the vertical space needed for a node in the diagram is interesting -- in "XML speak" instead of "graph speak"
the EXSLT support of several XSLT 1.0 processors is compared.
In the attached archive stylesheet exslt.xsl is used to display tabular, interlinked output detailing the support.
With DataPower firmware 3.8.2 a bunch of new EXSLT functionality has become available.
Eg. the Math package is completely implemented since then.
If you just want to lookup DataPower EXSLT support for firmware 3.8.2 and higher take this link: attachment_14686524_382.html
These three functions ARE supported in DataPower firmware (even in pre 3.8.2 firmware) and are just incorrectly reported as unsupported:
func:function, func:result, dyn:evaluate
Attached to that posting is a correctly formatted multipart/signed sample message (with CRLFs) and the stylesheet.
This sytelsheet is a nice demonstration of these features: * accessing Non-XML input
* UTF-8 validate input (needed for safety, OK for scenario since ASCII is a subset of UTF-8) * having a func:function doing some preparation work (eliminate soft line breaks, split at '=3D') * having a recursive func:function doing the rest.
Important for the recursive function is doing only what needs to be done in the stylesheet and rely on efficient extension functions (regexp:replace) where possible.
Last, but not least, it demonstartes how you can map a unicode code point to a parsed charecter entity inside a stylesheet by mapping (for ISO-8859-1 sample).
Accessing the Non-XML data is possible by a binary transform action. WTX provides QUOTEDTOTEXT() function, but what I want to show here is a simpler way to do it.
The solution is by simply replacing the "multipart/signed" Content-Type by "multipart/related" with the correct "boundary" setting. because "multipart/related" messages can be processed by DataPower. This Content-Type rewrite technique was also used in swaform tool allowing to process HTTP form data with binary file uploads (multipart/form-data):
a binary transform action with stylesheet Signed2Related.xsl, with input INPUT and output NULL
a results action with input INPUT
a backend URL of http://127.0.0.1:port2
And you will have a
loopback XML service listening on 127.0.0.1:port2
attachment processing set to "Skip"
store:///identity.xsl transform action
XML Manager with Minimum Output Escaping rule in Compile Options policy (for showing German Umlaute unescaped below)
That's all. I tested with MPGW 1st service and 2nd service as MPGW, XML FW or XSL Accelerator successfully (on 3.7.3, 3.8.0 and 4.0.1 firmware).
Here is the output generated by the service:
$ curl --data-binary @Qp.mime http://dp2-l3:8121; echo <?xml version="1.0" encoding="UTF-8"?> <sample>If you believe that truth=beauty, then surely mathematics is the most beautiful branch of philosophy. <umlaute>äöüÄÖÜß</umlaute></sample> $
<?xml version=3D"1.0" encoding=3D"ISO-8859-1"?> <sample>If you believe that truth=3Dbeauty, then surely=20= mathematics is the most beautiful branch of philosophy.=0A= <umlaute>=E4=F6=FC=C4=D6=DC=DF</umlaute>= </sample> ------=_Part_2_12345 Content-Type: application/pkcs7-signature; name=smime.p7s; smime-type=signed-data Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature
This should be base64 sign part data. Missing intentionally for qouted-printable demo. ------=_Part_2_12345--
<!-- Allow accessing the decoded (quotable-printable) body-part in chained service with "Skip" attachment processing by "multipart/related" --> <dp:set-http-request-header name="'Content-Type'" value="concat('multipart/related; type="text/xml"; ', 'boundary="',$boundary,'"')" />
The response returned from backend contains a 12 byte Non-XML prefix before XML. This stylesheet strips the Non-XML data, verifies the binary prefix correctness, and does XML validation for the rest. 004SA.xsl
This is an export containing both stylesheet for request/response policies, and a simulation of AS/400 backend by netcat (nc) tool is described and used for a full roundtrip verification.
and did numerous postings on develoerWorks DataPower forum making use of coproc2 service for demonstration.
The coproc2 service itself (MPGW export attached in this posting) is unchanged since first posting.
A one-line (bash) shell-script client (coproc2) and a Java client (coproc2.java) are available.
Today I posted new coproc2 client coproc2swa, another (bash) shell-script client usable in Linux and Cygwin under Windows (tested!). http://www.ibm.com/developerworks/forums/thread.jspa?threadID=387511 ... # This file is an all-in-one solution in that it # # 1) is the coproc2swa client for processing SWA data with coproc2 service # ("bash" script, in "preamble") # # 2) is a SWA file itself(!) and can be used as sample input # # 3) allows to inspect SWAfile by -preamble/-epilogue/-print (cids) # # 4) contains four demo stylesheets which may be referenced by "cid..." # # attman.xsl # - accessing attachment manifest and content-types # # pgm1st.xsl # - output first "image/x-portable-greymap" attachment (binary data!) # # xml1st.xsl # - output first "text/xml" attachment # # zipit.xsl # - return zip of all "text/xml" and "image/x-portable-greymap" attachments ...
The demo I like most is cid:zipit.xsl (invoked by "coproc2swa cid:zipit.xsl ~/bin/coproc2swa http://dp3-l3:2223 -s >z.zip").
It just determines all attachments of type "text/xml" and "image/x-portable-greymap" from SWA file,
adds them to archive "archive-zip" and returns that archive as result (binary data) !
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):
This is the display when a box is inaccessible (I intentionally rebooted dp5-l3 for this):
The solution is intentionally not installed on one of our boxes, but on a normal Linux server.
Below described solution can be used for Windows systems, too, by adaption or making use of cygwin (search for "cygwin cron").
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.
#!/bin/bash cd `dirname $0` xsltproc create_script.xsl empty.xml >script sh script sleep 15 xsltproc generate.xsl empty.xml >/var/www/html/myBoxesBB.html
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.
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.
One of the APARs fixed is IC70937 (VIEWING A REMOTE WSDL OF A WEBSERVICE PROXY IN WEBGUI FAILS IN CASE OF NON-DEFAULT XML MANAGER AND BASIC AUTHENTICATION). Part of fixing this APAR was enhancing CLI copy as well as XML management FetchFile commands in adding xmlmgr as optional new argument.
In pre-18.104.22.168 firmware releases copy/FetchFile always took the Basic Auth settings from User Agent of a domain's default XML Manager.
With 22.214.171.124 you are now able to specify the XML Manger to use for accessing its User Agent's Basic Auth settings for the copy operation. This allows you to define several XML Mangers with different User Agents to allow copy from differently secured web locations.
See the modified CLI help here:
xi50(config)# help copy copy [-f] <source-URL> <destination-URL> [xmlmgr] Uses a specified protocol (HTTP, HTTPS, SCP, or SFTP) to copy a file to or from the device. The optional "-f" argument forces an unconditional copy. With thisswitch enabled, the CLI does not warn of possible file overwrites. If optional "xmlmgr" argument is provided then User Agent is retrieved from XML Manager "xmlmgr" instead of default XML Manager for determining Basic Auth settings. ... xi50(config)#
And this is the modified FetchFile command with optional "XMLManager" element (from store:///xml-mgmt.xsd):
XML Manager "sec" references " User Agent "sec" which provides the access credentilals in its "Basic-Auth Policy" tab. Here you can see how to copy file "stock.wsdl" from secured directory http://dp4-l3/sec onto DataPower appliance:
Customer wanted to know how to store files (retrieved by scheduled rule) locally on DataPower box.
Solution consists of: * scheduled rule * dp:url-open to retrieve file * base64 encode it (either its serialization for XML, or the binaryNode response for Non-XML) * use set-file XML management operation to store the file * access XML management interface from within a stylesheet to execute the request