HermannSW

DataPower allows processing of XML processing in all ICU supported encodings.

You can find a list (including all alias names) here, 321 different groups with more than 1000 aliases:
http://demo.icu-project.org/icu-bin/convexp
 

GatewayScript does support the same few encodings nodejs does support:

• ascii, base64, binary, hex, utf16le, ucs2, utf16le, utf8

In this developerWorks forum posting the question was stated, how to XML parse base64 encoded codepage 1141 ebcdic string:
https://www.ibm.com/developerworks/community/forums/html/topic?id=d659ab27-563a-428e-9ec1-a2970e06ad67#d659ab27-563a-428e-9ec1-a2970e06ad67

In my response I showed a Non-XML stylesheet solution, which is required for all ebcdic type encodings.
[ Non-ebcdic encoding base64 strings can be parsed easily by "dp:parse($inp, 'base64')" ]

Customer came back that his appliance misses DataGlue license needed for processing Non-XML (DataPower proprietary) stylesheeet.

So here I will show how you can parse arbitray ICU encodings from above list in GatewayScript. Some work is needed, though, which I describe now. This is a followup on blog posting "Processing ISO-8859-15 data in GatewayScrip":
https://www.ibm.com/developerworks/community/blogs/HermannSW/entry/Howto_adapt_ICU_code_page_conversion_for_GatewayScript

First you need to open the code page you are interested in with your browser, this is for IBM01141 codepage, you can click the link on the page I pointed to above:
http://demo.icu-project.org/icu-bin/convexp?conv=ibm-1141_P100-1997&s=ALL

Next you select codepage layout table rows "00" to "F0" comletely and copy them.

Then you open LibreOffic Calc, create a new spreadsheet and paste your clipboard. Calc will recognize your data and create rows 1-16 and columns A-R from it.

First you delete column R (not needed), but keep not needed column A (that will generate needed commata later).

Then you add this formula into cell B18:
=+CONCATENATE("0x",RIGHT(B1,4))

Now you select area B18-Q33, then Edit->Fill->Down and then Edit->Fill->Right.

Next you check for conversions that did not work, P25 in our case and replace by correct value you lookup in codepage layout as 0x003D for codepoint 7E.

Finally you save the document with delimiter ',' and empty text delimiters (no quotes).

Then you take the last 16 rows of that file into your C or GatewayScript program for defining a 256 character mapping array.

The two boolean variables determine whether base64 encoded or raw IBM01141 encoded data is processed, and whether the decoded result will be returned as is, or will be XML parsed.

This is the sample input I use, the decoded cp1141 ebcdic does not look nice in browser:

$ cat ab.1141.xml.b64 
TG+nlJNApYWZoomWlX5/8Uvwf0CFlYOWhImVh35/ycLU8PHx9PF/b24lTIFu8UyCbvJMYYJu80xhgW4=$ 
$ base64 -d ab.1141.xml.b64 ; echo
Lo���@�������~�K�@��������~��������on%L�n�L�n�La�n�La�n
$ 

This is decoding without XML parsing:

$ coproc2 readIBM01141.js ab.1141.xml.b64 http://dp3-l3:2227 -s ; echo
<?xml version="1.0" encoding="IBM01141"?>
<a>1<b>2</b>3</a>
$ 
$ coproc2 readIBM01141.js ab.1141.xml.b64 http://dp3-l3:2227 -s | od -tx1
0000000 3c 3f 78 6d 6c 20 76 65 72 73 69 6f 6e 3d 22 31
0000020 2e 30 22 20 65 6e 63 6f 64 69 6e 67 3d 22 49 42
0000040 4d 30 31 31 34 31 22 3f 3e 0a 3c 61 3e 31 3c 62
0000060 3e 32 3c 2f 62 3e 33 3c 2f 61 3e
0000073
$ 

As you can see the result is UTF-8 encoded, and therefore Non-XML (wrong@encoding in XML declaration).

That is the reason why XML.parse() has to skip the XML declaration to successfully parse as XML.

Here you see correct XML parsed result with parseAsXML = true

$ coproc2 readIBM01141.js ab.1141.xml.b64 http://dp3-l3:2227 -s ; echo
<?xml version="1.0" encoding="UTF-8"?>
<a>1<b>2</b>3</a>
$ 

