Search

アーキテクチャ

Version 25.3.9469

アーキテクチャ

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

デザイン原則と実装

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

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

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

コアとなる原則

次の図は、Arc デザインの基本原則を示しています：

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

コンセプト

大枠では、Arc の実装は3つの要素から構成されます：

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

The following diagram illustrates the relationships between these elements:

フロー

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

UI では、フローはフローページのワークスペースに保持されます。コネクタを空のキャンバスに追加し、設定したり相互に接続することができます。次の画像は、AS2 とFile の2つのコネクタから構成される簡単なフローを示します。

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

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

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

コネクタ

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

操作は主に3つのカテゴリに分けられます：トリガー、変換、およびターミナル。

  • トリガーコネクタは、受信オートメーションがファイルを取得または作成することによって、またはパッシブ受信をサポートするコネクタの場合は、コネクタが外部クライアントからファイルを受信することによってフローを開始します。AS2、Email Receive、SFTP が例として挙げられます。
  • 変換コネクタは、フローの途中に存在するコネクタで、メッセージに対して作業を実行する（何らかの方法でメッセージを変更する）役割を担います。X12、XML Map、CSV が例として挙げられます。
  • ターミナルコネクタは、フローの終端です。Arc がメッセージを基底のディスクに渡すか、またはメッセージが送信アクション中にコネクタによって消費され、アウトプットは生成されません。File、MySQL、またはUpsert 用に構成された任意のデータベースコネクタが例として挙げられます。

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

フローページのワークスペースで、キャンバスにコネクタを追加すると、その構成設定パネルが開きます：

コネクタは、種類（AS2、SQL Server、XML など）に応じて異なる設定を持ちます。

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

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

メッセージ

フロー内のコネクタ間でデータをやりとりする際には、メッセージとしてやりとりされます。メッセージは主に、ファイルペイロードデータ（Arc が処理しているデータ）とメタデータ（Arc がアプリケーションを通過するデータのフローを追跡するために使用する情報）で構成されています。

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

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

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

実装の概要

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

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

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

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

Arc はこうしたファイルシステムベースの構造にWeb UI を提供し、フローの簡単な構築、設定を実現します。 Arc’s Admin API and UI are the recommended methods for managing configurations.These methods make direct modifications to the configuration files on disk.The file-based architecture also makes it easy to integrate Arc with Infrastructure as Code (IaC) tools and version control systems like Git.For more details on how to integrate Git with Arc, see Using Git with CData Arc.

メッセージの実装

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

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

ヘッダーとボディの組み合わせは、RFC2822に準拠した.eml 拡張子のファイルに保存されます。このファイルは、標準的なテキストエディタやメールクライアントで開くことが可能です。ヘッダーはname: value ヘッダーを改行 文字で区切ったリストであり、ボディは2つの改行 文字でヘッダーと区別されます。

Important: To ensure that Arc performs reliably, do not interact directly with these files while the application is running. External programs placing locks on these files can cause performance and reliability issues.

メッセージボディ

メッセージボディやペイロードは、アプリケーションによって処理される実際のファイルデータです。これは、リモートソースから受信されるデータで、変換コネクタなどで操作されます。メッセージヘッダーは主にArc がメッセージを追跡するために使用されますが、メッセージペイロードにはユーザーが主に関心を持つデータが含まれています。

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

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

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

メッセージヘッダー

メッセージヘッダーは、Arc がアプリケーションを通過するデータの進行状況を追跡するのに役立ちます。ヘッダーには、一意のMessageId（ファイル名が変更されても、Arc がメッセージのライフサイクルを完全に把握するのに役立ちます）、コネクタがメッセージを処理した時のタイムスタンプ、処理中に発生した可能性のあるエラー、その他のメタデータが含まれます。

ヘッダーは、メッセージの先頭にある headerName: headerValue 構文で、改行で区切られて表示されます。メッセージにカーソルを合わせて詳細を表示をクリックすると、関連するヘッダーが表示され、メッセージファイルの内容をダウンロードできます。

