Search

アーキテクチャ

Version 23.4.8841

アーキテクチャ

CData Arc は、ビジネスプロセスを統合するメッセージ駆動型のプラットフォームです。アプリケーション、データベース、外部メッセージシステムが互いにやり取りできるコミュニケーションハブを提供します。

デザイン原則と実装

Arc のアーキテクチャは、一連のコアとなるデザイン原則に則って決定されています。このセクションでは、Arc のデザインの3つの側面に着目します。

  • CData が重視する原則と価値
  • Arc の高度な理解に必要なコアとなるコンセプト
  • アーキテクチャ上の判断と、その判断がデザイン原則をどう反映しているか

原則およびコンセプトセクションは、技術的な知識を持ったユーザーと一般のユーザー、両方に向けたものになっています。残りの実装のセクションは、エンジニアにArc のアーキテクチャを活用する方法を理解してもらうためのものです。

コアとなる原則

Arc のデザインにおいて鍵となる原則は次のものです。

  • 透明性
  • シンプルさ
  • モジュール性
  • 使いやすさ

連携プラットフォームで上記のデザイン原則を実装する方法は、Arc のアーキテクチャ以外にも存在します。次に実装のアイデアと、それがどのようにデザイン原則を反映するかを説明します。

コンセプト

大枠では、Arc のソリューションは3つの要素から構成されます。

  • フロー
  • コネクタ
  • メッセージ

フロー

Arc フローは、一連の自動化されたデータ処理タスクを実行する設定済みのワークフローです。フローは複数のコネクタによって構成され、1つのコネクタが処理したデータが自動的にフロー内の次のコネクタに渡されるよう接続されます。

ユーザーインターフェース内では、フローはフローページに表示されます。コネクタを左のツールボックスから空のキャンバスにドラッグし、設定したり他のコネクタと接続することができます。次の画像は、AS2 コネクタとX12 コネクタの2つのコネクタから構成される簡単なフローを示します。

2つのコネクタ間の青い矢印は、AS2 コネクタが受け取ったデータが自動的にX12 コネクタに渡されることを示します。コネクタの右側にある青い点を他のコネクタの左側にドラッグすると、この関係が構成されます。

フロー内の一連のコネクタはデータ処理の論理的な手順を構成するため、特定のビジネスタスクを達成できるようフローをデザインしてください。タスクとしては単なるファイルのダウンロードから、受信したビジネス文書に基づいて複数のバックエンドアプリケーションを同期することまで、さまざまな複雑度のものがあり得ます。

異なるタスクを達成するためにArc 内で複数のフローを設定することもできます。フローは、青いフローの矢印で明示的に接続されていなければ、互いに独立して動作します。

フローに関する詳しい情報は、専用のフローセクションを参照してください。

コネクタ

コネクタはフローの個別の部品で、アプリケーションデータおよびメッセージに影響します。各コネクタはメッセージに特定の操作を実行し、フロー内の次のコネクタ、または外部パーティ（例えば、FTP 同期先）に渡します。

操作は主に3つのカテゴリに分けられます。

  • データの受信（転送したファイルやデータベースの出力、etc.）
  • データの処理または変換（フォーマット間でのデータの変換、新しい構造へのデータのマッピング、etc.）
  • データの送信（ファイルの送信やアップロード、データベースへのデータの挿入、etc.）

コネクタが上の操作を実行するときには、コネクタはトランザクションを処理していることになります。

フローページ内では、左のツールボックスからキャンバスへコネクタをドラッグすることでコネクタのインスタンスが作成されます。フロー内のコネクタをクリックすると、設定パネルが表示されます。

コネクタは種類（例えば、AS2、SQL Server、XML、etc）に応じて異なる設定が可能です。

AS2 コネクタやSFTP コネクタなどの一部コネクタは、外部パーティやサーバーからデータを受け取るか、外部パーティやサーバーにデータを送信するか、またはその両方が可能です。これらのコネクタは通常、データがアプリケーションに入力されたり出力される、フローの開始地点または終了地点にあります。

XML Map コネクタやX12 コネクタなどの他のコネクタは、アプリケーション内でローカルにデータを処理します。これらのコネクタは、（外部ソース以外の）他のコネクタからのみデータの受信が可能で、（外部デスティネーション以外の）他のコネクタにのみデータを送信できるため、通常設定済みのArc フロー内に組み込まれています。

コネクタについての詳細は、コネクタセクションを参照してください。

メッセージ

フロー内のコネクタ間でデータをやりとりする際には、メッセージとしてやりとりされます。Messages consist primarily of file payload data (the data that Arc is processing) and metadata (information that Arc uses to track the flow of data through the application).

メッセージについては、メッセージの実装セクションでより詳細に説明されていますが、メッセージは標準RFC822（インターネットメッセージ）形式のファイルである、というのが概要となります。コネクタがデータをフロー内の他のコネクタに渡すと、渡されたコネクタはデータをファイルに書き込み、ファイルを次のコネクタに渡します。

フローの各ステップで、メッセージ（ファイル）はアプリケーション側に受信、またはダウンロードされ、ローカル（アプリケーション内）で変換されて、アプリケーションからアップロード、または送信されます。これらの各操作をトランザクションと呼びます。

Arc は透明性の高いシステムです。ファイルシステムを参照したり、メッセージがあるフォルダから別のフォルダへコピーされるのを確認したり、またはメッセージ内容を通常のテキストエディタなどのツールを使って参照することで、プラットフォーム内の動作を理解できます。

Basic Message Structure

Basic messages have two parts: (1) a set of name-value pairs as headers, and (2) the message payload. Together, this message format is stored in a ‘.eml’ file type that can be opened by any standard text editor or email client.

