This posting describes the zip2html tool.
Sample HTML output's, service export as well as zip2html.xsl are attached in this sibling developerWorks DataPower forum thread:
tool allows to
easily create a single HTML page containing information from all domains of a DataPower backup
doing similar for DataPower exports
include all files in data:application/zip;base64,... links (Firefox, Opera and Chrome browsers allow to open these links)
choose between using the clixform.xsl attached or the onboard clixform.xsl (details below).
It can be used in different modes:
by sending .zip archives directly to service installed on a DataPower box
by using the HTML input form provided by zip2html.xsl
and even without being installed by using coproc2 service.
backup-b4.zip is a backup of the 4 domains "coproc2", "demo", "empty" (domain created, no config added) and "zip2html".
"demo" domain contains files of different types which your browser's application/zip helper should be able to correctly classify.
(428.1 KB) is the XML FW service export of zip2html
Fixed links above and below that got broken by developerWorks DataPower forum migration last month.
Add this is new export that can be used on all appliances including XB6 and XM70.
zip2html-mpgw.zip (492.9 KB) is the MPGW service export of zip2html tool.
Use this URL in your web browser: http://yourBox:2228/form
(22.0 KB) is the stylesheet discussed in detail under "Technical discussion" at the bottom.
With this tool even a full device backup is processed in seconds in case "files=none".
Be careful processing big backups with option "files=all" as that might take few minutes to complete.
Just having "default" domain as part of a backup takes time in case "files=all" -- all files in "store:///" folder belong to default domain and get added.
HTML form input
This is how the HTML form looks like.
It allows to select the backup (or export) from your filesystem,
Then you have to select whether you want the files to be included in the generated HTML page in "data" links. This allows inspecting the files by the "application/zip" helper application registered with your browser.
And you have to select whether the attached or the onboard clixform.xsl should be used.
The clixform.xsl converts the "export.xml"s in the .zip archive to a sequence of CLI commands (Command Line Interface) during the initial phase of a DataPower import. This output is what you will see in the yellow background sections.
Find more explanations on which clixform.xsl will be used by DataPower by clicking on the screenshot or the real HTML form opened in you browser.
You open the HTML form with "/form" enpoint of your DataPower service, eg:
HTTP GET to installed service
You can retrieve the HTML form with correct "post" link to the DataPower box by a simple HTTP GET.
You can then use the stored form.html instead of the HTML form from DataPower box itself.
$ curl -s http://dp3-l3:2229/form >form.html
HTTP POST to installed service
Selection of the clixform mode
is done by the endpoint, the files
selection is done in the query part of the URL:
$ curl -s --data-binary @zip2html.zip http://dp3-l3:2229/attached?files=none >x.html
Using clixform.xsl with coproc2(nonxml) service
As above the selection of the clixform mode
is done by the endpoint and the files
selection is done in the query part of the URL.
But this time stylesheet clixform.xsl is sent together with the .zip archive to the Non-XML endpoint of coproc2 service (find details here
$ coproc2 zip2html.xsl backup-b4.zip http://dp3-l3:2224/attached?files=none -s >y.html
Different output for backups and exports
Here you can see the difference in generated output for a DataPower backup (left) and a DataPower export (right):
For backups the "domains" section contains the list of domains contained in the backup.
After each line the "go" link allows you to quickly get to the start of the domain's information.
This is what the domain output looks like.
Above the table you find the domain name as well as a link to the top of the document (eg. for selecting another domain by "go" link).
The table contains a configuration and a files section.
You can easily jump between both by the "files" and "configuration" links,
The "(no)" before "files" indicates that this output was generated with "files=none" selection.
For "files=all" it looks like this: "(all)"
If your browser allows you to open "data:..." links you can inspect the files by clicking on "all" link.
The "application/zip" helper application of your browser will open the base64 encoded .zip archive in the all link then.
top; configure terminal;
no logging event default-log *
no logging eventcode default-log *
%if% available "wsm-agent"
<file name="local:///snake.00.svg" src="local/snake.00.svg" location="local" hash="JVFfJMUlxT3iNVYH8dQ/HXwXWXg="/>
<file name="local:///identity.xsl" src="local/identity.xsl" location="local" hash="Hd7HM2ulToOJ+M86nDaNhPOPWws="/>
<file name="local:///g1.png" src="local/g1.png" location="local" hash="zt/PjvLbefvfxjpcjSN10tn2nTQ="/>
<file name="local:///embedded-zip.zip" src="local/embedded-zip.zip" location="local" hash="GGALB4JtJJw1+xwZMgG4e9/JIkE="/>
<file name="local:///anim.gif" src="local/anim.gif" location="local" hash="OlrExOyx5upzCVDyewVYXtHb40Y="/>
<file name="local:///ab.xml" src="local/ab.xml" location="local" hash="28Gd7C36Raal4UZ1v4bLs8TpKd0="/>
<file name="config:///demo.cfg" src="config/demo.cfg" location="config" hash="2jmj7l5rSw0yVb/vlWAYkK/YBwk="/>
<file name="webgui:///clixform.xsl" src="dp-aux/clixform.xsl" location="dp-aux" internal="true" hash="d6RC8FFr0UzYDsJGF4JrmZUJpOg="/>
<file name="webgui:///SchemaUtil.xsl" src="dp-aux/SchemaUtil.xsl" location="dp-aux" internal="true" hash="oFgCGu3bq7UlztcmEKFBeYQt2gY="/>
<file name="webgui:///management.xsl" src="dp-aux/management.xsl" location="dp-aux" internal="true" hash="+Ew49hOqS776HMWjBuzmaGBUaac="/>
<file name="webgui:///map-dmz.xsl" src="dp-aux/map-dmz.xsl" location="dp-aux" internal="true" hash="IEZVhvGN+AlSI1ERT6daILfIUb0="/>
<file name="webgui:///drMgmt.xml" src="dp-aux/drMgmt.xml" location="dp-aux" internal="true" hash="YQTgEj4aquvbOg2GYkyxzxxs5Fo="/>
<file name="webgui:///basetypes.xml" src="dp-aux/basetypes.xml" location="dp-aux" internal="true" hash="va3o1RHfV1IkJRgzaRvf9jCxSgo="/>
With the description above you have everything you need to use zip2html tool.
If you are interested in some of the technical details of zip2html.xsl you are right here.
Stylesheet zip2html first creates a dummy context named "swa".
It then attaches the received backup.zip under Content-ID "sys" (cid:sys).
Next step is the extraction of export.xml from top level directory of the archive.
Then the general information HTML table at the top gets created.
Now iteration over the domains found in export.xml is done.
Each domain is contained in top level directory of received archive.
Eg. domain "dom1" will be read from cid:sys and attached as cid:dom1.zip.
The attaching allows to read export.xml from dom1.zip as well as to access
the files information for the domain by querying the attachment manifest.
In addition the files can be extracted and copied over to a newly created archive in case "files=all".
Finally the domain attachment gets removed by dp:strip-attachments before the next domain is processed.
There is a directory dp-aux in received archive (attachment cid:sys).
Above you see the inclusion hierarchy of the files in that directory.
Applying dp:transform(_,_) to clixform.xsl requires a URL as the reference to it.
"attachment://" is the protocol, "swa" is the context, "Archive=zip" says we have a zip-archive (DataPower has support for tar, too).
Finally "Filename=" points to a file in the archive, allowing to access all files at all directory levels.
The output of dp:transform() from clixform.xsl applied to export.xml is used to generate the CLI configuration output of each domain
(with yellow background color).
See the use of "localZip" if you need to create an empty archive yourself.
For each domain a new empty zip-archive gets attached to receive all files selected by "files=all" as "cid:aux".
Finally this zip-archive is read to generate the "data:application/zip;base64,..." links by just using dp:binary-decode().
At the bottom of stylesheet zip2html.xsl you find a section allowing to process "multipart/form-data" directly in the stylesheet.
swaform tool or func:filename() are needed in case you need to process binary file uploads, convert-http action cannot deal with those.
zip2html is realized by a Non-XML loopback XML firewall with "Process Messages Whose Body Is Empty" set to "on" on advanced tab.
The endpoint "/form" is for an HTTP GET request.
The endpoints "/attached", "/onboard" and "/mime" are for HTTP POST requests.
Now comes a tricky part, the dp:input-mapping needed to process the POST request input data requires data on its input context.
But there is no input data for the "/form" GET request using the same stylesheet.
On the right you see the simple solution I found for this mixed GET/POST processing problem for Non-XML input processing stylesheets:
Have two rules, one for "/form" endpoint, and another for everything else.
In "/form" rule have input context NULL for "Transform Binary" action.
In the other rule have input context INPUT -- that's it.
(click on the screenshot to see all details)