Hermann.

https://stamm-wilbrandt.de/en/forum/readIBM01141.js

session.input.readAsBuffer(function (error, buf) {
    "use strict";
    var str, i, n, buf2;
    var base64decode = true, parseAsXML = true;

    if (base64decode) {
        str = buf.toString();
        n = buf.write(str, 0, str.length, "base64");
    } else {
        n = buf.length;
    }

    buf2 = new Buffer(2 * n);

    if (error) {
        // handle error
        session.output.write(error.errorMessage);
    } else {
        // Conversion from unicode base plane to UTF16LE is really simple.
        for(i = 0; i < n; i += 1) {
            // write [converted] value n as 16bit little endian word
            buf2.writeUInt16LE( map1141[buf[i]], 2 * i );
        }

        str = buf2.toString("utf16le");

        if (parseAsXML) {
            session.output.write( XML.parse(str.substr(str.indexOf("?>") + 2)) );
        } else {
            session.output.write( str );
        }
    }
});

var map1141 = [
0x0000,0x0001,0x0002,0x0003,0x009C,0x0009,0x0086,0x007F,0x0097,0x008D,0x008E,0x000B,0x000C,0x000D,0x000E,0x000F
,0x0010,0x0011,0x0012,0x0013,0x009D,0x0085,0x0008,0x0087,0x0018,0x0019,0x0092,0x008F,0x001C,0x001D,0x001E,0x001F
,0x80,0x81,0x0082,0x0083,0x84,0x000A,0x0017,0x001B,0x0088,0x0089,0x008A,0x008B,0x008C,0x0005,0x0006,0x0007
,0x0090,0x0091,0x0016,0x0093,0x0094,0x0095,0x0096,0x0004,0x0098,0x99,0x009A,0x009B,0x0014,0x0015,0x009E,0x001A
,0x20,0x00A0,0x00E2,0x007B,0x00E0,0x00E1,0x00E3,0x00E5,0x00E7,0x00F1,0x00C4,0x002E,0x003C,0x0028,0x002B,0x0021
,0x0026,0x00E9,0x00EA,0x00EB,0x00E8,0x00ED,0x00EE,0x00EF,0x00EC,0x007E,0x00DC,0x0024,0x002A,0x0029,0x003B,0x005E
,0x002D,0x002F,0x00C2,0x005B,0x00C0,0x00C1,0x00C3,0x00C5,0x00C7,0x00D1,0x00F6,0x002C,0x0025,0x005F,0x003E,0x003F
,0x00F8,0x00C9,0x00CA,0x00CB,0x00C8,0x00CD,0x00CE,0x00CF,0x00CC,0x0060,0x003A,0x0023,0x00A7,0x0027,0x3D,0x0022
,0x00D8,0x0061,0x0062,0x0063,0x0064,0x0065,0x0066,0x0067,0x0068,0x0069,0x00AB,0x00BB,0x00F0,0x00FD,0x00FE,0x00B1
,0x00B0,0x006A,0x006B,0x006C,0x006D,0x006E,0x006F,0x0070,0x0071,0x0072,0x00AA,0x00BA,0x00E6,0x00B8,0x00C6,0x20AC
,0x00B5,0x00DF,0x0073,0x0074,0x0075,0x0076,0x0077,0x0078,0x0079,0x007A,0x00A1,0x00BF,0x00D0,0x00DD,0x00DE,0x00AE
,0x00A2,0x00A3,0x00A5,0x00B7,0x00A9,0x0040,0x00B6,0x00BC,0x00BD,0x00BE,0x00AC,0x007C,0x00AF,0x00A8,0x00B4,0x00D7
,0x00E4,0x0041,0x0042,0x0043,0x0044,0x0045,0x0046,0x0047,0x0048,0x0049,0x00AD,0x00F4,0x00A6,0x00F2,0x00F3,0x00F5
,0x00FC,0x004A,0x004B,0x004C,0x004D,0x004E,0x004F,0x0050,0x0051,0x0052,0x00B9,0x00FB,0x007D,0x00F9,0x00FA,0x00FF
,0x00D6,0x00F7,0x0053,0x0054,0x0055,0x0056,0x0057,0x0058,0x0059,0x005A,0x00B2,0x00D4,0x005C,0x00D2,0x00D3,0x00D5
,0x30,0x0031,0x0032,0x0033,0x0034,0x0035,0x0036,0x0037,0x0038,0x0039,0x00B3,0x00DB,0x005D,0x00D9,0x00DA,0x009F
];

