【Oracle】Oracle Integration Cloudで使用できるXSLT関数の調査

Oracle Integration Cloud(OIC)の統合定義は、内部的にXPath形式で値を保持しているようなので、例えばAPIのレスポンスの値をXSLT関数を使うことでちょっとした加工や変換ができるようです。
といいつつ、標準のXSLT関数はお世辞にも種類が豊富とはいえず、仮にXSLT関数が使えたとしてもあまり自由度の高い加工や変換はできませんが、どれくらいのことができるのか試してみたので、ちょっと記録として残しておきたいと思います。
※version 19.1.3.0.0 (190129.1200.23460)にて確認




OICの統合定義で旗マークからχのマークのオブジェクト「割り当て」を選んで統合定義の処理フロー上にドラッグ&ドロップで配置します。
別にこれじゃなくてもいい(ほかのフローでもXSLT関数を使える場面はある)のですが、とりあえず手軽なのでこれを使います。
20190225_blog_OIC_XSLT_Functions_IMG01.png

変数定義の画面に映るので右下の+マークをクリックして変数を追加します。
20190225_blog_OIC_XSLT_Functions_IMG02.png

変数に名前を付けて(とりあえずval1としましたが、本来はもっとわかりやすい名前のがいいですw)、値の列にある鉛筆マークをクリックします。
20190225_blog_OIC_XSLT_Functions_IMG03.png

左側から設定(or加工or変換)したい項目を選んで>ボタンを押すと右側の「式」という箇所にXPath形式の値参照が自動設定されます。
20190225_blog_OIC_XSLT_Functions_IMG04.png

要するにこれはXSLでいうところの
<xsl:variable name="val1" select="/nssrcmpr:execute/nssrcmpr:TemplateParameters/nsmpr1:message"/>
と同じであると推測できます。
つまり、select属性に記述する内容ならただのXPath指定だけではなく、XSLT関数が使えると推測できるわけです。
なお、この例では統合定義内に登場する項目をXPathで指定する形で紹介しましたが、要はxsl:variableなら何もないところからの新規変数の設定も可能です。
例えば
<xsl:variable name="val0" select="concat('this is ','test')"/>
などです。
ここで作った変数は別の場面で「$[変数名]」の形で使用できるのもxsl:variableでの変数定義であることを裏付けています。
(以下のような例)
20190225_blog_OIC_XSLT_Functions_IMG05.png
余談ですが、単純な四則演算なら別にXSLT関数ではなく下記のような記述での設定も可能です。
<xsl:variable name="val1" select="$val0 + 100"/>

まあ、というわけでXSLT関数を試してみます。
XSL Ver2.0だと関数が多くなりますが、ひとまずここのページを参照に関数を試していきます。

関数が使用できるかどうかは、この変数設定画面の右上にある「検証」のボタンを押すことで確認できます。
問題なく使用できる場合は、下記のような表示になります。
(下記はconcat関数の例)
20190225_blog_OIC_XSLT_Functions_IMG06.png

逆に使用できない関数の場合、エラーが起きて怒られます。
(下記は個人的に納得いっていないformat-number関数の例)
20190225_blog_OIC_XSLT_Functions_IMG07.png

まあ、とりあえず試してみましょう。
関数使用可否使用できない場合の
エラーメッセージ
コメント
concat 固定文字列を引数に指定する場合は
シングルクォートでもダブルクォートでもどっちでもいい
(が、どちらかで囲わないと当然怒られる)
contains ただもともとbool値を戻り値とする関数なので
OICの変数では型を自由に指定できない(「文字列」しかない)関係上
ちゃんと動作するのかはわからない。
型に深いこだわりなさそうなのでなんとなく動きそうではあるが。
format-number × javax.xml.transform.TransformerException: Could not find function: format-number 上述しているが、なぜ使えないのか納得いかない。。。
別に使えて良さそうな感じだが。
normalize-space
starts-with 使えるが、戻り値云々の懸念はcontainsと同様
string
string-length これは戻り値が数値なので、
型は違えどcontainsと同じ懸念はついてまわる
substring
substring-before
substring-after
translate
ceiling 固定で引数に文字列指定しても怒られない。
例えば「ceiling('AAA')」等。
実際動かしたときどうなるのかは知らないが…
count
floor ceilingと同様の懸念は残る
number ceilingと同様の懸念は残る
round ceilingと同様の懸念は残る
current × マッピング・コンポーネント''current''は認識されていません。 まあ、ことOICの統合定義において使う必要性が思いつかないので、
別に困りそうもないが…
戻り値がノード型という扱いづらい型だからかな?
last
local-name 多分「式の要約」はこれ使ってる(と思う)
name 使う意味が不明ではあるが一応使えるらしいw
namespace-uri
position
boolean 他と同様の型の懸念は残る
false 他と同様の型の懸念は残る
true
not
document × javax.xml.transform.TransformerException: Could not find function: document まあこれは使えなくても困らないだろうな…
element-available × マッピング・コンポーネント''element-available''は認識されていません。 同上
function-available × マッピング・コンポーネント''function-available''は認識されていません。 同上
generate-id × マッピング・コンポーネント''generate-id''は認識されていません。 同上
id × マッピング・コンポーネント''id''は認識されていません。 同上
key × (エラーメッセージとしてはなんも出てこないが
 式の要約部分に「不完全な式」とだけ表示される)
まあ、使いたいわけではないのでどうでもいいのだが
(つーか使ったことない)
system-property × マッピング・コンポーネント''system-property''は認識されていません。 別に使いたいわけではないが使えてもいい気はする
unparsed-entity-uri × javax.xml.transform.TransformerException: com.sun.org.apache.xpath.internal.functions.FuncUnparsedEntityURI only allows 1 arguments 初めて使ったが別に使いたいわけでは(ry


こうしてみると概ね使えるみたいですが、メタデータ系の取得関数とシステム回りの関数(document~以降)は使えないのが多いですね。
まあこの辺はこと「値の加工(や変換)」という観点では触れる機会の少ない関数だと思われるので、使えなくても困らないと思いますが。

文字列や数値の操作系はほぼほぼ使えますが、なぜかformat-numberが使えません。
これは別に使えてもいい気がするのですが、なんで使えないように制御してるんだかは謎ですね。。
XSLT関数として使えなくなったって話も聞かないので、謎が深まります。
バグじゃないだろうなあ~~??

この記事へのコメント