Message Headers

Message headers help Arc track the progress of data through the application. Headers include a unique Message ID (which helps Arc know the full lifecycle of a message, even if the filename is changed), timestamps from when connectors processed the message, any errors that might have occurred during processing, and other metadata.

Headers are listed in headerName: headerValue syntax at the top of the message, delimited by line breaks. Clicking on a message within Arc (e.g. within the Input our Output tab of a connector panel) will show the headers associated with the message, and allow for downloading the file content of the message.

Messages are also used for miscellaneous values that are helpful for Arc to know within a flow. For example, when downloading files from a subfolder on a remote FTP server, Arc uses a header to track the folder path to the message in case this folder path needs to be recreated on the local system.

Message Payload

The message payload is the actual file data being processed by the application. This is the data that is received/downloaded from a remote source, manipulated by transformation connectors, etc. While the message headers are primarily used by Arc for tracking messages, the message payload contains the data that users care primarily about.

Message payloads are separated from message headers by two line breaks. Opening an Arc message in a text editor or email client will display the message payload in plain text.

Messages Within a Flow

While Arc internally uses message headers for tracking and understanding the data processed by the application, it hides these details from users unless the message is inspected. For example, Arc uses an internal Message ID to identify a message, but will display a public filename in Input/Output tabs, transaction logs, etc.

To examine the headers on a message, simply click on the displayed filename to view further message information.

Message headers are added to files as soon as the first connector processes the file. Message headers are stripped from the message at the end of the flow (after the last connector in the flow has processed the message). In other words, message headers and the ‘.eml’ format is only relevant while file data is in the midst of being processed in an Arc flow.

Message Logs

Whenever a message is processed by a connector, Arc generates a transaction log for that processing. These logs can be accessed via the Transaction Log in the Status page, or by clicking on a message filename within a connector panel and selecting Download Logs.

Batch Groups and Batch Messages

Messages can contain multiple payloads, in which case they are considered “batch groups.” Each individual payload within a batch group is considered a “batch message.”

Batch Groups

Batch groups are MIME-format files where each MIME part is a separate batch message. The batch group maintains metadata about the batch using the same header scheme that basic messages use. These headers track the processing of the batch as a whole, rather than individual parts of the batch.

Batch Messages

Each batch message within a batch group is a MIME part containing the file payload data processed by the application. Each batch message contains metadata associated with the payload (but not the batch group) within the MIME part. Thus, batch messages have multiple sets of metadata: one set of headers for tracking the batch group as a whole, and a separate set of headers for each individual MIME part (each batch message) within the batch.

実装の概要

このセクションでは、上記のコアとなるコンセプト（メッセージ、コネクタ、フロー）の、Arc 上での実装に関する技術的な詳細と、この実装がどのようにCData のデザイン原則を満たすのかを説明します。

ファイルベースのアーキテクチャ

Arc はファイルシステム上のファイルにすべてのデータを保存します。そのため、アプリケーションに関わるすべてがディスク上に残ります。

  • アプリケーションデータ（メッセージ）
  • 設定データ（プロファイルとフロー）
  • ログ、etc。

設定済みフロー内のコネクタは、1つのインプットフォルダからファイル（メッセージ）を読み込み、1つのアウトプットフォルダにファイル（メッセージ）を書き込みます。データが1つのコネクタから別のコネクタにデータを渡す際には、これらのメッセージファイルは最初のコネクタのアウトプットフォルダから、次のコネクタのインプットフォルダに移動されます。

Arc はこうしたファイルシステムベースの構造にWeb UI を提供し、フローの簡単な構築、設定を実現します。ただし次のセクションで説明されているような、アプリケーションで使用されているフォルダ構造やファイル関連の決まりを理解していれば、ファイルシステムを直接編集することでArc のフローを構成することもできます。Arc は階層的なフォルダ構造を使ってアプリケーションのファイルを整理します。これについては、フォルダ階層セクションで説明します。

メッセージの実装

Arc のメッセージはアプリケーションが処理した生データを含む、ディスク上のファイルです。メッセージは2つの部分に分けられます。

  • ボディ- アプリケーションデータのペイロード
  • ヘッダー - メッセージのメタデータ

ヘッダーとボディは、合わせてRFC2822 準拠の.eml 拡張子を持ったファイルに保存されます。ヘッダーはname: value ヘッダーをnewline 文字で区切ったリストであり、ボディは2つのnewline 文字でヘッダーと区別されます。

ボディ

データを受信すると、Arc はメッセージを生成して（新規メッセージをディスクに書き込んで）、受信中のデータをメッセージのボディに使用します。例えば、SFTP コネクタがリモートサーバーからファイルをダウンロードすると、リモートファイルの内容が新規メッセージのボディとなります。

データがアプリケーション内でローカルに処理される際には（例えば、EDI がXML に変換されたり、ファイルが新しい形式にマッピングされるなど）、操作を実行中のコネクタがインプットメッセージのボディを読み込み、メモリ内でデータを処理して、アウトプットメッセージのボディに結果を書き込みます。

アプリケーションがデータを送信する際には（例えば、リモートサーバーにファイルをアップロードしたり、ピアにファイルを送る、データベースに挿入するなど）、インプットメッセージのボディだけが送信されます。

ヘッダー

Arc は生データファイルに、ファイル処理の方法に関するメタデータを付加します。次は最も頻繁に出現するヘッダーの一部です。

  • フロー内でファイルを識別する一意の、永続するMessageId。
  • 処理中のファイルのタイムスタンプ
  • ファイルを処理したコネクタのコネクタID
  • エラーで処理に失敗したファイルのインスタンス