<EDIT>you can play with DataPower developer Edition for free if you are interested: https://developer.ibm.com/datapower/docker/</EDIT>

In 2015 I blogged on DataPower Languages, and how to call from one of DataPower languages out to others (GatewayScript, XSLT, XQuery, XPath, Schema).

In 2016 I blogged on Using XPath 1.0 and XPath 2.0 in GatewayScript, which demonstrated how GatewayScript called out to XSLT that called out to XQuery allowing XPath 2.0 evaluation on XML in GatewayScript not available otherwise. In the solution there were three static files: GatewayScript script, XSLT stylesheet and XQuery script.

Last August I answered developerWorks forum posting Dynamic XQuery on how to execute dynamic XQuery from XSLT.

Today I want to show a more dynamic approach of calling XQuery from GatewayScript through XSLT, the red path in this diagram:

The simple XQuery sample I use today just calls (Xquery) XPaths 2.0 function fn:reverse() on XML nodeset "//*" from GatewayScript:

💻  coproc2 3lang.js <(echo '<a>1<b>2</b>3</a>') http://dp6-l3:2227; echo
<b>2</b><a>1<b>2</b>3</a>
💻  

You can find complete 3-language script here:
https://stamm-wilbrandt.de/en/blog/3lang.js

So lets discuss the different parts here now. Here GatewayScript variable "xslt" gets defined as XML parsed stylesheet. Why parsing? Sometimes in XSLT both, quotes and apostrophes are needed, which requires escaping in a GatewayScript string. Parsing successfully assures that no typo is in the stylesheet part. As you can see the XQuery script is inside the $xq XSLT variable definition. I added an unnneded XQuery comment only to have comment for 3 languages in a single source file (there is an XML comment explaining $xq nd the initial GatewayScript comment as well. While it is not documented in Knowledge  center how to write to a context with <dp:set-variable> in XSLT, it works and writing to context  variables is described of course. As you can see you need to write a sting into the context, writing just $xq (which is a text node) would not work. Finally <dp:xquery-transform> executed the dynamically create XQuery script in context "xquery":

// GatewayScript executes stylesheet "xslt", which executes XQuery script $xq
//
var xslt = XML.parse("                                                        \
<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:template match='/'>                                                    \
    <!-- $xq is XQuery script to be executed in XSLT -->                      \
    <xsl:variable name='xq'>fn:reverse(//*) (: comment :)</xsl:variable>      \
                                                                              \
    <dp:set-variable name=\"'var://context/xquery'\" value='string($xq)' />   \
                                                                              \
    <xsl:copy-of select=\"dp:xquery-transform('var://context/xquery', /)\"/>  \
  </xsl:template>                                                             \
                                                                              \
</xsl:stylesheet>                                                             \
");                                                                        // A

Next the input XML gets parsed in GatewayScript via .readAsXML(), the input "file" gets created on the fly in a bash sub shell in coproc2 command above:

var fs = require('fs');
var transform = require('transform');

session.input.readAsXML(function(error, xml) { throwIf(error);             // B

While GatewayScript context object allows to execute scripts stored in a context, and to create contexts, read and write to/from context variables, it misses the feature of filling a context with content. So how can we pass a dynamic XSLt for GatewayScript execution? The answer is to generate a temp file in "temporary:" folder, which is a ramdisk filesystem. In order to avoid any interference between concurrently executed transactions, fs module fs.temporary() function creates a unique temporary filename each time. I never used GatewayScript temporary files until now, but I really like the "Mission Impossible" like "this tempfile will self destruct in 5 seconds" ;-) So the fs.writeFile() just stores our XSLT in a temporary file, that will go away from alone in 5 seconds:

  var tmp_file = fs.temporary();
  var options = {'file': tmp_file, 'data': XML.stringify(xslt), 'TTL': 5};

  fs.writeFile(options, function(error) { throwIf(error);                  // C

Here we all out to XSLT referencing the new temp file as stylsheet:

    options = {"location": tmp_file, "xmldom": xml};

    transform.xslt(options, function(err, nodelist, abort) { throwIf(err); // D

Finally we output the resulting XML nodeset to session.output in GatewayScript. The explicit call to XML.stringify() demonstrates how to pass the option corresponding to XSLT's <xsl:output> setting omit-xml-declaration="yes":

      session.output.write(
        XML.stringify( {omitXmlDeclaration: true}, nodelist)               // E
      );

The rest is just my minimal error handling throwIf() function, which minimizes code lines in above code. It behaves identical to XSLT <xsl:message terminate="yes">, aborts immediately (as long as no catch block is specified in GatewayScript):

    });
  });
});