メッセージヘッダーは、Arc がフロー内で認識するのに有用なその他の値にも使用されます。例えば、リモートFTP サーバーのサブフォルダからファイルをダウンロードする際、Arc は、このフォルダパスをローカルシステムで再作成する必要がある場合に備えて、サブフォルダヘッダーを使用してメッセージへのフォルダパスを追跡します。

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

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

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

フロー内のメッセージ

Arc は、アプリケーションによって処理されたデータを追跡し理解するためにメッセージヘッダーを内部的に使用しますが、メッセージが調査されない限り、これらの詳細をユーザーに非表示にします。例えば、Arc は内部MessageId を使用してメッセージを識別しますが、インプット、アウトプット、トランザクションタブ、およびメッセージタブには公開ファイル名が表示されます。

To examine the headers on a message, hover over the message and choose View Message Details. The following image shows messages on the Transactions tab.

Arc stores messages in the .eml format when they are written to a connector’s internal Receive folder, regardless of where the message is in the flow. However, when messages are sent to an external system (for example, a database or an SFTP server), Arc only uploads the file content and does not include the .eml headers. Similarly, when writing files to disk using the File connector’s Send action, Arc omits the .eml structure so that the output matches what external processes expect. In other words, .eml headers are part of Arc’s internal file format but are not included when delivering data to external destinations.

バッチグループとバッチメッセージ

メッセージは複数のペイロードを含むことができ、その場合はバッチグループとみなされます。バッチグループ内の個々のペイロードは、次の図で示すように、バッチメッセージとみなされます。

バッチグループ

メッセージは、バッチグループにまとめてバッチ処理することで、パフォーマンスを向上させ、大きなメッセージのグループをより管理しやすくすることができます。バッチグループは、各MIME パートが個別のバッチメッセージであるMIME 形式のファイルです。バッチグループは、基本のメッセージで使用されるのと同じヘッダースキームを使用して、バッチに関するメタデータを保持します。これらのヘッダーは、バッチの個々の部分ではなく、バッチ全体の処理を追跡します。

バッチメッセージ

バッチグループ内の各バッチメッセージは、アプリケーションによって処理されるファイルペイロードデータを含むMIME パートです。各バッチメッセージには、MIME パート内のペイロード（バッチグループではない）に関連するメタデータが含まれます。バッチメッセージには複数のメタデータのセットがあります。1つはバッチグループ全体を追跡するためのヘッダーセットで、もう1つはバッチ内の各メッセージ用の個別のヘッダーセットです。

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

メッセージはディスク上のファイルなので、ユーザーや外部システムは現時点でArc パイプライン内にあるメッセージにアクセスし、閲覧することができます。外部アプリケーションを使用してメッセージにアクセスするには、ファイルシステム上のどこにメッセージ.eml ファイルがあるかを理解する必要があります。See Folder Hierarchy to learn the exact location of the message files.

Important: To ensure that Arc performs reliably, do not interact directly with messsage files while the application is running. External programs placing locks on these files can cause performance and reliability issues.

You can also see messages in the Arc UI and the Arc Admin API.メッセージは、メッセージを処理したすべてのコネクタのインプットタブ、アウトプットタブ、またはトランザクションタブ、およびアクティビティページに表示されます。Click View Details to open the Message Information page:

このパネルに表示された値はメッセージヘッダーです。Click the Download button to access the message body.Click Download Logs to download the logs associated with a message.

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

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

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

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

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

アプリケーションデータベース は、Arc が以下の目的で使用するリレーショナルデータベースです：

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

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

外部データベースを使用するには、アプリケーションをホストするサーバーの設定ファイルでデータベース接続文字列を設定する必要があります（.NET 版のアプリケーションデータベースの設定およびクロスプラットフォーム版のarc.properties ファイルのcdataappdb 設定を参照してください）。

アプリケーションデータベースには、メッセージの追跡やログの検索に使用されるテーブルがあります。これは、本アプリケーションが処理した各トランザクションのメタデータを保持し、メタデータには処理されたメッセージのMessageId が含まれます。UI のアクティビティページを使用して、メッセージログやトランザクションログを検索します。トランザクションのメタデータ（タイムスタンプ、ConnectorId、ステータスなど）は、アクティビティページで検索できます。データベースのフットプリントを最小化するため、verbose ログデータはアクティビティページには含まれず、ディスク上のログファイルに保存されます。

