第1章

exteNd Directorのルールについて

この章では、exteNd DirectorのRuleサブシステムの概要について紹介し、ルールベースのアプリケーションを開発する利点について説明します。この章は、次の節から構成されています。

ルールおよびRuleサブシステム

通常、exteNd Directorアプリケーションは、アプリケーションの決断を下すために論理フローの重要なポイントでルールを起動します。ルールでは、実質的にすべてのプログラミングタスクを実行できます。結果をポートレットコードで処理するか、またはルールを使用してアプリケーションのスコープ外の処理を行うことができます。

Ruleサブシステム

Ruleサブシステムでは、exteNd Directorアプリケーション用に柔軟で再使用可能な論理を作成するためのJava APIおよびツールサポートが提供されています。

ルールとは

ルールとは、値を返す「条件」と「アクション」を結合させたものです。基本的なルールの構文は、1つまたは一連の条件がtrueの場合、関連付けられた1つまたは複数のアクションが実行されるというものです。ルールの構造は、多数のプログラミング言語において標準の構成要素である「ケースステートメント」に基づいています。ユーザは、ルール論理を作成するためのユーザインタフェースが提供されているexteNd Directorの「ルールエディタ」を使用してルールを作成します。

基本的なルールの構造すべてのルールは、少なくとも1つの「Decisionノード」(ケース)から構成され、少なくとも次の2つのセクションがあります。

［時間］セクションには1つまたは複数の条件が含まれます。条件を選択し、AND演算子およびOR演算子を使用して個々の条件の結果をどのように結合するかを指定します。
［実行］セクションには、選択する1つまたは複数のアクションが含まれます。［時間］セクションがtrueに評価されると、実行されます。また、アクション内部にDecisionノードを挿入することもでき、これはネストしたルールとして評価されます。

最後の［その他の場合に実行］セクションはオプションです。ここには、いずれのDecisionノードもtrueでない場合に実行される、ルール用のデフォルトアクションを指定します。

たとえば、ケースが1つでデフォルトのセクションを持つルールの形式は次のようになります。

  When {condition group is true} 
    Do {actions}
  Otherwise Do {actions}

ルールエディタでは次のように表示されます。

wbREConditonExample

ネストした論理子ノードを親ノードに追加することによってルール内で論理をネストすることができ、標準的なケースステートメントと同じように、ブレークおよび続行ステートメントを使用して処理の流れを制御できます。

wbRECase

ルールのexteNd Director機能

次に、exteNd Director 開発環境で作成することができるルールベースのコンポーネントを示します。

機能	説明
条件とアクション	条件とアクションは、ルールエディタで設定できるプロパティが含まれる、事前に作成された再使用可能なJavaBeanです。exteNd Directorでは、汎用目的の条件とアクションのインストール済みセットが提供されています。独自のカスタムバージョンを作成することもできます。
マクロ	マクロは、再利用のために結合できる一連の条件またはアクションです。たとえば、「今日が平日で、時刻が午前9時から午後5時の間で、11月ではない場合」のような条件マクロを使用できます。
パイプライン	パイプラインは、ルールエディタで設定し、アプリケーションで実行可能な一連のルールです。パイプラインは、ユーザおよびグループ、あるいはユーザが定義する指定されたパイプラインにバインドできます。

For more information ルールエディタおよびマクロエディタの詳細については、を参照してください。

Rule API

ルールエディタでルールを定義したら、Rule APIを使用して、アプリケーションでルールにアクセスできます。APIには、ルールを起動し、セッションデータにアクセスするための「ルールマネージャ」および「コンテキスト」オブジェクトが含まれます。また、カスタム条件とアクションを定義するための実装クラスもあります。

For more information 詳細については、APIオンラインヘルプのcom.sssw.re パッケージを参照してください。

ルール使用の目的

アプリケーション開発者であれば、ルールを使用する理由は何なのか、アプリケーション内に直接論理をコーディングするだけでよいのではないかといった疑問を抱く場合があります。アプリケーションの開発および展開の観点からみて、ルールには次のような多くの利点があります。