function throwIf(error) { if (error)  throw error; }                       // F

Have fun with dynamic scripts in GatewayScript/XSLT, and self destruction temp files,

Hermann.

A customer wanted to determine all (defined) context variable names in GatewayScript.

I do not know the reasoning for that request, but here is a solution.

First, the variable names of any context in a DataPower transaction are stored in "var://local/_extension/variables".

GatewayScript can only access "var://context" variables, but not "var://local:" variables.

So GatewayScript has to callout to a stylesheet doing the job.

The stylesheet needs to iterate over all contexts ('var://service/multistep/contexts'), query the context variables and combine all as result. This is stylesheet context-variables.xsl doing that:

💻  cat context-variables.xsl 
<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="ctxsVar" select=" 'var://service/multistep/contexts' "/>
  <xsl:variable name="ctxs" select="dp:variable($ctxsVar)"/>
  <xsl:variable name="ctx" select=" 'var://context/' "/>
  <xsl:variable name="ev" select=" '/_extension/variables' "/>

  <xsl:template match="/">
    <result>
      <xsl:apply-templates select="$ctxs/contextList/contextName"/>
    </result>
  </xsl:template>
  
  <xsl:template match="contextName">
    <context name="{.}">
      <xsl:copy-of select="dp:variable(concat($ctx, ., $ev))"/>
    </context>
  </xsl:template>
  
</xsl:stylesheet>
💻  

This stylesheet can now be called from GatewayScript and that works:

💻  coproc2 context-variables.js <('') http://dp3-l3:2227 -s | tidy -q -xml
<result>
  <context name="foo">
    <variables>
      <variable>var://local/bar</variable>
      <variable>var://local/xyz</variable>
    </variables>
  </context>
  <context name="xsl">
    <variables />
  </context>
  <context name="INPUT">
    <variables>
      <variable>var://local/foo</variable>
    </variables>
  </context>
</result>

💻  

This is the first simple GatewayScript with XML output:

💻  cat context-variables.js
var transform = require('transform');

var options = {
    "location": "local:///context-variables.xsl",
    'xmldom': XML.parse('<dummy/>')
};
              
transform.xslt(options, function(error, nodelist, abortinfo) {
  if (error) {
    session.output.write(error);
  }
  else {
    session.output.write(nodelist.item(0));
  }
});
💻  

Now if you like a JSON response, this can be done as well by a small traversal of the XML DOM returned from transform.xslt():

💻  coproc2 context-variables.json.js <('') http://dp3-l3:2227 -s ; echo
{"foo":["var://local/bar","var://local/xyz"],"xsl":[],"INPUT":["var://local/foo"]}
💻  

And this is the GatewayScript script, just some additional traversal code over the previous:

💻  cat context-variables.json.js 
var transform = require('transform');

var options = {
    "location": "local:///context-variables.xsl",
    'xmldom': XML.parse('<dummy/>')
};
              
transform.xslt(options, function(error, nodelist, abortinfo) {
  if (error) {
    session.output.write(error);
  }
  else {
    var i, j, ctxs, obj={};

    ctxs=nodelist.item(0).getElementsByTagName("context");
    for(i=0; i<ctxs.length; ++i) {
        var ctx = ctxs.item(i);
        var arr = [];
        var vars=ctx.getElementsByTagName("variable");
        for(j=0; j<vars.length; ++j) {
          arr.push(vars.item(j).textContent);
        }
        obj[ctx.getAttribute('name')]=arr;
    }
    session.output.write(obj);
  }
});
💻  