Verbose ログファイル

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

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

ユーザーはMessageId がわかっていれば適切なログフォルダに手動で移動できます。しかし、こうしたverbose ログファイルを見つけるにはアプリケーションデータベースを使用する方が便利です。詳しくは、アプリケーションデータベースとログファイルの関係を参照してください。

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

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

  • アクティビティページには、すべてのトランザクションメタデータが含まれています。トランザクションエントリの上にカーソルを合わせて詳細を表示をクリックし、関連するログファイルにアクセスします。Arc はMessageId を使用して、ディスク上の適切なログファイルを検索しています。

  • 同様に、コネクタの設定パネルのインプットタブ、アウトプットタブ、およびトランザクションタブを使えば、特定のコネクタが処理したすべてのトランザクションにアクセスできます。これらのトランザクションを展開して、verbose ログファイルを表示およびダウンロードします。

  • アプリケーションデータベースは、トランザクションログファイルが保存されている適切なフォルダに手動で移動するのに役立ちます。ユーザーがトランザクションのファイル名を知っていても、内部のMessageId は知らない、ということは頻繁にあります。アクティビティページのメッセージタブは検索できるので、特定のファイル名で検索すると、そのファイル名に紐付けられたトランザクションのMessageId が表示されます。See Folder Hierarchy for more information on how to find the log folders once you know the MessageId and connector.

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

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

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

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

コネクタの実装

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

コネクタは3種類の操作を実行します：

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

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

コネクタは1つのインプットフォルダからインプットメッセージを読み込み、1つのアウトプットフォルダにアウトプットメッセージを書き込みます。コネクタがフロー内で接続されると、Arc は最初のコネクタのアウトプットフォルダからメッセージを次のコネクタのインプットフォルダに移動します。(On disk, the Input folder is labeled Send, and the Output folder is labeled Receive.)

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

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

The following sections explains how these folder contents function in the application. Folder Hierarchy explains the exact location of connector folders and subfolders.

Port.cfg

Each connector’s port.cfg file contains the settings that govern the connector’s behavior (the settings that appear in the connector’s Settings and Advanced tabs).ファイルはINI フォーマットであり、コネクタの設定はSettingName = SettingValue 構文で1行1設定としてリスト化されています。Editing connector settings in the UI is functionally equivalent to editing the settings directly in the port.cfg file.

The port.cfg file supports indirect values, which means settings can use a reference instead of a string literal. This is conceptually similar to setting a variable in other sections of the application, and referencing the variable name in the port.cfg file. See Data Directory for details on how to set indirect values.

インプットメッセージ

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

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

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

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

アウトプットメッセージ

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

コネクタによっては、インプットメッセージの処理を終えてすぐにアウトプットメッセージを書き込みます（データフォーマットを変換するコネクタなど）。Other connectors write an output message without first reading an input message.Examples include an SFTP connector that polls a remote server for files to download, and an AS2 connector that passively listens for incoming files.

When a connector is connected to another connector in the flow, output messages do not remain in the Receive folder. They are passed along to the Send folder for the next connector.

ログファイル

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

By default, all connector log files are organized in folders by week, as shown in the following folder structure:

To change the default weekly folder organization, set the Log Subfolder Scheme field of any connector to a different time interval (such as Daily or Monthly). This means that all logs generated in that time interval are held in one subfolder.これによって個々のサブフォルダのサイズを減らすことができ、ディスクI/O 性能の向上に繋がります。

You can use the Messages tab to find the appropriate log folder, either by finding the MessageId or by using Download Logs.

送信済みファイル

In addition to verbose log files, the connector maintains copies of the data payload of all successfully sent and processed messages in the Sent folder (messages that are not successfully processed are not added). Files are named based on the time they were generated, and organized in folders by week.To change the default weekly folder organization, set the Sent Folder Scheme field of any connector to a different time interval (such as Daily or Monthly). This means that all files generated in that time interval are held in one subfolder.これによって個々のサブフォルダのサイズを減らすことができ、ディスクI/O 性能の向上に繋がります。

