ナビゲーションに戻る

登録したインターフェイスの利用

次の各トピックでは、登録されたインターフェイスの利用の概要および以下の作業方法について説明します。

アプリケーションで使用する必要があるインターフェイスがレジストリに登録されている場合、インターフェイスを呼び出すコンシューマ アプリケーションの PeopleCode イベントにコードを作成する必要があります。

注: 登録済みサービスのレジストリの詳細ページで、[コンシューマ コードの生成] ボタンをクリックすると、コンシューマ アプリケーションで必要な全てのコードが生成されます。このコードを切り取り、コンシューマ アプリケーションの PeopleCode イベント (SavePostChange PeopleCode など) に貼り付けます。生成されたコードがこれらの手順で設定されている条件を満たしているかどうかを確認し、必要に応じて修正します。

注: コンポーネントの単一フィールドである SavePostChange PeopleCode には、"Set"、"Add"、"Delete" などの操作サービスのコードのみを置くことができます。操作サービス呼び出しは、複数の PeopleCode イベントにわたって展開することはできません。また、FieldChange PeopleCode に操作サービス呼び出しを置くこともできません。

アプリケーションを利用すると、以下の手順でサービス インターフェイスが呼び出されます。

  1. フレームワーク クラス、サービス クラス、およびタイプ クラスをインポート、宣言、作成します。

  2. サービス マネージャの LocateService メソッドを使用してサービス実装にバインドします。

    サービス マネージャは、実装済みの適切なインターフェイス アプリケーション クラスを実行時に特定して、そのインスタンスをコンシューマ アプリケーションに返し、以下の手順で呼び出しを実行します。

    1. コンシューマ コードのインポート ステートメントで、必要な登録済みのインターフェイスを指定します。

    2. 登録済みのインターフェイスには、必要な実装済みのインターフェイス クラスに関する情報が含まれます。

    3. サービス マネージャの LocateService メソッドで、実装クラスのインスタンスを返します。

      注: LocateService メソッドには、適切なサービスにバインドするために、サービス名とサービス バージョンが必要です。

    コンシューマ コードで認識する必要があるのは、使用する登録済みのインターフェイスだけです。プロバイダ アプリケーションでは、どの実装済みクラスをコンシューマに返すかを指定します。これにより、コンシューマに影響を与えることなく、実装済みのインターフェイスをプロバイダで変更できるようになります。

  3. タイプ インターフェイスを呼び出す場合、コンシューマ アプリケーションでは、タイプ クラスを DoService 呼び出しに渡す前に、入力パラメータ内のタイプ クラスのプロパティを設定する必要があります。

    レジストリに登録されているタイプ インターフェイスでは、タイプ クラスのプロパティを記述します。コンシューマでは、コンシューマ アプリケーションからタイプ クラス プロパティに、プロパティを個別にマッピングできます。

  4. サービス実装クラスの DoService メソッドを呼び出し、サービス署名で定義したパラメータを渡します。

    サービス署名では、サービスに渡す必要がある入力または出力パラメータの数 (0 以上) を定義します。パラメータは、単純タイプ (文字列、数値、日付、ブール値など) または複合タイプにできます。パラメータのタイプは、インターフェイス レジストリのタイプとして、以下のように定義して登録されます。

    • サービスのパラメータで複合タイプが必要な場合は、コンシューマでタイプ クラスをインポートしてローカル変数として宣言し、CREATE コマンドを使用してインスタンス化する必要があります。

    • サービスのパラメータで単純タイプが必要な場合は、コンシューマで単純タイプを宣言するだけです。

  5. 例外をキャッチして管理します。

    コンシューマ コードでは、"try-catch" ブロック内の全てのサービスを呼び出す必要があります。try ステートメントと catch ステートメント間で実行される全てのコードは、保護された範囲にあるため、サービスの実行中にスローされる例外は、コンシューマ コードの catch ステートメントにコントロールをすぐに返します。これにより、コンシューマ アプリケーションで例外に応答できます。

    コンシューマ コードでは、特定の例外または baseException をキャッチできます。baseException は、登録されている全ての例外の親クラスです。

    注: サービス固有でない例外をキャッチする場合、コンシューマ コードでは常に baseException をキャッチする必要があります。

  6. サービス実行ログの関連情報を解析します。

    レジストリ フレームワークは、サービスの実行中にプロバイダによって出された全ての警告とメッセージを収集し、サービス実行ログとしてコンシューマ側に表示します。コンシューマでは、必要に応じて実行ログのクエリーを実行し、警告とメッセージに基づいてアクションを実行できます。

    各サービスには、ExecutionLog と呼ばれるプロパティがあります。このプロパティには、Log と呼ばれる LogType の配列があります。LogType には、以下の属性があります。

    • DEFAULT_TEXT

    • MESSAGE_SET_NBR

    • MESSAGE_NBR

    • MESSAGE_SEVERITY

    サービスの Log クラスには、実行ログの内容を表示するための汎用メソッド ShowLog() があります。