Hermann.

GatewayScript is a secure and performant JavaScript runtime designed with a similar look and feel to Node.js, but with support for secure modules, parallel processing and access to the native DataPower crypto and XML capabilities. It currently does not have support for zlib.

I was asked on how to "gunzip" in GatewayScript, and answered that some CommonJS module for that (there are some) needs to be found and tested. Somebody pointed to "pako", and I gave it a try:
https://www.npmjs.com/package/pako
http://nodeca.github.io/pako/

pako is under MIT license, so you need to decide whether that is acceptable for you.

"dist/pako.js" does some requires to other moduls in that archive.
So I tested with "pako.min.js" which is self-contained.

As you can see gunzip "just works" without issues (pako function name is ungzip):

💻  coproc2 gunzip.js <(echo 'ABCäöüß1💻 23' | gzip -c)  http://dp3-l3:2227
ABCäöüß1💻 23
💻  
💻  cat gunzip.js 
var pako = require('local:///pako.min.js');

session.input.readAsBuffer(function (error, buffer) {
  if (error) {
    session.output.write (error);
  } else {
    session.output.write (pako.ungzip(buffer));
  }
});
💻  

"echo" generates a new line terminated string, containing German umlauts and an emoji. That string gets piped to gzip which compresses the string, and send to console. The surrounding <(...) subshell provides that output as file to coproc2 tool, that executes gunzip.js with that compressed data on DataPower. As can be seen the original string gets returned.

Next I tried "pako.gzip()", but that did not work, the library seems to do an illegal access that GatewayScript does not tolerate:

DataPower XSLT compiler does provide dp:inflate() and dp:deflate() functions for different algorithms, including "gzip".
But a call out from GatewayScript via transform.xslt() does only help for xs:string data, a sequences of XML characters, and not arbitrary binary data.

Anyway, pako.min.js provides provides working "pako.ungzip()" for GatewayScript.
Of course thorough testing is needed if you plan to use it in prod.

Hermann.

P.S:
Exercise to the reader, install "pako.js" and its required modules on "local:" and debug why pako.gzip does illegal access.
(using pako.js allows GatewayScript to report meaningful line number and file information in the error message)

I stumbled on Wikipedia article on "self-modifying code":
https://en.wikipedia.org/wiki/Self-modifying_code

I did such things myself more than 20 years ago for performance reasons.
But I disagree with "thus simplifying maintenance" in Wikipedia article.
 

Anyway, I just tried the JavaScript sample from that Wikpedia article:

https://en.wikipedia.org/wiki/Self-modifying_code#High_level_languages

The result was compiler error "Code generation from strings disallowed"
Reason for this is same as why GatewayScript disallows "eval" command: prevent injection attacks.
See more details on GatewayScript "programs and system security" here:

https://www.ibm.com/support/knowledgecenter/SS9H2Y_7.0.0/com.ibm.dp.xb.doc/security_js.html
 

My 2nd try shows that at least function overwrite is possible, allowing for "some" runtime code modifications (eg. conditional rewrite):

💻  coproc2 self.js <('') http://dp3-l3:2227; echo
7
💻  cat self.js 
var f = function (x) {return x + 1};

// f = new Function('x', 'return x + 2');
// EvalError: Code generation from strings disallowed ...

f = function (x) {return x + 2};

session.output.write(f(5));
💻  

Hermann.

Customer task was simple, how to hex encode >1GB of binary data efficiently in GatewayScript.

GatewayScript strings are restricted by 256MB in length, and even "buffer" object is restricted by 1GB in size.

Solution was to use Buffers object and jump from Buffers to buffer to string and the way back to generate the output:
https://www.ibm.com/developerworks/community/forums/html/topic?id=0d376f87-9f30-468c-8148-6d6615905e3a#6e4168a3-6eb1-4864-9953-7054ed3e63ec

GatewayScript processing times are good,

Hermann.

Today is Pi day (3.14), and I wanted to do "something" Pi related with GatewayScript.

