サービス・オーダー活動処理

サービス・オーダー活動でサービス・オーダー・プロセスがどのように管理されるかを理解するために、オーケストレーション活動ビジネス・オブジェクトのライフサイクルを理解することが重要です。

サービス・オーダー・オーケストレーション活動のライフサイクル

すべてのサービス・オーダー・オーケストレーション活動ビジネス・オブジェクトで、そのライフサイクルを定義する共通の親ビジネス・オブジェクトが共有されます。これは、「サービスポイント活動オーケストレーション」ビジネス・オブジェクト(D1-SPActivityOrchestration)です。次の表は、このビジネス・オブジェクトのライフサイクルの概要を示しています。


状態	摘要
保留	オーケストレーション活動の最初の状態です。入力アルゴリズムによって要求元システムに肯定応答が送信されます。活動は、モニター・プロセスを介して次の状態へ遷移します。
検証	入力アルゴリズムによって次の処理が実行されます。活動タイプの検証サービス・ポイントの検証同じサービス・ポイントの非最終の重複サービス・オーダー要求活動をチェックします。
検証エラー	「保留」状態のビジネス・オブジェクトがいずれかの検証に失敗した場合、そのビジネス・オブジェクトはこの状態になります。この状態の活動は、修正して再試行できます。
破棄済	他の状態で破棄された活動はこの状態になります。入力アルゴリズムによって次の処理が実行されます。取消活動を必要とせずに非最終の子活動を破棄できるかどうかを検証します非最終の子活動を取り消します要求元システムに失敗通知を送信します
発効日の待機中	オーケストレーション活動に将来の発効日がある場合は、発効日になるまでこの状態が維持されます。活動の発効日時に達すると(処理日時>=発効日時)、モニター・アルゴリズムによってこの活動が次の状態に遷移します。
サービス・ポイントおよび設備準備完了?	オーケストレーション活動ビジネス・オブジェクトの各タイプには、サービス・オーダー要求のタイプに適切な操作を実行する入力アルゴリズムの固有のセットがあります。これらのアルゴリズムの詳細は、「サービス・オーダー活動のアルゴリズム・タイプ」を参照してください。
活動進行中	子活動が処理されているときは、オーケストレーション活動はこの状態のままになります。モニター・アルゴリズムは、現在の活動に関連する非最終の子活動がない場合に、「サービス・ポイントおよび設備準備完了?」状態に活動を遷移します。モニター・アルゴリズムは、オーケストレーション活動のタイプの「失効日数」パラメータとオーケストレーション活動の「失効日時」に基づいて、長時間現在の状態が続いていないことを検証します終了アルゴリズムによってオーケストレーション活動の「失効日時」がリセットされるため、活動がこの状態を終了するたびに「失効日時」が更新されます。
活動エラー	1つ以上の子活動がエラー状態になると、オーケストレーション活動はこの状態になります。この状態の活動は、修正して再試行できます。
再試行	エラー状況の修正後にオーケストレーション活動が再試行されると、この状態になります。入力アルゴリズムによって次の処理が実行されます。応答を待機しているアウトバウンド通信を持つ進行中の子フィールド活動があるかどうかをチェックします。非最終の子活動を「拒否」状態に遷移します(子活動ビジネス・オブジェクトのライフサイクルで「拒否」として定義された状態。多くの場合、これは「破棄済」状態です)。
完了	すべての子活動が正常に完了すると、オーケストレーション活動はこの状態になります。入力アルゴリズムによって、要求元システムに成功通知が送信されます。

このビジネス・オブジェクトとそのライフサイクル・アルゴリズムの詳細を確認するには、ビジネス・オブジェクトとアルゴリズムのポータルを使用してください。

取消オーケストレーションおよび更新オーケストレーションのライフサイクル

「取消オーケストレーション」(D1-CancelOrchestration)および「更新オーケストレーション」(D1-UpdateOrchestration)のビジネス・オブジェクトのライフサイクルは似ていますが、次の例外があります。