本アプリケーションがメッセージヘッダーを編集、および上書きすることはありません。処理履歴がすべて保持されるよう、新規ヘッダーは常に既存のリストに追加されます。

Batch Groups

Messages can be batched together to improve performance and make large groups of messages more manageable. Multiple messages batched together are called “Batch Groups.” Batch groups are MIME-format files where each MIME part is a separate batch message. The batch group maintains metadata about the batch using the same header scheme that basic messages use. These headers track the processing of the batch as a whole, rather than individual parts of the batch.

Batch Messages

Each batch message within a batch group is a MIME part containing the file payload data processed by the application. Each batch message contains metadata associated with the payload (but not the batch group) within the MIME part. Thus, batch messages have multiple sets of metadata: one set of headers for tracking the batch group as a whole, and a separate set of headers for each individual MIME part (each batch message) within the batch.

メッセージへのアクセスと閲覧

メッセージはディスク上のファイルなので、ユーザーや外部システムは現時点でArc パイプライン内にあるメッセージにアクセスし、閲覧することができます。メッセージ.eml ファイルがファイルシステムのどこにあるのかを知っておくだけで、外部アプリケーションからメッセージにアクセスできます。こうしたメッセージファイルの正確な場所は、フォルダ階層セクションに記載されています。

メッセージは、Arc のWeb UI およびArc のREST API からも利用可能です。メッセージは、メッセージを処理したすべてのコネクタのインプットタブやアウトプットタブ、またはステータスページのトランザクションログに表示されます。これら3つのインターフェース内のどのファイル名をクリックしても、メッセージがモーダルに表示されます。

このパネルに表示された値はメッセージヘッダーです。メッセージのボディにはダウンロード ボタンをクリックすることでアクセスできます。メッセージに関連するログは（メッセージログセクションで説明されているように）、ログをダウンロードボタンでダウンロードできます。

メッセージトラッキングとログ

メッセージには、メッセージの一意の識別子として機能するMessageId ヘッダーが含まれます。このMessageId は、ファイル自体の名前が変更されたとしても、フロー内では変化しません。そのため、フロー内でのすべてのファイルの状態はMessageId を参照することで追跡できます。ユーザーはこの値を使って、特定のトランザクションに関連したログデータを見つけることができます。

Arc はログデータを次の2つのフォーマットで保存します。

  • アプリケーションデータベース。
  • ディスク上のVerbose ログファイル。

これら2つのフォーマットとその関係については次で説明します。

アプリケーションデータベース

アプリケーションデータベースは、Arc がさまざまな方法で使用するリレーショナルデータベースです。

  • 本アプリケーションが処理した各トランザクションのメタデータを保存
  • どのトランザクションにも特定的でないアプリケーションの操作のログを保存
  • 特定のコネクタの状態を保存（コネクタが確認応答または受信確認を待機している場合など）

Arc はデフォルトのSQLite（Windows / .NET）、またはDerby（Java）データベースを同梱していますが、SQL Server やPostgreSQL、MySQL などの外部データベースを使用することもできます。Arc はアプリケーションデータベース内のすべての関連するテーブルの作成と保守を行います。

トランザクションログは、特定のトランザクションのメッセージを追跡したりログを見つけるための、アプリケーションデータベース内のテーブルです。このテーブルは、本アプリケーションが処理した各トランザクションのメタデータを保持し、メタデータには処理されたメッセージのMessageId が含まれます。Web UI のステータスページを使用することで、ブラウザからトランザクションログやデータベース内の他のテーブルを閲覧できます。

トランザクションログはトランザクションのメタデータ（タイムスタンプ、ファイル名、ConnectorId など）で検索できます。データベースのフットプリントを最小化するため、verbose ログデータはトランザクションログには含まれず、ディスク上のログファイルに保存されます。

Verbose ログファイル

Arc は、メッセージを処理するたびにMessageId と同名のログフォルダを生成します。このフォルダにはverbose ログファイルが含まれ、ログ内容はファイルを送信および受信（または送信か受信のどちらか）したコネクタの種類に依存します。例えば、AS2 コネクタはメッセージ自体を表示する.eml ファイルに加えて、MDN レシート、生のリクエストと応答、接続ログをログに記録します。

こうしたログファイルは、フロー内のメッセージを追跡するだけであれば不要です。アプリケーションデータベースに保存されたメタデータだけで、メッセージの追跡には十分です。ただし、デバッグの際などに特定のトランザクションの詳細がほしい場合は、メッセージのMessageId と処理したコネクタに基づいて、適切なファイルを見つける必要があります。

当然、ユーザーはMessageId が分かっていれば適切なログフォルダに手動で移動できます。しかし次で説明するように、こうしたverbose ログファイルを見つけるにはアプリケーションデータベースを使用する方が便利です。

アプリケーションデータベースとログファイルの関係

アプリケーションデータベースに保存されたメタデータには、特定のトランザクションに関連するログファイルを見つけるのに必要なすべての情報が含まれます。Arc のWeb UI およびREST API はこの関係を使って、すべてのトランザクションのログファイルに簡単にアクセスできるようにします。

ステータスページにはトランザクションログテーブルが含まれ、テーブルにはトランザクションのメタデータが含まれます。こうしたトランザクション項目はすべて、トランザクションに紐付けられたログファイルを表示するように拡張できます。Arc は適切なログファイルを見つけるために、背後でMessageId を使用しています。

同様に、コネクタの設定パネルのインプットタブとアウトプットタブを使えば、特定のコネクタが処理したすべてのトランザクションにアクセスできます。これらの項目は、トランザクションのverbose ログファイルを閲覧、ダウンロードできるように拡張することもできます。

