このセクションでは、以下について説明します。
始動時に、PeopleSoft アプリケーション・サーバーに接続するために使用するセッション・オブジェクトを作成します。アプリケーション・サーバーに接続すると、サポート・ビジネス・オブジェクトに対応するすべてのコンポーネント・インターフェースの API に、コネクターがアクセスできます。サーバーには、イベント通知のためにアダプターに組み込まれている、PeopleCode およびアプリケーション・デザイナー・オブジェクトへのアクセス機能も用意されています。
各コンポーネント・インターフェース (および、それに関連するビジネス・コンポーネント、レコード、フィールド、スクロール、および PeopleCode) には、コネクターが PeopleSoft に関する階層構造の WebSphere ビジネス・オブジェクトを処理するために必要な情報がすべて格納されています。各コンポーネント・インターフェースはビジネス・コンポーネントのデータと処理ロジックをカプセル化しているため、コネクターはこの処理ロジックを複製しません。例えば、コネクターは重複レコードの検査、編集表の検証、またはセキュリティーを明示的に処理する必要はありません。
コネクター内、または PeopleSoft アプリケーション内でのオンライン処理時にエラーが発生した場合、コネクターのアプリケーション固有のコンポーネントからコネクター・フレームワークに戻りコード FAIL が送られ、さらにそれがコネクター・フレームワークから InterChange Server Express に送られます。コネクターとアプリケーション・サーバーとの接続が失われると、コネクターのアプリケーション固有のコンポーネントにより、戻りコード APPRESPONSETIMEOUT が送られて terminate() メソッドが呼び出されます。
ビジネス・オブジェクト内のデータをコネクターが処理する方法の詳細については、コネクター用のビジネス・オブジェクトについてを参照してください。
コネクターは、アプリケーション内のデータを変更するビジネス・オブジェクト要求を受け取ると、階層ビジネス・オブジェクトを再帰的に処理します。つまり、コネクターは、ビジネス・オブジェクトに関連するコンポーネント・インターフェースのすべてのレベルのデータを処理するまで、子ビジネス・オブジェクトをそれぞれ処理します。
コネクターは、InterChange Server Express からのビジネス・オブジェクト要求を処理する場合、次の順序でセッション・オブジェクトから PeopleSoft API を呼び出します。
キー属性のアプリケーション固有情報により PeopleSoft アプリケーションが固有 ID を生成することが指定されると、コネクターは、属性の値としてストリング NEXT を指定して、ビジネス・オブジェクトをアプリケーションに送ります。PeopleSoft 用の WebSphere ビジネス・オブジェクトでの、ストリング NEXT の使用の詳細については、"属性レベルのアプリケーション固有情報"を参照してください。
ビジネス・オブジェクトのアプリケーション固有情報で setInteractiveMode を true に定義する場合、各フィールドの入力または終了で、基本となるコンポーネントの関連したビジネス・ロジックが起動され、これによりエラーが PeopleSoft PSMessage コレクション・キューにただちにパブリッシュされます。
ビジネス・オブジェクト内のデータをコネクターが処理する方法の詳細については、コネクター用のビジネス・オブジェクトについてを参照してください。コネクター固有のプロパティーの詳細については、"コネクター固有のプロパティー"を参照してください。
コネクターがビジネス・オブジェクト要求を処理する際に接続エラーが検出されると、コネクターのアプリケーション固有コンポーネントにより致命的エラーがログに記録され、戻りコード APPRESPONSETIMEOUT が送信されて、電子メール通知が起動されます。その後、コネクターは終了します。
次のセクションでは、要求動詞の処理について説明します。
InterChange Server Express が Create 動詞を使用してビジネス・オブジェクト要求を送信すると、コネクターは PeopleSoft の Create() メソッドを使用してコンポーネント・インターフェースの新しいインスタンスを作成します。トランザクションの進行で、インスタンスからすべての PeopleSoft ビジネス・ロジックが渡される場合、インスタンスはアプリケーションに保管されます。アプリケーションに作成されるオブジェクトに、すべての子ビジネス・オブジェクトなどの、ビジネス・オブジェクトに格納されるすべての値が格納されます。
作成操作の処理の詳細については、"作成操作"を参照してください。
InterChange Server Express が Retrieve 動詞を使用してビジネス・オブジェクト要求を送信すると、コネクターは PeopleSoft の Get() メソッドを使用して対応するコンポーネント・インターフェースの固有のインスタンスが存在することを確認します。この Get() メソッドによりコンポーネント・インターフェースがインスタンス化され、コネクターがその値をビジネス・オブジェクトにロードできるようになります。コネクターが InterChange Server Express に戻すビジネス・オブジェクトは、コンポーネント・インターフェースのインスタンスと正確に一致します。
つまり、InterChange Server Express に戻されるビジネス・オブジェクトの各単純属性の値は、コンポーネント・インターフェースの対応するプロパティー・フィールドの値と一致します。また、戻されたビジネス・オブジェクトが階層構造の場合、各配列内の個々のビジネス・オブジェクト数は、その配列に関するコンポーネント・インターフェース内のレベルまたはコレクションの数に一致します。
検索操作の処理の詳細については、"検索操作"を参照してください。
InterChange Server Express が Update 動詞を使用してビジネス・オブジェクト要求を送信すると、コネクターはコンポーネント・インターフェースの既存のインスタンスを変更します。トランザクションの進行で、インスタンスからすべての PeopleSoft ビジネス・ロジックが渡される場合、インスタンスはアプリケーションに保管されます。
アプリケーションで更新されるオブジェクトは、要求ビジネス・オブジェクトと正確に一致します。コネクターによりすべての単純なプロパティー・フィールドが更新されます。ただし、要求ビジネス・オブジェクト内の対応する属性に値 CxIgnore がある場合は除きます。要求ビジネス・オブジェクト内に格納されているすべての子ビジネス・オブジェクトを挿入します。コネクターは、その KeepRelationship アプリケーション固有情報パラメーターの値に基づいて、要求ビジネス・オブジェクトに存在しない子ビジネス・オブジェクトを削除または保持します。
更新操作の処理の詳細については、"更新操作"を参照してください。
PeopleSoft がトランザクションの削除をサポートしないため、コネクターもサポートしません。論理削除の処理の標準の振る舞いは、Update 動詞を使用してビジネス・オブジェクトの EffectiveStatus 属性の状況を「I」(非アクティブ) に変更することです。
ただし、コネクターがオブジェクト全体の削除をサポートするようにするには、次を実行します。
InterChange Server Express が Exists 動詞を使用して階層ビジネス・オブジェクト要求を送信すると、コネクターはコンポーネント・インターフェースのインスタンスを検査します。コネクターのアプリケーション固有コンポーネントから、アプリケーションにインスタンスが存在する場合は SUCCEED が戻され、オブジェクトが存在しない場合は FAIL が戻されます。
イベント通知には、次の 3 つの主要なプロセスが関係します。
イベントをコネクターのイベント表にパブリッシュするために、PeopleSoft アプリケーションはアダプターに組み込まれている PeopleCode オブジェクトおよびアプリケーション・デザイナー・オブジェクトを使用します。これらのオブジェクトの詳細については、"イベント処理コンポーネント"を参照してください。
イベントのパブリッシュ・プロセスでは、cw_publish_events() 関数を使用し ます。この関数は FUNCLIB_CW レコードの FieldFormula イベントに格納されています。この関数は、イベントに関係するコンポーネントの SavePostChg() PeopleCode で宣言し、呼び出す必要があります。
詳細については、"cw_publish_events() 関数"を参照してください。
コネクターは、構成可能で定期的な間隔でイベント表をポーリングします。イベントの検索は、最初は状況により、次にコネクター・プロパティー ConnectorID の値により行います。この値が null またはブランクの場合、プロパティーは検索に使用されません。コネクターがイベントを処理すると、状況をただちに INPROGRESS (値 3) に更新します。コネクターの初期設定時は、保留中の INRPOGRESS イベントは READYFORPOLL (値 0) にリセットされます。
コネクターは CW_EVENT_CI コンポーネント・インターフェースの Find() メソッドを使用してイベント表をポーリングします。このメソッドは、状況が READYFORPOLL であるイベントのコレクションを戻します。コネクターはコレクションをループ処理して、CW_EVENT_TBL にリストされているすべてのビジネス・オブジェクトの名前を取得します。
コネクターは API を使用してプロパティー値を設定および取得して、コレクションで戻された各イベントのイベント情報を収集します。また、サブスクライブされるビジネス・オブジェクトを検査して判別します。使用する InterChange Server Express に固有のサブスクリプション情報については、ブローカーのインプリメンテーション・ガイドを参照してください。
詳細については、"イベントおよびアーカイブ表"を参照してください。
CW_EVENT_CI コンポーネント・インターフェースがインスタンス化される間に、コネクターは処理する各イベントに関してユーザー定義のメソッド cw_archive_events() を呼び出します。PeopleCode 形式のこのメソッドにより、アーカイブ・フラグが Y に設定されます。このフラグが設定されると、ユーザーが Save() メソッドを呼び出す際に、SavePostChg() PeopleCode によりイベントがアーカイブされます。アーカイブ表にイベントが処理された日付と時刻も記録されます。
アーカイブ表は、イベント・ヒストリーの照会またはイベント処理の問題のトラブルシューティングに使用することができます。例えば、アンサブスクライブされるイベントはすべて、unsubscribed の状況になっています。
イベントの処理に関連した潜在的な障害ポイントが存在するため、イベント管理プロセスでは、イベントがアーカイブ表に挿入されるまで、イベント表からイベントを削除しません。
図 2 に、イベント通知プロセス・フローを示します。統合ブローカーは InterChange Server Express です。
次に、図 2 に示すステップを説明します。
詳細については、"cw_publish_events() 関数"を参照してください。
データがサブスクライブされない場合、コネクターはイベント・レコードを CW_EVENT_TBL から CW_ARCHIVE_TBL に移動し、状況を unsubscribed にします。