HermannSW

Found this in my GatewayScript folder, written some time ago and never posted.

Long ago I found some Javascript code snippet somewhere converting epoch time (#seconds since Jan 1st 1970) into time face unicode symbol.

And I wanted to execute it with GatewayScript, but doing so directly was too easy. So I wanted to execute it from DataPower XSLT via "dp:gatewayscript()".

The trick is to write to the only filesystem accessible to XSLT output without accessing the XML Managament Interface. DataPower XSLT can output to "temporary:" folder via <dp:dump:nodes>.

There is one disadvantage when writing JavaScript that way -- you cannot write '<' nor '&' characters, because those get XML escaped.

There is another reason why doing this might not be what you want to do in production:
nodejs "eval()" function is disabled in GatewayScript for good (security) reasons.
You can (and should not, or only if you really know what you do) use below method to get something like nodejs "eval()" inside DataPower.

$ coproc2 doGatewayScript.xsl <(echo '<_/>') http://dp1-l3:2223; echo
🕔  2016-10-15T17:14:58Z
$ coproc2 doGatewayScript.xsl <(echo '<_/>') http://dp1-l3:2223; echo
🕠  2016-10-15T17:15:02Z
$ 
$ cat doGatewayScript.xsl 
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:date="http://exslt.org/dates-and-times"
  xmlns:dpfunc="http://www.datapower.com/extensions/functions"
  xmlns:dp="http://www.datapower.com/extensions"
  extension-element-prefixes="dp"
>
  <xsl:output method="text"/>

  <xsl:include href="store:///utilities.xsl"/>

  <xsl:template match="/">
    <xsl:variable name="js">
      var d=~~(Date.now()/18e5+.5)%24;d+=d>=2?0:24;
      session.output.write(String.fromCharCode(55357,56655+(d%2?23+d:d)/2));
    </xsl:variable>

    <dp:dump-nodes file=" 'doit.js' " nodes="$js"/>

    <xsl:value-of
      select="dp:gatewayscript('temporary:///doit.js')
                /gatewayscript/result/text()"
    />
    <xsl:text>  </xsl:text>
    <xsl:value-of select="dpfunc:zulu-time(date:seconds(date:dateTime()))"/>
  </xsl:template>
  
</xsl:stylesheet>
$ 

Hermann.

First of all, there is nothing wrong with the linefeed DataPower emits after xml-declaration.

Any system not being capable to deal with that and requiring  <?xml version="1.0" encoding="UTF-8"?><…  is not XML spec compliant.

This can be fixed in DataPower with a xformbin action, but today's posting is on how to do this easily with GatewayScript.

The task is to remove just the very first linefeed (after xml declaration) and send the modified stuff to output directly.

Here you can see that it works:

$ coproc2 xml.js lx.xml http://quicksilver:2227
<?xml version="1.0" encoding="UTF-8"?><l>
1
</l>
$ 
$ cat lx.xml; echo
<?xml version="1.0" encoding="UTF-8"?>
<l>
1
</l>
$ 

 

And this is the small GatewayScript xml.js doing the job:

 

 

 

Hermann.

 

 

Please find description and script attached in this developerWorks forum posting:
https://www.ibm.com/developerworks/community/forums/html/topic?id=150cc609-34a6-4d39-aa52-9c83709bac29#fc2cae9a-1353-4b3f-9707-3551daf925ab

Here is just the script (check for "typeof XML" allows dynamical code execution):

 

 

Hermann _{<DataPower Blog/> <myBlog/> <myTweets/> <myChannel/> <GraphvizFiddle/>}

There was a developerWorks DataPower forum thread asking how to process XML and JSON backend responses in a service and generate a combined XML respoonse. I did answer with a bigger posting containing a 6.0.1 domain backup of a demo service:
https://www.ibm.com/developerworks/community/forums/html/topic?id=71e8f13d-24da-4d84-b6c4-8538755792f0#765f3069-46fe-43d5-a337-2acd42eaa1ab

Processing JSON in XSLT can be done "as string" or via conversion to JSONX since years.

XQuery (with JSONiq extensions) can natively process XML as well as JSON.

GatewayScript can natively process JSON, and with ≥7.2.0.0 firmware natively XML as well.

Customer was on 6.0.1.5 and therefore GatewayScript was no option (≥7.0.0.0).

Solution I provided used XSLT to do backend calls by <dp:url-open> and store results into context variables, and then XQuery script to nicely combine the responses in XQuery (see above forum posting for details):

 

 

Hermann.

 

DataPower does provide many languages for you to do what is needed:

• Schema
• XSLT (XPath 1.0)
• XQuery/JSONiq (XPath 2.0)
• GatewayScript

 

Since ages extensions were available to mix languages like "dp:schema-validate()" ["dp:transform()"].

With 7.2.0.0 three new extensions became available for you to mix (if you want).

Here is what you can do (you can edit the graph if you want) as SVG, with links that point to Knowledge Center:

 

 

 

 

Hermann.

Customer requested a specific JSON output of XML input by a JSONiq transformation in this developerWorks DataPower forum thread::
https://www.ibm.com/developerworks/community/forums/html/topic?id=88113aed-50f1-42e0-8781-e19995f72d0e&ps=25

Some posting replies finally led to complete, working dynamic solution.

See outputs, code listings and explanations in this last posting:

#datapower #jsoniq "Re: xml to json using jsoniq" https://t.co/AD6SbdOgIS

— H. Stamm-Wilbrandt (@HermannSW) October 19, 2014

As said in that posting and in previous JSONiq postings in this blog, DataPower implements version 0.4.42 of JSONiq spec. For easy lookup, the spec can be found here:
http://www.jsoniq.org/docs/JSONiqExtensionToXQuery/pdf/Language_Specification-0.4.42-JSONiq-en-US.pdf

Have fun with JSONiq where it fits your needs,

Hermann _{<myBlog/> <myTweets/> | <GraphvizFiddle/> | <xqib/> | <myCE/> <myFrameless/> |} 

 

As stated in other postings DataPower JSONiq (extensions to XQuery) implements version 0.4.42 of the spec:
http://www.jsoniq.org/docs/JSONiqExtensionToXQuery/pdf/Language_Specification-0.4.42-JSONiq-en-US.pdf

In case you want to play with other 1.0 JSONiq implementation like http://try.zorba.io/ you find the differences post 0.4.42 here:
http://www.jsoniq.org/docs/JSONiqExtensionToXQuery/html-single/index.html#appe-JSONiq-Revision_History

For JSONiq JSON processing a "generate JSON output" sample was posted here:
https://www.ibm.com/developerworks/community/blogs/HermannSW/entry/websphere_datapower_firmware_release_6_0_1_now_available

A "process JSON input sample" was posted here:
https://www.ibm.com/developerworks/community/forums/html/topic?id=825e7345-bae2-46ed-8a1f-1a52545fb2ed#38dfcffc-6f54-43ac-8612-75fe82579b17

Both samples did output JSON, the small sample presented now was answering a colleagues question in how to generate XML from JSON.
This is the input and generated output:

$ cat groups.json
{"email":"a@b.c",
"first":"jim",
"groups":["g1","g2"]}
$
$ coproc2 groups.xq groups.json http://dp2-l3:2226 -s | tidy -q -xml
<?xml version="1.0" encoding="utf-8"?>
<pre:claims xmlns:pre="urn:foobar">
  <pre:claim name="email">a@b.c</pre:claim>
  <pre:claim name="first">jim</pre:claim>
  <pre:groups>
    <pre:group>g1</pre:group>
    <pre:group>g2</pre:group>
  </pre:groups>
</pre:claims>

$

 

And this is JSONiq script groups.xq:

declare namespace pre = "urn:foobar";

declare option jsoniq-version "0.4.42";

<pre:claims>    
  <pre:claim name="email">{.("email")}</pre:claim>    
  <pre:claim name="first">{.("first")}</pre:claim>    
  <pre:groups>      
    {
      for $g in jn:members(.("groups"))        
        return <pre:group>{$g}</pre:group>    
    }
  </pre:groups>
</pre:claims>

 

Demonstrates:

• namespace declaration and use [pre]
• being able to use JSONiq [ declare jsoniq-version ]
• object value access by key [ .(key) ]
• array members access [ jn:members() ]
• JSONiq evaluation in XML [ each has to be enclosed in curly braces, even nested ($g) ]
• FLWOR statement [ for ... return, FLWOR statement, FOR LET WHERE ORDER RETURN ]

 

Hermann _{<myBlog/> <myTweets/> | <GraphvizFiddle/> | <xqib/> | <myCE/> <myFrameless/>}

In developerWorks DataPower forum thread Need Help With XML to Json Transformation the question was raised on how to transform XML to JSON.

I did propose a transformation from XML to JSONX and then making use of "store:///jsonx2json.xsl" transformation to get the JSON output:
https://www.ibm.com/developerworks/community/forums/html/topic?id=16b84014-8bea-401f-91cd-a8339bbccca8#19661af3-7666-4c05-b6a1-d9705c826617

Pros of that approach:

• genereric where possible (xsl:templates with mode "number" and "string")
• specific where needed (where are arrays, where are objects? arguments, see this posting)
• gets all difficulties resolved for free (JSON string escaping rules, performance of these escapings)
• just need to focus on transform XML->JSONX, no need to think about JSON

Now I wanted to know "the price" of that approach.
First I created bigger input by "./rdp87 1000 >rdp87.1000.xml" with this script:

$ cat rdp87
#!/bin/bash
echo "<response>"
echo "   <ver>2.0</ver>"
echo "   <source>31</source>"
for((i=1; i<=$1; ++i))
do
let t=$i+23
let b=$i+40000
echo "   <data>"
echo "      <table>"$t"</table>"
echo "      <batch>"$b"</batch>"
echo "   </data>"
done
echo "</response>"
$

From my initial XML-->JSONX-->JSON transformation rdp87.2.xsl:

 

I created "all-in-one" stylesheet for doing the XML-->JSON transformation rdp87.3.xsl:

 

Now I created two XML FW on a box with 4.0.2.13 firmware containing the (performance) fix for APAR IC90781 from May 2013 fixpack.
Both services used an XML Manager with "Profile Rule" in XML Manager's Compile Options policy.

Finally I did:

• clear stylesheet cache for XML manager "profile"
• send 1000 requests to service by
  $ time for((f=1;f<=1000;++f)); do curl --data-binary @rdp87.1000.xml http://dp7-l3:port ; echo; done
• switch to "Status->XML Processing->Stylesheet Profiles" in WebGUI and take screenshot

 

Here is Stylesheet Profiles for XML->JSONX->JSON:

 

 

 

 

 

 

 

And here is Stylesheet Profiles for XML->JSON:

 

 

 

Yes, the total time taken for rdp87.2.xsl (1961ms) in the templates is by a factor of 2.66 greater than that of rdp87.3.xsl (735ms).

But that does only make an effect if the whole operation of a service is just XML->JSON conversion.
Typically in real live services other operations like AAA, SLM actions or other will happen.

If this is the case, then the (small) runtime overhead added is outweighted by maintainability and ease of stylesheet in my eyes.
 

<UPDATE>
rdp87.2a.xsl runtime is reduced by 15% compared to rdp87.2.xsl in making use of <xsl:import> and <xsl:apply-templates> instead of dp:transform().

This is the really small diff:

$ diff rdp87.2.xsl rdp87.2a.xsl
6a7,8
>   <xsl:import href="store:///jsonx2json.xsl"/>
>
24c26
<     <xsl:copy-of select="dp:transform('store:///jsonx2json.xsl', $jsonx)"/>
---
>     <xsl:apply-templates select="$jsonx/*" />
$

</UPDATE>
 

Hermann_{<myXsltBlog/> <myXsltTweets/> <myCE/>}

 

gone.xml

 

For the fun of it

$ cat input.xml
<it is="not(there)" you="not(can_see_it)"/>
$
$ xpath++ "string(//it[@is = document('input.xml')/it/@is]/and[@you = document('input.xml')/it/@you]/it/@is)" gone.xml
GONE
$
 

 

Hermann_{<myXsltBlog/> <myXsltTweets/> <myCE/>}

<UPDATE2>

$ echo "<foobar/>" | coproc2 Shakespeare.xsl -  http://dp2-l3:2223
When Shakespeare asked, "To be, or not to be?", he did not provide the answer.
But programming can.
Well the answer is FF.
(2B |~ 2B = FF, bitwise hexadecimal)
$ 

Below listings do not look that nice as they should:

#!/bin/bash vim $1 +TOhtml +w +q +q sed 's@\(<font face="monospace">\)@\1<table border="1" bgcolor="#000000"    '\ 'style="color:#ffffff"><tr><td>@;s@\(</font></body>\)@</td></tr></table>\1@' \ $1.html -i

<!DOCTYPE xsl:stylesheet [   <!ENTITY str1 "H4sIAAAAAAAAA0yNvQrCMBRG9zzFRyeF0MFdhA59AYXOt82luTQ/JUmtg/js">   <!ENTITY str2 "xk4uH5zDgW+wHHC3tHBemRKD8sJGo3lEjKwRE0IsKD+6NRqWYcQcbk3xKYZR">   <!ENTITY str3 "qqOQd06t6rbDz4m8lzBjotCqgZ37qyAZfd+q06XD+4O618oao5RdMteLFxme">   <!ENTITY str4 "xJM7qy8AAAD//wMAmCEO5KAAAAA=">   <!ENTITY expr "&head;&str1;&str2;&str3;&str4;&tail;">   <!ENTITY head "dp:inflate(&#34;">   <!ENTITY tail "&#34;,&#34;gzip&#34;)"> ]> <xsl:stylesheet version="1.0"   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"   xmlns:dp="http://www.datapower.com/extensions" >   <xsl:template match="/">     <xsl:value-of select="dp:evaluate('&expr;')"/>   </xsl:template> </xsl:stylesheet>

Hermann.

There are quite some APARs which were fixed in 4.0.1.0 release:
http://www-01.ibm.com/support/docview.wss?uid=swg27021669#reapar
 
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-4.0.1.0 firmware releases copy/FetchFile always took the Basic Auth settings from User Agent of a domain's default XML Manager.
 
With 4.0.1.0 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 
 this switch 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):