注: 全てのコンシューマ PeopleCode は、コンシューマ コンポーネント セッションの範囲内で実行されます。このトランザクションの範囲内では、コンポーネントの実行中に呼び出されるサービスも全て実行されます。サービスの実行中に致命的なエラーが発生した場合は、エラーが例外として明確にキャッチされない限り、コンポーネント トランザクション全体がロールバックされます。たとえば、コンシューマ アプリケーションのコンポーネントが、SavePostChange PeopleCode で呼び出されるサービスを 2 つ使用している場合、一方のサービスが正常に実行され、もう一方のサービスが致命的なエラーをスローすると、各サービスからコンポーネントにデータは保存されません。

サービス呼び出しで "Add" アクションを使用してコンシューマ アプリケーションのコンポーネントを更新する場合は、無効なデータのチェックを設定する必要はなく、Component.SavePostChange PeopleCode のサービスを呼び出すことができます。

ただし、前に選択したデータをサービスで更新する場合は、無効なデータのチェックを設定して、基になるデータがコンシューマ側のユーザー操作で変更されていないことを確認する必要があります。これを行うには、Component.PostBuild PeopleCode に Get サービスを作成し、Component.SavePostChange PeopleCode に Set サービスを作成します。

レジストリでデータの不整合が検出されると、エラーが発生します。このエラーは、baseException でキャッチできます。

複数のサービスの実装で、各サービスがコンポーネント インターフェイスの同じインスタンスを使用する場合があります。パフォーマンスを向上するには、コンポーネント インターフェイスをプールします。コンポーネント インターフェイスの範囲は、1 つのローカル PeopleCode イベントにする必要がありますが、このイベントの範囲内のコードで、同じオープン コンポーネント インターフェイスを使用して、複数の呼び出しをサービスに送信できます。

コンポーネント インターフェイスのプールは、サービス マネージャの LocateService メソッドに渡されます。リクエスト側が PeopleCode イベントで 1 つのサービスしか呼び出さない場合は、コンポーネント インターフェイスのプールとして NULL が渡されます。

アイテムまたはコレクション (行セット) で実行するためのサービスを設定できます。コンシューマ アプリケーションが行のコレクションを使用する場合は、コレクション全体をサービスに渡すようにコンシューマ アプリケーションを設定する必要があります。コレクションのサービスに渡されないアイテムは、サービスによって削除されます。コンシューマが空のコレクションを渡すと、プロバイダ実装の全てのデータ行が効果的に削除されます。

コレクション タイプ クラスのロードや操作を行う場合や、Set サービスに戻す場合は、コレクションサイズの Get サービスを使用します。

全てのサービスでは、パラメータとして単純タイプと複合タイプを使用します。単純タイプは、PeopleCode データ タイプとして使用できます。プロバイダ アプリケーションでは、アプリケーション クラスとして複合タイプを実装します。アプリケーション クラスのプロパティはページ上に直接表示できないため、Rowset.Row.Record.Field オブジェクトに基づいて、コンシューマ アプリケーションでページを作成し、タイプ クラスのプロパティを各フィールドにマッピングする必要があります。

コンシューマ コードで、ヘルパー メソッドの PopulateToRowset の呼び出しを設定し、タイプ クラスのインスタンスからコンシューマ コンポーネントのユーザー インターフェイスに全てのデータをロードします。ヘルパー メソッドの PopulateFromRowset の呼び出しを設定し、タイプ クラスのユーザー インターフェイスで使用される行セットから全ての値をロードします。

注: 一部のタイプ クラスには、ヘルパー メソッドが用意されていません。また、コンシューマ コンポーネントで動作しないヘルパー メソッドもあります。このような場合は、独自のロジックを作成して、タイプ クラス値をコンシューマのユーザー インターフェイスにバインドする必要があります。

アプリケーションの利用では、登録済みの sqlView をバインドせずに直接使用できます。登録済みの sqlView は、以下で使用します。

  • 検索ビュー

  • プロンプト

  • 関連表示