アプリケーションデータベースは、トランザクションログファイルが保存されている適切なフォルダに手動で移動するのに役立ちます。ユーザーがトランザクションのファイル名（またはタイムスタンプ、etc）を知っていても、内部のMessageId は知らない、ということは頻繁にあります。トランザクションログ内は検索できるので、特定のファイル名で検索すると、そのファイル名に紐付けられたトランザクションのMessageId が表示されます。フォルダ階層セクションは、MessageId とコネクタが分かったあとで、ログフォルダの場所を見つける方法に関する情報を含みます。

メッセージ実装のデザイン判断

アプリケーションデータはユーザーと外部システムにとって透明であってほしいと考えており、そのためメッセージは不透明な内部データチャネル上ではなく、ファイルシステム上のデータファイルとしてやり取りする実装になっています。そのため、Arc は処理中にデータが隠ぺいされるブラックボックスではありません。Arc は実質的に、ファイルシステム上の特定のフォルダからファイルを取得したり、そこにファイルをドロップするようなどんなシステムにも組み込むことができます。

また、特別なツールやプログラムなしでメッセージにアクセスできる方が望ましいと考えています。メッセージはRFC2822 準拠のファイルに格納されるので、どんなテキストエディタでも簡単にファイルを開くことができます。ダブルクリックするとシステムのデフォルトE メールクライアントがメッセージを開いて内容を表示するよう、.eml 拡張子を使用しています。

メッセージとログが手軽に利用でき透明性を保つよう、トランザクションメタデータを検索可能なデータベースを提供しています。このデータベースはメッセージペイロードとverbose ログファイルへの直接アクセスに使用でき、しかもメモリをあまり使用しません。

コネクタの実装

コネクタは設定済みのフロー内で1つのステップとして表示されます。複雑なフローは、データ処理の論理的な手順を実行する任意のコネクタの集まりを繋ぐことで作成します。

コネクタは3種類の操作を実行できます。

  • データを受信してアウトプットメッセージを書き込む（例えば、SFTP 経由でリモートファイルをダウンロード）
  • インプットメッセージを読み込んでデータを外部パーティに送信（例えば、AS2 経由でファイルを送信）
  • インプットメッセージを読み込んでローカルで処理し、アウトプットメッセージを書き込む（例えば、EDI ファイルをXML に変換）

多くのコネクタは最初の2つの操作（データのリモートエンドポイントへの送受信）、または最後の操作（データをローカルで変換）を実行できます。コネクタが実行するすべての操作は、トランザクションと呼ばれます。

すべてのコネクタは1つのインプットフォルダからインプットメッセージを読み込み、1つのアウトプットフォルダにアウトプットメッセージを書き込みます。コネクタがフロー内で接続されると、Arc は最初のコネクタのアウトプットフォルダからメッセージを次のコネクタのインプットフォルダに移動します。

コネクタファイルとフォルダ

すべてのコネクタインスタンスは、ConnectorId（フロー内の表示名）と同名のディスク上の1つのフォルダとして存在します。各コネクタフォルダには次が含まれます。

  • port.cfg ファイルには設定が含まれます
  • ‘Send’ サブフォルダ内の送信、または処理するメッセージ（インプットメッセージ）
  • ‘Receive’ サブフォルダ内の受信したメッセージ（アウトプットメッセージ）
  • コネクタが処理したメッセージのログファイル
  • マップ、テンプレート、スクリプトといったコネクタに固有のファイル

このセクションではこうしたフォルダの内容が本アプリケーションでどのように機能するかを説明し、フォルダ階層セクションではコネクタフォルダとその中のサブフォルダ階層の正確な場所を説明します。

Port.cfg

各コネクタのport.cfg ファイルにはコネクタの動作を制御する設定が含まれます（コネクタUI の［設定］と［高度な設定］に表示される設定です）。ファイルはINI フォーマットであり、コネクタの設定はSettingName = SettingValue 構文で1行1設定としてリスト化されています。

port.cfg ファイルは_間接値_、つまり文字列リテラルの代わりに参照を使ったフィールドの設定をサポートします。この設定は、概念的にはアプリケーションの別のセクションで変数を設定して、その変数名をport.cfg ファイルで参照するのと同じです。間接値の設定に関する詳細は、データディレクトリセクションのsettings.json サブセクションを参照してください。

コネクタ設定をアプリケーションUI で変更するのと、port.cfg ファイルから設定を直接変更するのは、実質的には同じことです。

インプットメッセージ

‘Send’ フォルダはインプットメッセージ、つまりコネクタが処理するためにキューに入っているメッセージを保持します。

各クロックティック（デフォルトでは0.5秒）毎に、Arc はコネクタのSend フォルダをチェックしてワーカースレッドを利用可能なメッセージを持つすべてのコネクタに割り当てます。メッセージが処理されると、Arc はそのメッセージに処理試行時のタイムスタンプが付いたヘッダーを付加します。

Arc は、より古いファイルが最初に処理されるよう、インプットメッセージを最終変更時間に応じてソートします。Arc は各試行中にヘッダーを付加するので、エラーを起こすメッセージが複数回再試行することで、コネクタを無意味にブロックしてしまうことはありません。

各クロックティックでインプットメッセージを処理するには、コネクタ内で_送信_オートメーションを有効化しておく必要があります。

アウトプットマッピング

‘Receive’ フォルダはアウトプットメッセージ、つまりコネクタが受信、ダウンロード、または処理したメッセージを保持します。