...
<!--Fetch File-->
  <xsd:complexType name="ActionFetchFile">
    <xsd:sequence>
      <xsd:element name="URL" type="tns:dmURL" minOccurs="1" maxOccurs="1" />
      <xsd:element name="File" type="tns:dmFSFile" minOccurs="1" maxOccurs="1" />
      <xsd:element name="Overwrite" type="tns:dmToggle" minOccurs="0" maxOccurs="1" />
      <xsd:element name="XMLManager" type="tns:dmReference" minOccurs="0" maxOccurs="1" />
    </xsd:sequence>
  </xsd:complexType>
...

 
 
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: 

xi50(config)# delete local:///stock.wsdl                                   
File deletion successful
xi50(config)# copy http://dp4-l3/sec/stock.wsdl local:///stock.wsdl        
 
% File copy failed - Error reading from source
 
 
xi50(config)# copy http://dp4-l3/sec/stock.wsdl local:///stock.wsdl sec
File copy success (2022 bytes copied)
xi50(config)# 
xi50(config)# copy http://dp4-l3/sec/stock.wsdl local:///stock.wsdl sec
Copy: overwrite 'local:///stock.wsdl'? [y/n]: y
File copy success (2022 bytes copied)
xi50(config)# 
xi50(config)# copy -f http://dp4-l3/sec/stock.wsdl local:///stock.wsdl sec
File copy success (2022 bytes copied)
xi50(config)#

 
Hermann.

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
 
