WebSphere DataPower 開発ガイド: 第2回 「処理ポリシー設計」

この連載では、WebSphere DataPowerの設計・開発を行う際に必要となる、ルール設計の考慮点や指針、開発方法のTIPS等について解説します。
第2回は「処理ポリシー設計」です。

安本 親文 Chikafumi Yasumoto, WebSphere Services, Software Development Lab, IBM

安本 親文の肖像安本 親文 (やすもと ちかふみ)
日本アイ・ビー・エム株式会社 WebSphereサービス ITスペシャリスト
入社後、WebSphere、DB2、Rationalなどのソフトウェア製品を利用して、分散系のWebアプリケーション開発・保守を担当。2007年からWebSphereサービスにて、主にWebSphere Application Serverのインフラ設計・構築プロジェクトや提案活動に従事。現在は、WebSphereサービスのConnectivityチームの一員として、WebSphere DataPower、WebSphere Enterprise Service Bus、WebSphere Cast IronなどWebSphere関連製品を担当。



2013年 5月 16日

1. 処理ルールの設計方針について

1つの処理ポリシー内には複数の処理ルールを作成することができます(第1回内容参照)。お客様要件により設計方針は変わりますが、最も一般的と思われる処理ルールの設計方針を記載します。また、処理ルール設計と同時に考慮する点についても合わせて記載します。

まず、本章で使用するアイコン(ルールおよびアクション)一覧を下記に記載します。

アイコン名称説明
マッチング・ルール各処理ルールの先頭に配置し、当該処理ルールを適用するための条件指定を行う。
On-Errorアクションこのアクション以降の処理にてエラーが発生した場合に呼び出すルールを指定する。
TransformアクションSOAP電文の編集、宛先制御、変数設定などのXSLT処理を行う。
Resultアクション各処理ルールの末尾に配置し、処理ルールの終了処理として、宛先への電文送信を行う。

1.1 要求ルールの設計方針

  • 要求ルール例
  • 要求電文に対する処理フローを作成します
    • マッチング・ルールを設定し、マッチング条件を「url=*」に設定する(全ての要求電文を本ルール内で処理する)。
    • お客様要件に合わせてアクションを配置する。このときに、コンテキスト(2章で説明)の値も合わせて設定する。
    • On-Errorアクションによる、エラーハンドリングの設定を行う。
      • ルール内に「不正な電文」が入ってきた場合と、ルール内でメッセージ処理中にエラーが発生した場合で、異なるエラー処理を行うため、On-Errorアクションを2箇所設定する。

1.2 応答ルールの設計方針

  • 応答ルール例
  • 応答電文に対する処理フローを作成します
    • マッチング・ルールを設定し、マッチング条件を「url=*」に設定する(全ての応答電文を本ルール内で処理する)。
    • お客様要件に合わせてアクションを配置する。コンテキスト(2章で説明)の値も合わせて設定する。
    • On-Errorアクションによる、エラーハンドリングの設定を行う。
      • ルール内に「不正な電文」が入ってきた場合と、ルール内でメッセージ処理中にエラーが発生した場合で、異なるエラー処理を行うため、On-Errorアクションを2箇所設定する。

1.3 エラールールの設計方針

  • 5つのエラールールを作成します
    • デフォルト・エラールール
    • 要求エラールール①
    • 要求エラールール②
    • 応答エラールール①
    • 応答エラールール②
  • 各エラールールの設計方針を以下に記載します

    i) デフォルト・エラールール(要求および応答用エラールール)
    • デフォルト・エラールール例
      • タイムアウトやバックサイドで接続に失敗した場合に使用する。
      • お客様要件に合わせてアクションを配置する。コンテキスト(2章で説明)の値も合わせて設定する。
    ii) 要求エラールール①(要求用エラールール)
    • 要求エラールール①例
      • メッセージフォーマットが不正な電文や、想定を超えるサイズの電文が要求電文として入ってきた場合に使用する。
      • お客様要件に合わせてアクションを配置する。このときに、コンテキスト(2章で説明)の値も合わせて設定する。
    iii) 要求エラールール②(要求用エラールール)
    • 要求エラールール②
      • 要求ルール内でメッセージ処理中にエラーが発生した場合に使用する。
      • お客様要件に合わせてアクションを配置する。このときに、コンテキスト(2章で説明)の値も合わせて設定する。
    iv) 応答エラールール①(応答用エラールール)
    • 応答エラールール①例
      • メッセージフォーマットが不正な電文や、想定を超えるサイズの電文が応答電文として入ってきた場合に使用する。
      • お客様要件に合わせてアクションを配置する。このときに、コンテキスト(2章で説明)の値も合わせて設定する。
    v) 応答エラールール②(応答用エラールール)
    • 応答エラールール②例
      • 応答ルール内でメッセージ処理中にエラーが発生した場合に使用する。
      • お客様要件に合わせてアクションを配置する。このときに、コンテキスト(2章で説明)の値も合わせて設定する。