コネクタによっては、インプットメッセージの処理を終えてすぐにアウトプットメッセージを書き込みます（例えば、データフォーマットを変換するコネクタなど）。ダウンロードするファイルをリモートサーバーにポーリングするSFTP コネクタ、受信するファイルを待機してリッスンするAS2 のようなその他のコネクタは、インプットメッセージを最初には読み込みません。

コネクタがフローで他のコネクタに接続されている場合、アウトプットメッセージはReceive フォルダに待機せず、次のコネクタのSend フォルダに渡されます。

ログファイル

コネクタが処理する各トランザクションは、一連のログファイルを生成します。トランザクションメタデータはトランザクションログに追加され、verbose ログ情報はディスク上にファイルとして格納されます。ログファイルには常に.eml フォーマットのメッセージとコネクタ固有のログが含まれます。

デフォルトでは、ログファイルは次のフォルダ構造に従って整理されています。

├── Logs
    ├── Sent
        ├── MessageId_1
        ├── MessageId_2
    ├── Received
        ├── MessageId_3
        ├── MessageId_4

つまりログファイルはすべて、親の’Logs’ フォルダ内にある’Sent’ または’Received’ フォルダ内の、処理されたメッセージのMessageId と同名のフォルダに保存されます。

ログは、生成された時間に応じてログフォルダをまとめることでさらに整理できます。すべてのコネクタのログサブフォルダのスキームフィールドは、時間間隔（例えば、Weekly）に設定することでその間隔でログをまとめることができます（例えば、同じ週に生成されたすべてのログが同じサブフォルダに生成される、といったように）。これによって個々のサブフォルダのサイズを減らすことができ、ディスクI/O 性能の向上に繋がります。

MessageId を見つけるか本アプリケーションのUI からダウンロードログ機能を使うことで、トランザクションログを使って適切なログフォルダを検索する必要があるかもしれません。

送信ファイル

verbose ログファイルに加えて、コネクタはすべての送信または処理されたメッセージを’Sent’ フォルダに保持しています。この’Sent’ フォルダはコネクタフォルダ直下のフォルダであり、’Logs’ フォルダ内の’Sent’ フォルダではありません。

‘Sent’ フォルダのファイルには送信に成功したメッセージのデータペイロードだけが含まれます。エラーが発生して処理に失敗したメッセージは’Sent’ フォルダには追加されません。

送信ファイルは生成された時間に基づいてさらに整理できます。Sent フォルダのスキームフィールドは時間間隔（例えば、Weekly）に設定して、その間隔でログをまとめることができます（例えば、同じ週に送信されたすべてのファイルが同じサブフォルダに保持される、といったように）。これによって個々のサブフォルダのサイズを減らすことができ、ディスクI/O 性能の向上に繋がります。

設定ファイルの追加

コネクタの種類によっては、コネクタフォルダに追加の設定ファイルが含まれます。追加のファイルには次が含まれます。

  • map.json
  • script.rsb
  • テンプレートXML ファイル

これらのファイルはマッピング関係、カスタムスクリプトの動作、コネクタのインプットとアウトプット構造を保持します。これらのファイルをディスク上で編集することは、アプリケーションUI の関連するコネクタ設定を変更することと同じです。

コネクタ実装のデザイン判断

フローは完全なモジュラー型を志向しており、各コネクタが予測できる直感的な方法でわかりやすい機能を提供することを目指しています。Arc には任意のコネクタを組み合わせる機能があるため、シンプルなインターフェースでありながら複雑なタスクを実行することができます。洗練されたフローであっても、コネクタの連鎖を個々のステップに分解することで簡単に理解できます。

コネクタに関連するすべてのデータ（設定データ、アプリケーションデータ、ログデータ、etc.）に簡単にアクセスできるようにしたいと考えています。すべてのデータはコネクタ固有のフォルダにあるので、フォルダの場所さえ分かっていればそのフォルダにアクセスできます。設定データはメッセージデータと同様、透明性の高いINI フォーマットで格納されているため、シンプルなツールで閲覧・編集できます。

フォルダベースのアプローチでコネクタをデザインしているので、コネクタ間でどのようにデータがやり取りされるのかも容易に理解できます。メッセージファイルを移動する操作では、1つのコネクタのアウトプットを別のコネクタのインプットに移動します。Arc にはこうしたファイル移動の関係を自動で構成する組み込みツールが含まれますが、同じことはファイルシステムを直接操作することによっても可能です。

フローとワークスペースの実装

フローはファイルシステム上で、フローでのコネクタの位置と接続を含むflow.json ファイルとして表されます。ファイルの場所は以下のファイル階層セクションに記載されています。

フローでのコネクタの位置は純粋に見た目上のものに過ぎず、アプリケーションUI でフローを設定する場合にのみ使用されます。コネクタ間の接続はデータ処理に影響します。各コネクタがアウトプットメッセージを書き込むと、コネクタはアプリケーションエンジンにアウトプットメッセージを別のコネクタのインプットフォルダに渡すかどうかクエリします。本アプリケーションはflow.json ファイルを使って、（もしあれば）どのコネクタがファイルを渡されるか決定します。

同じフローキャンバスで複数のフローを設定でき、Arc のUI ではキャンバスをドラッグしてフロー間を移動できます。この操作は、例えばGoogle Maps の道路地図を使う場合のようなオンライン地図の操作と同様です。

ワークスペースはフロー間を論理的に分離します。各ワークスペースはコネクタの論理フローを設計するための新しいキャンバスとなります。Google Maps のアナロジーを拡張すると、ワークスペースは個別の’惑星’ のように機能します。

新しいフローを設定するために別のワークスペースを使うか同じワークスペースを使うかは、好みの問題です。

ファイルシステム上のワークスペース