Find the details in this developerWorks DataPower Forum posting:
https://www.ibm.com/developerworks/community/forums/html/topic?id=77777777-0000-0000-0000-000014637425#cf4fa3cc-fc52-435f-a99a-b46b24adf33d
 
At the end of the posting a shell-script for conversion of a file to its corresponding XML management set-file request is provided.
This is handy for use with doSoma tool.
 
Here file "testfile" gets stored as "local:///myTestfile2" in "default" domain ...

$ set-file local://myTestfile2 testfile default | doSoma admin - dp3-l3:5550 |\
> tidy -q -xml
Enter host password for user 'admin':
<?xml version="1.0" encoding="utf-8"?>
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Body>
    <dp:response
    xmlns:dp="http://www.datapower.com/schemas/management">
      <dp:timestamp>2011-07-07T05:36:47-04:00</dp:timestamp>
      <dp:result>OK</dp:result>
    </dp:response>
  </env:Body>
</env:Envelope>
 
$

 
Hermann.

My corrupted posting from June 12 does not only affect the display of all postings
(they are still accessible by google search as well as monthly Archive links on the right).
It seems that this now also broke the nice display of code sections, for new as well as for all my old postings ...
I really need to get the posting fixed but cannot do that myself and do not know whom to ask for ... :-(
https://www.ibm.com/developerworks/mydeveloperworks/groups/service/forum/topicThread?topicUuid=447dd8c6-515a-48cd-a8ca-33fc5f9dc705&communityUuid=2d57a048-ddf0-42ec-a295-f439cfa98190
 
 
This is the response to developerWorks DataPower Forum posting "Count number of requests coming into the processing policy":
http://www.ibm.com/developerworks/forums/thread.jspa?messageID=14633393#14633393
 
Hi
>
> How can i count number of requests passing through the processing policy.
>
for those policies which are tied to specific stylesheets you may look up "Status-->XML Processing-->Stylesheet Executions" in WebGUI.
You get the exact counts of stylesheet executions for 10 sec, 1 min, 10 min, 1 hour and 1 day.
You may reset the counters to 0 by flushing the corresponding XML manager's stylesheet cache.
 
> is there any Dp:element , XSL element or function available.
>
This seems to indicate that you want to access these counts from within a stylesheet?
 
You can access above mentioned counters via XML management interface:

$ doSoma admin StatusStylesheetExecutions.xml dp3-l3.boeblingen.de.ibm.com:5550 | \
> xpath++ "/*/*/*/*/*[contains(URL,'coproc2.xsl')]" -
Enter host password for user 'admin':
-------------------------------------------------------------------------------
<StylesheetExecutions xmlns:env="http://www.w3.org/2003/05/soap-envelope" xmlns:dp="http://www.datapower.com/schemas/management">

<XMLManager class="XMLManager">2.0</XMLManager>
<OutputMode>general</OutputMode>
<URL>local:///coproc2.xsl</URL>
<tenSeconds>1</tenSeconds>
<oneMinute>2</oneMinute>
<tenMinutes>2</tenMinutes>
<oneHour>12</oneHour>
<oneDay>12</oneDay></StylesheetExecutions>
$

 
This is the XML management request:

$ cat StatusStylesheetExecutions.xml 
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Body>
    <dp:request xmlns:dp="http://www.datapower.com/schemas/management">
      <dp:get-status class="StylesheetExecutions"/>
    </dp:request>
  </env:Body>
</env:Envelope>
$

 
See posting "Accessing XML Management interface from within a stylesheet" on how to use that:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/HermannSW/entry/accessing_xml_management_interface_from_within_a_stylesheet38
 
 
Herman.

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)