GatewayScript "Number" precision is that of JavaScript numbers (15 digits), because they are stored as (IEEE 754) double precision floating point numbers.

So for doing any "precision" computing with GatewayScript arbitrary precision numbers are needed.

Googling around I found "decimal.js" library with easy to use MIT license:
https://github.com/MikeMcl/decimal.js/

I gave that library a try, downloaded the .zip, and uploaded "decimal.js" to "local:" folder of DataPower.

Then I computed Pi by evaluating 1,000,000 loops of non-alternating series forumula from Wikipedia,

and did output difference to 1025 digit precision value of PI:

💻  time ( coproc2 add.js <('') http://dp3-l3:2227; echo )
"5.0000000002976264338e-7"

real    0m9.558s
user    0m0.003s
sys    0m0.016s
💻  

This is the GatewayScript script used:

💻  cat pi.js 
var Decimal = require('local:///decimal.js');

var PI = new Decimal('3.1415926535897932384626433832795028841971693993751058209749445923078164062862089986280348253421170679821480865132823066470938446095505822317253594081284811174502841027019385211055596446229489549303819644288109756659334461284756482337867831652712019091456485669234603486104543266482133936072602491412737245870066063155881748815209209628292540917153643678925903600113305305488204665213841469519415116094330572703657595919530921861173819326117931051185480744623799627495673518857527248912279381830119491298336733624406566430860213949463952247371907021798609437027705392171762931767523846748184676694051320005681271452635608277857713427577896091736371787214684409012249534301465495853710507922796892589235420199561121290219608640344181598136297747713099605187072113499999983729780499510597317328160963185950244594553469083026425223082533446850352619311881710100031378387528865875332083814206171776691473035982534904287554687311595628638823537875937519577818577805321712268066130019278766111959092164201989380952572010654858632789');

var n, pi = new Decimal(0.0), two = new Decimal(2);

for(n=0; n<1000000; ++n) {
  var n4 = new Decimal(4*n); 
  pi = pi.add(two.dividedBy(n4.plus(1).times(n4.plus(3))));
}

pi = pi.times(4);

session.output.write(PI.minus(pi));
💻  

Extended latency log says "...,AXF=5,AGS=9772,...", and there are 6 "Decimal" operations inside loop, 4 outside, resulting in 1.63μs per Decimal operation on average:

💻  bc -ql
(9772-5)/(1000000*6+4)*1000
1.62783224811183459000

Yes, slow convergence for the chosen formula (there are much quicker converging formulas).

But good to see how easy arbitrary precision math can be done in GatewayScript based on a library with acceptable license for most.

Hermann.

XInclude standards version 1.0 and 1.1
https://www.w3.org/TR/xinclude/

https://www.w3.org/TR/xinclude-11/

have not been implemented widely due to their complexity.

They are not supported by DataPower, see "Supported standards and protocols" of release notes:
https://www.ibm.com/support/knowledgecenter/SS9H2Y_7.5.0/com.ibm.dp.doc/releasenotes.html#relnotes__standards
 

In developerWorks DataPower forum posting customer asked how to deal with them.

Despite saying just "not supported", I mentioned that a service implementing XInclude could help in cases where a URL is needed that should specify a XML file -- just reference the service, and that will return the expanded XML.

So this blog posting is on stylesheet  xinclude.xsl  I have implemented to do simple XInclude processing with depth/loop protection.

Why simple? The only feature implemented is following the "href" attribute, but either that's already OK for you, or you can use xinclude.xsl as starting point and add other spec features.

Here are customer sample XML files:

💻  cat AAA.xml 
<AAAInfo xmlns="http://www.datapower.com/AAAInfo" xmlns:xi="http://www.w3.org/2001/XInclude">
    <FormatVersion>1</FormatVersion>
    <xi:include href="MasterAAA.xml"/>
</AAAInfo>
💻  
💻  cat MasterAAA.xml 
<Authenticate>
    <Username>abcd</Username>
    <Password>abcd</Password>
    <OutputCredential>guest</OutputCredential>
</Authenticate>
💻  

And here you can see that DataPower XSLT processor can process the <xi:include>:

💻  xj xinclude.xsl AAA.xml ; echo
<AAAInfo xmlns="http://www.datapower.com/AAAInfo" xmlns:xi="http://www.w3.org/2001/XInclude">
    <FormatVersion>1</FormatVersion>
    <Authenticate xmlns="">
    <Username>abcd</Username>
    <Password>abcd</Password>
    <OutputCredential>guest</OutputCredential>
</Authenticate>
</AAAInfo>
💻  

So you just create eg. a loopback XML Firewall service on DataPower, add a Fetch action for your top  XML file, and a Transform action with xinclude.xsl. That's all. Here is the stylesheet:
https://stamm-wilbrandt.de/en/blog/xinclude.xsl

💻  cat xinclude.xsl
<xsl:stylesheet version="1.0"
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
>
  <xsl:output omit-xml-declaration="yes" />
 
  <xsl:template match="*[local-name()='include' and namespace-uri()=$xinc-ns]">
    <xsl:param name="L" select="$maxL"/>
    <xsl:if test="$L &lt; 1"><xsl:message terminate="yes"/></xsl:if>
    <xsl:apply-templates select="document(@href)">
      <xsl:with-param name="L" select="$L - 1"/>
    </xsl:apply-templates>
  </xsl:template>
  
  <xsl:template match="* | comment() | processing-instruction()">
    <xsl:param name="L" select="$maxL"/>
    <xsl:if test="$L &lt; 1"><xsl:message terminate="yes"/></xsl:if>
    <xsl:copy>
      <xsl:copy-of select="@*"/>
      <xsl:apply-templates select="node()">
        <xsl:with-param name="L" select="$L"/>
      </xsl:apply-templates>
    </xsl:copy>
  </xsl:template>

  <xsl:variable name="maxL" select="5"/>

  <xsl:variable name="xinc-ns" select="$xinc/ns"/>
  <xsl:variable name="xinc">
    <ns>http://www.w3,org/1999/XML/xinclude</ns>
    <ns>http://www.w3.org/2001/XInclude</ns>
  </xsl:variable>
 
</xsl:stylesheet>
💻  

Some comments:

• the template parameter "L" is used to prevent following loops endlessly, or XIncludes that are too deep
• you may want to add a message text, the empty <xsl:message> is used to immediately terminate stylesheet execution (maximal inclusion level)
• xinc-ns variable definition is the simplest way I know of to instantiate a nodeset
• DataPower XSLT compiler does not distinct RTF (Result Tree Fragment) and XML tree, so for other XSLT processors use of exslt:node-set() may be needed
• xinc variable allows you to list all XInclude namespaces that you want to work
• comparison of namespace-uri() with $xinc-ns works nicely (comparison of string and nodeset)

​

Hermann.

Buffer, array as well as typed arrays like Uint8array all have (2³¹-1)=2,147,483,647 as maximal number of elements.

All allocations need linear runtime, because of initialization of the data requested.
GatewayScript does not provide  Buffer.allocUnsafe()  from nodejs, but even that requires linear runtime, see 
http://stackoverflow.com/questions/42261684/why-is-node-js-buffer-allocunsafe-3-orders-of-magnitude-slower-than-c-malloc

So what is the biggest size of memory you can request in GatewayScript, and what time does it take?

Because of index restriction mentioned above, Uint32array seems to be the biggest you can get.
Here you see that it takes 0.75s/2.9s to allocate 2GB/8GB of Uint8/Uint32 array (your mileage may vary depending on your DataPower model, IDG gives you 160GB memory out of 192GB, virtual appliances provide what you configured):

💻  coproc2 2d.js <('') http://dp3-l3:2227; echo
745 2886 / (42) 0
💻  
💻  cat 2d.js
var servicevars = require ('service-metadata');
var N=2000000000, t0, t1, t2, t3;
t0=servicevars.timeElapsed;
var A=new Uint8Array(N);
t1=servicevars.timeElapsed;
var B=new Uint32Array(N);
t2=servicevars.timeElapsed;
A[N-1]=42;
t3=servicevars.timeElapsed;
session.output.write ((t1-t0)+" "+(t2-t1)+" / ("+A[N-1]+") "+(t3-t2));

💻  

Hermann.