ルールの利点	詳細
作成および使用が容易	ルールエディタでは、多数のアプリケーションニーズに対応可能な事前に作成された一連の汎用目的の条件とアクションが提供されています。マウス操作によるインタフェースを使用して、柔軟に条件とアクションを結合させ、さまざまなタイプのルールを作成できます。また、ランタイムプロパティ(ユーザIDなど)にアクセスし、ホワイトボード機能を使用してユーザ独自のセッション値を容易に保存、取得、および評価できます。 exteNd Director APIメソッドでは、ルールとアプリケーションコードの間で情報を交換することによって、容易にルールを起動したり、論理を作成したりできます。
論理のカプセル化	ルールは、アプリケーションのモジュール化という目的に役立ちます。たとえば、ビジネス論理を複数のルールに分離し、プレゼンテーションをアプリケーションコードで処理することによって、コード保守を向上させることができます。また、アプリケーションの設計によっては、このように機能を分離することによって、ビジネスアナリストなどのプログラマ以外の人でも、基本となるアプリケーションコードに影響を与えることなく論理を再設定できます。
再使用可能および拡張可能	条件とアクションを再使用して、異なる目的のために異なるルールを作成できます。または、同じアプリケーション内または異なるアプリケーション間でルール自体を再使用できます。たとえば、1つのアプリケーションに異なる複数のグループのユーザがログインする際に、プロパティが異なる同じセットのルールを使用して実行することができます。または、部分的に重複するルールを使用して、各グループに対していくつかの固有のルールを設定することもできます。条件とアクションはJavaBeansとして実装されているため、容易に拡張することができます。Ruleサブシステムでは、ユーザ独自のカスタム条件とアクションの作成を容易にする組み込み構成要素などを含む、JavaBeansの完全なサポートが提供されています。
他のexteNd Directorサブシステムと相互運用可能	ルールは、他のexteNd Directorサブシステムと容易に統合できます。たとえば、次の場合にルールを使用できます。 Content Managementサブシステムのドキュメントへのアクセスを制御するワークフローアプリケーションでルーティング論理を定義する exteNd Directorアプリケーションでユーザプロファイルを作成する

ルールベースのアプリケーションの計画

ルールは柔軟で、多数の実装オプションを備えているため、アプリケーションで使用する方法とタイミングについて注意深く計画する必要があります。最も重要な決定事項は、ビジネス論理をアプリケーションコードに直接実装するのではなく、ルール内に実装するかどうかです。

ルールを使用する場合

次の条件について考慮してください。

論理の使用条件	使用するもの
アプリケーションのさまざまなパートで共有される場合がある複数のアプリケーションで使用される可能性があるデータまたは条件が頻繁に変更されるプログラマ以外の人によって更新される可能性がある	ルール
小さなアプリケーションデータまたは条件はめったに変更されない特定のシナリオに対して切り離す必要があるプログラマによって制御される必要がある	ダイレクトJavaコード

設計ガイドライン

次に、ルールベースのアプリケーションを設計するためのガイドラインをいくつか示します。

ガイドライン	詳細
どのビジネス論理をルールにカプセル化できるか、およびアプリケーション自体で処理する必要があるものは何かを決定します。	これは要件によって異なります。一般的な原則として、ルールにカプセル化できる論理が多いほど、コードの再利用性が向上します。
各ルールの処理を定義した詳細な設計仕様を作成します。	設計仕様書には、次のことが含まれている必要があります。アクションを決定する1つの条件または複数の条件のセット(条件ノード)。たとえば、「時間」で現在のユーザが管理グループに属していることを指定し、「および」でその日が平日であることを指定します。条件がtrueまたはfalseの場合に実行される1つまたは複数のアクション。たとえば、条件ノードがtrueの場合はtrueを返し、「および」コール側にHTTP応答句を返します。「その他の場合」はfalseを返し、「および」別の応答句を返します。ルールを起動したアプリケーションがアクションの結果に応答する方法。たとえば、アクションがtrueの場合、応答を表示し、「および」ログを増やします。アクションがfalseの場合は、応答を表示して電子メールを送信します。場合によっては、このルールはまったく応答しません。

ガイドライン

詳細

どのビジネス論理をルールにカプセル化できるか、およびアプリケーション自体で処理する必要があるものは何かを決定します。

これは要件によって異なります。一般的な原則として、ルールにカプセル化できる論理が多いほど、コードの再利用性が向上します。

各ルールの処理を定義した詳細な設計仕様を作成します。

設計仕様書には、次のことが含まれている必要があります。

アクションを決定する1つの条件または複数の条件のセット(条件ノード)。たとえば、「時間」で現在のユーザが管理グループに属していることを指定し、「および」でその日が平日であることを指定します。
条件がtrueまたはfalseの場合に実行される1つまたは複数のアクション。たとえば、条件ノードがtrueの場合はtrueを返し、「および」コール側にHTTP応答句を返します。「その他の場合」はfalseを返し、「および」別の応答句を返します。
ルールを起動したアプリケーションがアクションの結果に応答する方法。たとえば、アクションがtrueの場合、応答を表示し、「および」ログを増やします。アクションがfalseの場合は、応答を表示して電子メールを送信します。場合によっては、このルールはまったく応答しません。