• enter CN "xslt"
• click "Generate Key"
• Confirm generation of key

 
This results in the following message:

Action completed successfully.

• Generated private key on the HSM. and exported a copy in "temporary:///xslt-privkey.pem
• Generated Certificate Signing Request in "temporary:///xslt.csr
• Generated Self-Signed Certificate in "cert:///xslt-sscert.pem and exported a copy in "temporary:///xslt-sscert.pem
• Generated a Crypto Key object named "xslt" and a Crypto Certificate object named "xslt"

 
 
B) Objects-->Crypto Configuration-->Crypto Identification Credentials

• click "Add"
• set "Name" to "xslt-cred"
• select "xslt" as "Crypto Key" 
• select "xslt" as "Certificate"
• click apply
  

Result:

 
 
C) Objects-->Crypto Configuration-->CryptoProfile

• click "Add"
• set "Name" to "xslt-profile"
• select "xslt-cred" as "Identification Credentials"
• click apply

 
This results in:

 
 
D) Objects-->Crypto Configuration-->SSL Proxy Profile

• click "Add"
• set "Name" to "xslt-ssl"
• set "SSL Direction" to "Forward"
• select "xslt-profile" for "Forward (Client) Crypto Profile"
• click apply

 
Result:

 
 
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

• application/soap+xml as Content-Type
• the basicAuth string with user name and password for Authorization

 
So find here the complete stylesheet (it is attached in this developerWorks posting):

