メインコンテンツまでスキップ
Version: 3.4.4

SAF取引アーキテクチャー

SAF取引は、送信システムからメッセージを受けてSAFキューに保存する保存処理と、SAFキューに保存されているメッセージを受け取って受信システムに送信する2つの部分に分けられている。

下記はSAF取引処理に対する基本的なアーキテクチャーである。

SAF取引アーキテクチャー

取引メッセージ保存

送信システムがオンライン取引と同じ方式でEAIにメッセージを送信すると、EAIは当該メッセージを分析して、SAF取引の場合、インターフェースのSAF情報を利用してキューに保存する。

SAFキューに保存する時に、キューに接続できない場合、送信システムにエラーで応答し、それ以外の場合は、非同期方式でキューに保存して送信システムに正常`を応答する。

SAF取引メッセージ保存アーキテクチャー

  1. 送信システムで要求したメッセージをQueue Producerに伝達する。
  2. Queue Producerは、受信したメッセージをSAFキューに非同期方式に保存する。 (保存するSAFキューのパーティション数だけ同時処理可能)
  3. Queue Producerは、SAFキューへの保存エラーの際に、内部キューに保存して再処理する。 非同期方式でSAFキューに保存するため、非同期呼び出し前のエラーの場合、送信システムに取引処理エラーと応答し、SAFキューに保存する途中でエラーが発生した場合、再処理のために内部キューに保存する。
  4. Send Error Producerは、内部キューに保存されたメッセージをSAFキューに保存する。
  5. Send Error Producerは、SAFキューに保存する際に、エラーが発生すると、メッセージの再処理のために内部キューに保存し、一定時間待機してから再試行する。ただし、3回以上保存エラーが発生した場合、当該メッセージはエラーロギング後にスキップする。

取引メッセージ送信

SAFキューのメッセージを1つずつ読み込んで、メッセージ送信プロセスを通じて受信システムを呼び出す。

受信システムは同期方式で呼び出し、メッセージ送信時点にエラーが発生すると内部キューに保存して再処理しながら、エラー回数を管理する。

もし指定された回数以上のエラーが発生した場合、当該メッセージは処理できないためスキップする。

再処理の方式は、内部キューに保存されているSAFメッセージを別途のSAFエラーキューに保存して処理する構造である。

別のSAFエラーキューを利用して再処理する理由は、再処理によって正常に処理するメッセージが影響を受けないようにするためである。 ただし、再処理するプロセスは1つのスレッドとして処理する。

SAFエラーキュー名は、下記で説明するSAFキュー情報に登録したキュー名に、_errorを追加したものをエラーキュー名として使用する。

info

受信システムでエラーと応答する場合は、EAIでエラーであるかどうかを判断できないため、正常応答と見なす。

SAF取引メッセージ送信アーキテクチャー

  1. Process Consumerは、SAFキューからメッセージを受け取って送信プロセスを呼び出す。 同時処理のために、SAFキューのパーティション数分のマルチスレッドで構成されている。
  2. メッセージ送信プロセスは、メッセージを一度に1つずつ同期方式で受信システムを呼び出す。
  3. メッセージ送信エラー時には、処理回数を1増加して内部キューに保存して再処理する。 受信システムでメッセージを正常に処理すると下記のメッセージを処理し、正常に処理できない場合は、処理回数を1増加させた後、内部キューに保存して再処理する。
  4. Process Error Producerは、内部キューに保存されたメッセージをSAFエラーキューに保存する。
  5. Process Error Producerは、SAFエラーキューに保存できない場合、メッセージの再送信のために内部キューに保存し、一定時間待機してから再試行する。
  6. Process Error Consumerは、SAFエラーキューからメッセージを受け取ってメッセージ送信プロセスを呼び出して再処理する。 ただし、Process Error Consumerは、順次処理のため、1つのスレッドで構成されている。
  7. 指定された処理エラー回数を超過した場合、当該メッセージは処理できないため、スキップされる。

取引再処理

EAIは、受信システムへのメッセージ送信時にエラーが発生した場合、指定された回数だけ再処理する。

SAF再処理アーキテクチャー

  1. Process ConsumerやProcess Error Consumerはメッセージ送信処理エラー時に処理回数を増加して内部キューに保存する。
  2. Process Error Consumerは、SAFキューからメッセージを受け、メッセージ送信前の処理回数を検証して再処理回数を超過した場合、エラー処理し、当該メッセージはスキップする。 再処理の回数は、システムパラメータ(SAF_MAX_ERROR_COUNT)に登録するか、登録しなければ基本的に3回再処理する。ただし、3回以上SAFエラーキューの保存エラーが発生した場合、当該メッセージはエラーロギング後にスキップする。
  3. 直ちに再処理せず、エラー回数に応じて一定時間待機した後、再処理する。 待機時間はエラー回数が増加するとより多く待機する構造で、システムパラメータ(SAF_RETRY_UNIT_SLEEP_TIME)にエラー回数当たりの待機時間を登録し、基本的に5秒待機する。
  4. ただし、受信システムが障害の場合には受信システム障害による待機時間が優先適用される。 受信システム障害時の処理方法は下の受信システムの障害処理を参照する。

受信システムの障害処理

受信システム障害によってSAFメッセージを送信できなかった場合、EAIは受信システムを障害と認知して一定時間待機後に処理する。

受信システムのエラー判断ケース
  • 受信システム呼び出し時にエラー発生
  • 接続不可
  • タイムアウト発生
  • HTTP状態コードが2xxではない場合

障害は受信システム呼び出し時にエラーが発生すると、システム業務単位でエラー回数を増加させ、正常に処理された場合にエラー回数を減少する方式で管理する。

もしエラー回数が指定された回数(3回)を超過した場合、超過した回数当たりのシステムパラメータ(SAF_SYSTEM_UNIT_SLEEP_TIME)に登録された時間の間待機するが、基本的には、回数当たり30秒待機する。

待機時間は最大10分を超えることはできない。

受信システムの障害処理

取引処理のためのインスタンス構成方法

SAF取引処理インスタンスは、取引量に応じて2つの方式で構成される。

☑ 1つのインスタンスで構成

取引が少ない場合、1つのオンラインインスタンスで、SAF取引保存と送信を同時に処理する。

1つのインスタンスに構成する方法

  1. Node Management > Instance Informationでオンラインインスタンスを登録する。
  2. Interface Management > Online InterfaceのSAFキューポップアップでSAFキュー情報を登録する。 SAFキュー情報登録時、Instance IDに1.で登録したインスタンスを登録するか、または何も登録しなければ、基本的に1のインスタンスで当該SAFキューに対する保存と送信を処理する。

☑ 保存と送信を分離して構成

取引量が多い場合、保存インスタンスと送信インスタンスを分離して構成する。

保存と送信を分離してインスタンスを構成する方法

  1. Node Management > Instance Informationでオンラインインスタンスを登録する。

  2. Interface Management > Online InterfaceのSAFキューポップアップでSAFキュー情報を登録する。 この時、Instance IDには、必ず1.の送信インスタンスを登録する。

SAFキューとインターフェースの関係

要求したSAF取引を処理する保存インスタンスは、SAF取引種類ごとにそれぞれオンラインインターフェース情報を登録する必要がある。

インターフェース情報を登録する時、当該取引がSAF取引であり、メッセージ保存をどのSAFキューに保存するかについての情報も、一緒に登録する 。ユーザーは、インターフェース別に、それぞれ異なるキューに保存することもでき、または複数のインターフェースを1つのキューに保存することもできる。

インターフェース別に、それぞれのキューに保存するか、複数のインターフェースを1つのキューに保存するかによって、SAF取引メッセージの受信システムへの送信時に影響がある。

インターフェース別にそれぞれのキューに保存する場合、当該メッセージの処理時に障害が発生したり、処理速度が遅いメッセージでも影響はないが、複数のインターフェースを1つのキューに保存する場合は処理速度が遅いメッセージによって他のメッセージ処理が遅れることもある。

しかし、あまりにも多くのキューを使用する場合、キュー管理が難しい場合があるため、処理する必要がある取引量に応じてキューの数を調整しなければならない。

SAFキューとインターフェースの関係