The advantage of dp:decode(_,'base-64') is that it does a UTF-8 validation and preventes negative effects.
I cannot give a more complete example until having access to my boxes in the IBM network which I do not have (and do not want to have :-) ) by my cell phone or the Internet terminal in our youth hostel in most nordic German town List on North Sea island Sylt ...
... the total precision is therefore 53 bits (approximately 16 decimal digits). ... ... For the next range, from 253 (=9,007,199,254,740,992) to 254, everything is multiplied by 2, ...
Below you can see the output of DataPower, xsltproc, xalan and saxon XSLT processors for numbers with 15 to 18 digits. Reported is the length, the conversion of the input string to number (by XSLT core function number()) as well as the original input string. The last 16 digit number is the lowest (positive) integer with precision loss:
In addition the posting shows how to make use of netcat tool as simplest form of a rawTCP server. This
is useful in debugging issues between DataPower and other TCP servers
-- get it working with netcat and you know that DataPower side is fine.
The latency values get logged at information level when a DataPower service accesses some real backend (not with skip-backside).
If you do want the entries in loopback case just have a simple pass-thru XML FW on the box as "backend".
The technote describes the 16 values by order of output in the log message.
This does not correspond to the order these values get timestamped during execution of a transaction.
Find below the reordering of technote table according to the real execution order (see <EDIT>...</EDIT> below for a restriction).
The messages in the table have been replaced by WebGUI online help messages (if you click on "Latency: ..." in the log).
In addition I added coloring of the different phases of the transaction:
receive request header
front side processing
transmit to back side
receive header from back side
back side processing
transmit response to front side
You do have access to 3 of the values by read-only service variables:
In addition you may access var://service/time-elapsed (the value used for creation of all 16 latency values, read-only).
request headers read
front side transform begun
front side parsing complete
front side stylesheet ready
front side transform complete
back side connection attempted
(this is when the connection is first tried)
back side connection completed
(or time connection attempt gave up)
request headers sent
entire request transmitted
response headers received
back side transform begun
back side parsing complete
back side stylesheet ready
back side transform complete
response headers sent
A colleague made me aware that this order cannot be guaranteed in case of streaming processing.
(see DataPower XML data processing)
Unfortunately the time column did not report timing values as milliseconds (as it should) but in sub-microseconds. The real value are not that important as for performance tuning the relative correctness of the reported times was good enough to work on transformation bottlenecks. The incorrect timing values have been fixed in April fixpack:
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
set "Name" to "xslt-cred"
select "xslt" as "Crypto Key"
select "xslt" as "Certificate"
C) Objects-->Crypto Configuration-->CryptoProfile
set "Name" to "xslt-profile"
select "xslt-cred" as "Identification Credentials"
select "xslt-profile" for "Forward (Client) Crypto 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
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):