Validation

アクションの検証

アクション検証は、アクションを実行できるかどうかをチェックします。

したがって、アクション検証は個々のアクションを参照し、この特定のアクションを一連のノードインスタンスで実行できるかどうかを判断するために使用されます。

アクションの検証は、アクションが呼び出されたとき、およびアクションが実行される前に実行されます。特定のインスタンスで検証が失敗した場合、失敗したすべてのインスタンスでアクションが実行されるわけではありません。アクション検証は、アクションが実行されない可能性のあるノードインスタンスのメッセージとキーのみを返します。

例

CUSTOMER_INVOICEビジネスオブジェクトのRELEASEアクションを使用して、請求書をRELEASEDステータスに設定することができます。ただし、請求書がリリースされる前に、承認される必要があります。コンシューマーがRELEASEアクションを呼び出すと、CHECK_RELEASEアクションの検証が自動的に実行されます。RELEASEアクションが呼び出されたノードインスタンスをチェックします。APPROVEDステータスのインスタンスのみがRELEASEアクションによって処理されます。

アクション検証を明示的に呼び出す

BOPFフレームワークは、アクションがコンシューマー（レポート、UI）によって呼び出されるたびにアクション検証を自動的に呼び出すため、アクションを直接呼び出す必要があることはほとんどありません。ただし、必要に応じて、/ BOBF / IF_TRA_SERVICE_MANAGERインターフェイスはCHECK_ACTION（）メソッドを提供します。

構文：

/ BOBF / IF_TRA_SERVICE_MANAGER-> CHECK_ACTION（）

このメソッド呼び出しは、アクションを実行できるかどうかをチェックします。

一貫性の検証

整合性検証は、ノードインスタンスがビジネス要件によって課される整合性基準に関して整合性があるかどうかをチェックします。このような検証は、BOPF BOトランザクションサイクル内の事前定義されたポイントで呼び出され、BOノードが一貫した状態で永続化されることを保証します。これらのポイントは、整合性検証用に構成できます。このような各検証構成には、トランザクション中のいくつかの時点でBOPFによってチェックされるトリガー条件が含まれています。トリガー条件が満たされると、整合性検証が実行されます。それ以外の場合、一貫性のないノードインスタンスがある場合、一貫性の検証は次のいずれかの方法で動作します。

• 検証はメッセージをコンシューマーに送信します
• 検証はメッセージをコンシューマーに送信し、不整合が修正されるまでトランザクションが保存されないようにします
• 検証はメッセージをコンシューマーに送信し、整合性ステータスを変更します。

例

CUSTOMER_INVOICEビジネス・オブジェクトには、請求書の項目が一貫性のある状態にあるかどうかを確認するためのいくつかの一貫性検証が含まれている場合があります。たとえば、ある整合性検証では、各アイテムの数量と価格が維持されているかどうかがチェックされます。別の整合性検証では、購入者のアドレスが有効かどうかをチェックします。そうでない場合、整合性検証によりトランザクションが保存されないようにして、整合性のある請求書インスタンスのみを保存できるようにします。

整合性検証を明示的に呼び出す

整合性検証は、構成された要求ノードに応じて、ノードデータを変更するたびに、および整合性チェックが明示的にトリガーされたときに（たとえば、UIによって）実行されます。

整合性検証を明示的に呼び出すには、 / BOBF/IF_TRA_SERVICE_MANAGERインターフェースによって提供される対応するメソッドを使用できます。

構文：

/ BOBF / IF_TRA_SERVICE_MANAGER-> CHECK_AND_DETERMINE（）

このメソッド呼び出しは、整合性チェックを実行し、依存する決定もチェックします。

/ BOBF / IF_TRA_SERVICE_MANAGER-> CHECK_CONSISTENCY（）

このメソッドは、整合性チェックを実行します。

カスタム検証クラスの実装

検証ロジックは、検証インタフェース/ BOBF/IF_FRW_VALIDATIONを実装するABAPクラス内にカプセル化されています。

詳細：検証APIを理解する