1.4 その他の考慮事項

  • メッセージタイプを設定します
    • マルチプロトコルゲートウェイの[Request Type]と[Response Type]を設定する。一般的なWebサービスの要求/応答であれば、それぞれSOAPを設定する。
  • フロントサイドハンドラーを設定します
    • HTTPの要求/応答を扱う場合は、[HTTP Front Side Handler]を使用する。許可メソッドを合わせて設定する。
      • GETを許可する場合は、追加で許可メソッドに設定する必要あり。

2. コンテキストについて

処理ルールを作成する際、コンテキストを意識して使いこなすことが重要なポイントとなります。コンテキストは大きく分けて以下の2種類があります。

①処理ルールに配置する各アクションの入出力となるデータ。実際の入力電文や各アクションの出力などXMLやバイナリー形式のデータです。

②処理ルールに配置する各アクションの内部で使用される変数。トランザクション(要求・応答・エラールール)を通して維持され、コンテキスト変数と呼びます。一般的にはTransformアクションの中で当変数をセットし、後続のアクションの中で使用します。

本項では「①アクションの入出力データとして設定するコンテキスト」について説明します。なお、「②コンテキスト変数」については第3回にて説明します。

例: Transformアクションによって入力電文を変換し、その結果を出力電文として出力する場合

Transformアクションの後にResultアクションを設定します。Transformアクションの入力コンテキストにINPUTを指定し、出力コンテキストにtmp(tmpは「任意名称コンテキスト」)を指定します。Resultアクションの入力コンテキストにtmpを指定し、出力コンテキストにOUTPUTを指定します。

アクションの入出力データとして設定できるコンテキストには以下のようなものがあります。処理ルールを作成する際には、処理ルール上にアクションを並べると同時に、各アクションの入出力データ(コンテキスト)についても、あらかじめ設計しておく必要があります。

  • INPUT
    • 処理ルールが最初に受け取るメッセージが入ります。例えば、要求ルールの場合は、クライアントから送信された要求電文データが入り、応答ルールの場合には、サーバーからの応答電文データが入ります。
  • OUTPUT
    • 処理ルールが最後に出力するメッセージが入ります。通常はResultアクションの出力に設定します。
  • NULL
    • そのアクションの実行結果をデータとして保持する必要がない場合、アクションの出力に指定します。
    • そのアクションで空のデータを入力データとして利用して処理したいとき、アクションの入力に指定します。
    • 一般的にはアクションの出力に指定する方法がよく使われます。
  • PIPE
    • アクションの出力に指定すると、出力データが次のアクションの入力データになります。
    • このとき次のアクションの入力コンテキストには必ずPIPEを指定する必要があります。
    • あるアクションの出力データを、直後のアクションの入力データとしてのみ使用する場合には、パフォーマンスの観点からPIPEを使用します。処理ルール上のその他のアクションの入力データとして使用したい場合には、次の「任意名称のコンテキスト」に出力データを格納します。
  • 任意名称のコンテキスト
    • 各アクションの入力、出力のコンテキストに任意の名前を付けることができます。
    • アクションの実行結果をデータとして保持したい場合に使用します。コンテキストにデータを格納することにより、以降のアクションの入力コンテキストとして同一トランザクション中で使用することができます。
  • (auto)
    • アクションをドラッグ&ドロップして処理ルールに配置した場合、コンテキスト設定カラムに(auto)が指定され、自動的にコンテキストが設定されます。
    • この設定は初心者には便利な機能ですが、意図しないコンテキストが設定されることがあるため、基本的にはこの機能は使用せず、事前に設計したコンテキスト値を明示的に設定します。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=WebSphere
ArticleID=929301
ArticleTitle=WebSphere DataPower 開発ガイド: 第2回 「処理ポリシー設計」
publish-date=05162013