アーキテクチャー
EAIアーキテクチャーは、インターフェースの処理方式によりオンラインアーキテクチャー
とバッチアーキテクチャー
に区分され、ロギング時に必要なロギングアーキテクチャー
およびL4 Switchの役割をするポーリングアーキテクチャー
、そしてSAF処理アーキテクチャー
で構成されている。
オンラインアーキテクチャー

APtoAPなどの一般取引インターフェースが実行される環境で、ゲートウェイコンポーネント
とインターフェースコンポーネント
で構成される。
ゲートウェイコンポーネント

A. 通信プロトコル処理
通信プロトコル処理のために、コネクション情報とコネクショングループ情報を管理する。
コネクション情報は、接続対象の接続情報および通信処理のための詳細属性で、コネクショングループは、同じインターフェースを複数のコネクションが処理する場合に各コネクションの負荷分散ポリシーを管理する。
コネクション情報の詳細設定は、コネクション設定を参照する。
B. 電文伝送
連携対象から受信した電文を、インターフェースコンポーネント
で伝達するか、インターフェースコンポーネント
で受信した電文を連携対象に送信する。
この時、キャラクターセットのエンコーディング/デコーディング処理、および全電文の暗号・復号化処理を行う。
インターフェースコンポーネント

インターフェースコンポーネントは、インターフェース処理を行い、イベントハンドラ
と処理フロー
で構成される。
A. イベントハンドラ
イベントハンドラは、ゲートウェイコンポーネント
から非同期方式で伝達された電文を解析し、インターフェースIDと要求/応答を区分する。
また、インターフェース制御状態を確認して処理フローに伝達する。
B. 処理フロー
処理フローは、電文変換などのインターフェース処理を行う。
要求処理を行う要求フロー
と応答処理を持つ応答フロー
があり、インターフェースごとに定義する。
それぞれのフローは、多数のルーターで構成される。
- フロー
Apache Camelのルーターグループを意味する。 それぞれの単位機能のルーターを順序に呼び出し、オンラインインターフェースを処理する。
BXIでは、電文変換などのインターフェース処理時に必要な基本フローを提供する。 特化したインターフェース要件を処理するために、フローを開発して適用することができる。
- ルーター
Apache CamelのRouteのことで、フローで処理される単位機能である。
例えば、電文をマップに変換するUnmarshalは、1つのルーターが提供する機能である。 BXIは、インターフェースの取引処理で一般的に使用されるルーターを提供する。
一般的に提供されるルーターの機能以外の追加機能が必要な場合は、新規にルーターを開発して適用することができる。 開発方法は、Customizingを参照する。
バッチアーキテクチャー

バッチインターフェース処理アーキテクチャーは、DBtoDB
、FiletoFile
などのバッチインターフェースが実行される環境であり、
バッチ作業スケジュールコンポーネント
とバッチ作業の実行コンポーネント
で構成される。
バッチ作業スケジュールコンポーネント
登録されたバッチインターフェースの作業スケジュールを管理する機能を持つ。 バッチインターフェースに登録されたスケジュールを利用して、インターフェースを実行する。
スケジュールタイプは、シンプルトリガーとCRONトリガーがある。 シンプルトリガーはN秒、N分、N時間単位で動作する方式であり、CRONトリガーは表現式によって定められた時間に動作する方式である。 ex) 45 5 * * 5 毎日金曜日午前5時45分 スケジュール実行。
バッチ作業の実行コンポーネント
バッチインターフェースの処理を行い、インターフェースのタイプに応じて下記の機能が使われる。
☑ File処理(FTP)
Fileを使用するインターフェースのタイプで、FTP方式でファイルを送受信処理する。 FTP接続およびFTP GET/PUT機能を活用して、ファイル転送を実行する。
☑ File処理(Agent)
File to Fileインターフェースのタイプで、File Agent Event Executorは、各業務システムにインストールされたFile Agentを使用してファイルを伝送する。
File Agent Event Executorは、File Agentに伝送を指示するイベントを伝達し、File Agentはイベントの伝達を受けて、システム間のファイルを送受信処理する。
☑ DB処理
DBを使用するインターフェースのタイプでデータを送受信する。 登録されたDataSource情報を使ってDBに接続し、定義されたSQLを実行する。
SAFアーキテクチャー

SAF 取引は、送信システムからメッセージを受け取りSAFキューに保存する保存処理と、SAFキューに保存されたメッセージを受け取り受信システムに伝送する2つの部分に分かれている。
詳しいアーキテクチャーは、SAFアーキテクチャーを参照する。
ロギングアーキテクチャー
BXIのログ処理方式は、オンラインインスタンスが直接ロギングするローカル(L)
方式と、別のロギングアーキテクチャーを活用したリモート(R)
方式に区分される。
ローカル(L)方式
インスタンスが、オンラインインターフェースを処理しながら、直接DB/ファイルにログを格納する方式である。 オンライン取引量が多くない場合に使用する。
リモート(R)方式

インターフェース処理時に発生するログデータを非同期でロギングする。 オンライン取引量が多い場合、インターフェース処理の性能向上のために使用する。
ログデータは、非同期ロギングアーキテクチャーで、Apache Kafkaに非同期で伝達され、レシーバーコンポーネントおよびロギングコンポーネントで構成された、別のロギングインスタンスでDB/Fileに記録される。
☑ Apache Kafka
大容量のリアルタイムログ処理に特化したアーキテクチャーを提供するオープンソースソフトウェアである。
☑ ロギングインスタンス
ロギングインスタンスは、下記のコンポーネントで構成される。
- レシーバーコンポーネント : Kafkaに格納されているログをKafkaコンシューマーから読み込んでロギングコンポーネントに伝達する。
- ロギングコンポーネント : DBやファイルにログ情報を格納する。 ログ設定およびログ管理は、ログ管理を参照する。
ポーリングアーキテクチャー
BXIでは、システムとの連携時にL4 Switchを使用しない場合、L4 SwitchのFail-Over機能に代わる機能を提供する。
定期的なメッセージポーリング方式でこれに対応するため、インターフェース処理を実行するインスタンス以外に別のシステムポーリングインスタンスが必要である。 インターフェース処理を行うオンラインインスタンスは、システムポーリングインスタンスのシステム状態情報を利用して取引を処理する。
システムポーリングインスタンス

HTTP
でシステムと定期的にメッセージを送受信しながら状態を確認する。
システム状態情報は、メモリー上で管理され、別のDB同期スレッドが、システムポーリング状態をDBに同期する。
オンラインインスタンス

定期的にDBのシステムポーリング状態情報をメモリーに同期し、このシステム状態情報を使用して、正常に取引処理が可能だと判断されたシステムに対して、取引を要求する。
システムポーリングインスタンスはノード別に1つだけ登録することができ、1つのシステムポーリングインスタンス情報として複数のノードで使用することができる。 ポーリングアーキテクチャーを使用するための詳細設定はシステムポーリングを参照する。