「発効日の待機中」状態がありません。
「サービス・ポイントおよび設備準備完了?」状態のかわりに、「特定の活動の取消」状態または「特定の活動の更新」状態があります。これらの状態の入力アルゴリズムによって、特定の子活動の取消または更新が試行されます。
「活動進行中」状態と「活動エラー」状態のかわりに、「通信進行中」状態と「通信入力エラー」状態があります。

サービス・オーダー活動から発行されるコマンドの制限

サービス・オーダー管理は、指定した時間範囲内に実行される、サービス・オーダー活動によって開始されるスマート・メーター・コマンド活動の数を限定、つまり"制限"するように構成できます。たとえば、公益事業者が1日に数十(または数百)の支払時サービスの停止活動を開始する場合、この機能を使用すると、関連するすべてのリモート切断コマンドをその日の最初の1時間に実行するのではなく、それらのコマンドの実行を数時間に分散できます。

注意: 制限は、「未払によるサービスの停止」サービス・オーダー活動および「リモート切断」スマート・メーター・コマンド活動についてのみサポートされています。

コマンド処理の制限を構成するには、サービス・オーダー活動タイプおよび関連するスマート・メーター・コマンド活動タイプのパラメータを使用します。

サービス・オーダー活動タイプ

「未払によるサービスの停止」活動タイプの次の「業務時間」パラメータを使用して、リモート切断コマンドを実行できる営業日と業務時間を定義します。

業務時間の確認: 「作業カレンダ」、「開始時間」および「終了時間」パラメータで定義した指定業務時間中にコマンドを処理する必要があるかどうかを示します。
作業カレンダ: コマンドを処理できる作業日を決定するために使用される作業カレンダ。
開始時間: コマンドを処理できる日の開始時間。
終了時間: コマンドを処理できる日の終了時間。

詳細は、「未払によるサービスの停止」活動タイプの「業務時間」の埋込みヘルプを参照してください。

スマート・メーター・コマンド活動タイプ

「リモート切断」活動タイプの「制限パラメータ」を使用して、制限を有効にするかどうかと、有効にする場合は、各営業日中の特定の時間範囲の間に処理できるコマンドの数を定義します。次のようなパラメータがあります。

制限オプション: 制限を許可するかどうかを指定します。「許可」に設定した場合、「スケジュール」リストで1つ以上の時間範囲を定義する必要があります。
スケジュール: 1つ以上の時間範囲(「自」列と「至」列で定義)と、それぞれの間に処理できるレコードの数(「要求数」列で定義)を定義します。

バッチ処理

制限するように構成されたコマンドの処理は、「制限オプションのあるコマンド要求待機モニター」バッチ管理(D1-CRWTO)を使用して実行されます。

このバッチ管理は、発効日時の待機状態のコマンド活動をモニターし、「制限オプション」パラメータ(enableThrottle)が「Y」に設定されている場合は、コマンド活動タイプの「スケジュール」セクションで定義された現在の時間範囲に指定されているレコード数までのみ処理します。たとえば、発効日時の待機状態の「リモート切断」コマンドが50個あり、このバッチ管理(「制限オプション」が「Y」に設定されているもの)が、「要求数」が30に設定されている時間範囲の間に実行される場合、30個のコマンドのみが「接続準備完了」状態に遷移します。

このバッチ管理は、コマンド活動のタイプに基づいて必要に応じて「制限オプション」パラメータを設定して、すべてのコマンドに使用できます。このリリースでは、「リモート切断」スマート・メーター・コマンド活動でのみ制限を使用できます。

注意:

このバッチ管理は、発効日時の待機状態にモニター・プロセスが定義されていないコマンド活動ビジネス・オブジェクトでのみ使用できます。
このバッチ管理が特定の時間範囲の間に複数回実行される場合は、それぞれの実行中に、その時間範囲に指定されているレコード数まで処理されます。前述の例では、バッチ管理が同じ時間範囲の間に2回実行された場合、1回目の実行では30個のレコードが処理され、2回目の実行では残りの20個のレコードが処理されます。

詳細は、このバッチ管理の詳細摘要を参照してください。