プロトコル
本章では、複数のプロトコルのうち、一般的に多く使用される金融決済院CMSプロトコルと銀行連合会(KFB)プロトコルについて説明する。
金融決済院CMSプロトコル
金融決済院CMSプロトコルは、顧客企業で多く使用される電文処理方式で、銀行連合会プロトコル方式とは異なり、ヘッダー、データ、トレーラー構造に区分しないで送信する特徴がある。
ファイル送信時には、ファイルIDを要求開始電文に送らず、開始応答を受け取ってからファイル情報管理(0630)電文に送る方式である。
また、センター機関での開始要求がなく、参加機関で送受信に関係なく開始要求を送る電文処理プロトコルである。 送受信処理は、ファイル情報要求の電文を送ることによって区別する。
業務処理フロー
業務処理は、センター/参加機関によって異なり、業務開始、データ送信、業務終了に区分される。 電文上の送受信Flagはセンター基準で設定される。 ただし、バッチファイル情報の送受信区分フィールドは、顧客企業の基準で設定されるため注意が必要。
☑送信業務処理
一般的に、業務開始はファイルを送信する機関で開始電文を要求する。 しかし、金融決済院CMSプロトコルは、送受信するかどうかに関係なく、参加機関が開始電文要求するのが特長である。 下記は、ファイル送信業務処理に対するフローで、センター機関がファイルを送信するが、業務開始は参加機関が要求する。
☑受信業務処理
下記はファイル受信業務処理に対するフローである。同様に業務開始は参加機関が要求する。
機能フロー
金融決済院CMSプロトコルの機能フローは、送信・受信業務処理フローに区分され、業務処理の基本構造は上記のとおり、業務開始、データ送信、業務終了で構成されている。 その他にも連続送信、継続送信などの機能フローがある。
☑業務開始フロー
銀行連合会のプロトコルは、開始後にヘッダー電文を送る構造であるが、金融決済院CMSプロトコルは電文の代わりにファイル情報管理(0630)電文を送る。
業務開始要求は参加機関が送り、センター機関は開始要求電文の送受信Flagにより、送受信処理を区分して、ファイル情報の要求電文を送る。
送信業務開始フロー
受信業務開始フロー
☑データ送信フロー
データ送信は、ブロック単位で行われ、ブロックにつき100個のシーケンスで構成される。1つのブロック送信完了後、消失したデータの有無を確認するために、欠番確認要求(0620)電文を送信する。
欠番が発生した場合、欠番の数だけ欠番対象フィールドに対する 欠番データ送信(0310)電文を送信する。 欠番送信が完了すると、再度欠番を確認して、送信ブロックに欠番がなくなるまで、欠番確認および欠番送信を繰り返す。
欠番がないと、次のブロックの送信が行われる。 データ送信フローは、送信データがなくなるまで、データ送信、欠番確認、欠番送信の3つの処理を繰り返し続ける。
☑ 業務終了フロー
これ以上送信するデータがない場合、個別業務終了と全業務終了を実行する。業務終了の要求処理は、送信機関から開始する。
☑ 連続送信フロー
送信するファイルが複数の場合、ファイル継続指示(0600/002)電文を送信する。この電文のあとにファイル情報管理(0630)電文を送り、新しいファイルに対するデータ送信フローを新たに実行する。
ファイル継続指示電文を受信した機関は、その前にファイル処理作業を完了する必要がある。
☑ 継続送信フロー
ファイル受信機関が、特定ファイルを初めて受信する場合、ファイル情報管理応答(0640)電文のファイルサイズ(FILE_SIZE)フィールドに０を設定して送信する。
もし、当該値に０より大きい値が設定されている場合、受信機関は、以前に何らかのファイルデータを受信しているという意味で、継続送信フローを実行する。
連携されたファイルサイズ値で、ブロック番号、シークエンス番号を計算し、当該位置から続けてデータ送信フローを行う。
☑ 重複ファイル処理フロー
バッチ設定管理 > 一括伝送インターフェースで、一括伝送インターフェースの「重複を許可するかどうか」を使用しないと選択した場合、重複ファイルに対する処理を行う。
ファイル情報管理(0630)電文を受信してファイル情報を確認した結果、既に受信したファイルの場合、ファイル情報管理応答(0640)電文を送信する際に、共通ヘッダー電文の応答コード(RESPONSE_CODE)フィールドに既に、受信済み(630)を設定して送信する。
銀行連合会プロトコル
銀行連合会が提供する一括伝送プロトコルで、参加機関からセンター機関に信用情報ファイルを送受信する際に使用する。
ファイル送信時に、センター機関から開始する方法と、機関から開始する方法の2つがあり、受信は参加機関から開始要求する。 ヘッダーおよびトレーラー電文は、応答電文(0330)を受信する形式で、データ送信および欠番処理方式は、金融決済院CMSプロトコル方式と同じである。
業務処理フロー
業務処理は、センター/参加機関によって異なり、業務開始、データ送信、業務終了に区分される。 電文上の送受信Flagはセンター基準で設定される。 ただし、バッチファイル情報の送受信区分フィールドは、顧客企業の基準で設定されるため注意が必要。
☑送信業務処理
ファイル送信時の業務開始は、センター機関から開始電文を要求する一般送信と、参加機関から開始電文を要求する選択送信の2つの方式がある。
一般送信 : センター機関から、一日の業務中に作成された変動分を参加機関に通知する方式である。
選択送信 : センター機関で毎日作成された変動データを、参加機関が必要に応じて随時受信できるように方式である。
☑受信業務処理
参加機関が、センター機関に送信するデータが発生した場合に、センター機関にファイルを送信する業務で使用する方式である。
機能フロー
銀行連合会プロトコルの機能フローは、送信・受信業務処理フローに区分され、業務処理の基本構造は上記のとおり、業務開始、データ送信、業務終了で構成されている。 その他にも連続送信、継続送信などの機能フローがある。
☑業務開始フロー
銀行連合会プロトコルの業務開始フロー方式は、開始後ヘッダー電文を送る基本構造を持つ。一般的に業務開始要求処理は、送信ファイルがある機関から要求する。 また、参加機関がファイルを選択して受信できる選択送信に対応している。
- 送信機関の送信業務開始フロー
送信するファイルがある機関が業務開始電文を送信してから、ファイルヘッダーレコードを送信するフローである。
- 受信機関の送信業務開始フロー
受信機関では、業務開始完了通知(0610/001)電文を受信すると送信開始要求(0600/008)電文を送信する。
この電文は受信機関が業務開始完了通知(0610/001)電文を正常に受信したというACKのような機能である。
送信機関は送信開始要求(0600/008)電文を受信するとHeader Record(0320)電文を送信し、受信されない場合には、決められた回数だけ業務開始完了通知(0610/001)電文を繰り返して送信する。
☑データ送信フロー
銀行連合会プロトコルはファイルデータを、ヘッダー、データ、トレーラーに区分して送信する。それぞれを区分する方法は、データ送信(0320)電文のブロック番号、シークエンス番号のフィールド値を下記のように、設定する。
| 区分 | ブロック番号 | シークエンス番号 |
|---|---|---|
| ヘッダー | 0000 | 000 |
| データ | 0001〜9998 | 001〜100 |
| トレーラー | 9999 | 999 |
銀行連合会プロトコルのデータ送信フローは、金融決済院CMSプロトコルの送信フローと同じである。 (ただし、ヘッダーとトレーラーは欠番を確認せず、受信報告(0330)電文で応答する。)
☑ 業務終了フロー
ファイルデータの終わりであるTrailer Record(0320)電文を送信し、送信するファイルがこれ以上ない場合、個別業務終了要求(0600/003)電文を送信して業務を終了する。
☑ 連続送信フロー
送信するファイルが複数の場合、ファイル送信継続指示(0600/002)電文を送信する。この電文のあとにHeader Record(0320)電文を送り、新しいファイルに対するデータ送信フローを新たに実行する。
ファイル送信の継続指示電文を受信した機関は、その前にファイル処理作業を完了する必要がある。
☑ 継続受信(最終受信の内容処理)フロー
受信機関で障害が発生した場合、障害回復後、障害発生時に受信していたファイルを引き継ぐ機能に対応している。
受信機関から最終受信内容報告(0680)電文を送信すると、送信機関は当該電文のブロック番号、シークエンス番号から開始し、データ電文送信を開始する。その後の電文処理フローは同じである。
