第8章
前章では、コンポーネントの作成に必要な、基本的なアクションを紹介しました。 本章ではより高度なアクションについて解説します。 I/O関係、制御フロー、その他さまざまなアクションがあります。
本章で解説するアクションの作成には、［アクション］以下のサブメニューとして並んでいるコマンドを使います。 サブメニューとしては、［詳細］、［データ交換］、および［繰り返し］があります。 また、アクションモデル内を右クリックし、コンテキストメニューから作成することもできます。
メニュー構成は、次のようになります。
次の表は、［詳細］に属するアクションの概要です (［データ交換］、［繰り返し］に属するアクションは、節を改めて解説します)。
注記: アクションの使用例については、第11章共通タスクへのアクションの適用を参照してください。
コンポーネントは本来、(スキーマに照らして)妥当なXMLドキュメントを受け取り、データを適切にマップ、変換して生成した、妥当なXMLドキュメントを送信するようになっています。 ただし、実際には、妥当なXMLドキュメントばかりが渡されるとは限りません。 したがってXMLドキュメントの検証手段が重要になります。
検証はスキーマに照らして行いますが、このスキーマにはネームスペースが使われていることがあります。 ただし、スキーマ、ネームスペース、およびプレフィックスは、XML変換処理においてしばしば問題になります。 ドキュメントの検証やマーシャリング、Composerのスキーマ処理機能、XMLテンプレートに関する機能、ドラッグ&ドロップ操作のマッピングなど、ごく単純なストレートスルー処理においては、ネームスペースやそのプレフィックスの管理について、通常気にする必要はありません。 ただし、ドキュメント変換においては、ネームスペースやそのプレフィックスについて特別な取り扱いが必要なこともしばしば起こります。たとえば次のような場合です。
ビジネスパートナーとやり取りするドキュメントが同ネームスペースに属しているが、そのプレフィックスが異なる場合。 相手先が作ったドキュメントを検証し、それを使う際には、自社側および相手先が使っているそれぞれのネームスペースプレフィックスを、ドキュメント内で宣言する必要があります。
XMLテンプレートがないため、ドキュメントに使われているプレフィックスからネームスペースを解決できない場合(すなわち、入力XMLテンプレートが「システム{Any}」である場合)。 マップアクションが適切に機能するためには、マップのソースおよびターゲットに使われているプレフィックスから、ネームスペースを解決できなければなりません。
さらに、ネームスペースを単に無視して処理したい場合もあるでしょう。 ComposerにはデフォルトのスキーマやXMLテンプレートが組み込まれており、それを使ってプレフィックスやネームスペースを処理できることもありますが、それ以外の方法でXMLを処理したい場合も少なくありません。
ネームスペースの適用アクションを使えば、コンポーネントのアクションモデルにおいて、XMLドキュメントに使われているネームスペースやそのプレフィックスを、必要に応じて適切に取り扱うことができます。 ドキュメント内のネームスペースやプレフィックス宣言を1箇所にまとめる、コンポーネントのXMLテンプレートで宣言されたネームスペースやプレフィックスとは異なる定義を使うようにする、あるいはネームスペースを単に無視する、といった処理が可能です。
ネームスペースの適用アクションは、(Input、Input1、Temp、Temp1、あるいはOutputなど、)どのメッセージパートに対して施すこともできます。 また、同じメッセージパートに対して、複数のネームスペースの適用アクションを用意しても構いません。アクションモデルで指定された条件に応じて、ネームスペースを切り替えながら処理することができます。 あるパートで宣言されたネームスペースは、アクションモデルの末尾に達するか、または別のネームスペースの適用アクションが実行されるまでの間有効です。 言い替えると、あるパートについて有効なのは、直近に実行されたネームスペースの適用アクションだけであるということです。
新しいコンポーネントを作成すると、XMLテンプレートでネームスペースが宣言されている出力パートについては、自動的にネームスペースの適用アクションが追加されます。 ほかのメッセージパートについても、コンポーネントの作成後に、手動でネームスペースの適用アクションを追加できます。 いずれにしても、［アクション］ダイアログを開くと、XMLテンプレートに記述のあったネームスペースやプレフィックスが最初から設定された状態になっています。 必要に応じてネームスペースやプレフィックスを追加、変更、または削除してください。
［アクション］メニューから、［新規アクション］>［詳細］>［ネームスペースの適用］の順に選択します。 次のような［ネームスペースの適用］ダイアログが開きます。
［次のネームスペースをパートに適用してください］ドロップダウンリストから、アクションの適用対象(出力パート)を選択します。 ここにはネームスペース宣言のリストを適用できるメッセージパートのみが列挙されています。
行を追加するにはプラス記号アイコン(+)をクリックします。行を削除するにはマイナス記号アイコン(-)をクリックします。 ［ネームスペース］欄にはURLを入力し、対応する［プレフィックス］も指定します。
注記: プレフィックステーブルには、［次のネームスペースをパートに適用してください］に指定したドキュメントで有効なネームスペース宣言が、すべて表示されています。 ネームスペースの適用アクションを作成しても、選択したパートに適用される宣言が、最初からすべてこのテーブルに載っているとは限りません。 初期状態では、XMLテンプレートの［ネームスペース宣言］パネルで定義された宣言が載っているだけだからです。 あるパートのXMLテンプレートが「システム{Any}」である、あるいはスキーマベースでないものである場合、このテーブルは空になっています。ただし、テンプレートの［ネームスペース宣言］パネルで追加した場合を除きます。
注記: あるメッセージパートの宣言リスト内では、プレフィックスは一意的でなければなりません。 ただしプレフィックスが違っていれば、ネームスペースのURIエントリは重複しても構いません。 逆にいうと、同じネームスペースURIに対して複数のプレフィックスを宣言してもよい、ということです。
(必要に応じて) ［XPath式でパートが使用される場合はネームスペースを無視する］チェックボックスをオンにすると、マップアクションでソースXPathから要素を検索する際、ドキュメントのXMLローカル名のみを基準とするようになります。
注記: これはあまり厳密でない方法でマップアクションを適用するしくみです。ソース仕様に記述されたプレフィックスが誤っている、あるいはプレフィックスの記述そのものがない可能性がある、という状況でもマップアクションを適用したい場合に有用です。 入力メッセージにプレフィックスが含まれているか、含まれていない場合でも、入力を他のドキュメントにマップする一連のアクションがあるか、を判断する決定アクション内に、ネームスペースの適用アクションを置くことができます。 言い替えると、コンポーネントでは、入力ドキュメントにプレフィックスが使われていない場合を考慮に入れず、プレフィックス付きのマップアクションだけを作成しておいても構わないのです。 仮に入力にプレフィックスが使われていなくても、決定アクションでそれを検出し、ネームスペースを無視する設定に切り替えるにようにすれば、マップアクションを正常に実行できることになります。
注記: この機能は、setSkipNameSpaces(true)という関数を実行した場合と同じ処理になります。setSkipNameSpaces()はどのパートにも適用できます。 この関数とネームスペースの適用アクションの両方が使われている場合、アクションモデル内で直近に実行された方が有効になります。
(必要に応じて) ［これらのネームスペースを宣言する］チェックボックスをオンにすると、ドキュメントをマップターゲットとして使う際、アクションモデルで作成される出力ドキュメントのルート要素内に、ネームスペース宣言が埋め込まれるようになります。 出力ドキュメントに対しては通常、このチェックボックスをオンにしてください。マップアクションにより出力ドキュメント内に作成されたプレフィックス付き要素から、ネームスペースを適切に解決できるようになります。
注記: ネームスペース宣言があると、出力ドキュメントを受け取った側でも適切に検証できます。 ネームスペースの適用アクションでこのチェックボックスをオンにすれば、元々ネームスペース宣言が埋め込まれているドキュメントに対し、新しい宣言を追加することもできます。
［ターゲットドキュメントのルート要素名］に、ネームスペース宣言属性を記述するルート要素名を指定します。 ターゲットメッセージパートが、スキーマを使って検証可能なXMLテンプレートをベースとしたものであれば、最初から値が入っています。 そうでない場合(たとえば「システム{Any}」の場合)は自分で入力してください。
コンポーネントでXMLドキュメントを処理する際、XMLテンプレート、ネームスペース、およびプレフィックスによって、マップアクションが想定どおりに動作したりしなかったりします。 通常は、マップアクションが正常に動作するよう、ソースXPathにおけるプレフィックスと要素名を組み合わせ、完全名として扱います。 マップアクションで参照されるメッセージパートについても同じ処理を施します。 ソース仕様とメッセージパートに対応が取れれば、データまたはコンテンツモデルが、マップアクションのターゲットにマップされます。 ここで重要なのは、マップアクションのソースをXMLメッセージパートと比較する際に、プレフィックスがネームスペースに展開されるかどうか、ということです。 ネームスペースの解決を行わない場合は、常にマップアクションが動作します。
デフォルトでは、ネームスペースの解決を行う設定になっています。 ただしこれを回避したい場合、その方法は2つあります。 ひとつはパートに対してsetSkipNameSpaces()メソッドを適用する方法です。「Input.setSkipNameSpaces(true)」という形で呼び出します。 もうひとつは、ネームスペースの適用アクションを追加し、ドキュメントがマップアクションのソースとして使われる場合には、［XPath式でパートが使用される場合はネームスペースを無視する］をオンにする、という方法です。
ネームスペースを解決する場合、マップアクションが正常に動作するためには、ほかに次の2つの条件を満たさなければなりません。 すなわち、マップアクションに使われているプレフィックスと、ドキュメント内に記述されているプレフィックスが、(1)どちらもネームスペースURIに解決可能で、(2)しかも解決されたネームスペースURIが合致する必要があるのです。 条件(1)は、条件(2)の前提です。
条件(1)を詳しくいうと、マップアクションのソースに記述された(想定)プレフィックスと、処理対象ドキュメントの要素に記述された(実)プレフィックスのどちらも、解決してネームスペースURIに展開できなければならない、ということです。 解決できない場合、マップアクションは失敗します。 さらに条件(2)として、想定プレフィックスと実プレフィックスを展開した結果が一致する必要があります。 マップアクションでは、プレフィックスを、XMLテンプレートまたはネームスペースの適用アクションで指定されたネームスペースURIに展開します。 一方、XMLドキュメントの要素のプレフィックスは、XMLドキュメントに宣言されたネームスペースURIに展開されます。この宣言は、ルート要素に、「xmlns:someprefix="someURI" 」という形の属性として記述されています。 この2つのネームスペースURIが一致しなかった場合、マップアクションは失敗します。
新しく作成したコンポーネントで、その出力メッセージがベースとするXMLテンプレートにネームスペース宣言が含まれている場合、ネームスペースの適用アクションが、自動的にアクションモデルに追加されます。 コンポーネントの実行の際、このアクションにより、適切なルート要素とそのネームスペースプレフィックス、およびルート要素のネームスペース宣言属性が、出力XMLメッセージに埋め込まれます。 このアクションは通常、アクションモデルの先頭に置きます。 さらにこのアクションにより、XMLテンプレートに宣言されていないネームスペース宣言があれば、それも出力メッセージに追加されます。 次の図は、一般的な出力メッセージにネームスペースの宣言アクションを定義する様子を示します。
このコンポーネントの出力を受け取るコンポーネントやプログラムが、同じネームスペースであっても、プレフィックスが異なるものを想定して動作することがあります。そのような場合、ネームスペースの適用アクションを使い、ネームスペースプレフィックスを書き替えて出力メッセージに埋め込むようにすれば、問題を回避できます。 ネームスペースの適用アクションを開き、［追加］ボタンを押してください。 次に、別のプレフィックスを対応付けたいネームスペースURIをコピーし、新しい行に貼り付けます。 この行に代替プレフィックスを指定してください。
注記: 注記： マップアクションのターゲットとして一時ドキュメントを使う場合も、同様にネームスペースを適用アクションを定義する必要があります。 一時ドキュメントはマップアクションのソースとしてもターゲットとしても使えるので、どちらを意図しているのか自動的には判別できません。そのため、自動的にはアクションが作成されないようになっています。
ネームスペースやプレフィックスが、あるコンポーネントのマッピングや変換処理に必要ない場合もあります。 たとえば、ドキュメントは検証済みだけれども、バックエンドデータストアに追加する前に構成を変える必要がある場合です(JDBCコンポーネント経由で関係データベースに追加、あるいはCICS/RPCコンポーネント経由でCICSトランザクションを追加、など)。 この場合、マップアクションの役割は、入力XMLメッセージを別の構造に置き換えることだけです。ドキュメント内でのみ有効なローカル名だけを参照して処理できるようにすれば、マップアクションの設計が容易になります。 ネームスペースを適用アクションで、ネームスペースを無視するよう設定します。 これを使えば、ソースXPathに使われているネームスペースプレフィックスのうち、不要のものを無視するマップアクションを作成できます。 マップアクションのソースには、
INV:INVOICEBATCH/INV:INVOICE/INV:INVOICEHEAD/INV:INVOICENO
と書く代わりに、
INVOICEBATCH/INVOICE/INVOICEHEAD/INVOICENO
と書けばよいことになり、読みやすくなります。
このアクションは、COBOL Copybookリソースを使って、ByteArrayをXMLデータに変換します。これにより、ByteArray中のCOBOLフィールドが、XML要素にマップされます。 いったん変換してしまえば、コンポーネントでは普通のXMLと同様に扱えます。
［アクション］メニューから、［新規アクション］>［詳細］>［CopybookからXMLへの変換］の順に選択します。 ダイアログボックスが表示されます。
あらかじめ定義しておいたCopybookリソースを、［Copybookリソース］プルダウンメニューから選択します(266Copybookリソースについてを参照)。
［ターゲット］グループの［パート］プルダウンメニューから、ByteArrayの変換結果を格納するXMLメッセージパートを選択します。
［適用］ボタンをクリックすると、アクションの実行結果が表示されます。アクションの作成が終わった場合は、［OK］ボタンをクリックして、アクションモデル画面に戻ります。
注記: CICS RPCに習熟していれば、このアクションの処理が、CICS RPCコンポーネントエディタの「Copybookの自動マップ」機能と同じものであることがわかるでしょう。 ただしこの機能では、マップアクションは作成されません。 変換アクションにより正常にマップするためには、Copybookの構造を正確に表現した、正しい形式のXMLドキュメントが必要です。 そのためのXMLサンプルは、CICS RPCコンポーネントやJMSコンポーネント内で容易に作成できます。 CICS RPCコンポーネントの自動マップ機能を使うだけで、XMLテンプレートを作成し、このアクションのターゲットとして使うことが可能です。 詳しくは『CICS RPC Component Editor User\qs Guide』を参照してください。
このアクションは、COBOL Copybookリソースを使って、XMLデータをByteArrayに変換します。これにより、XML要素が、ByteArray中のCOBOLフィールドにマップされます。 このByteArrayは、CICS RPCコンポーネントのECIの実行アクションで直接扱えるほか、おそらく、本文メッセージタイプがCopybook (JMSバイト)であるようなJMSの送信アクションでも扱えます。 変換後のByteArrayオブジェクトは、exportObject()という拡張ECMAScriptコンポーネントメソッドでグローバルに公開し、他のコンポーネントからも名前で参照できるようにすることが可能です。
［アクション］メニューから、［新規アクション］>［詳細］>［XMLからCopybookへの変換］の順に選択します。 ダイアログボックスが表示されます。
あらかじめ定義しておいたCopybookリソースを、［Copybookリソース］プルダウンメニューから選択します(266Copybookリソースについてを参照)。
［適用］ボタンをクリックすると、アクションの実行結果が表示されます。アクションの作成が終わった場合は、［OK］ボタンをクリックして、アクションモデル画面に戻ります。
注記: CICS RPCに習熟していれば、このアクションの処理が、CICS RPCコンポーネントエディタの「Copybookの自動マップ」機能と同じものであることがわかるでしょう。 ただしこの機能では、マップアクションは作成されません。 変換アクションにより正常にマップするためには、Copybookの構造を正確に表現した、正しい形式のXMLドキュメントが必要です。 そのためのXMLサンプルは、CICS RPCコンポーネントやJMSコンポーネント内で容易に作成できます。 CICS RPCコンポーネントの自動マップ機能を使うだけで、XMLテンプレートを作成し、このアクションのソースとして使うことが可能です。 詳しくは『CICS RPC Component Editor User\qs Guide』を参照してください。
同時コンポーネントアクションを使うと、複数のコンポーネントを同時に実行できます(それぞれ独自のスレッドで実行されます)。 XML統合アプリケーションにおいてこの機能が重要なのは、応答性に多少問題がある、旧式のシステムに問い合わせを行う必要がある場合です。 たとえば、次のとおりです。 あるサービスで、CICS RPCおよびJDBCを介して、2つのデータソースから情報を取得する必要があるとしましょう。 CICSへの問い合わせに対する応答が返ってくるまでに5秒、JDBCへの問い合わせに対しては4秒かかるとします。 この2つの問い合わせを順に行うとすれば、データが揃うまでに9秒かかってしまいます。 ただし、各バックエンドシステムに同時に問い合わせを出すことができれば、待ち時間は全体でも約5秒で済むことになります。 これは性能改善に大きな効果があります。
同時コンポーネントアクションを追加すると、アクションモデルに「Simultaneour Component」ヘッダ行が追加されます。この下に、コンポーネントや(他の)アクションをいくつでも挿入することができます。
上の図で、「Simultaneour Component」行の下には、3270コンポーネントのコール、JDBCコンポーネントのコール、および「メールの送信」アクションがあります。 2つのコンポーネントアクションは、それぞれ別のスレッドに生成(spawn)されます。 メールの送信アクションは、3270とJDBCの両方の処理が終了次第(結果が返されたか否かにかかわらず)、実行が始まります。
注記: 同時コンポーネントアクション行以下には、(マップ、決定など)どんなアクションでも置くことができます。 ただし、他のコンポーネントアクションの結果に依存したアクションを置くことはできません。あるアクションが別のアクションよりも先に終わる、という保証はないからです。
「Simultaneous Component」ブロックの外側、ブロックよりも後(下流)の位置には、ブロック内で実行されるコンポーネントの結果に依存したアクションを置いても構いません。同時コンポーネントアクションで生成されたコンポーネントがすべて終了してからでないと、次に制御が渡ることはないからです。 言い替えると、「Simultaneous Component」ブロックの次に制御が移る時点で、同期が起こることが保証されています。
［アクション］メニューから、［新規アクション］>［詳細］>［同時コンポーネント］の順に選択します。 アクションモデルに、(上図のように)「同時コンポーネント」ヘッダ行が現れます。
ヘッダ行の下に、必要な数だけアクションを追加します (ヘッダ行を右クリックしてコンテキストメニューからアクションを追加、または「Simultaneous Component」ブロック内にアクションを貼り付け)。
注記: コンポーネントアクション以外が新しいスレッドで実行されることはありません。
「同時コンポーネント」ブロックの範囲外(下流)に新しいアクションを追加するには、「同時コンポーネント」ヘッダ行のすぐ上の行を右クリックし、新規アクションを追加します。 新しいアクションが「同時コンポーネント」ブロックの下に追加されます。次の図を参照してください。
障害のスローアクションを使うと、あるアクションに障害が発生したときに、必要な情報をXMLメッセージとして書き出せます。実際にスローする前にいくつかのアクションを実行し、これが終わってからコンポーネントの実行を停止します。 障害のスローアクションは、所定の条件が満たされたときにのみ実行されます。 障害のスローアクションで作成されるメッセージパートを障害ドキュメントといいます。また、このメッセージ内のXMLには、ERRORというグローバルオブジェクトを置くことができます。 障害パートについて詳しくは、133障害メッセージパートの作成を参照してください。
障害のスローアクションを単独で使う方法。 障害条件およびそれに対応したエラーメッセージを、［障害のスローアクション］ダイアログで指定できます。 具体例については後述します。 アクションでは、障害条件を評価した結果が真になった場合、次のような処理が実行されます。
決定アクションの決定式で障害のスローアクションを使う方法。決定アクションの決定式に障害条件を指定することもできます。 この場合、決定アクションのうち条件が真になった場合のブランチ先に、「障害のスロー」文を置くことになります。 ［障害のスロー］ダイアログの［障害の条件］に条件式を追加することもできますし、これは空のままにしておき、障害ドキュメントを指定するだけにしても構いません。 決定アクションが起動され、条件がすべて真になると、上記のように障害のスローアクションが実行されます。 決定アクションまたは障害のスローアクションのいずれか一方でも、障害条件が偽であった場合は、アクションモデルに沿って、次のアクションに制御が移ります。
Try/On Faultアクション内で障害のスローアクションを使う方法。 Try/On Faultアクション(Try/On Faultアクションで後述)の実行ブランチに上記のメソッドを置けば、コンポーネントに障害が起こっても停止することなく、原因を取り除いて復旧することができます。 Try/On Faultアクションの実行ブランチ内に、上述のいずれかの方法で障害条件を記述します。あるアクションの結果を障害条件に含めたい場合は、それよりも後に置きます。 障害条件をいくつも並べ、実際に起こった障害に応じて異なる処理にブランチすることも可能です。 この動作はスイッチアクションと同様です。 ある障害のスローアクションが実際に実行され、障害がスローされると、Try/On Faultアクションの該当するOn Faultブランチに制御が移ります。 ここにはエラーを修復または対処するアクションを指定できます。
エラー条件をどこで評価すればよいかを判断し、それに応じて障害のスローアクションを使ってください。 たとえば、実行時にエラー条件が満たされたとき、コンポーネントを停止し(、これを起動したサービスに制御を戻し)たい場合は、障害のスローアクションを単独で使います。 障害のスローアクションが投げた例外はComposerのダイアログに表示され、アプリケーションサーバではコンポーネントが停止します。
一方、あるサービスが別のコンポーネントを、Try/On Faultアクション(の試行ブランチ)で呼び出しているとしましょう。 その呼び出されたコンポーネント内では、決定アクションでXMLドキュメントのデータを検査しているとします。 データが妥当であれば、コンポーネントの処理はそのまま続行します。 ただし、妥当なドキュメントでなかった場合は、障害のスローアクションが実行されます。すなわち、障害ドキュメントに情報を書き出した後、コンポーネントは停止し、サービスに制御が戻るのです。 Try/On Faultアクションは、障害がスローされたことを検出し、障害に応じたOn Faultブランチに制御を移すので、適切に対処することができます。 On Falutブランチには、障害メッセージパートに対する処理を自由に記述できます。 たとえば、ログファイルにメッセージを記録する、といった処理です。
［アクション］メニューから、［新規アクション］>［詳細］>［障害のスロー］の順に選択します。 [障害のスロー］ダイアログが表示されます。
[障害条件]フィールドにEXMAScript式を入力します。これが真になれば障害がスローされることになります。 また、［式ビルダ］ボタンをクリックして、式を作成することもできます。
エラーメッセージを_SystemFaultドキュメントに書き込みたい場合は、［{システム}{障害} のスロー］を選択します。 ［エラーメッセージ］フィールドに入力した内容は、ドキュメントの障害/障害情報/メッセージノードに書き込まれます。 他のノードに書き込みたい場合は指定してください。 ［ECMAScript 式ビルダ］ボタンをクリックして、式を作成することもできます。
別にエラーメッセージを書き込む障害ドキュメントを指定したい場合は、［定義済み障害のスロー］から選択します。メッセージパートがコンポーネントに対応付けられているドキュメントの中から選べます。
アクションモデルに新しいアクションが追加されます。 「Before Throw Actions」ブロック内に、アプリケーションの停止前に実行するべきアクションを置きます。
トランザクションアクションを使うと、アクションモデルに「トランザクションの開始(begin)」、「トランザクションの実行(commit)」、または「トランザクションのロールバック(rollback)」コマンドを置けるようになります。これにより、トランザクションを使うコンポーネント内で、トランザクションの単位を細かく制御できます。
注記: Professional Editionに入っているComposerでは、このアクションは使えません。
アクションリストにトランザクションアクションを置くと、サービスのアプリケーションメタデータに、Javaの該当する処理を呼び出すアクションが生成されます。 実際に何が起こるかの説明は、本マニュアルの範囲を超えています。 Novell exteNdアプリケーションサーバについては、『Novell exteNd Composer User\xd5 s Guide』の「Transaction Management」を参照してください (他のアプリケーションサーバを使っている場合は、該当する『exteNd User\xd5 s Guide』を参照)。
注記: トランザクションアクションを正しく使うためには、Javaのトランザクションモデルについてよく理解しておかなければなりません。 exteNd Composerで作成するサービスは、サーブレットトリガまたはEnterprise Java Bean (EJB)トリガを使って展開できます。 トランザクション管理を実装する上では、展開モードを適切に選ぶことが重要です。
トランザクションアクションを配置するアクションモデルの行を選択します。 選択した行の下に新しいアクションが挿入されます。
［アクション］メニューから、［新規アクション］>［詳細］>［トランザクション］の順に選択します。 ［トランザクション］ダイアログが表示されます。
トランザクションコマンドの種類が並んでいるので、適切なものを選びます。
注記: トランザクションモードによっては、一部のラジオボタンが選択できない状態になっている場合があります。トランザクションモードは、［ツール］メニューから［初期設定］ダイアログを開き、［デザイナ］タブで選択します。 たとえば上の図では、上3つのラジオボタンだけが選択可能で、［ロールバックのみ設定］ボタンは選択できません。 トランザクションエミュレーションモードがサーブレット管理またはBean管理の場合、このようになります。 ［ロールバックのみ設定］ボタンは、コンテナ管理のEJBを展開する場合にのみ使えます。サーブレット管理やBean管理のEJBを展開する場合は使えません。 エミュレーションモードを変える(したがって選択できるラジオボタンも変わる)には、［変更］ボタンをクリックします。
次の図は、アクションモデルペインにトランザクションアクションの組が作成されている様子を示します。
アクションモデルにトランザクションアクションを作成すれば、Composerでコンポーネントを実行し、動作を確認できます(アニメーション/デバッグセッションで、アクションリストをステップ実行しても同様です)。 「トランザクション」コマンドの使い方に問題があれば、それに応じたエラーメッセージが表示されます。 たとえば開始コマンドのあと、コミットすることなく再びbeginコマンドを実行しようとすると、入れ子になったトランザクションには対応していない旨の警告ダイアログが現れます。
Try/On Faultアクションを使うと、実行ブランチ内で障害が発生した場合に、一連のアクションが実行されるようになります。 実行ブランチ内で発生しうる障害はいくつでも定義できます。 発生を予測できる障害について、実際に発生した場合に、それを修復または報告するアクションを実行します。 たとえばXML交換アクションで、ファイルが見つからなかった場合の対処方法を記述するために使えます。
Try/On Faultアクションを追加すると、定義済みの障害パート名の数を選択するダイアログが表示されます。 これはコンポーネントの設定時に定義した障害メッセージです。 するとアクションモデルペインに、Tryアクションの開始、Executeブランチ、指定された各障害に対応するブランチ、「それ以外の障害」に対応するブランチを表す行が、それぞれ追加されます。 障害が発生しうることがわかっている一連のアクションを、実行ブランチに置きます。 エラー処理アクションは、それぞれの障害種別に対応したOn Faultブランチに置きます。 実際に障害が起こると、On Faultブランチにあるアクションが実行されることになります。
上述の例を続けると、XML I/Oアクションで障害が起こりうるとわかっている場合、このアクションを実行ブランチに置きます。 On Faultブランチには、たとえば、別の場所からファイルを読み込んでみるというXML I/Oアクションを置くことになるでしょう。 また、拡張子を変えてファイルを検索してみる、というXML I/Oアクションも考えられます。
Try/On Faultアクションを配置するアクションモデルの行を選択します。選択した行の下に新しいアクションが挿入されます。
青のプラス記号アイコン(+)を押すと、コンポーネントに関連付けられた障害パート名を追加できます。 赤のマイナス記号アイコン(-)を押すと削除できます。 また上下の矢印で、障害の順序を変更できます。
注記: 障害の種類に応じた独自の障害パートを定義するほか、［All Other Faults］ブランチには、その他の場合の復旧アクションを置きます。
アクションモデルペインに、Try/On Faultアクションのアイコンが現れます。1つの実行ブランチ、1つ以上の［On Fault］ブランチ、および1つの ［All Other Faults］ブランチも表示されます。
次の図は、各ブランチが揃ったTry/On Faultアクションがアクションモデルに表示されている様子を示します。
注記: プログラミングの方針として、必要な箇所では積極的にTry/On Faultアクションを使うようお勧めします。
注記: Professional Editionに入っているComposerでは、このアクションは使えません。 Novell exteNd Professional EditionのComposerでXForm関連の機能を使うためには、exteNd Directorが必要です。 詳しくは、Directorのマニュアルを参照してください。
XFormプロセスアクションを使うと、XFormドキュメントを指定して、出力にマップするためのさまざまな前処理を施すことができます。 このアクションを使うためには、通常、プロジェクトにあらかじめフォームリソース(リソースに関する章を参照)を作成しておくことになります。そうでない場合、XFormは、コンポーネントまたはサービスの入力メッセージパートとして使われます。 典型的には、ユーザからの要求に応じてJSPがComposerサービスを呼び出し、フォームセッションを開始します。 この場合、サービスの機能は、適切なXFormを作成、出力することです。
普通の使い方では、XFormをそのままの形でユーザ(クライアント)に示すことはありません。XFormは、そのままでは人が読んでわかりやすい表示ができず、最終的にどのように整形、表示すれば読みやすいか、ある程度の仮定を設ける必要があるからです。 同じXFormでも、たとえばデスクトップPC用と携帯端末用では、外観がまったく異なる場合もあります。 最終的にどのように表示するかの決定は実行時に行われます。たとえばXHTMLに変換するという場合、その処理はサーブレットレベルで行う必要があります。Webブラウザやクライアントデバイスには、XFormを整形、表示する機能がないからです。
一般的には次のような処理の流れになります。
その結果、Composerサービスを起動するURLにリダイレクトされます。 パラメータ(顧客の氏名など、cookieを参照して取得したもの)は、URLの末尾に付加する形でサービスに渡されます。
ビジネスロジックを追加実行するよう要求されていれば実行し、その結果を出力ドキュメント(整形済みの注文書を含む)として返します。
顧客が注文書に記入し、[送信］ボタンをクリックすると、リダイレクト処理、別のXFormセッションの開始など、必要なアクションが実行されます。
注記: ここではXFormそのものについては解説しません。 XForm技術について詳しくは、http://www.w3.org/MarkUp/Forms/を参照してください。 exteNdに組み込まれているXForm関係の機能については、exteNd Directorのマニュアルを参照してください。
XFormプロセスアクションを配置するアクションモデルの行を選択します。選択した行の下に新しいアクションが挿入されます。
［アクション］メニューから、［新規アクション］>［詳細］>［XFormプロセス］の順に選択します。ダイアログボックスが表示されます。
［ターゲット］グループで［XPath］または［式］のいずれかを選び、XFormのルートになるDOMノードを指定します (上の例では、ターゲットメッセージパートが出力、出力ドキュメントのルートノードが「<html>」という、典型的な使い方になっています)。
XSLT変換アクションは、DOMおよびXSLスタイルシートを入力とし、処理結果をコンポーネント内の別のDOMに送ります。 この処理のことをサーバサイドXSLプロセスともいいます。
XSL出力を得るためには、パラメータを3つ指定する必要があります。 ソースドキュメント式とは有効なECMAScriptの式で、評価結果がDOMまたはドキュメントハンドルの名前(Inputなど)になるものです。 XSL URL式とは、有効なECMAScriptの式で、XSLスタイルシートを指し示すものです。 このパラメータは、XSLスタイルシートを指定するXSL処理命令がDOMに記述されていれば、指定しなくても構いません。 逆にXSLスタイルシートがDOMに指定されていなければ、このパラメータを指定する必要があります。 DOMにXSLスタイルシートの処理命令が記述されていても、パラメータで指定した場合はそちらが優先します。
ターゲットドキュメント/要素式は、XSL処理結果を格納するDOMを指定します。
［アクション］メニューから、［新規アクション］>［詳細］>［XSLT変換］の順に選択します。 ［XSLプロセス］ダイアログボックスが表示されます。
整形しようとする「ソースドキュメント」の名前を入力するか、または［式ビルダ］ボタンをクリックして有効なパートを指定するECMAScriptスクリプト式を作成します。
変換に使うXSLスタイルシート名を［XSL URL式］フィールドに入力するか、［式ビルダ］ボタンをクリックし、有効なスタイルシートを指定するECMAScript式を作成します。
使用する「ターゲットパート/要素」の名前を入力するか、または［式ビルダ］ボタンをクリックしてパートを指定するECMAScriptスクリプト式を作成します。
次の図は、完成したXSLT変換アクションがアクションモデルに表示されている様子を示します。
このサブメニューには、ファイルの読み書き、WebサービスやXMLのデータ交換に関するアクションが並んでいます。
Composerリソースデータ交換アクションを使えば、XMLまたはXSLリソースをメッセージパートに読み込むことができます。
［アクション］メニューから、［新規アクション］>［データ交換］>［Composerリソース］の順に選択します。次のダイアログボックスが表示されます。
［リソース名］を指定します。リソースとして追加してあるXSLまたはXMLファイルが、このリストに列挙されています。 リソースとして追加する手順についてはを参照してください。
［ターゲット］グループで、XMLまたはXSLとして生成した結果を格納するパートを直接指定する場合は［XPath］、ECMAScript 式ビルダで指定する場合は［式］を選択します。
注記: Composerリソースアクションは、XMLまたはXSLのテキストとして生成したドキュメントを、指定されたパートに追加します。 このパートも他のパートと同じように操作できますが、 読み込み専用です。
XML以外の形式のファイルを、XPathで示される場所に読み込むアクションです。
［アクション］メニューから、［新規アクション］>［データ交換］>［URL/ファイルの読み込み］の順に選択します。次のダイアログボックスが表示されます。
［ソース］グループ内に、ファイルのURLを入力します。 これはECMAScript式なので、URL文字列は引用符で囲む必要があります。
必要に応じ、ファイルの形式に合わせて、ドロップダウンメニューから［エンコード］アルゴリズムを選択します。
注記: 上の図には一般的な設定例を示しました。 ファイルがバイナリ形式の場合は、エンコードアルゴリズムとして「バイナリからBase64」を選択するとよいでしょう。 「URL/ファイルの書き込み」アクション(後述)では、これに合わせて「デコード」アルゴリズムを選択することになります。
接続の［タイムアウト］を秒単位で指定するか、0のままにしておきます。 接続リソースでタイムアウトを指定していても、ここで指定された値が優先します。
［ターゲット］グループで［XPath］>［入力］を選び、ファイルの中身を格納するXPathターゲットを入力します。 またはラジオボタンで［式］を選択します。 必要ならば［式］アイコンをダブルクリックして式ビルダを起動します。
ファイルの内容をCDATAセクションでラップしたい場合は、［CreCDADAセクションとしてのターゲットの作成］チェックボックスをオンにします (上の例のように、バイナリファイルをBase64にエンコードする場合は必要ありません)。これにより、角括弧( < > )などの文字は、開始タグまたは終了タグの一部として解釈されることなく、XMLドキュメント内で使用できます。
DOMまたはメッセージパートを、XML以外のファイル形式で書き込むためのアクションです。
注記: このアクションには、上述のURL/ファイルの読み込みアクションとちょうど反対の機能があります。
［アクション］メニューから、［新規アクション］>［データ交換］>［URL/ファイルの書き込み］の順に選択します。次のダイアログボックスが表示されます。
ファイルの内容を示すXPathを入力します (あるいは［式］ラジオボタンを選択し、ファイルの内容がある場所を指定するECMAScript式を入力します)。
ファイル形式に合わせて［エンコード］アルゴリズムを選択します。その逆方向の処理でデコードした結果を書き込むことになります。
接続の［タイムアウト］を秒単位で指定するか、0のままにしておきます。 接続リソースでタイムアウトを指定していても、ここで指定された値が優先します。
通常Composerで作成するのは「クライアント向け」サービスですが、場合によっては、他のサービスの「クライアント」として振る舞うサービスが必要になることもあります。
WS交換アクションを使えば、WSDLリソースで指定されたコール規則に従い、コンポーネントからWebサービスを起動することができます (WSDLリソースについて詳しくは297WSDLリソースについてを参照)。 コンポーネントが他のWebサービスの「クライアント」として、リモートサービスを受ける必要がある場合に使います。
WS交換アクションを作成するためには、サービスを記述したWSDLリソースが必要であることに注意してください。
［アクション］メニューから、［新規アクション］>［データ交換］>［WS交換］の順に選択します。 ［WS交換］ダイアログボックスが表示されます。
ドロップダウンメニューを使って、［WSDLリソース］、［サービス名］(必要な場合)、［ポート］、および［操作］を選択します (各メニューの選択肢は、WSDLリソースを参照して列挙されます。 WSDLリソースについて詳しくは、を参照してください)。
Webサービスの［エンドポイント場所］(一般にサーブレットを指すURL)を、引用符で囲んで入力します (あるいは評価結果がエンドポイント場所になるECMAScript式を入力します)。
注記: このダイアログの［WSDL］タブで、値を自分で入力しなければならないのはここだけです。
起動しようとするサービスの入出力メッセージを指定します。 ［メッセージ］、［パート］、および［タイプ/要素］の各フィールドには最初から値が入っています。 ［式］に、各メッセージのソースおよびターゲットを表すECMAScript式を入力します。 この式を評価すると、通常、入力パートまたは出力パートの場所を示すXPathになります。 右側の［式ビルダ］アイコンをクリックすると[式ビルダ]ダイアログが表示され、マウス操作で簡単に式を作成できます。
(必要ならば、)［接続名］ドロップダウンメニューから、HTTP接続リソースを選択します。
注記: 通常のHTTPで接続するのであれば、ここで［<なし>］を指定しておいても構いません。 このフィールドは、HTTPSで接続する場合を想定したものです。HTTPSを使えば、HTTP接続リソースに格納されたユーザIDやパスワードなどの情報を使って、安全に接続できます。
接続の［タイムアウト］を秒単位で指定するか、0のままにしておきます。 接続リソースでタイムアウトを指定していても、ここで指定された値が優先します。
［パラメータ］および［値］フィールドには、最初から値が入っています。この値は、他のタブで指定した、操作やメッセージに関する情報から求めらたものです。 ［値］フィールドが空であれば、交換に使うSOAPアクションまたはコンテンツタイプ(MIMEタイプ)、あるいはその両方を表す文字列または式を入力します。
HTTPヘッダ情報を追加で指定したい場合は、コンボボックスの上にあるプラス記号アイコン(+)をクリックして、HTTPパラメータフィールドを追加してください。
プロジェクトの証明書リソースがプルダウンメニューに並んでいるので選択してください (証明書リソースの作成方法については証明書リソースについてを参照)。
［適用］ボタンをクリックすると、アクションの動作をリアルタイムで確認できます。［OK］ボタンをクリックするとダイアログが消えます。
XML交換アクションを使うと、外部XMLドキュメントをコンポーネントのDOMに読み込んだり、逆にコンポーネントのDOMからXMLファイルとしてデータを書き出したりすることができます。 XML交換アクションには次の4種類があります。
「GET」による交換の場合、［交換URL式］フィールドには、コンポーネントに読み込もうとするXMLドキュメントのURLを指定します。 HTTPまたはFTPによる認証接続リソースが作成済みであれば、その名前を［接続名］に指定します。 ない場合は接続情報をURLに埋め込む形で指定します。 ［応答パート］フィールドには、XMLを受け取るDOMを指定します。 該当する名前のDOMが存在しない場合、新しく作成されます。
「PUT」による交換の場合、［交換URL式］フィールドには、XMLドキュメントを書き込もうとする場所を指すURLを指定します。 HTTPまたはFTPによる認証接続リソースが作成済みであれば、その名前を［接続名］に指定します。 ない場合は接続情報をURLに埋め込む形で指定します。 ［要求パート］には、コンポーネント内のDOM名を指定します。このDOMのデータをXML形式で送信することになります。
「POST」による交換の場合、［交換URL式］フィールドには、XMLドキュメントを書き込もうとする場所を指すURLを指定します。 HTTPまたはFTPによる認証接続リソースが作成済みであれば、その名前を［接続名］に指定します。 ない場合は接続情報をURLに埋め込む形で指定します。 ［要求パート］には、コンポーネント内のDOM名を指定します。このDOMのデータをXML形式で送信することになります。
「応答のPost処理」による交換の場合は、「POST」の場合と同じパラメータに加え、 ［応答パート］に応答XMLドキュメントを受け取るDOM名を指定します。 「応答のPost処理」は「POST」と違って、発信元サーバから応答XMLオブジェクトが返されるものと想定しています。
［アクション］メニューから、［新規アクション］>［データ交換］>［XML交換］の順に選択します。 ［XML交換アクション］ダイアログが表示されます。
［交換URL式］フィールドに、XMLドキュメントを完全修飾URLで入力します。このURLには次のプロトコルを指定できます。
交換タイプによって、このURLがXML交換アクションの交換元XMLファイルを表す場合と、交換先XMLファイルを表す場合があります。 たとえば、次のとおりです。
file:///g:/xmldata/invoicebatch1.xml
ftp://accounting:password@123.456.789.987:21/invoices/inv1.xml
プラス(+)アイコンをクリックして、ヘッダパラメータを追加します。 ［パラメータ］名とこれに対応する［値］を入力します。 よく使われるHTTPヘッダパラメータとしては、「コンテンツタイプ」、「コンテンツの長さ」、および「接続の維持」などがあります。 このダイアログで、パラメータと値の組をいくつでも追加できます。
［OK］をクリックして、［HTTPヘッダパラメータ］ダイアログを閉じます。 ［XML交換］ダイアログが再び表示されます。
接続の［タイムアウト］を秒単位で指定するか、0のままにしておきます。 接続リソースでタイムアウトを指定していても、ここで指定された値が優先します。
注記: 0を指定した場合、接続できるまで無制限に待つようになります。ただしHTTP接続リソース(認証せずに接続する場合は必須ではありません)を使っている場合を除きます。 接続リソースにタイムアウト値が設定されていればそれに従います。
［要求パート］には、コンポーネント内のDOM名を指定します。このDOMのデータをXML形式で送信することになります。 ［要求パート］は、交換タイプが「PUT」、「POST」、および「応答のPost処理」のうちいずれかの場合に使います。
［応答パート］フィールドに、XMLを受け取るDOMツリー名を指定します。 ［応答パート］は、交換タイプが「GET」または「POST」の場合に使います。
必要に応じ、［ドキュメントのフィルタリング］ボタンの隣にあるチェックボックスをオンにして、ボタンが押せるようにします。 ドキュメントのフィルタリング(後述)を行う場合はこのボタンをクリックします。ダイアログボックスが表示されます。
注記: ダイアログに表示されているドキュメントは、［XML交換］ダイアログの［応答パート］で選択したものです。
このダイアログの目的は、入力XMLドキュメント中の不要なノードをはぎ取り、必要なノードだけをリアルタイムで取得することにより、性能を改善し、RAMの消費量を削減することです。
除去せずに残しておきたいノードのチェックボックスをオンにします。 オフになっているノードは、解析に先立ってはぎ取られます (詳しくはこの後の節を参照)。
［OK］をクリックします。 また、［適用］ボタンを押すと、ダイアログボックスを閉じずにXML交換アクションの結果を表示できます。 これにより、XML交換アクションを繰り返し編集しても、結果をすばやく確認できます。
［XML交換］ダイアログ(上述)の［ドキュメントのフィルタリング］ボタンを押すと、大規模なドキュメントを扱う場合に、大幅に性能を改善できるような設定が可能になります。 さらに、消費メモリを削減できるという利点もあります。
［ドキュメントのフィルタリング］ボタンを押すと、当該ドキュメントの構造がツリー表示されたダイアログが現れます。
このダイアログに表示されるドキュメントは、XML交換アクションの交換モード(「GET」か「応答のPost処理」か)、およびコンボボックスで選択したターゲットメッセージパートによって異なります (交換モードが「PUT」または「POST」の場合、出力ドキュメントしかないので、このダイアログを開くことはできません)。 このツリー表示では、ドキュメントの各要素にチェックボックスが付いています。 これがオンになっている要素は、コンポーネントでドキュメントを解析した結果得られるDOMに反映されます。 逆にオフになっている要素(およびその属性)ははぎ取られるので、解析の結果得られるDOMの容量が小さくなります。
先の図に示した例で、入力されるドキュメントのルートノードは「DoctorResp」です。その直下に「/physician」ノードおよび「/patients」ノードがあり、さらに「/patients」要素の下には「PatientData」要素があります。 同様に、「PatientData」の子ノードとして、「LastName」および「FirstName」があります。 ただし、「Physician」のチェックボックスをオフにした場合、入力されるドキュメントで次のXPathを参照しても、何もないことになります。
DoctorResp/physician/patients/PatientData/Physician
同様に、「/physician/NoOfInquiries」以下、「/Department」以下にも何もありません。対応するノードのチェックボックスがオフになっているからです。
入力ドキュメント中のノードやXPathで示される場所のうち、あるコンポーネントやサービスが必要とするのはごく一部に過ぎないことも珍しくありません。 このような場合、［ドキュメントのフィルタリング］ダイアログで不要な部分をはぎ取るよう指定すると、性能改善などの意味で大きな効果があります。 この機能をうまく使うと、最小限のメモリ消費量で、効率的にドキュメントを処理するサービスを作ることができます。
注記: (上述のダイアログを使った)フィルタリング機能の適用対象は、入力ドキュメントやサービスの種類によりません(XML交換アクションで取得したドキュメントでなくても構いません)。 この機能について詳しくはを参照してください。
このサブメニューには、処理の繰り返しを制御するアクションが集まっています。
ブレークアクションは、「要素の繰り返し」、「グループの繰り返し」、または「Repeat While」によるループの実行を中断し、ループから脱出するために使います。 ループ範囲外に脱出し、次のアクションから実行が続行されます。
たとえば、あるノードリストから特定の項目を検索する処理で、ブレークアクションが使えることがあります。 該当する項目が見つかれば繰り返しを続ける必要はなくなるので、ブレークアクションを使ってすぐにループを脱出しても構わないのです。
注記: 多くの場合、ブレークアクションは、ループ内にある決定アクションの一方のブランチに置かれることになります。 決定アクションのうち、「真」または「偽」のいずれか適切な方のブランチに置きます。
繰り返しアクションのあるコンポーネントを開きます。この中にブレークアクションを追加して、制御の流れを変えることになります。
ループ内の、ブレークアクションを置きたい位置を選択します。 一般には決定アクションの一方のブランチ内になります(以下の説明を参照)。
［アクション］メニューから、［新規アクション］>［繰り返し］>［ブレーク］の順に選択します。 ブレークアクションがアクションモデルに追加されます (設定ダイアログはありません)。次の図を参照してください。
続行アクションが「要素の繰り返し」、「グループの繰り返し」、または「条件による繰り返し」によるループ範囲内にあると、その時点で実行をやめてループの先頭に戻り、処理を続行します。 ループ内のある箇所から直接ループ先頭に戻って処理を続行するという、処理の流れの「近道」を作る働きがあります。
たとえば、リストの各項目について繰り返す処理において、ある条件を満たす項目については処理を飛ばすような場合に使います。
注記: 多くの場合、続行アクションは、ループ内にある決定アクションの一方のブランチに置かれることになります。 決定アクションのうち、「真」または「偽」のいずれか適切な方のブランチに置きます。
ループ内の、続行アクションを置きたい位置を選択します。 一般には決定アクションの一方のブランチ内になります(以下の説明を参照)。
［アクション］メニューから、［新規アクション］>［繰り返し］>［続行］の順に選択します。 続行アクションがアクションモデルに追加されます。
グループの宣言アクションを使うと、特別なリストが2つ作成されます。どちらもDOMを参照します。 このグループリストは、グループの繰り返しアクションでループを構成する「材料」になります。 リストを作成するには、グループ名とXPathを指定する必要があります。 すると次のようにしてリストが作成されます。 まずグループリストは、XPathに合致する要素を、重複を除いて列挙したリストです。 先に指定したグループ名で参照できます。 次に詳細リストは、グループリストと同様ですが、重複を除かずにすべて列挙したものです。 先に指定したグループ名に「(詳細)」というラベルを付加した名前で参照できます。
グループ化すると、入力DOMで繰り返し要素を選択し、その繰り返し要素のすべてのインスタンス(兄弟)全体で固有な値に基づき、より少数の要素を作成できます。 したがって、入力DOMに繰り返し現れる要素でも、出力DOMには1回ずつ書き込むという処理が可能になります。
［アクション］メニューから、［新規アクション］>［繰り返し］>［グループの宣言］の順に選択します。 ［グループの宣言］ダイアログが表示されます。
必要な要素をすべてグループに追加したら［OK］をクリックします。
注記: 具体例は、コンピュータ上にインストールされている、「Action Examples」というサンプルプロジェクトを参照してください。
繰り返しアクションには、アクションモデルにループ構造を作る働きがあります。 ループを使えば、一連のアクションを繰り返し実行できます。 ループには3つの種類があります。 すなわち、「要素の繰り返し」、「グループの繰り返し」、および「条件による繰り返し」です。
XMLでは、同じドキュメント内に、要素のインスタンスをいくつでも記述できるようになっています(データベースのテーブルに複数のレコードを置けるのと同様です)。 インスタンスの個数はドキュメントによって異なり、ドキュメントスキーマ(DTDやXMLスキーマ)に定義されています。 たとえば、請求書に記載する、日次の「品目」データを集めたXMLドキュメントの処理を考えてみましょう。 「品目」数は日によって異なるものとします。 実際の「品目」数がわからなければ、その個数を入力XMLドキュメントから出力XMLドキュメントに転記しようとしても、プログラムで処理することはできません。 ただし、要素の繰り返しアクションを使用すれば、この問題が解決します。
要素の繰り返しアクションでは、複数回発生する要素をマークできます。 その後、マークされた要素の各インスタンスに対して(そのようなインスタンスがなくなるまで)1つまたは複数のアクションを実行する処理ループを設定します。 先の例では、ループ内にマップアクションを1つ置いて、品目数を転記するようにします。これをすべての品目について繰り返すことになります。
要素の繰り返しアクションには、エイリアスの概念も使われています。 エイリアスには2つの役割があります。 エイリアスは、マーク付けされた繰り返し要素を表す、別名あるいは略記法であると考えるとよいでしょう。長々としたXPath式を何度も記述する必要がなくなります。 場合によっては、ドキュメント階層に応じ、繰り返し要素を何重もの入れ子にすることもあります。 マーク付けされた要素の子要素を転記するループ内にマップアクションを作成する際、このエイリアスを使えば、XPath式を長々と入力しないで済みます。 エイリアスには、ループ内のマップアクションに対する、インジケータとしての働きもあります。ループ処理を繰り返すごとに、繰り返し要素の「次の」インスタンスがエイリアスに代入されます。 エイリアスが使えなければ、ループ内のマップアクションは、ソースパートの要素の先頭インスタンスを毎回参照することになってしまいます。
注記: ［マップ］ダイアログの「繰り返し」エイリアス上にマウスカーソルを持っていくと、これで表されるXPathがツールチップとして表示されます。
要素の繰り返しアクションを使用すると、ループ内のアクションを繰り返し実行できます。 最も単純な場合、ループには、入力パートから出力パートに現在の要素インスタンスの値を転記するマップアクションが1つだけ含まれます。 また、処理ループでは、現在の値を転送するマップアクションと、転送ごとに監査ログを作成してファイルに書き込むログアクションなど、複数のアクションを定義することもできます 。
パート内の繰り返し要素を右クリックし、［アクション］メニューから、［新規アクション］>［繰り返し］>［要素の繰り返し］の順に選択します。
「マップ」など、コンポーネントに必要なアクションを追加する作業を始めます。まず、「ループアクション」を選択してください。
次の例に示すアクションモデルには、要素の繰り返しアクションが2つ、および、このコンポーネントで使う入出力XMLドキュメントが含まれています。 このモデルには「要素の繰り返し」グループが2つあります。個数が可変の「品目」を含む、よく似た構造の入力DOMを2つ扱うモデルです。 マップアクションを処理ループ内で使って、2つの入力DOMから1つの出力DOMに、「品目」を転記しています。
受信したXMLドキュメントの形式は、常にビジネスプロセスの条件を満たす形式であるとは限りません。たとえば、XMLドキュメントに異なる販売者からの請求書が含まれる場合があります。データは個々の請求書として受信されますが、B2Bトランザクションのコンテキストでは、データを要約してマネージャにサマリデータを送信すると同時に、会計支払部署に請求書データを送信しなければならないことがあります。
グループの繰り返しアクションでは、データを再作成したり、データを集約計算するためのフレームワークを確立したりすることができます。 グループ化すると、入力パートで繰り返し要素を選択し、その繰り返し要素のすべてのインスタンス(兄弟)全体で固有な値に基づき、より少数の要素を作成できます。 これにより、請求書全体(一部の請求書では販売者値が同じ)で複数の販売者要素を使用する代わりに、出力パートの固有な販売者値それぞれに対して1つの要素を使用することになります。
グループの繰り返しアクションでは、グループの宣言アクションで作成した2つのリストを使ってループ処理を行います。 ループは、グループリストまたはグループ(詳細)リストの各エントリについて、繰り返し実行されます。 先の例でグループリストを使った場合、販売者あたりに1つの要素を設定したら、処理ループにマップアクションを追加して、各販売者における請求書の数を計算できます。また、各販売者の下に個々の請求書数をリストすることもできます。 「グループの繰り返し」処理ループを「マップ」コマンドと結合させると、元のXMLドキュメントとは構造とデータが異なる新しいXMLドキュメントを作成できます。
要素の繰り返しアクションと同様、グループの繰り返しアクションでもエイリアスの概念を使います。 ［グループの繰り返し］ダイアログの［ソース］グループには、グループの宣言アクションで作成したリスト名を指定します。 このリスト名には2つの役割があります。 リスト名は、ループ内のマップアクションで使うXPathソースを表す、別名あるいは略記法であると考えるとよいでしょう。 長々としたXPath式を何度も記述する必要がありません。 グループリスト名には、マップアクションソースのDOM名の代わりとして使った場合、「繰り返し」ループ内のマップアクションに対するインジケータとしての働きもあります。ループ処理を繰り返すごとに、繰り返し要素の「次の」インスタンスがエイリアスに代入されます。 グループ名が使えなければ、ループ内のマップアクションは、ソースパートの要素の先頭インスタンスを毎回参照することになってしまいます。
グループの繰り返しアクションのターゲットエイリアスにも2つの役割があります。 このエイリアスは、ループ内のマップアクションで使うXPathターゲットを表す、別名あるいは略記法であると考えるとよいでしょう。 長々としたXPath式を何度も記述する必要がありません。 ターゲットエイリアスには、パート名の代わりとして使った場合、「繰り返し」ループ内のマップアクションに対するインジケータとしての働きもあります。ターゲットメッセージパート内に、ソースのインスタンスが作成されます。 「グループの繰り返し」ループでこのターゲットエイリアスを使わなければ、ループ内のマップアクションでソースグループリストの各インスタンスを参照しようとしても、実際にはターゲットメッセージパートに作成された最初のインスタンスを毎回参照することになってしまいます。
「グループの作成」アクションの作成には、次の3つの作業が必要です。
［アクション］メニューから、［新規アクション］>［繰り返し］>［グループの繰り返し］の順に選択します。 ［グループの繰り返し］ダイアログが表示されます。
必要に応じ、グループリストをフィルタリングするWhere句を［Where］に入力するか、［式ビルダ］ボタンを押してWhere句を作成します。
次の図は、完成したグループの繰り返しアクションが、アクションモデルに表示されている様子を示します。
Repeat Whileアクションは、所定の条件が満たされている間、一連のアクションを繰り返します。 たとえば、請求書の各「品目」データから合計金額を求めるために使えます。あらかじめ、金額を積算するための変数を作っておいてください。 Repeat Whileアクション内で、請求書を読み込み、各品目の金額を加算します。すべての品目について繰り返せば合計が求められることになります。
Repeat Whileアクションで作成されるターゲットエイリアスには、2つの役割があります。 このエイリアスは、ループ内のマップアクションで使うXPathターゲットを表す、別名あるいは略記法であると考えるとよいでしょう。 長々としたXPath式を何度も記述する必要がありません。 ターゲットエイリアスには、マップアクションのDOM名の代わりとして使った場合、「繰り返し」ループ内のマップアクションに対するインジケータとしての働きもあります。ターゲットDOM内に、ソースのインスタンスが作成されます。 「グループの繰り返し」ループでこのターゲットエイリアスを使わなければ、ループ内のマップアクションでソースの各インスタンスを参照しようとしても、実際にはターゲットDOMに作成された最初のインスタンスを毎回参照することになってしまいます。
注記: 「要素の繰り返し」や「グループの繰り返し」と違い、DOMツリーのデータをベースにしてはいないので、 これとは関係なくループを実行できます。
アクションモデルで、Repeat Whileアクションを配置する行を選択します。選択した行の下に新しいアクションが挿入されます。
［アクション］メニューから、［新規アクション］>［繰り返し］>［Repeat While］の順に選択します。［Repeat While］ダイアログボックスが表示されます。
次の図は、完成したRepeat Whileアクションが、アクションモデルに表示されている様子を示します。
Composerは通常、サービスが受け取った入力ドキュメント全体をメモリに読み込み、構文解析してDOMに変換しようとします。 メッセージパート(Input、Input1、Tempなど)はその後、自己完結したDOMとして、コンポーネントからコンポーネントに(あるいはサービスxObjectからコンポーネントに)受け渡すことになります。 多くのサービスにはこの方式が適しています。 ただし、大規模なドキュメントを日常的に扱うなど、状況によってはメモリ消費や構文解析処理の負荷が無視できないほどになることがあります。 大規模なドキュメントを小さく分割することにより、このような問題を解決できる場合があります。
「ドキュメントの分割」は、大規模なXMLドキュメントを小さく分割して処理できるよう設計された、特殊目的のアクションです。 ドキュメントの分割アクションを組み込んだ場合、入力ドキュメントは「ストリーム」として扱われます。 ストリームは所定の大きさの「チャンク」に分割され、それが順次処理されることになります。 したがってシステムRAMの消費量を大幅に削減でき、その結果、DOM処理の負荷が軽減されるため、スループットも改善できる可能性があります。
次のような場合、ドキュメントの分割アクションの導入を検討してください。
ドキュメントの分割アクションを使う上で注意しなければならない事項があります。 最も重要な要件は、当該ドキュメントが分割処理に適した性質のものであること、すなわち、「繰り返し要素」が含まれており、それを基準としてチャンクに分割できるということです。 分割位置は、区切りとするノードのタイプを表すXPath式で定義します (繰り返しのないXMLドキュメントも技術的には分割できますが、一般的な使い方ではなく、お勧めできません)。
ドキュメントを分割した各チャンクは、処理が終わればメモリから削除され、後から参照することはできなくなります。したがって、ドキュメントのある部分を処理するために、前の部分に戻って参照する(たとえば「フッタ」セクションを処理するために本文を参照する)ようなビジネスロジックを組み込むことはできない、という点を理解しておいてください。 一般に、「ドキュメントチャンク」間をまたがるような依存関係がある場合、ドキュメントの性質に合わせ、その依存関係を追跡する処理を、独自に作成する必要があります。
注記: ドキュメント全体を見通す統計処理が必要な場合、すなわち、count()、last()など、XPathの集約メソッドを使うような場合、ドキュメントの分割アクションを使ったストリームベースの処理は適切ではありません。このためにはドキュメント全体をメモリに展開しておかなければならないからです。
ドキュメントの分割アクションは、サービスのコンポーネント全体を包含する、トップレベルのサービスxObjectで使います。 さらに、サービスのアクションモデルにおいて、DOM処理アクションのうち最初に現れるものでなければなりません。 すなわち、ドキュメントの分割アクションより前に、分割対象のメッセージパート(一般には入力)を他のアクションが参照することはできないのです。
アクションモデル中、ドキュメントを参照する最初のアクションにより、ドキュメントの取り扱い方法が決まります。 これがマップなど、ドキュメントの分割以外のアクションであれば、入力ドキュメント全体がひとつのDOMとして扱われます。 逆にドキュメントの分割アクションであれば、入力ソースドキュメントは「ストリーム」として扱われます。 この場合、サービス全体にわたって、ドキュメント全体に対応する「自己完結した」DOMを使うことはできなくなります。
注記: サービスにおいて、あるドキュメントはDOMとして扱うかストリームとして扱うかのいずれか一方であり、両立はできません。 ある入力ドキュメントをストリームとして処理する場合、最後まで一貫してストリームとしてしか扱えないのです。 ただし、別のドキュメント(Temp、Outputなど)を通常どおりDOMとして扱うことは可能です。
ドキュメントの分割アクションを使うには、要素のタイプを表すXPath式を指定する形で、分割位置を設定する必要があります。 たとえば次のような、一連の請求書を表すXMLドキュメントがあるとします。
<DATA>
<PrologInfo/>
<BatchDate/>
<InvoiceBatch>
<Invoice/>
<Line Item/>
<Line Item/>
<Invoice/>
<Line Item/>
<Line Item/>
<Invoice/>
<Line Item/>
<Line Item/>
<Invoice/>
<Line Item/>
<Line Item/>
<Invoice/>
<Line Item/>
<Line Item/>
</InvoiceBatch>
<SummaryLog/>
<NumberOf<Invoices/>
</DATA>
この場合、自然な「分割位置」は次のようなXPathになるでしょう。
DATA/InvoiceBatch/Invoice
このXPathを指定してドキュメントの分割アクションを適用すると、上記のドキュメントは次のようなチャンクに分割されます。
<PrologInfo/>
<BatchDate/>
<InvoiceBatch/>
<Invoice/>
<Line Item/>
<Line Item/>
続いて、
<InvoiceBatch/>
<Invoice/>
<Line Item/>
<Line Item/>
<InvoiceBatch/>
<Invoice/>
<Line Item/>
<Line Item/>
<InvoiceBatch/>
<Invoice/>
<Line Item/>
<Line Item/>
<InvoiceBatch/>
<Invoice/>
<Line Item/>
<Line Item/>
<SummaryLog/>
<NumberOf<Invoices/>
最終的に5つのチャンクに分割されます。 最初と最後のチャンクは特別で、請求書データのほかにヘッダ/トレイラ(あるいはプロローグ/エピローグ)部分が含まれています。 ただしチャンクに分割する処理自体に特殊なものはありません。 ドキュメントは単純に、DATA/InvoiceBatch/Invoiceが現れる位置で分割されるのです。
注記: 分割されたチャンクには、そのノード以下のサブツリーもすべて含まれています。 構文解析可能な最初のノードより前にプロローグ情報がある場合、最初のチャンクには、(プロローグを含む)その位置までのドキュメント全体と、最初のノードおよびその子ノードが含まれます。 同様に、構文解析可能な最後のノードより後にエピローグ情報があれば、その部分は最後のチャンクに含まれます。
先に挙げた例で、もしも請求書が数千件含まれている場合、1件ずつの「請求書」チャンクに細かく分割するのは、適切なやり方とはいえません (コンポーネントを繰り返し呼び出す負荷が、性能に悪影響を及ぼす恐れがあります)。 効率をあげるため、もう少し大きな単位で分割した方がよいでしょう。 ドキュメントの分割アクションには、まさにそのための機能があります。 ［ドキュメントの分割］ダイアログの［分割ごとのオカレンス］フィールドに2以上の値を指定することにより、分割の単位を変更できるのです (詳しくは後述)。 たとえば数千件の請求書が含まれるドキュメントを、10件ごと、あるいは100件ごとに分割できます。 ただし、アクションモデルレベルで、チャンクに含まれる各請求書について繰り返し処理を行うのは、請求書を処理するコンポーネント側の責任になります。
先に挙げた例と同じ文書を、［分割ごとのオカレンス］として2を指定したコンポーネントの分割アクションで処理すると、次のような結果が得られます。
<PrologInfo/>
<BatchDate/>
<InvoiceBatch>
<Invoice/>
<Line Item/>
<Line Item/>
<Invoice/>
<Line Item/>
<Line Item/>
続いて、
<InvoiceBatch/>
<Invoice/>
<Line Item/>
<Line Item/>
<InvoiceBatch/>
<Invoice/>
<Line Item/>
<Line Item/>
続いて、
<InvoiceBatch/>
<Invoice/>
<Line Item/>
<Line Item/>
<SummaryLog/>
<NumberOf<Invoices/>
この場合もやはり、ヘッダ要素は最初のチャンク、フッタ要素は最後のチャンクに含まれることに注意してください。 先頭から2つのチャンクにはそれぞれ2件の請求書が入っています。 一方、最後のチャンクには1件しか含まれません。5を2で割った余りは1になるからです。 つまり最後のチャンクには、分割による「剰余」部分が入るということです。 したがってチャンクを処理するハンドラは、分割数よりノード数が少ない場合も考慮に入れて記述する必要があります。 そのためには、(［分割ごとのオカレンス］に指定した)2、10、100などといった固定の回数ではなく、チャンクに含まれる実際のノード数を数えてループ処理するようにするとよいでしょう。
たとえば次のようなECMAScript式を使えば、先の例で、あるチャンクに含まれる<Invoice>要素の数を求めることができます。
Input.XPath(\qInvoiceBatch/Invoice\q).length
ループカウンタの値がこの式で示される値になるまで繰り返せば、適切にループの処理ができることになります。
ドキュメントの分割アクションは、それ自身がループとして働きます。 実際、アクションモデルを見ると、「Split Document」行の下に、自動的に「Loop Action」ブロックが入っています。 このブロックに、コンポーネントアクションを置くことができます。チャンクの前処理や後処理、例外処理なども可能です。
ループの停止条件の判断は自動であり、カウンタ変数を宣言したり、停止条件を設定したりする必要はありません。 必要な分だけストリームを読み込んで分割するという処理が、チャンクがなくなるまで繰り返されます。
このループから脱出する、あるいはループ先頭から継続することも可能です。たとえば決定アクションで、真の場合のブランチにブレークアクションや続行アクションを置きます。 さらに高度なループ制御も可能です。Try/On Faultアクション(Try/On Faultアクションを参照)を用意しておいて、チャンクハンドラコンポーネントで障害をスローする、あるいはチャンクハンドラから返される独自の出力ドキュメントを解析して障害をスローする、といった方法があります。
ドキュメントの分割アクションは通常、チャンク処理コンポーネント(具体的にはXMLマップ、JDBCなど)を呼び出すサービスに置きます。 サービスはコンポーネントアクションを介してコンポーネントを呼び出します。 コンポーネントでは、ビジネスロジックに従い、チャンクの中身を参照して処理します。 コンポーネントから呼び出し元のサービスに出力ドキュメントを返す方法と、サービス自身が呼び出し元ならではの情報を使って出力ドキュメントを作成する方法があります。
ドキュメントの分割アクションで分割する対象は一般に、Inputメッセージパートです。 コンポーネントアクションは、チャンクハンドラコンポーネントを呼び出す際、その入力として「Input」と指定します。 このように、チャンクはそれ自身でDOM(きちんとしたドキュメント)になります。 一般的なDOM操作は何でも適用できます。 コンポーネントから別のコンポーネントに渡す、ディスクに書き込む、他のDOMに追加する、マップする、などといった操作ももちろん可能です。
サービスにドキュメントの分割アクションがある場合、入力ドキュメントウィンドウは最初、空の状態になっています (通常は入力テンプレートドキュメントがツリー表示されているはずです)。 アニメーションモードにしてこのアクションモデルをステップ実行すると、ドキュメントの分割アクションを実行した時点で、ドキュメントウィンドウに内容が表示されます。 ここには、入力テンプレートを構文解析した結果にもとづき、入力ストリームの最初の「チャンク」が表示されます。 ここでステップインし、Loop Actionブロックを実行すると、入力ウィンドウにはその時点で処理しているチャンクが表示されます。 繰り返し処理の途中でいつでも停止し、ドラッグ&ドロップ操作で、入力のデータを他のメッセージパート(一時、出力など)にマップすることができます。
ドキュメントの分割アクションが終了しても、入力ペインには最後のチャンクが表示されたままになります。 この時点で、(ドラッグ&ドロップ操作、または通常のマップアクションにより、)フッタデータを出力にマップするなどの操作が可能です。
注記: 入力テンプレートドキュメント全体が表示されることはありません。 常に一部分だけが表示されます。 ドキュメント全体を参照したい場合は、コンポーネントとは別に、該当するテンプレートを開いてください。
設計の際は、編集中のコンポーネントやサービスを保存しない限り、ドキュメントの処理モード(ストリームかDOMか)は切り替わらないことに注意してください。 アクションモデルにドキュメントの分割アクションを追加しても、保存することなくすぐにアニメーション実行すると、ストリーム処理にはならないのです。 したがって、ドキュメントの処理モード(ストリームかDOMか)が変わるような変更をアクションモデルに施した場合は、そのサービスやコンポーネントを保存するようにしてください。
もうひとつ、設計時に注意しなければならないことがあります。アクションモデルで、ドキュメントの分割アクションよりも上流の位置に入力を参照するアクションを置いた場合、アニメーション実行すると、入力全体がひとつの大きなDOMとして扱われてしまいます。デバッグ用に置いた関数アクションやログアクションも同様です。 ストリームがないので、ドキュメントの分割アクションにステップインしようとすると例外が発生します (DOMを構築するために、ストリーム全体が読み込まれてしまっています)。 先にも注意したように、ドキュメントの分割アクションより前に、当該ドキュメントを参照する他のアクションを置くことはできないのです。 このようなアクションは、アクションモデル上、必ずドキュメントの分割アクションよりも下流に置いてください。
最後に、ドキュメントの分割は大規模なドキュメントの処理用に設計されたアクションですが、設計時に使うサンプルは、必ずしも大規模なドキュメントでなくても構わないことに注意してください。 設計作業用にもメモリを使っているため、さらに大規模なドキュメントを読み込もうとすると、かなりの負荷になってしまいます。 ドキュメントの分割アクションを使ってストリーム処理する場合でも、それは変わりありません。 設計時には、できるだけ小さなサンプルドキュメント(実際に使うドキュメントを縮めたもの)を使って、正しく動作することを確認すればよいでしょう。 実ドキュメントを処理するのは、アプリケーションサーバに展開してからで構いません。
ドキュメントの分割アクションを作成し、実際に使えるようにするための手順を以下に示します。 ここでは、サンプル入力ドキュメントが既に用意されていると仮定します。実際に大規模である必要はありませんが、構造としては大規模で、分割が可能なXMLドキュメントであるとします。 また、各ドキュメントチャンクを処理するコンポーネント(チャンクハンドラ)は作成済みであり、Webサービスがこのコンポーネントを呼び出すようになっていると仮定します。
アクションモデル上の、新規アクションを追加しようとしている位置にカーソルを合わせます (該当位置の前の行を選択し、強調表示にしてください)。
注記: 先にも注意したように、ドキュメントの分割アクションを、分割対象ドキュメント(一般には入力)を参照する他のアクションよりも後(下流)に置くことはできません。 入力ドキュメントを分割して処理する場合、入力を参照するアクションは、ドキュメントの分割アクションよりも後(下流)に置く必要があります。
［アクション］メニューを使って新規アクションを作成するか、右クリックして、コンテキストメニューから［新規アクション］>［繰り返し］>［ドキュメントの分割］の順に選択します。ダイアログボックスが表示されます。
やはり［ソース］グループにあるテキストフィールドに、ドキュメント分割の区切りとなるノードを表すXPath式を入力します (右側の「X」アイコンをクリックし、式ビルダでXPathを作成しても構いません。マウス操作で作成できます)。
［分割ごとのオカレンス］に、チャンクあたりいくつ分の繰り返し要素を入れるか、正の整数で指定します。 初期状態では1になっているので、区切りとして指定されたノードが現れるたびに分割が起こります。 たとえば3つごとにチャンクにまとめるならば3、4つごとならば4と指定します。
(必要に応じて)［コメントの無視］チェックボックスをオンにすると、入力ストリームからXMLコメントが自動的にはぎ取られるようになります。 大量にコメントがある(おそらく自動生成した)文書を処理する場合に、処理性能を改善し、メモリ消費量を削減する効果があります。
(必要に応じて)［属性の無視］チェックボックスをオンにすると、入力ストリームから属性データが自動的にはぎ取られるようになります。 やはり大規模なドキュメントを処理する場合に、処理性能やメモリ消費量の面で効果があります。
ドキュメントの分割アクションのすぐ下に、自動的に「Loop Action」ブロックが生成されていることに注意してください。
Loop Actionブロックにコンポーネントアクションを追加します。これを介して、入力ドキュメントを分割したチャンクを処理するコンポーネントが呼び出すことになります(このアクションを作成し、使う方法については、コンポーネントアクション を参照)。 上の例では「Mapping」というXMLマップコンポーネントを呼び出しています。その入力として、サービスの入力が渡されます。
注記: 実行時には、サービスの入力ドキュメントを分割したものが、(この例の)入力ドキュメントに相当します。
重要： 保存しなければ、(アニメーションモードでは)ドキュメントの分割アクションが動作しません。
Copyright © 2004 Novell, Inc. All rights reserved. Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC. All rights reserved. more ...
