ルーティング構造

ひとつの開始プレースがあります。そこには入力トランジションがありません。プランが実行される場合、これが最初に実行されるプレースとなります。
ひとつの終了プレースがあります。そこには出力入力トランジションがありません。プランの実行が終わる際、これが最後に実行されるプレースとなります。
モデル中のすべてのプレースを通るパスがあります。
少なくとも1つの制約条件なしのパスが、すべてのプレースの外に存在しなければなりません。

モデルを実行すると、トークンが開始ノードに置かれ、終了ノードに至るまでネット上を進みます。モデルには、下記で説明する構造を含む場合があります。トークンがプレースに到達したら、そのプレースに関係付けられているタスク（Ruby や Javaスクリプト）が実行されます。そのプレースから出るトランジションは、そのプレースのタスクが完了するまでにトリガーされます。

連続ルーティング

連続ルーティングは、あるプレースからの単一出力を他のプレースの入力に指定します。これは実行の順序を表します。下記の例では、プレースAが実行されます。それが終了すると、プレースBが実行されます。プレースBが終了するとプレースCが実行されます。

条件付ルーティング

条件付ルーティングは、プレースから出る複数のトランジションがあることを示唆します。採択されるパスは、そのパスに対して定義された制約条件によって決められます。条件付ルートは、下記の例のように、ひとつのプレースからの複数プレースへの接続によって定義されます。このタイプのルーティングは、Explicit-OR（明示的OR）とも呼ばれます。

このケースでは、Aの実行後、Xの値によってトークンがBかCに遷移します。 XはAのタスクの中で処理される変数です。 Xが１と等しければ、トークンはプレースB に移ります。そうでなければ、トークンはプレースCに移動します。上記のモデルを表すもう一つの方法は、下記のように、ORトランジションノードを組み込むことです。これらはまったく同一のモデルです - ORトランジションノードの使用は任意で、視覚的完全性のために組み込まれます。

下記に示す、Implicit OR（暗示的OR）は条件付ルーティングのもう一つのタイプです。接続の上に制約条件がないことに注意してください。

Implicit OR（暗示的OR）のために、最初のORトランジション以降のすべてのプレースが実行されます。トークンがどのパスを採るかの判断は、プレースBとCのタスク処理の中で行われます。最初に完了したプレースが継続され、その他のプレースは終結されます。ここの例では、Bを通るパスが採られました。実際的な例として、あなたがトリガーイベントをある一定の時間だけ待っている場合があります。上記のモデルでは、Cにトリガーを待つタスク（たとえば、ユーザからの入力を待つダイアログボックス）を、Bにタイムアウトのタスクを含んでいるでしょう。タイムアウトBになったら、Cではもう停止せず、Bのパスに沿ってモデルが継続されます。

並行ルーティング

ペトリネットのモデルは、同時に複数のプレースにトークンを認めています。この並行ルーティングは、ネットが同時に複数のパスを認めることで導入されます。並行ルートを作るため、AND分割したトランジションノードが並行ルートを作るために使用され、終了ANDトランジションは並行パスを再結合するために使用されます。これらのトランジションノードは、必ず、開始と終了の対で使用される必要があります。下記に例を示します。

AND分割の後、トークンが各プレースに置かれます。両方のプレースの処理は同時に実施されます。

AND結合によって結合されるまでは、両パスの処理が継続します。すべての分割されたトークンが終了AND結合に到達するまでは、トークンはAND結合の後ろには進まないことに注意して下さい。

AND処理の変異にTimed-AND（時間付きAND）トランジションがあります。これは、下記のように、異なるトランジションノードを使って定義されます。このケースでは、標準のANDトランジションのように、複数のパスにトークンが置かれます。しかし、最初の分割トークンが終了Timed-AND結合トランジションに到達すると、残りの分割トークンは-それらがTimed-AND結合に到達する前に停止されます（私たちは、このルーティング構造を「デスレース」と呼んでいます）。

その後、トークンは、速やかにTimed-AND結合の後ろに渡されます。

繰り返し

繰り返しは、ある条件に適合するまで繰り返しプレース処理が実施される構造です。その例を下記に示します。

この例では、Tryプレース内の処理が実行されます。条件を満足（変数OKが真）すれば、プロセスは続けられます。そうでなければ、条件を満足するまで確認を繰り返し実行します。変数OKはTryプレース内で必ず確認される必要があり、条件付きORの制約が繰り返し終了時に判断されます。

モデルの確認

あなたのモデルに赤いノードが有る場合、それは検証されていません。検証のテストを行うには、メニューからFile、Traverse Model を選んでください。あなたのモデルが正しければ、"Petri Net is well formed"と報告するダイアログボックスが表示されるでしょう。

トリガー

トリガーは、トークンが次のトランジションやプレースに移動したことを示します。トリガーのタイプを下記に示します、注意：処理のトリガーは、プレースやトランジション内のスクリプトによって行われます。

ユーザ

ユーザトリガーはプレースの外のトランジションを開始した場合です。これは、モデルが実行された際にユーザに表示されるダイアログボックスと一緒に導入されます。Javaのタスク処理で、入力ボックス、確認ボックスや選択リストなど、さまざまのユーザダイアログが呼び出せます。これらが表示されたら、モデルはユーザがダイアログボックスに応答するまで停止します。ユーザのアクションはトリガーによって翻訳され、そして処理が再開されます。一般的に、モデルはユーザのアクションによって条件付処理をします。ユーザ開始トリガーの例については、タスクプログラミングのセクションを参照してください。

外部イベント

プレースのタスクで外部イベントを処理することができ、その際、条件付きトランジションがトランジションを定義するために定義できます。タスク処理（JavaやRubyスクリプト）で多くの関数が実行されうるため、下記を含む幅広い外部イベントが導入されるでしょう:

監視システムイベント
パフォーマンスやキャパシティの計測値
データベース問い合わせ
構成管理システムなどの、外部システム
ファイル内容、監視スクリプト結果などの、アクティブチェック

Tap In Systems監視システムのイベントと収集したパフォーマンスデータに基づくトリガーの例は、こちらを参照してください。

時間

時間トリガーはタスク処理に容易に導入できます。一般的な時間トリガーには下記があります:

次のプレースに進む前に指定された時間待つ
テストを実施し、次のプレースに進む前にその結果を待つ
" テストを実施し、結果を待って、ある回数だけ（繰り返しルーティング構造を使って）テストを繰り返す。テストの結果、あるいはそのテストが応答しなかった場合に基づいて、異なるルートが採られる

これらのシナリオのサンプルは、タスクプログラミングのセクションにあります。

階層処理

Control Plan Editor では、コントロールプランを他のコントロールプラン内での一つのプレースとして表すことができます。これは、スーパーノード（Supernode）プレースを追加することで導入します。スーパーノードを追加するとユーザにそのプレースに使用するためにコントロールプランを指定するようユーザが促されます。この階層処理により、コントロールプランを他のモデルｎ上に構築し、下記のメリットを提供します。

モデルをより小さなモジュラー形モデルに分割することで、複雑なモデルがより簡単に配備できます。
複雑さを下位モデル内に隠蔽することで、分かりやすいハイレベルのビューが作成できます。これにより、技術に弱いユーザのこのグラフィカルモデルへの理解を容易にします。
共通プロセスが再利用でき、複雑なモデルの開発を容易にします。