新しい（デフォルトではない）ワークスペースを導入すると、Arc のフォルダ階層に新しい一連のフォルダが追加されます。 ワークスペースディレクトリには、デフォルトワークスペースで設定したすべてのコネクタのコネクタフォルダが含まれます。このワークスペースは次のセクションで説明するデータディレクトリの兄弟です。

フローとワークスペースのデザイン判断

CData では、フロー内の個々のコネクタ間のシンプルでモジュラーな関係を保つ最良の方法は、フローを純粋に論理的な概念として扱うことだと考えています。データ処理の効率的な連鎖を決めるために必要なすべての情報は、すでにコネクタの実装に含まれています。

ワークスペースはコネクタをより根本的なレベルで分離する機能にしたいと考えています。個々のワークスペースは、ファイルシステムレベルの操作（例えば、権限やディレクトリリスティング）が簡単に特定のワークスペースのみに適用されないよう、コネクタを格納する個別のフォルダを与えられています。

フォルダ階層

Arc のすべてのリソースはファイルシステムから利用できるため、Arc の低レベルの実装を理解するにはアプリケーションのフォルダ構造を知っておく必要があります。このセクションでは、ディスク上でファイルやフォルダがどのように整理されているかを説明します。

この階層をよく理解するには、Arc のインストール先のディレクトリ構造を知っておくのがよいでしょう。次のテキストはそのフォルダ構造を示しており、以下のサブセクションで詳細を説明します。

├── Arc
    ├── data
        ├── AS2_Amazon
            ├── Archive
            ├── Logs
            ├── Pending
            ├── Receive
            ├── Send
            ├── Sent
        ├── Database_MySQL
            ├── Archive
            ├── Logs
            ├── Receive
            ├── Send
            ├── Sent
            ├── Templates

この階層は、フローがデフォルトのワークスペースだけで設定されていることを想定しています。追加のワークスペースについてはフローとワークスペースセクションで説明します。

ルートインストールディレクトリ

All Arc resources are contained in the installation directory, which are the following default locations:

  • Windows：C:\Program Files\CData\CData Arc
  • Linux/：/opt/arc

For Java installations, CData provides a zip file that you can extract to the installation directory of your choice (for example, /opt/arc).

When the Java edition of Arc is hosted on an external Java servlet, like Tomcat, Arc resources reside here:

~/cdata/arc

In this path, ‘~’ resolves to the home directory of the user that hosts the Java servlet.

In the folder hierarchy that is shown in the previous section, the root installation directory is the Arc folder at the top of the tree.

データディレクトリ

data ディレクトリには次が含まれます。

  • （デフォルトワークスペースの）フローページで設定された各コネクタのサブフォルダ
  • profile.cfg ファイル
  • flow.json ファイル
  • settings.json ファイル
  • すべての証明書ファイル

Profile.cfg

profile.cfg ファイルには、設定済みローカルプロファイル（例えば、AS2 プロファイル）用のアプリケーション全体の設定が含まれます。このファイルはINI フォーマットであり、アプリケーションの設定はSettingName = SettingValue といった1行1設定の構文でリスト化されています。

profile.cfg の設定は、一般のアプリケーションセクション用のApplicationと、各プロファイル（例えば、AS2 プロファイルのAS2 セクションやローカルSFTP サーバー設定のSFTPServer セクション etc）用の専用セクションに分割されています。

アプリケーションUI のプロファイル ページからアプリケーション設定を変更することと、profile.cfg ファイル内で直接設定を変更するのは実質的に同じことです。

Flow.json

flow.json ファイルには設定済みのフローの位置と各コネクタインスタンス間の関係が含まれます。フローページでコネクタを移動、再接続することとflow.json ファイルを直接変更するのは、実質的に同じことです。

Settings.json

settings.json ファイルには、アプリケーション内で値ではなく参照名を使用することで、別の箇所で参照できる設定の一覧が含まれます。This enables you to store secure values (like passwords) in a way that does not display them in the application.You can also use reference names to centralize the configuration of Flows that are deployed across multiple instances.

この統一された参照構文はWeb UI 上で「鍵」アイコンが付いた設定でサポートされており、それをクリックすることでsettings.json ファイルで定義された参照の一覧を閲覧できます。この機能に関して詳しくは、Global Settings Vault を参照してください。

証明書

本アプリケーションで作成、またはアップロードされた証明書はすべてdata ディレクトリに保存されます。通常、証明書はパブリックとプライベートの対となっており、プライベートは.pfx、パブリックは.cer と異なる拡張子となっています。本アプリケーションにアップロードされた他のフォーマットの証明書はそのまま保存されます。

Arc はUI からドロップダウンメニューで証明書を設定する際に、data ディレクトリの証明書を一覧化します。data ディレクトリに直接証明書ファイルをドロップすることは、アプリケーションに証明書をアップロードすることと実質的に同じことです。

コネクタフォルダ

設定済みの各コネクタインスタンス用に、data ディレクトリに専用のフォルダが設置されています。これらのフォルダ名はフロー内の各コネクタのConnectorID の値（表示名）と同じです。上の画像では、’AS2_Amazon’ と’Database_MySQL’ がフロー内の2つの設定済みコネクタです。

コネクタフォルダの内容はコネクタファイルとフォルダセクションで説明されていますが、次の説明はコネクタフォルダ内のサブフォルダ構造の概要となります。

  • Send（インプット）- コネクタが送信、または処理するメッセージはこのフォルダから読み込まれます。
  • Receive（アウトプット）- コネクタが受信、または処理したメッセージはこのフォルダに書き込まれます。
  • Sent - 処理に成功したメッセージのコピー（生データファイルのフォーマット）はこのフォルダに書き込まれます。
  • Logs - コネクタが処理した各メッセージのverbose ログファイル。
    • Sent - コネクタが送信したメッセージのログ。各メッセージはMessageId と同名のフォルダを持っています。
    • Received - コネクタが受信したメッセージのログ。各メッセージはMessageId と同名のフォルダを持っています。
  • Archive - 古いログファイルは圧縮されてこのフォルダに移動されます。