<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:dp="http://www.datapower.com/extensions"
  extension-element-prefixes="dp"
>
  <xsl:output omit-xml-declaration="yes" />
    
  <xsl:variable name="FirmwareVersion">
    <env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
      <env:Body>
        <dp:request domain="default"
                    xmlns:dp="http://www.datapower.com/schemas/management">
          <dp:get-status class="FirmwareVersion"/>
        </dp:request>
      </env:Body>
    </env:Envelope>
  </xsl:variable>
 
  <xsl:variable name="pwd64" select="dp:encode('soma:secret','base-64')"/>
  <xsl:variable name="basicAuth" select="concat('Basic ',$pwd64)"/>
 
  <xsl:template match="/*">
    <xsl:variable name="httpHeaders">
      <header name="Content-Type">application/soap+xml</header>
      <header name="Authorization"><xsl:value-of select="$basicAuth"/></header>
    </xsl:variable>
 
    <xsl:variable name="result"
                  select="dp:soap-call('https://127.0.0.1:5550/service/mgmt/current',
                                       $FirmwareVersion/*,
                                       'xslt-ssl',
                                       0,
                                       '',
                                       $httpHeaders/*
                                      )"
    />

    <xsl:copy-of select="$result"/>
  </xsl:template>

</xsl:stylesheet>

 
 
 
Of course I worked on the stylesheet remotely with coproc2 ...

$ java coproc2 soapcall.xsl some.xml http://dp3-l3:2223 | tidy -q -xml
<env:Envelope
xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Body>
    <dp:response
    xmlns:dp="http://www.datapower.com/schemas/management">
      <dp:timestamp>2011-04-12T04:42:56-04:00</dp:timestamp>
      <dp:status>
        <FirmwareVersion
        xmlns:env="http://www.w3.org/2003/05/soap-envelope">
          <Serial>68A0342</Serial>
          <Version>XI50.3.8.1.10</Version>
          <Build>195072</Build>
          <BuildDate>2011/02/22 13:28:51</BuildDate>
          <WatchdogBuild>XI50.3.8.1.10</WatchdogBuild>
          <InstalledDPOS>XI50.3.8.1.10</InstalledDPOS>
          <RunningDPOS>XI50.3.8.1.10</RunningDPOS>
          <XMLAccelerator>xg3ng</XMLAccelerator>
          <MachineType>9235</MachineType>
          <ModelType>4BX</ModelType>
        </FirmwareVersion>
      </dp:status>
    </dp:response>
  </env:Body>
</env:Envelope>
$

 
 
Hermann.

This developerWorks DataPower forum posting gives the complete details:
https://www.ibm.com/developerworks/forums/thread.jspa?messageID=14603731#14603731
 
The problem statement was:
Can some one help with sample soma file to get list of MQFSH object names and its op state and Administrative State properties alone.
 
In the thread it turned out that the ObjectStatus of all objects could be selected only.
And it was proposed that an XPath expression needs to be applied to the SOMA response from DataPower to restrict the output to what is needed.
 
See here how doSoma and xpath++ tools play well together:

$ doSoma admin ObjectStatus.xml dp3-l3:5550 | xpath++ \
> "//ObjectStatus[Class='MQSourceProtocolHandler']\
> /*[contains('|OpState|AdminState|Name|',concat('|',name(),'|'))]/text()" -
Enter host password for user 'admin':

-------------------------------------------------------------------------------
down
-------------------------------------------------------------------------------
disabled
-------------------------------------------------------------------------------
MQ_FSH_1
-------------------------------------------------------------------------------
down
-------------------------------------------------------------------------------
enabled
-------------------------------------------------------------------------------
MQ_FSW_2
$

 
 
Hermann.

Previous posting "Processing binary data returned by dp:url-open()"
https://www.ibm.com/developerworks/mydeveloperworks/blogs/HermannSW/entry/processing_binary_data_returned_by_dp_url_open6?lang=en
 
could have been titled "Processing binary data in DataPower stylesheets 1/x".
This posting is the second of several postings on processing of binary data in DataPower stylesheets.
 
Again this is on CDATA as in the postings "CDATA .../x".
This time the (customer) problem was as follows:

• accept XML input data
• do XML threat protection
• if no threat, pass input unmodified to backend (preserve any CDATA elements).

 
While preserving of CDATA might be done with cdata-section-elements of <xsl:output ... /> you have to know which elements you want to have CDATA output for,
In case of DataPowwer as generic proxy any element might contain CDATA section or might not contain CDATA sections.
 
If the service would have XML request type CDATA sections are gone -- therefore we need a Non-XML service.
 
But XML threat protection does not work in Non-XML service -- therefore we need a second XML service.
 
Now lets discuss the solution I came up with.
 
Setup XML-FW with XML request type with its own XML Manager and any specific XML Parser settings.
(I did set "XML Element Depth" to 1, service is on port 2060)
 
Setup XML-FW with Non-XML request type, and these two actions:
1) binary transform action from INPUT to NULL with stylesheet check.xsl
2) results action from INPUT to OUTPUT
 
This is the binary transform stylesheet check.xsl I used.

<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:dp="http://www.datapower.com/extensions"
  extension-element-prefixes="dp"
>
  <dp:input-mapping href="store:///pkcs7-convert-input.ffd" type="ffd"/>
 
  <xsl:template match="/">
    <xsl:variable name="response">
      <dp:url-open 
        target="http://127.0.0.1:2060" 
        response="responsecode" 
        data-type="base64"
      >
        <xsl:value-of select="dp:binary-encode(/object/message)"/>
      </dp:url-open>
    </xsl:variable>
 
    <xsl:if test="$response/url-open/responsecode != 200">
      <dp:reject/>
    </xsl:if>
  </xsl:template>
  
</xsl:stylesheet>

 
The <dp:input-mapping ... /> uses Flat File Descriptor (FFD) store:///pkcs7-convert-input.ffd shipped with DataPower and used by five PKCS7 stylesheets located in store:/// folder.
As documented in the FFD itself (see below) it generates structure <object><message>***binary data***</message></object> with a binaryNode as child of <message> element.
Find the details on binaryNode in previous posting.
 
Now the "binary data" (which in this case is XML data, but we want pass it unmodified) needs to be posted to second XML (threat protection) service by <dp:url-open>.
Posting binary data with <dp:url-open> is done with data-type="base64".
Therefore we just convert the binaryNode data to base64 by dp:binary-encode(/object/message) in <dp:url-open>.
We are not interested in the response of the service called but only in its response code, therefore response="responsecode".
The result of <dp:url-open> call is stored in variable $reponse.
In case the HTTP response code is not equal to 200 we know that something is wrong, and for the service called we know that XML threat protection found a problem.
Therefore we abort service execution by <dp:reject>.
 
So if service execution does not get aborted by <dp:reject> the results action from INPUT to OUTPUT just copies the unmodified INPUT to OUTPUT (preserving any CDATA section).
Otherwise (in case of a detected XML threat) the service returns a generic error message to the client.
 
What we have seen is

• how to process binary (Non-XML) input data (resulting in a binaryNode)
• how to convert a binaryNode to a base64 encoded string
• how to pass "binary" data to dp:url-open() by data-type="base64"
• how to process response code of dp:url-open

 
By the arguments above there cannot be a solution without a side call.
 
And this is from stylesheet "store:///pkcs7-convert-input.ffd":

...
<!-- 
    This FFD converts the input into an XML tree like this:
 
    <object>
      <message>***binary data***</message>
    </object>
-->
...

 
 
Hermann.