ペイロードの解析: ペイロードを外部システムから受信するとき
ペイロードの作成: ペイロードを外部システムに送信する前
OTD の単一のインスタンスは、同じコラボレーション内で同時に両方の目的に使用するようになっていません。この制限を強制するには、アダプタの「一般設定」パラメータの下に「解析または作成モード」と呼ばれる設定があります。この設定で「解析」または「作成」のいずれかを選択できます。
get() および put() メソッドは、この OTD の機能の中核です。いずれかのメソッドを呼び出すと、取得または追加するレコードは、固定長または区切りなど、アダプタの設定で指定されたタイプであると見なされます。
get() メソッドは例外をスローできますが、この動作は、通常、重大な失敗がある場合のみ起こります。ペイロードデータ (またはストリーミングしている場合はストリーム) が設定される前に get() を呼び出そうとすることは、こうした失敗の一例です。get() 呼び出しからの戻り値を確認するようにコラボレーションをコーディングすることをお勧めします。戻り値 true は取得処理が成功したことを意味し、false は失敗を意味します。
アダプタは、モード設定に従って、適切な呼び出しが行われているかどうかを確認します。たとえば、解析モード環境で put() を呼び出すと、アダプタは、原因を説明する該当エラーメッセージを添えて、例外をスローします。作成モードで get() を呼び出してもエラーになります。
アダプタがこうした制限を必要とするのは、次の理由からです。
インバウンドペイロードを処理している場合は、ペイロードからレコードを抽出 (解析) するために get() を呼び出します。この状況では、put() を呼び出すことはほとんど意味はありません。この時点で呼び出すと、ペイロードからレコードを抽出しようとしているのに、ペイロードは変更されます。put() を呼び出すとペイロードは上書きされ、取得しようとしてるデータは破壊されます。
反対に、put() を呼び出すことでペイロードを作成している場合、この時点でデータを抽出、つまり解析する必要はありません。したがって、get() を呼び出すことはできません。
このため、OTD は、特定のコラボレーションの転送元側または転送先側に必要に応じて配置し、OTD をペイロードの解析または作成に使用します。しかし、同時に解析と作成を行うことはできません。OTD をコラボレーションに実装するには、コラボレーションルールエディタを使用します。
ペイロードデータを外部システムに送信する場合は、そのシステムとインタフェースをとっているコラボレーションのアウトバウンド側に OTD を配置できます。連続して put() を呼び出すと、アダプタ設定で定義した形式でペイロードデータが構築されます。
すべてのレコードがペイロードに追加されたら、コラボレーションのアウトバウンドの転送先を表すノード (複数可) にペイロードをドラッグ&ドロップできます。また、ペイロードの転送先として出力ストリームを設定できます (ペイロードのストリーミングの詳細は、表 1–3 を参照)。
データペイロードを構築するときは、送信するデータのタイプと形式を考慮します。アダプタでは、次の形式を使用できます。
単一レコード: このタイプのペイロードは、送信する単一レコードを表します。put() を連続して呼び出すごとに、ペイロードは出力中のデータのサイズ単位で大きくなります。ペイロードは、隣接する 1 つのバイトストリームです。
固定サイズレコード: このタイプのペイロードは、レコードで構成されており、各レコードのサイズはまったく同じです。指定されたサイズではないレコードを put() しようとすると、例外がスローされます。
区切りレコード: このタイプのペイロードは、末尾に区切り文字を持つレコードで構成されます。各レコードのサイズは異なってもかまいません。このデータタイプが put() に渡されるときには、区切り文字を追加しないでください。区切り文字は、アダプタによって自動的に追加されます。
ユーザー定義: このタイプのペイロードでは、セマンティクスはユーザー自身の実装によって完全に制御されます。
外部システムからのインバウンドのペイロードデータを表すには、(コラボレーションルールエディタから) OTD のペイロードノードにデータをマップします。また、入力ストリームを転送元として指定することもできます。
いずれの場合も、連続して get() を呼び出すごとに、ペイロードから次のレコードが抽出されます。抽出されるレコードのタイプは、固定サイズ、区切りなどのアダプタの設定で設定したパラメータによって決まります。
解析コラボレーションは、抽出した各レコードに対する処理を含めて設計します。通常、レコードを別のコラボレーションに送り、そこにあるカスタム OTD がレコード形式を記述し、さらに処理を実行するという方法がとられます。
ペイロードの完全な消費
ペイロードは完全に消費することができます。つまり、get() を連続して何度も呼び出すと、ペイロード内のすべてのレコードを取得できます。この時点で連続して get() を呼び出すと、ブール型の false が返されます。サブジェクトコラボレーションのビジネスルールは、この可能性を考慮に入れて設計します。
データストリーミングでレコード処理 OTD を使用している場合は、出力ファイルを上書きしないように注意してください。OTD が、同じ出力ファイル名を使用する BatchLocalFile OTD に絶えずストリーミングしている場合、OTD は出力側のファイルを上書きすることがあります。
この問題を回避するためには、ファイルのシーケンス番号付けを使用するか、またはコラボレーションルールの出力ファイル名を変更します。シーケンス番号付けを使用すると、BatchLocalFile OTD は、個々のファイルにシーケンス番号を追加することでそれぞれを区別します。ターゲットファイル名と転送後ファイル名のいずれか、または両方を使用すると、出力ファイルの名前を別のファイル名に変更できます。
これらの機能の使用法については、「シーケンス番号付け」および「ファイル転送前/転送後コマンド」を参照してください。