Note: This Sent folder is a direct child of the connector folder, which is different from the Sent folder in the Logs folder described above.

追加の設定ファイル

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

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

これらのファイルはマッピング関係、カスタムスクリプトの動作、コネクタのインプットとアウトプット構造を保持します。Manually editing these files is equivalent to editing the associated connector UI settings.

Important: It can be risky to manually edit any of these files. The layout is easy to understand and transparent, but incorrectly modifying these configuration files can have unintended consequences.

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

フローは完全なモジュラー型を志向しており、各コネクタが予測できる直感的な方法でわかりやすい機能を提供することを目指しています。Arc には任意のコネクタを組み合わせる機能があるため、シンプルなインターフェースでありながら複雑なタスクを実行することができます。Sophisticated flows remain easy to understand because the connector chain is broken down into discrete steps.

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

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

Important: To ensure that Arc performs reliably, do not interact directly with any configuration files while the application is running. External programs placing locks on these files can cause performance and reliability issues.

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

フローはファイルシステム上で、フローでのコネクタの位置と接続を含むflow.json ファイルとして表されます。See Folder Hierarchy for the location of this file.

The position of connectors in a flow is purely cosmetic and is only used when you configure flows in the UI. The connections between connectors are relevant at the data processing level: after a connector writes an output message, it queries the application engine to see if it needs to pass the output message to another connector’s Send folder.本アプリケーションはflow.json ファイルを使って、（もしあれば）どのコネクタがファイルを渡されるか決定します。

You can configure multiple flows on the same flow canvas, and the Arc UI lets you drag the canvas around to navigate between flows. This is similar to navigating geographical maps such as Google Maps online.

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

It is common practice to separate workspaces by trading partners or integrations. However, deciding whether to configure new flows in separate workspaces is a matter of preference. See Organize Flows into Workspaces for more information.

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

When you introduce new (non-default) workspaces, Arc adds a new set of folders in the folder hierarchy.workspaces ディレクトリには、デフォルトワークスペースで設定したすべてのコネクタのコネクタフォルダが含まれます。workspaces フォルダはデータディレクトリの兄弟です。

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

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

ワークスペースはコネクタをより根本的なレベルで分離する機能にしたいと考えています。Separate workspaces use separate folders to hold connectors so that filesystem-level operations (such as permissions and directory listings) can be easily isolated to a particular workspace.

フォルダ階層

Because all Arc resources are available on the filesystem, understanding Arc at a low level requires learning the application’s folder structure and how files and folders are organized on disk.

階層を理解するには、Arc のインストール先のディレクトリ構造を知っておくのがよいでしょう。Following is a visual representation of the folder structure. The details of this structure are explained in the following sections.

Note：この階層は、フローがデフォルトのワークスペースだけで設定されていることを想定しています。See Flows and Workspaces for details on additional workspaces.

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

すべてのArc リソースはインストールディレクトリにあり、デフォルトでは以下の場所にあります：

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

Java 版のインストールについては、CData はzip ファイルを提供しており、それを任意のインストールディレクトリ（例えば、/opt/arc）に展開することができます。

Arc のJava 版はTomcat のような外部Java サーブレットにホストされているので、Arc のリソースは~/cdata/arc に配置されます。このパスでは、~ はJava サーブレットをホストするユーザーのホームディレクトリになります。

上記のフォルダ階層では、ルートインストールディレクトリはツリーの最上部にあるArc フォルダです。

データディレクトリ

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

Profile.cfg

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

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

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

Flow.json

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

Roles.json

The roles.json file includes details related to all custom user roles. Editing roles.json directly accomplishes the same thing as adding and configuring roles on the Roles page.

Settings.json

settings.json ファイルには、アプリケーション内で値ではなく参照名を使用することで、別の箇所で参照できる設定の一覧が含まれます。これにより、セキュアな値（パスワードなど）をアプリケーションに表示しない方法で保存することができます。また、参照名を使用して、複数のインスタンスにデプロイされているフローの設定を一元化することもできます。

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

Users.json

