> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arc.cdata.com/llms.txt
> Use this file to discover all available pages before exploring further.
# アーキテクチャ
> CData Arc のメッセージ駆動型統合プラットフォームのデザイン原則、コアとなるコンセプト、実装の詳細。
export const companyName = "CData";
export const siteNameShort = "Arc";
export const siteName = "CData Arc";
{siteName} は、ビジネスプロセスを統合するメッセージ駆動型のプラットフォームです。アプリケーション、データベース、外部メッセージシステムが互いにやり取りできるコミュニケーションハブを提供します。
## デザイン原則と実装
{siteNameShort} のアーキテクチャは、一連のコアとなるデザイン原則に則って決定されています。このセクションでは、{siteNameShort} のデザインの3つの側面に着目します：
* {companyName} が重視する原則と価値
* {siteNameShort} の高度な理解に必要なコアとなるコンセプト
* アーキテクチャ上の判断と、その判断がデザイン原則をどう反映しているか
[コアとなる原則](#コアとなる原則)および[コンセプト](#コンセプト)セクションは、技術的な知識を持ったユーザーと一般のユーザー、両方に向けたものになっています。残りの実装のセクションは、エンジニアに{siteNameShort} のアーキテクチャを活用する方法を理解してもらうためのものです。
### コアとなる原則
次の図は、{siteNameShort} デザインの基本原則を示しています：
連携プラットフォームで上記のデザイン原則を実装する方法は、{siteNameShort} のアーキテクチャ以外にも存在します。次に実装のアイデアと、それがどのようにデザイン原則を反映するかを説明します。
## コンセプト
大枠では、{siteNameShort} の実装は3つの要素から構成されます：
* フロー
* コネクタ
* メッセージ
次の図は、これらの要素間の関係を示しています：
### フロー
{siteNameShort} [フロー](../flows)は、一連の自動化されたデータ処理タスクを実行する設定済みのワークフローです。フローは複数のコネクタによって構成され、1つのコネクタが処理したデータが自動的にフロー内の次のコネクタに渡されるよう接続されます。
UI では、フローは**フロー**ページのワークスペースに保持されます。コネクタを空のキャンバスに追加し、設定したり相互に接続することができます。次の画像は、AS2 とFile の2つのコネクタから構成される簡単なフローを示します。
コネクタ間の青い矢印は、AS2 コネクタが受け取ったデータが自動的にFile コネクタに渡されることを示します。コネクタの右側にある青い点を別のコネクタの左側にドラッグすると、この関係が構成されます。
フロー内の一連のコネクタはデータ処理の論理的な手順を構成するため、特定のビジネスタスクを達成できるようフローをデザインしてください。タスクとしては単なるファイルのダウンロードから、受信したビジネス文書に基づいて複数のバックエンドアプリケーションを同期することまで、さまざまな複雑度のものがあり得ます。
異なるタスクを達成するために{siteNameShort} 内で複数のフローを設定することもできます。フローは、青いフローの矢印で明示的に接続されていなければ、互いに独立して動作します。
### コネクタ
[コネクタ](../connectors)はフローの個別の部品で、アプリケーションデータおよびメッセージに影響します。各コネクタはメッセージに特定の操作を実行し、フロー内の次のコネクタ、または外部パーティ（FTP 同期先など）に渡します。
操作は主に3つのカテゴリに分けられます：トリガー、変換、およびターミナル。
* トリガーコネクタは、**受信オートメーション**がファイルを取得または作成することによって、またはパッシブ受信をサポートするコネクタの場合は、コネクタが外部クライアントからファイルを受信することによってフローを開始します。[AS2](../connectors/as2)、[Email Receive](../connectors/email-receive)、[SFTP](../connectors/sftp) が例として挙げられます。
* 変換コネクタは、フローの途中に存在するコネクタで、メッセージに対して作業を実行する（何らかの方法でメッセージを変更する）役割を担います。[X12](../connectors/x12)、[XML Map](../connectors/xml-map/xml-map)、[CSV](../connectors/csv) が例として挙げられます。
* ターミナルコネクタは、フローの終端です。{siteNameShort} がメッセージを基底のディスクに渡すか、またはメッセージが送信アクション中にコネクタによって消費され、アウトプットは生成されません。[File](../connectors/file)、[MySQL](../connectors/mysql/mysql)、またはUpsert 用に構成された任意のデータベースコネクタが例として挙げられます。
コネクタが上の操作を実行するときには、コネクタは*トランザクション*を処理していることになります。
**フロー**ページのワークスペースで、キャンバスにコネクタを追加すると、その構成設定パネルが開きます：
コネクタは、種類（AS2、SQL Server、XML など）に応じて異なる設定を持ちます。
AS2 やSFTP などの一部のコネクタは、外部パーティまたはサーバーからデータを受け取るか、外部パーティまたはサーバーにデータを送信します（あるいはその両方を行います）。これらのコネクタは通常、データがアプリケーションに入力されたり出力される、フローの起点または終点にあります。
XML Map やX12 などの他のコネクタは、アプリケーション内でローカルにデータを処理します。これらのコネクタは、（外部データソース以外の）他のコネクタからのみデータの受信が可能で、（外部デスティネーション以外の）他のコネクタにのみデータを送信できるため、通常はフローの中間に組み込まれています。
### メッセージ
フロー内のコネクタ間でデータをやりとりする際には、メッセージとしてやりとりされます。メッセージは主に、ファイルペイロードデータ（{siteNameShort} が処理しているデータ）とメタデータ（{siteNameShort} がアプリケーションを通過するデータのフローを追跡するために使用する情報）で構成されています。
メッセージについては、[メッセージの実装](#メッセージの実装)でより詳細に説明されていますが、メッセージは標準RFC822（インターネットメッセージ）形式のファイルである、というのが概要となります。コネクタがデータをフロー内の他のコネクタに渡すと、次の図に示すように、渡されたコネクタはデータをファイルに書き込み、ファイルを次のコネクタに渡します。
フローの各ステップで、メッセージ（ファイル）はアプリケーション側に受信、またはダウンロードされ（トリガーコネクタを使用）、アプリケーション内でローカルに変換されて（変換コネクタを使用）、アプリケーションから送信、またはアップロードされます（ターミナルコネクタを使用）。これらの各操作を*トランザクション*と呼びます。
{siteNameShort} は透明性の高いシステムです。ファイルシステムを参照したり、メッセージがあるフォルダから別のフォルダへコピーされるのを確認したり、またはメッセージ内容を通常のテキストエディタなどのツールを使って表示することで、プラットフォーム内の動作を理解できます。
## 実装の概要
このセクションでは、先に定義したコアとなるコンセプト（[フロー](#フロー)、[コネクタ](#コネクタ)、および[メッセージ](#メッセージ)）の、{siteNameShort} の実装に関する技術的な詳細と、この実装がどのように{companyName} の[デザイン原則](#コアとなる原則)を満たすのかを説明します。
#### ファイルベースのアーキテクチャ
{siteNameShort} はファイルシステム上のファイルにすべてのデータを保存します。そのため、アプリケーションに関わるすべてがディスク上に残ります。次に例を示します：
* アプリケーションデータ（メッセージ）
* 設定データ（[プロファイル](./administration/profiles) とフロー）
* ログ（詳しくは、[アクティビティ](./administration/activity)を参照）
設定済みフロー内のコネクタは、**トランザクション**タブからファイル（メッセージ）を読み書きします。データが1つのコネクタから別のコネクタにデータを渡す際には、これらのメッセージファイルは最初のコネクタのReceive フォルダから、次のコネクタのSend フォルダに移動されます。
{siteNameShort} はこうしたファイルシステムベースの構造にWeb UI を提供し、フローの簡単な構築、設定を実現します。設定を管理するには、{siteNameShort} の[管理API](../admin-api)とUI の使用を推奨します。これらの方法はディスク上の設定ファイルを直接変更します。ファイルベースのアーキテクチャにより、{siteNameShort} をInfrastructure as Code（IaC）ツールやGit などのバージョン管理システムと統合するのも容易です。Git を{siteNameShort} と統合する方法の詳細については、{siteName} の構成をGit でバージョン管理する方法を参照してください。
## メッセージの実装
{siteNameShort} のメッセージはアプリケーションが処理した生データを含む、ディスク上のファイルです。メッセージは2つの部分に分けられます：
* ボディ：アプリケーションデータのペイロード
* ヘッダー：メッセージのメタデータ
ヘッダーとボディの組み合わせは、RFC2822に準拠した`.eml` 拡張子のファイルに保存されます。このファイルは、標準的なテキストエディタやメールクライアントで開くことが可能です。ヘッダーは`name: value` ヘッダーを`改行` 文字で区切ったリストであり、ボディは2つの`改行` 文字でヘッダーと区別されます。
{siteNameShort} を安定して動作させるために、アプリケーションの実行中はこれらのファイルに直接アクセスしないでください。外部プログラムがこれらのファイルをロックすると、パフォーマンスと信頼性の問題が発生する可能性があります。
### メッセージボディ
メッセージボディやペイロードは、アプリケーションによって処理される実際のファイルデータです。これは、リモートソースから受信されるデータで、変換コネクタなどで操作されます。メッセージヘッダーは主に{siteNameShort} がメッセージを追跡するために使用されますが、メッセージペイロードにはユーザーが主に関心を持つデータが含まれています。
データを受信すると、{siteNameShort} はメッセージを生成して（新規メッセージをディスクに書き込んで）、受信中のデータをメッセージのボディに使用します。例えば、SFTP コネクタがリモートサーバーからファイルをダウンロードすると、リモートファイルの内容が新規メッセージのボディとなります。
データがアプリケーション内でローカルに処理される際には（例えば、EDI がXML に変換されたり、ファイルが新しい形式にマッピングされるなど）、操作を実行中のコネクタがインプットメッセージのボディを読み込み、メモリ内でデータを処理して、アウトプットメッセージのボディに結果を書き込みます。
アプリケーションがデータを送信する際には（例えば、リモートサーバーにファイルをアップロードしたり、ピアにファイルを送る、データベースに挿入するなど）、インプットメッセージのボディだけが送信されます。
### メッセージヘッダー
メッセージヘッダーは、{siteNameShort} がアプリケーションを通過するデータの進行状況を追跡するのに役立ちます。ヘッダーには、一意のMessageId（ファイル名が変更されても、{siteNameShort} がメッセージのライフサイクルを完全に把握するのに役立ちます）、コネクタがメッセージを処理した時のタイムスタンプ、処理中に発生した可能性のあるエラー、その他のメタデータが含まれます。
ヘッダーは、メッセージの先頭にある *headerName: headerValue* 構文で、改行で区切られて表示されます。メッセージにカーソルを合わせて**詳細を表示**をクリックすると、関連するヘッダーが表示され、メッセージファイルの内容をダウンロードできます。
メッセージヘッダーは、{siteNameShort} がフロー内で認識するのに有用なその他の値にも使用されます。例えば、リモートFTP サーバーのサブフォルダからファイルをダウンロードする際、{siteNameShort} は、このフォルダパスをローカルシステムで再作成する必要がある場合に備えて、[サブフォルダヘッダー](../connectors/ftp#subfolder-headers)を使用してメッセージへのフォルダパスを追跡します。
{siteNameShort} は生データファイルに、ファイル処理の方法に関するメタデータを付加します。次は最も頻繁に出現するヘッダーの一部です：
* フロー内でファイルを識別する一意の永続するMessageId
* 処理中のファイルのタイムスタンプ
* ファイルを処理したコネクタのConnectorId
* エラーで処理に失敗したファイルのインスタンス
本アプリケーションがメッセージヘッダーを編集、および上書きすることはありません。処理履歴がすべて保持されるよう、新規ヘッダーは常に既存のリストに追加されます。
### フロー内のメッセージ
{siteNameShort} は、アプリケーションによって処理されたデータを追跡し理解するためにメッセージヘッダーを内部的に使用しますが、メッセージが調査されない限り、これらの詳細をユーザーに非表示にします。例えば、{siteNameShort} は内部MessageId を使用してメッセージを識別しますが、**トランザクション**タブおよび**メッセージ**タブには公開ファイル名が表示されます。
メッセージのヘッダーを確認するには、メッセージにカーソルを合わせて**メッセージ詳細を表示**を選択してください。次の画像は**トランザクション**タブのメッセージを示しています。
{siteNameShort} はコネクタの内部Receive フォルダに書き込まれる際、フロー内のどの位置にあるかに関わらず、メッセージを`.eml` 形式で保存します。ただし、メッセージが外部システム（データベースやSFTP サーバーなど）に送信される場合、{siteNameShort} はファイルの内容のみをアップロードし、`.eml` ヘッダーは含みません。同様に、[File コネクタ](../connectors/file)のSend アクションを使ってファイルをディスクに書き込む場合も、外部プロセスが期待する出力に合わせるため、{siteNameShort} は`.eml` 構造を省略します。つまり、`.eml` ヘッダーは{siteNameShort} の内部ファイル形式の一部ですが、外部の送信先にデータを渡す際には含まれません。
### バッチグループとバッチメッセージ
メッセージは複数のペイロードを含むことができ、その場合は*バッチグループ*とみなされます。バッチグループ内の個々のペイロードは、次の図で示すように、*バッチメッセージ*とみなされます。
#### バッチグループ
メッセージは、バッチグループにまとめてバッチ処理することで、パフォーマンスを向上させ、大きなメッセージのグループをより管理しやすくすることができます。バッチグループは、各MIME パートが個別のバッチメッセージであるMIME 形式のファイルです。バッチグループは、基本のメッセージで使用されるのと同じヘッダースキームを使用して、バッチに関するメタデータを保持します。これらのヘッダーは、バッチの個々の部分ではなく、バッチ全体の処理を追跡します。
#### バッチメッセージ
バッチグループ内の各バッチメッセージは、アプリケーションによって処理されるファイルペイロードデータを含むMIME パートです。各バッチメッセージには、MIME パート内のペイロード（バッチグループではない）に関連するメタデータが含まれます。バッチメッセージには複数のメタデータのセットがあります。1つはバッチグループ全体を追跡するためのヘッダーセットで、もう1つはバッチ内の各メッセージ用の個別のヘッダーセットです。
### メッセージへのアクセスと閲覧
メッセージはディスク上のファイルなので、ユーザーや外部システムは現時点で{siteNameShort} パイプライン内にあるメッセージにアクセスし、閲覧することができます。外部アプリケーションを使用してメッセージにアクセスするには、ファイルシステム上のどこにメッセージ`.eml` ファイルがあるかを理解する必要があります。メッセージファイルの正確な場所については、[フォルダ階層](#フォルダ階層)を参照してください。
{siteNameShort} を安定して動作させるために、アプリケーションの実行中はメッセージファイルに直接アクセスしないでください。外部プログラムがこれらのファイルをロックすると、パフォーマンスと信頼性の問題が発生する可能性があります。
{siteNameShort} のUI や{siteNameShort} の[管理API](../admin-api)でもメッセージを確認できます。メッセージは、メッセージを処理したすべてのコネクタの**トランザクション**タブ、および[アクティビティ](./administration/activity)ページに表示されます。**詳細を表示**をクリックすると、**メッセージ情報**ページが開きます：
このパネルに表示された値はメッセージヘッダーです。**ダウンロード**ボタンをクリックするとメッセージボディにアクセスできます。**ログをダウンロード**をクリックすると、メッセージに関連する[ログ](#メッセージトラッキングとログ)をダウンロードできます。
### メッセージトラッキングとログ
メッセージには、メッセージの一意の識別子として機能するMessageId ヘッダーが含まれます。このMessageId は、ファイル自体の名前が変更されたとしても、フロー内では変化しません。そのため、フロー内でのすべてのファイルの状態はMessageId を参照することで追跡できます。ユーザーはこの値を使って、特定のトランザクションに関連したログデータを見つけることができます。
{siteNameShort} はログデータを次の2つのフォーマットで保存します：
* [アプリケーションデータベース](#アプリケーションデータベース)
* ディスク上の[Verbose ログファイル](#verbose-ログファイル)
これらのフォーマットとその関係については次で説明します。
#### アプリケーションデータベース
*アプリケーションデータベース* は、{siteNameShort} が以下の目的で使用するリレーショナルデータベースです：
* 本アプリケーションが処理した各トランザクションのメタデータを保存
* どのトランザクションにも特定的でないアプリケーションの操作のログを保存
* 特定のコネクタの状態を保存（例えば、コネクタが確認応答または受信確認を待機している場合）
{siteNameShort} はSQLite（Windows / .NET）、またはH2（Java）データベースを同梱していますが、SQL Server やPostgreSQL、MySQL などの外部データベースを使用することもできます。{siteNameShort} はアプリケーションデータベース内のすべての関連するテーブルの作成と保守を行います。
外部データベースを使用するには、アプリケーションをホストするサーバーの設定ファイルでデータベース接続文字列を設定する必要があります（[.NET 版](./installation/windows-edition)の[アプリケーションデータベースの設定](./installation/windows-edition#アプリケーションデータベースの設定)および[クロスプラットフォーム版](./installation/cross-platform-edition)の`arc.properties` ファイルの[cdataappdb](./installation/arc-properties-configuration#cdata-app-db) 設定を参照してください）。
アプリケーションデータベースには、メッセージの追跡やログの検索に使用されるテーブルがあります。これは、本アプリケーションが処理した各トランザクションのメタデータを保持し、メタデータには処理されたメッセージのMessageId が含まれます。UI の**アクティビティ**ページを使用して、メッセージログやトランザクションログを検索します。トランザクションのメタデータ（タイムスタンプ、ConnectorId、ステータスなど）は、**アクティビティ**ページで検索できます。データベースのフットプリントを最小化するため、verbose ログデータは**アクティビティ**ページには含まれず、ディスク上のログファイルに保存されます。
#### Verbose ログファイル
{siteNameShort} は、メッセージを処理するたびにMessageId と同名のログフォルダを生成します。このフォルダにはverbose ログファイルが含まれ、ログ内容はファイルを送信および受信（または送信か受信のどちらか）したコネクタの種類に依存します。例えば、AS2 コネクタはメッセージ自体を表示する`.eml` ファイルに加えて、MDN レシート、生のリクエストと応答、接続ログをログに記録します。
こうしたログファイルは、フロー内のメッセージを追跡するだけであれば不要です。アプリケーションデータベースに保存されたメタデータだけで、メッセージの追跡には十分です。ただし、デバッグの際などに特定のトランザクションの詳細がほしい場合は、メッセージのMessageId と処理したコネクタに基づいて、適切なファイルを見つける必要があります。
ユーザーはMessageId がわかっていれば適切なログフォルダに手動で移動できます。しかし、こうしたverbose ログファイルを見つけるにはアプリケーションデータベースを使用する方が便利です。詳しくは、[アプリケーションデータベースとログファイルの関係](#アプリケーションデータベースとログファイルの関係)を参照してください。
#### アプリケーションデータベースとログファイルの関係
アプリケーションデータベースに保存されたメタデータには、特定のトランザクションに関連するログファイルを見つけるのに必要なすべての情報が含まれます。{siteNameShort} のUI および[管理API](../admin-api) はこの関係を使って、すべてのトランザクションのログファイルに簡単にアクセスできるようにします。
* **アクティビティ**ページには、すべてのトランザクションメタデータが含まれています。トランザクションエントリの上にカーソルを合わせて**詳細を表示**をクリックし、関連するログファイルにアクセスします。{siteNameShort} はMessageId を使用して、ディスク上の適切なログファイルを検索しています。
* 同様に、コネクタの設定パネルの**トランザクション**タブを使えば、特定のコネクタが処理したすべてのトランザクションにアクセスできます。これらのトランザクションを展開して、verbose ログファイルを表示およびダウンロードします。
* アプリケーションデータベースは、トランザクションログファイルが保存されている適切なフォルダに手動で移動するのに役立ちます。ユーザーがトランザクションのファイル名を知っていても、内部のMessageId は知らない、ということは頻繁にあります。**アクティビティ**ページの**メッセージ**タブは検索できるので、特定のファイル名で検索すると、そのファイル名に紐付けられたトランザクションのMessageId が表示されます。MessageId とコネクタがわかっている場合のログフォルダの見つけ方については、[フォルダ階層](#フォルダ階層)を参照してください。
### メッセージ実装のデザイン判断
アプリケーションデータはユーザーと外部システムにとって透明であってほしいと考えており、そのためメッセージは不透明な内部データチャネル上ではなく、ファイルシステム上のシンプルなデータファイルを使用してやり取りする実装になっています。そのため、{siteNameShort} は処理中のデータが隠蔽されるブラックボックスではありません。これは、{siteNameShort} が、ファイルシステム上の特定のフォルダにファイルを取得したり、配置したりするあらゆるシステムに効果的に組み込むことができることを意味します。
また、特別なツールやプログラムなしでメッセージにアクセスできる方が望ましいと考えています。メッセージはRFC2822 準拠のファイルに格納されるので、どんなテキストエディタでもファイルを開くことができます。メッセージには`.eml` 拡張子が付いているため、ファイルをダブルクリックするとメッセージが開き、その内容がシステムのデフォルトのメールクライアントに表示されます。
メッセージとログが手軽に利用でき透明性を保つよう、トランザクションメタデータの検索可能なデータベースを提供しています。このデータベースはメッセージペイロードとverbose ログファイルへの直接アクセスに使用でき、しかもメモリをあまり使用しません。
## コネクタの実装
コネクタは[フロー](../flows)内の1つのステップを表します。複雑なフローは、データ処理の論理的な手順を実行するコネクタの集まりを繋ぐことで作成します。
コネクタは3種類の操作を実行します：
* データを受信してアウトプットメッセージを書き込む（SFTP 経由でリモートファイルをダウンロードするなど）
* インプットメッセージを読み込んでデータを外部パーティに送信（AS2 経由でファイルを送信するなど）
* インプットメッセージを読み込んでローカルで処理して、アウトプットメッセージを書き込む（EDI ファイルをXML に変換するなど）。
多くのコネクタは最初の2つの操作（データのリモートエンドポイントへの送受信）、または最後の操作（データをローカルで変換）のいずれかを実行できます。コネクタが実行するすべての操作は、*トランザクション* と呼ばれます。
コネクタは**トランザクション**タブからインプットおよびアウトプットメッセージを読み書きします。コネクタがフロー内で接続されると、{siteNameShort} は最初のコネクタの**トランザクション**タブからメッセージを次のコネクタの**トランザクション**フォルダに移動します。（ディスク上では、インプットフォルダはSend、アウトプットフォルダはReceive という名前になっています。）
### コネクタファイルとフォルダ
すべてのコネクタインスタンスは、ConnectorId（フロー内の表示名）という名前の単一のフォルダとしてディスク上に存在します。各コネクタフォルダには次が含まれます：
* コンフィグ設定を含む[port.cfg](#port-cfg) ファイル
* [Send](#インプットメッセージ) サブフォルダ内の送信または処理するメッセージ（インプットメッセージなど）
* [Receive](#アウトプットメッセージ) サブフォルダ内の受信済みメッセージ（アウトプットメッセージなど）
* コネクタが処理したメッセージの[ログファイル](#ログファイル)
* マップ、テンプレート、スクリプトといった[コネクタに固有のファイル](#追加の設定ファイル)
以下のセクションでは、これらのフォルダの内容がアプリケーション内でどのように機能するかを説明します。[フォルダ階層](#フォルダ階層)では、コネクタフォルダとサブフォルダの正確な場所を説明しています。
#### Port.cfg
各コネクタの`port.cfg` ファイルには、コネクタの動作を制御する設定（コネクタの**設定**タブと**高度な設定**タブに表示される設定）が含まれます。ファイルはINI フォーマットであり、コネクタの設定は`SettingName = SettingValue` 構文で1行1設定としてリスト化されています。UI でコネクタ設定を変更することは、`port.cfg` ファイルで直接設定を変更することと機能的に同等です。
`port.cfg` ファイルは *間接値* をサポートしており、設定に文字列リテラルの代わりに参照を使用することができます。これは、アプリケーションの他のセクションで変数を設定し、その変数名を`port.cfg` ファイルで参照するのと概念的に類似しています。間接値の設定方法の詳細については、[データディレクトリ](#データディレクトリ)を参照してください。
#### インプットメッセージ
**トランザクション**フォルダはインプットメッセージ、つまりコネクタが処理するためにキューに入っているメッセージを保持します。
各クロックティック（デフォルトでは0.5秒）毎に、{siteNameShort} はコネクタのSend フォルダをチェックしてワーカースレッドを利用可能なメッセージを持つすべてのコネクタに割り当てます。メッセージが処理されると、{siteNameShort} はそのメッセージに処理試行時のタイムスタンプが付いたヘッダーを付加します。
{siteNameShort} は、より古いファイルが最初に処理されるよう、インプットメッセージを最終変更時間に応じてソートします。{siteNameShort} は各試行中にヘッダーを付加するので、エラーを起こすメッセージが複数回再試行することで、コネクタを無意味にブロックしてしまうことはありません。
各クロックティックでインプットメッセージを処理するには、コネクタ内で *送信* オートメーションを有効化しておく必要があります。
#### アウトプットメッセージ
'Receive' フォルダはアウトプットメッセージ、つまりコネクタが受信、ダウンロード、および / または処理したメッセージを保持します。
コネクタによっては、インプットメッセージの処理を終えてすぐにアウトプットメッセージを書き込みます（データフォーマットを変換するコネクタなど）。インプットメッセージを読み込まずにアウトプットメッセージを書き込むコネクタもあります。例えば、リモートサーバーをポーリングしてダウンロードするファイルを探すSFTP コネクタや、受信ファイルを受動的にリッスンするAS2 コネクタが挙げられます。
コネクタがフロー内の別のコネクタに接続されている場合、アウトプットメッセージはReceive フォルダに残りません。次のコネクタのSend フォルダに渡されます。
#### ログファイル
コネクタが処理する各トランザクションは、一連のログファイルを生成します。トランザクションメタデータはログに追加され、[verbose ログ](#verbose-ログファイル)情報はディスク上にファイルとして格納されます。ログファイルには常に`.eml` フォーマットのメッセージとコネクタ固有のログが含まれます。
デフォルトでは、すべてのコネクタのログファイルは次のフォルダ構造に示すように、週単位でフォルダに整理されます：
デフォルトの週単位のフォルダ整理を変更するには、任意のコネクタの**ログサブフォルダのスキーム**フィールドを別の時間間隔（例：*日単位* や *月単位*）に設定してください。これにより、その時間間隔内に生成されたすべてのログが1つのサブフォルダに保持されます。これによって個々のサブフォルダのサイズを減らすことができ、ディスクI/O 性能の向上に繋がります。
[メッセージタブ](./administration/activity#メッセージタブ)を使用して、MessageId を検索するか**ログをダウンロード**を使用することで、適切なログフォルダを見つけることができます。
#### 追加の設定ファイル
コネクタの種類によっては、コネクタフォルダに追加の設定ファイルが含まれます。追加のファイルには次が含まれます：
* `map.json`
* `script.rsb`
* テンプレートXML ファイル
これらのファイルはマッピング関係、カスタムスクリプトの動作、コネクタのインプットとアウトプット構造を保持します。これらのファイルを手動で編集することは、関連するコネクタのUI 設定を編集することと同等です。
これらのファイルを手動で編集するのはリスクを伴う場合があります。レイアウトは理解しやすく透明性が高いですが、これらの設定ファイルを誤って変更すると意図しない結果を招く可能性があります。
### コネクタ実装のデザイン判断
フローは完全なモジュラー型を志向しており、各コネクタが予測できる直感的な方法でわかりやすい機能を提供することを目指しています。{siteNameShort} には任意のコネクタを組み合わせる機能があるため、シンプルなインターフェースでありながら複雑なタスクを実行することができます。コネクタチェーンが個別のステップに分解されているため、複雑なフローも理解しやすい状態を保てます。
コネクタに関連するすべてのデータ（設定データ、アプリケーションデータ、ログデータ、など）に簡単にアクセスできるようにしたいと考えています。すべてのデータはコネクタ固有のフォルダにあるので、フォルダの場所さえわかっていればそのフォルダにアクセスできます。設定データはメッセージデータと同様、透明性の高いINI フォーマットで格納されているため、シンプルなツールで閲覧・編集できます。
フォルダベースのアプローチでコネクタをデザインしているので、コネクタ間でどのようにデータがやり取りされるのかも容易に理解できます。メッセージファイルを移動する操作では、1つのコネクタのアウトプットを別のコネクタのインプットに移動します。{siteNameShort} にはこうしたファイル移動の関係を自動で構成する組み込みツールが含まれます。
{siteNameShort} を安定して動作させるために、アプリケーションの実行中は設定ファイルに直接アクセスしないでください。外部プログラムがこれらのファイルをロックすると、パフォーマンスと信頼性の問題が発生する可能性があります。
## フローとワークスペースの実装
[フロー](../flows)はファイルシステム上で、フローでのコネクタの位置と接続を含む`flow.json` ファイルとして表されます。このファイルの場所については、[フォルダ階層](#フォルダ階層)を参照してください。
フロー内のコネクタの位置は純粋に外観上のものであり、UI でフローを設定する際にのみ使用されます。コネクタ間の接続はデータ処理レベルで重要です。コネクタがアウトプットメッセージを書き込むと、アプリケーションエンジンに問い合わせて、そのアウトプットメッセージを別のコネクタのSend フォルダに渡す必要があるかどうかを確認します。本アプリケーションは`flow.json` ファイルを使って、（もしあれば）どのコネクタがファイルを渡されるか決定します。
同じフローキャンバスに複数のフローを設定することができ、{siteNameShort} のUI ではキャンバスをドラッグしてフロー間を移動できます。これはGoogle Maps などの地図サービスをナビゲートするのに似ています。
[ワークスペース](../flows/workspaces)はフロー間を論理的に分離します。各ワークスペースはコネクタの論理フローを設計するための新しいキャンバスとなります。Google Maps のアナロジーを拡張すると、ワークスペースは個別の *惑星* のように機能します。
トレーディングパートナーや統合ごとにワークスペースを分けるのが一般的です。ただし、新しいフローを別のワークスペースに設定するかどうかは好みの問題です。詳細については、[ワークスペースにフローを整理する](../flows/designing-a-flow#ワークスペースにフローを整理する)を参照してください。
#### ファイルシステム上のワークスペース
新しい（デフォルト以外の）ワークスペースを追加すると、{siteNameShort} はフォルダ階層に新しいフォルダセットを追加します。`workspaces` ディレクトリには、デフォルトワークスペースで設定したすべてのコネクタのコネクタフォルダが含まれます。`workspaces` フォルダは[データディレクトリ](#データディレクトリ)の兄弟です。
### フローとワークスペースのデザイン判断
{companyName} では、フロー内のコネクタ間のシンプルでモジュラーな関係を保つ最良の方法は、フローを純粋に論理的な概念として扱うことだと考えています。データ処理の効率的な連鎖を決めるために必要なすべての情報は、すでにコネクタの実装に含まれています。
ワークスペースはコネクタをより根本的なレベルで分離する機能にしたいと考えています。ワークスペースを分けることで、コネクタを保持するフォルダも分かれるため、ファイルシステムレベルの操作（権限やディレクトリリストなど）を特定のワークスペースに簡単に分離できます。
## フォルダ階層
すべての{siteNameShort} リソースはファイルシステム上で利用できるため、低レベルで{siteNameShort} を理解するには、アプリケーションのフォルダ構造と、ファイルやフォルダがディスク上でどのように整理されているかを学ぶ必要があります。
階層を理解するには、{siteNameShort} のインストール先のディレクトリ構造を知っておくのがよいでしょう。次にフォルダ構造の視覚的な表現を示します。この構造の詳細については以下のセクションで説明します。
* この階層は、フローがデフォルトのワークスペースだけで設定されていることを想定しています。追加のワークスペースの詳細については、[フローとワークスペース](#フローとワークスペースの実装)を参照してください。
* **設定 > 高度な設定**ページの[クリーンアップ設定](./administration/settings/cleanup-settings)セクションの**ローカルアーカイブフォルダ**が空の場合、各コネクタには**Archive** フォルダもあります。
### ルートインストールディレクトリ
すべての{siteNameShort} リソースはインストールディレクトリにあり、デフォルトでは以下の場所にあります：
* **Windows**：`C:\Program Files\CData\CData Arc`
* **Linux**：`/opt/arc`
Java 版のインストールについては、{companyName} はzip ファイルを提供しており、それを任意のインストールディレクトリ（例えば、`/opt/arc`）に展開することができます。
{siteNameShort} のJava 版はTomcat のような外部Java サーブレットにホストされているので、{siteNameShort} のリソースは`~/cdata/arc` に配置されます。このパスでは、`~` はJava サーブレットをホストするユーザーのホームディレクトリになります。
上記の[フォルダ階層](#フォルダ階層)では、ルートインストールディレクトリはツリーの最上部にある`Arc` フォルダです。
### データディレクトリ
`data` ディレクトリには次が含まれます：
* （デフォルトワークスペースの）[フロー](../flows)ページで設定された各コネクタのサブフォルダ
* [profile.cfg](#profile-cfg) ファイル
* [flow.json](#flow-json) ファイル
* [roles.json](#roles-json) ファイル
* [settings.json](#settings-json) ファイル
* [users.json](#users-json) ファイル
* すべての[証明書](#証明書)ファイル
#### Profile.cfg
`profile.cfg` ファイルには、設定済みローカル[プロファイル](./administration/profiles)（例えば、AS2 プロファイル）用のアプリケーション全体の設定が含まれます。このファイルはINI フォーマットであり、アプリケーションの設定は`SettingName = SettingValue` といった1行1設定の構文でリスト化されています。
`profile.cfg` の設定は、一般のアプリケーション設定用の`Application`と、各プロファイル（例えば、AS2 プロファイル設定には`AS2` セクション、ローカルSFTP サーバー設定には`SFTPServer` セクションがあります）用の専用セクションに分割されています。
UI の**プロファイル**ページでアプリケーション設定を変更することと、`profile.cfg` ファイル内で直接設定を変更するのは実質的に同じことです。
#### Flow\.json
`flow.json` ファイルには設定済みのフローの位置と各コネクタインスタンス間の関係が含まれます。**フロー**ページでコネクタを移動、再接続することと`flow.json` を直接変更するのは、実質的に同じことです。
#### Roles.json
`roles.json` ファイルにはすべてのカスタム[ユーザーロール](./administration/settings/user-roles)に関する詳細が含まれます。`roles.json` を直接編集することは、**ロール**ページでロールを追加・設定することと同じ効果があります。
#### Settings.json
`settings.json` ファイルには、アプリケーション内で値ではなく参照名を使用することで、別の箇所で参照できる設定の一覧が含まれます。これにより、セキュアな値（パスワードなど）をアプリケーションに表示しない方法で保存することができます。また、参照名を使用して、複数のインスタンスにデプロイされているフローの設定を一元化することもできます。
この統一された参照構文はUI 上で「鍵」アイコンが付いた設定でサポートされており、それをクリックすることで`settings.json` ファイルで定義された参照の一覧を閲覧できます。詳しくは、[グローバル設定Vault](./administration/settings/global-settings-vault) を参照してください。
#### Users.json
`users.json` ファイルにはすべての{siteNameShort} の[ユーザー](./administration/settings/users)に関する詳細が含まれます。`users.json` を直接編集することは、**ユーザー**ページでユーザーを追加・編集することと同じ効果があります。
#### 証明書
本アプリケーションで作成、またはアップロードされた証明書はすべて`data` ディレクトリに保存されます。通常、証明書はパブリックとプライベートの対となっており、プライベートは`.pfx`、パブリックは`.cer` と異なる拡張子となっています。アプリケーションにアップロードされた他のフォーマットの証明書はそのまま保存されます。
{siteNameShort} は、`data` ディレクトリの証明書を列挙して、UI から証明書を設定する際に利用可能なオプションを決定します。証明書ファイルを`data` ディレクトリに追加することは、UI で証明書をアップロードすることと同じ効果があります。
### コネクタフォルダ
設定済みの各コネクタインスタンス用に、`data` ディレクトリに専用のフォルダが設置されています。フォルダ名はフロー内の各コネクタのConnectorId の値（表示名）と一致します。上のフォルダ構造例では、'AS2\_Amazon' と'Database\_MySQL' の2つが設定済みコネクタです。
コネクタフォルダの内容は[コネクタファイルとフォルダ](#コネクタファイルとフォルダ)セクションで説明されています。コネクタフォルダ内のサブフォルダ構造の概要は以下のとおりです：
* Logs：コネクタが処理した各メッセージのverbose ログファイル
* Received：コネクタが受信したメッセージのログ。各メッセージはMessageId に一致する独自のフォルダを持っています
* Sent：コネクタが送信したメッセージのログ。各メッセージはMessageId に一致する独自のフォルダを持っています
* Receive：コネクタが受信または処理したメッセージ
* Send：コネクタが送信または処理すべきメッセージ
* Sent：処理に成功したメッセージのコピー（生データファイル形式）。非推奨の**Sent フォルダに保存**設定が有効な場合のみ存在します。
コネクタの種類によっては、他のサブフォルダを持つ場合があります：
* Pending：他のパーティからの確認応答を待っている処理済みのメッセージ
* Public：アプリケーションでパブリックエンドポイントとしてパブリッシュされるべきファイル
* Schemas：特定のコネクタに固有の（EDI スキーマのような）スキーマファイル
* Templates：コネクタのインプット、アウトプットデータのXML 表示
### フォルダ階層のデザイン判断
{siteNameShort} のデータは透明性を保ち簡単にアクセスできる状態にしておきたいと考えているため、本アプリケーションの特定のファイルは簡単に見つけられるようになっています。シンプルな階層を持ったフォルダ構造にすることで、ユーザーや外部システムが{siteNameShort} のデータファイルを見つけやすくなっています。
{siteNameShort} のUI はアプリケーションを設定、使用する上で便利なインターフェースとなっていますが、他のソリューションに完全に組み込むことができるようにもしたいと考えています。{siteNameShort} のフォルダ構造を理解しさえすれば、他のソリューションは{siteNameShort} に関連するすべてのデータを参照することができます。
## オートメーション
{siteNameShort} のオートメーションサービスは各コネクタの**トランザクション**フォルダ内でファイルを処理します。オートメーションサービスは0.5秒毎の *クロックティック* で実行され、メッセージは各ティック毎にフローを1ステップ進みます。
{siteNameShort} は、複数スレッドを各コネクタに割り当てることで並列処理をサポートし、各スレッドはコネクタで複数ファイルを処理することができます。割り当てられるワーカー数とワーカー毎に処理されるファイル数は、[プロファイル](./administration/profiles)のパフォーマンス設定と各コネクタの設定で決まります。
### クロックティック
事前定義された間隔（デフォルトでは500ミリ秒）で、{siteNameShort} はすべての設定済みコネクタのSend フォルダをチェックし、新しいファイルが見つかればワーカースレッドを割り当てて、コネクタ設定に応じてファイルを処理します。
本アプリケーションはどのコネクタのインプットが最初に一覧化されるか保証しません。複数のファイルが単一コネクタのSend フォルダに存在する場合、それらは最終更新時に応じて処理されます（最も古い変更時間のファイルが最初に処理されます）。
{siteNameShort} がファイルを処理しようとする際には、処理時のタイムスタンプを付加したメッセージヘッダーを追加し、これによってファイルの最終更新時が変わります。ファイルが処理に失敗した場合（エラーが起きた場合）、Send フォルダの他のファイルに対する優先順位は最低になります。これによって1つのファイルが何度もエラーとなって即座に中止され、コネクタの操作をブロックしてしまわないようにします。
### 並列処理
並列処理を有効化すると、{siteNameShort} は1度のクロックティック内で複数ワーカースレッドを同じコネクタに分散できます。これらワーカーの数と動作は、**設定**ページの**高度な設定**タブ内の3つの設定で決まります（その内いくつかは個々のコネクタの**高度な設定**タブから上書きできます）：
* **ワーカープール**：アプリケーションがコネクタ全体に同時に割り当て可能な全体の最大スレッド数を決定します。スレッドが特定のコネクタ内で割り当てを完了したら、プールにリサイクルされます。ホストマシンのハードウェアリソースがこの設定の上限を決定します。
* **コネクタあたりの最大ワーカー数**：1つのコネクタに同時に割り当て可能な最大スレッド数を決定します。コネクタに割り当てられた各スレッドはそのコネクタのSend フォルダ内のファイルを、フォルダが空になるまで（または**コネクタあたりの最大ファイル数**に達するまで）1つずつ処理します。この条件に達すると、コネクタに割り当てられたスレッドは処理の完了後ワーカープールにリサイクルされます。この設定は個々のコネクタの**高度な設定**タブで上書きできます。
* **コネクタあたりの最大ファイル数**：1回のクロックティック内で1つのコネクタ内で処理されるファイル数の上限を決定します。例えば、この設定を5に指定すると、コネクタのSend フォルダにまだファイルが残っていても、コネクタに割り当てられたスレッドは（合計で）5ファイル処理したあとにワーカープールにリサイクルされます。この設定は個々のコネクタの**高度な設定**タブで上書きできます。これを0に設定すると、コネクタはスレッドが割り当てられた時点でコネクタに存在するすべてのファイルを処理しようと試みます。
スレッドはラウンドロビン方式でコネクタに割り当てられるので、これらの値を調整することで（全体でも特定のコネクタでも）スループットの問題を軽減したり、コネクタがシステムリソースを占有したりしないようにしたりできます。次の図は、並列処理設定がどのように連携して機能するかを示しています。
#### パフォーマンスの最大化
**コネクタあたりの最大ワーカー数**と**コネクタあたりの最大ファイル数**の設定は、あるコネクタが他のものより多い、または少ないリソースを必要とする際に、それに応じて各コネクタで調整することで{siteNameShort} のパフォーマンスを最大化するのに役立ちます。
特定のコネクタの**コネクタあたりの最大ワーカー数**を増やすと、アプリケーションはそのコネクタのインプットファイルの処理により多くのシステムリソースを割り当てます。特定のコネクタがフローのスループットのボトルネックになっている際には有効です。しかし、スレッドはラウンドロビン方式で割り当てられるため、多くのコネクタでこの設定を増やすとアプリケーションが**ワーカープール**内のスレッドを使い尽くしてしまう可能性があります。その場合、残ったコネクタにスレッドを割り当てるには、アプリケーションは他のスレッドが完了するまで待たなくてはなりません。
特定のコネクタの**コネクタあたりの最大ワーカー数**を下げることで、ファイルの処理中にコネクタがワーカープールを大きく圧迫するのを避けることができます。これは、ラウンドロビンでの割り当て中にアプリケーションがスレッドを使い尽くしてしまうのを避けるのに役立ちます。しかし、コネクタのSend フォルダに大量のファイルがある場合、スレッド数が小さいとファイルの処理を完了してプールにリサイクルするまでに時間がかかることがあります（次に説明するように、**コネクタあたりの最大ファイル数**も調整されていない場合）。
特定のコネクタの**コネクタあたりの最大ファイル数**を上げる（または`0` に設定してすべてのファイルを処理する）ことで、複数回クロックティックしてもファイルがコネクタのSend フォルダに残ったままにならないようにすることができます。これは、大容量コネクタのスループットを向上させるのに役立ちます。ただし、これによってコネクタに割り当てられたスレッドが長時間ワーカープールにリサイクルされない（これにより、スレッド不足を引き起こす）可能性も上昇します。
特定のコネクタの**コネクタあたりの最大ファイル数**を下げることで、そのコネクタに割り当てられたスレッドが時間どおりにプールにリサイクルされます。しかし、Send フォルダ内のファイル数がティック毎の最大処理数を超えた場合、ファイルが1回のクロックティック内で処理されない可能性もあります。
パフォーマンスの最大化は、特定の環境やユースケースに依存します。一般的には、大量のファイルを処理または送信する必要があるコネクタにはより多くのワーカーを割り当て、ワーカーがリサイクル前により多くのファイルを処理できるようにするとよいでしょう。スレッドプールを枯渇させないためには、他のコネクタに割り当てるワーカーと、ワーカーが処理するファイルを減らすのがよいでしょう。
### 受信オートメーション
{siteNameShort} では、上記のインプットファイルの自動処理は\_送信\_ オートメーションと呼ばれます。{siteNameShort} は *受信* オートメーションもサポートしており、これはコネクタがスケジュールされた間隔に従って、{siteNameShort} のフローに自動でファイルを入れていく処理を記述します。
受信操作は次の2つのカテゴリに分けられます：
* リモートホストまたはサーバー（FTP、SFTP、S3 など）からファイルをダウンロード
* バックエンドシステム（データベース、ERP システム、CRM など）からデータを取得してXML として書き込み
受信オートメーションは、コネクタが外部システムからファイルをダウンロード、またはデータを取得する試行の回数を決定するためのスケジュールされた間隔と常に紐付けられています。
各クロックティックで、オートメーションサービスは受信間隔を経過したコネクタがないか調べます。ある場合、経過したコネクタはすぐに外部接続を確立し、コネクタの設定に従ってデータを取得します。
AS2 コネクタのような一部のコネクタは、受信データを受動的にリッスンします。こうしたコネクタは能動的にデータを外部システムから取得することができないので、受信オートメーションをサポートしません。
## このドキュメントの活用方法
{siteNameShort} を使い始めるのに、基盤となるアーキテクチャを完全に理解する必要はありません。しかし、アプリケーションを構成するさまざまなレイヤーを理解していくことには重要なメリットがあります：
* {siteNameShort} のアプローチが技術的な要件を満たすかどうかを[評価](#arc-の技術的特性の評価)する
* より深い理解と制御でアプリケーションを[操作](#より高度なarc-の操作)、設定する
* より大規模なデータ処理ソリューションに{siteNameShort} を[組み込む](#より大規模なソリューションにarc-を組み込む)方法を理解する
#### Arc の技術的特性の評価
{siteNameShort} はメッセージ駆動型の統合フレームワークを軽量で実装します。その基盤を理解することで、エンジニアの方は{siteNameShort} のアプローチがビジネス上のニーズを満たすかどうか決定できます。
デザイン上の原則は本アプリケーションの成長と発展を形作るものですので、このドキュメントを読むことで、{siteNameShort} のデザイン上の決定を導く原則が明確になることを願っています。アプリケーションデザインの裏にある *why* を理解することで、本アプリケーションがユーザーの皆さんにとって適切なものかどうか判断を下すのに役立つことと思います。
#### より高度なArc の操作
{siteNameShort} のUI はアプリケーションを操作、設定する上で使いやすいインターフェースとなっています。その基盤となっているアーキテクチャをより深く理解することで、ユーザーの皆さんは、特定のフォルダーに対する権限を設定してユーザーアクセスを細かく制御するなど、*内部の仕組み* にまで踏み込んだより高度な操作を実行できるでしょう：
さらにフローやコネクタ、そしてこうした機能のアプリケーションデータとの関係を理解することで、最適なワークフローを素早く簡単に設定することができます。{companyName} では、ユーザーの皆さんが最小限の設定コストで{siteNameShort} の機能を利用できるよう努めています。
#### より大規模なソリューションにArc を組み込む
{siteNameShort} のフォルダ構造を理解すれば、{siteNameShort} を別のデータ処理システムに組み込むのは簡単です。{siteNameShort} は明確に定義された一連のディスク上のフォルダを介してシステムとやり取りするので、特定のフォルダに読み書きするアプリケーションはスムーズに{siteNameShort} にデータを渡したり、{siteNameShort} からデータを取得することができます。{companyName} では、外部システムとの連携には[File コネクタ](../connectors/file)の使用を推奨しています。設定の詳細については、[ローカルファイルシステムとのやり取り](../flows/designing-a-flow#ローカルファイルシステムとのやり取り)を参照してください。
#### Arc に親しむ
最後に、弊社ではエンジニアの皆さんが、使用するシステムの基盤となっている仕組みを理解したいという共通の願いを持っていると信じています。上記のメリットがどれもお客様の実装に当てはまらない場合でも、このドキュメントが{siteNameShort} を使用して独自のデータ統合ワークフローを構築する際に、さらなる安心感と親しみやすさをもたらす一助となれば幸いです。このドキュメントの内容についてご不明な点がある場合、またはさらなるサポートが必要な場合は、専任のサポートチーム（**[sales@cdata.co.jp](mailto:sales@cdata.co.jp)**）までお気軽にご連絡ください。