コネクタの種類に応じて、場合によっては他のサブフォルダを持つこともあります。

  • Pending - 処理したが他パーティからの確認応答を待っているメッセージ。
  • Templates - コネクタのインプット、アウトプットデータのXML 表示。
  • Public - 本アプリケーション内でパブリックエンドポイントとしてパブリッシュされるはずのファイルはここに設置されます。
  • Schemas - （EDI スキーマのような）特定のコネクタに固有のスキーマファイルはここに設置されます。

フォルダ階層のデザイン判断

Arc のデータは透明性を保ち簡単にアクセスできる状態にしておきたいと考えているため、本アプリケーションのファイルの場所は簡単に見つけることができるようになっています。シンプルな階層を持ったフォルダ構造にすることで、ユーザーや外部システムがArc のデータファイルを見つけやすくなっています。

Arc のUI はアプリケーションを設定、使用する上で便利なインターフェースとなっていますが、他のソリューションに完全に組み込むことができるようにもしたいと考えています。Arc のフォルダ構造を理解しさえすれば、他のソリューションはArc に関連するすべてのデータを参照することができます。

オートメーション

Arc のオートメーションサービスは各コネクタのインプットフォルダ内でファイルを処理します。オートメーションサービスは0.5秒毎の「クロックティック」で実行され、メッセージは各ティック毎にフローを1ステップ進みます。

Arc は、複数スレッドを各コネクタに割り当てることで並列処理をサポートし、各スレッドはコネクタ内で複数ファイルを処理することができます。割り当てられるワーカー数とワーカー毎に処理されるファイル数は、［プロファイル］のパフォーマンス設定と各コネクタの設定で決まります。

クロックティック

事前定義された間隔（デフォルトでは500ミリ秒）で、Arc はすべての設定済みコネクタのインプットフォルダをチェックし、新しいファイルが見つかればアプリケーションがワーカースレッドを割り当てて、コネクタ設定に応じてファイルを処理します。

本アプリケーションはどのコネクタのインプットが最初に一覧化されるか保証しません。1つのコネクタのインプットフォルダに複数のファイルが存在する場合、それらのファイルは最終更新時に応じて処理されます（最も古い変更時間のファイルが最初に処理されます）。

Arc がファイルを処理しようとする際には、処理時のタイムスタンプを付加したメッセージヘッダーを追加し、これによってファイルの最終更新時が変わります。ファイルが処理に失敗した場合（エラーが起きた場合）、インプットフォルダの他のファイルに対する優先順位は最低になります。これによって1つのファイルが何度もエラーとなって即座に中止され、コネクタの操作をブロックしてしまわないようにします。

並列処理

並列処理を有効化すると、Arc は1度のクロックティック内で複数ワーカースレッドを同じコネクタに分散できます。これらワーカーの数と動作は、［設定］ページの［高度な設定］タブ内の3つの設定で決まります（その内いくつかは個々のコネクタの［高度な設定］タブから上書きできます）。

  • ワーカープール
  • コネクタ毎の最大ワーカー数
  • コネクタ毎の最大ファイル数

スレッドはラウンドロビン方式でコネクタに割り当てられるので、これらの値を調整することで（全体でも特定のコネクタでも）スループットの問題を軽減したり、コネクタがシステムリソースを占有したりしないようにしたりできます。

ワーカープールは、アプリケーションがコネクタ全体に同時に割り当て可能な全体の最大スレッド数を決定します。スレッドが特定のコネクタ内で割り当てを完了したら、プールにリサイクルされます。ホストマシンのハードウェアリソースがこの設定の上限を決定します。

コネクタあたりの最大ワーカー数は、1つのコネクタに同時に割り当て可能な最大スレッド数を決定します。コネクタに割り当てられた各スレッドはそのコネクタのインプットフォルダ内のファイルを、フォルダが空になるまで（または、次で説明するようにコネクタあたりの最大ファイル数に達するまで）1つずつ処理します。この条件に達すると、コネクタに割り当てられたスレッドは処理の完了後ワーカープールにリサイクルされます。特定のコネクタについて、コネクタの［高度な設定］からこの設定を上書きできます。

コネクタあたりの最大ファイル数は、1回のクロックティック内で1つのコネクタ内で処理されるファイル数の上限を決定します。例えば、この設定を5に指定するとコネクタに割り当てられたスレッドは、（合計で）5ファイル処理したあとに、コネクタのインプットフォルダにファイルが残っていたとしてもワーカープールにリサイクルされます。特定のコネクタについて、コネクタの［高度な設定］からこの設定を上書きできます。

パフォーマンスの最大化

コネクタあたりの最大ワーカー数とコネクタあたりの最大ファイル数の設定は、あるコネクタが他のものより多い、または少ないリソースを必要とする際に、それに応じて各コネクタ内で調整することでArc のパフォーマンスを最大化するのに役立ちます。

特定のコネクタのコネクタあたりの最大ワーカー数を増やすと、アプリケーションはそのコネクタのインプットファイルの処理により多くのシステムリソースを割り当てます。特定のコネクタがフローのスループットのボトルネックになっている際には有効です。しかし、スレッドはラウンドロビン方式で割り当てられるため、多くのコネクタでこの設定を増やすとアプリケーションがワーカープール内のスレッドを使い尽くしてしまう可能性があります。その場合、残ったコネクタにスレッドを割り当てるには、アプリケーションは他のスレッドが完了するまで待たなくてはなりません。