The users.json file contains details related to all Arc users. Editing users.json directly accomplishes the same thing adding or editing users on the Users page.

証明書

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

Arc は、data ディレクトリの証明書を列挙して、UI から証明書を設定する際に利用可能なオプションを決定します。証明書ファイルをdata ディレクトリに追加することは、UI で証明書をアップロードすることと同じ効果があります。

コネクタフォルダ

設定済みの各コネクタインスタンス用に、data ディレクトリに専用のフォルダが設置されています。フォルダ名はフロー内の各コネクタのConnectorId の値（表示名）と一致します。上のフォルダ構造例では、’AS2_Amazon’ と’Database_MySQL’ の2つが設定済みコネクタです。

コネクタフォルダの内容はコネクタファイルとフォルダセクションで説明されています。Following is an overview of the subfolder structure in the connector folder:

  • Archive：古いログファイルは圧縮されてこのフォルダに移動されます
  • Logs：コネクタが処理した各メッセージのverbose ログファイル
  • Received：コネクタが受信したメッセージのログ。各メッセージはMessageId に一致する独自のフォルダを持っています
  • Sent：コネクタが送信したメッセージのログ。各メッセージはMessageId に一致する独自のフォルダを持っています
  • Receive（アウトプット）：Messages that the connector has received or processed
  • Send（インプット）：Messages that the connector should send or process
  • Sent：処理に成功したメッセージのコピー（生データファイル形式）

Depending on the connector type, some connectors can have other subfolders:

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

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

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

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

オートメーション

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

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

クロックティック

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

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

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

並列処理

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

  • ワーカープール：アプリケーションがコネクタ全体に同時に割り当て可能な全体の最大スレッド数を決定します。スレッドが特定のコネクタ内で割り当てを完了したら、プールにリサイクルされます。ホストマシンのハードウェアリソースがこの設定の上限を決定します。
  • コネクタあたりの最大ワーカー数：1つのコネクタに同時に割り当て可能な最大スレッド数を決定します。コネクタに割り当てられた各スレッドはそのコネクタのSend フォルダ内のファイルを、フォルダが空になるまで（またはコネクタあたりの最大ファイル数に達するまで）1つずつ処理します。この条件に達すると、コネクタに割り当てられたスレッドは処理の完了後ワーカープールにリサイクルされます。You can override this setting on an individual connector’s Advanced tab.
  • コネクタあたりの最大ファイル数：1回のクロックティック内で1つのコネクタ内で処理されるファイル数の上限を決定します。例えば、この設定を5に指定すると、コネクタのSend フォルダにまだファイルが残っていても、コネクタに割り当てられたスレッドは（合計で）5ファイル処理したあとにワーカープールにリサイクルされます。You can override this setting on an individual connector’s Advanced tab.これを0に設定すると、コネクタはスレッドが割り当てられた時点でコネクタに存在するすべてのファイルを処理しようと試みます。

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

パフォーマンスの最大化

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

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

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

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

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

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

受信オートメーション

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

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

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

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

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

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

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

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

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

Arc の技術的特性の評価

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

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

より高度なArc の操作

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

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

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

Arc のフォルダ構造を理解すれば、Arc を別のデータ処理システムに組み込むのは簡単です。Arc は明確に定義された一連のディスク上のフォルダを介してシステムとやり取りするので、特定のフォルダに読み書きするアプリケーションはスムーズにArc にデータを渡したり、Arc からデータを取得することができます。CData では、外部システムとの連携にはFile コネクタの使用を推奨しています。設定の詳細については、ローカルファイルシステムとのやり取りを参照してください。

Arc に親しむ

最後に、弊社ではエンジニアの皆さんが、使用するシステムの基盤となっている仕組みを理解したいという共通の願望を持っていると信じています。上記のメリットがどれもお客様の実装に当てはまらない場合でも、このドキュメントがArc を使用して独自のデータ統合ワークフローを構築する際に、さらなる安心感と親しみやすさをもたらす一助となれば幸いです。If you have any questions about the content of this document or need further guidance, please reach out to our dedicated support team at [email protected] and we will be happy to assist you.