特定のコネクタのコネクタあたりの最大ワーカー数を下げることで、ファイルの処理中にコネクタがワーカープールを大きく圧迫するのを避けることができます。これは、ラウンドロビンでの割り当て中にアプリケーションがスレッドを使い尽くしてしまうのを避けるのに役立ちます。しかし、コネクタのインプットフォルダに大量のファイルがある場合、スレッド数が小さいとファイルの処理を完了してプールにリサイクルするまでに時間がかかるかもしれません（次に説明するように、コネクタあたりの最大ファイル数も調整されていない場合）。

特定のコネクタのコネクタあたりの最大ファイル数を上げることで、複数回クロックティックしてもファイルがコネクタのインプットフォルダに残ったままにならないようにします。これによって大量の処理を行う必要があるコネクタのスループットを向上できますが、コネクタに割り当てられたスレッドが長時間ワーカープールにリサイクルされない（そのためスレッド不足を引き起こす）可能性も上昇します。

特定のコネクタのコネクタあたりの最大ファイル数を下げることで、そのコネクタに割り当てられたスレッドが時間どおりにプールにリサイクルされます。しかし、インプットフォルダ内のファイル数がティック毎の最大処理数を超えた場合、ファイルが1回のクロックティック内で処理されない可能性もあります。

パフォーマンスの最大化は特定の環境やユースケースに依存します。一般的には、大量のファイルを処理、送信する必要があるコネクタにはより多くのワーカーを割り当て、ワーカーがリサイクル前により多くのファイルを処理できるようにするとよいでしょう。スレッドプールを枯渇させないためには、他のコネクタに割り当てるワーカーと、ワーカーが処理するファイルを減らすのがよいでしょう。

受信オートメーション

Arc 内では上記のインプットファイルの自動処理は「送信」オートメーションと呼ばれます。Arc は「受信」オートメーションもサポートしており、これはコネクタがスケジュールされた間隔に従って、Arc のフローに自動でファイルを入れていく処理を記述します。

受信操作は次の2つのカテゴリに分けられます。

  • リモートホストまたはサーバー（FTP、SFTP、S3、etc）からファイルをダウンロード
  • バックエンドシステム（データベース、ERP システム、CRM、etc）からデータを取得してXML として書き込み

受信オートメーションは、コネクタが外部システムからファイルをダウンロード、またはデータを取得する試行の回数を決定するためのスケジュールされた間隔と常に紐付けられています。

各クロックティックで、オートメーションサービスは受信間隔を経過したコネクタがないか調べます。経過したコネクタはすぐに外部接続を確立し、コネクタの設定に従ってデータを取得します。

AS2 コネクタのような一部のコネクタは次に受信するデータを受動的にリッスンします。こうしたコネクタは能動的にデータを外部システムから取得することができないので、受信オートメーションをサポートしません。

このドキュメントの活用方法

Arc を使い始めるのに、基盤となるアーキテクチャを完全に理解する必要はありません。しかし、アプリケーションを構成するさまざまなレイヤーを理解していくことには重要なメリットがあります。

  • Arc のアプローチが技術的な要件を満たすかどうかを評価する
  • より深い理解と設定能力でアプリケーションを操作、設定する
  • より大規模なデータ処理ソリューションにArc を組み込む方法を理解する

CData Arc の技術的特性の評価

Arc はメッセージ駆動型の統合フレームワークを軽量で実装します。その基板を理解することで、エンジニアの方はArc のアプローチがビジネス上のニーズを満たすかどうか決定できます。

デザイン上の原則は本アプリケーションの成長と発展を形作るものですので、このドキュメントを読むことで、Arc のデザイン上の決定を導く原則が明確になることを願っています。アプリケーションデザインの裏にある”why” を理解することで、本アプリケーションがユーザーの皆さんにとって適切なものかどうか判断を下すのに役立つことと思います。

より高度なCData Arc の操作

Arc のWeb UI はアプリケーションを操作、設定する上で使いやすいインターフェースとなっています。その基盤となっているアーキテクチャをよりよく理解することで、ユーザーの皆さんは次の例のように、内部の仕組みにまで踏み込んだより高度な操作を実行できるでしょう。

  • Arc のファイルやフォルダを直接変更する、スクリプトを使った管理プロセスを作成。
  • Arc のファイルとフォルダをバージョン管理システムに追加してバックアップとスナップショットを保持。
  • ユーザーアクセスをより細かく管理するために特定のフォルダに権限を設定。

さらにフローやコネクタ、そしてこうした機能のアプリケーションデータとの関係を理解することで、最適なワークフローを素早く簡単に設定することができます。CData では、ユーザーの皆さんが最小限の設定コストでArc の機能を利用できるよう努めています。

より大規模なソリューションにCData Arc を組み込む

Arc のフォルダ構造を理解すれば、Arc を別のデータ処理システムに組み込むのは簡単です。Arc は明確に定義された一連のディスク上のフォルダを介してシステムとやり取りするので、特定のフォルダに読み書きするアプリケーションはスムーズにArc にデータを渡したり、Arc からデータを取得することができます。

CData Arc に親しむ

最後に、弊社ではエンジニアの皆さんが、使用するシステムの基盤となっている仕組みを理解したいという共通の願望を持っていると考えています。上記のメリットがどれもお客様の特定の状況に当てはまらなかったとしても、このドキュメントを読むことでユーザーの皆さんが、Arc を使ったデータ連携ワークフローの構築に、より親しみをもって取り組んでいただけることを願います。