Glossary
Version 23.4.8839
Glossary
Version 23.4.8839
The following table provides a set of standard terms used in the product’s documentation.
| Term | Definition |
|---|---|
| Admin API | The Admin API is a REST API built-in to the application that allows for managing, monitoring, and administering the application from afar or via automated processes. Everything that can be accomplished within the CData Arc Administration Console (web UI) can be achieved by a single or series of Admin API calls. |
| Access Log | The Access Log records any web request that reaches Arc. This can be helpful in troubleshooting connectivity issues when partners send AS2 or AS4 requests to your web server. The Access Log can be viewed on the Status page of the application. |
| Application Directory | The Application Directory is a folder that contains configuration files, certificate files, raw data files, and logfiles for the application. For Windows installations, this is C:\ProgramData\CData\Arc\. All Profile settings and settings for connectors configured in the default Workspace are held in subfolders of the Application Directory. Each connector within the default Workspace has a dedicated subfolder within the data directory, named the same as the ConnectorID. Each connector’s Input Folder and Output Folder are held within this directory tree. Connectors configured in non-default Workspaces are held in the Workspaces Directory using a scheme similar to the default Workspace. |
| Application Log | The Application Log stores application-level errors and calls to application resources. The Application Log can be viewed on the Status page of the application, and the full log can be exported using the ‘Download Log File’ button in the top right. More specific information for an error during a particular transaction may be found in the Transaction Log. |
| ArcScript | ArcScript is an XML-based language that you can use to write custom processing logic in a dedicated Script Connector, in the Events of other connectors, and during a data mapping/transformation step in the XML Map Connector. |
| Connector | Connectors are the building blocks for creating a logical Flow of data processing. Each connector performs a single operation on a data file: Send a file over the network to a remote system/host, receive or download a file over the network, transform the file locally (within the bus), or route the file to another connector within the Flow (each of these operations is referred to as a Transaction). Each connector has an Input Folder where files are processed/sent from, and an Output Folder where files are received/written to. |
| Embedded Web Server | Arc can be hosted on any web server, but the application comes bundled with an embedded web server that can be used to immediately get up and running. Running the Arc executable or .jar file launches the embedded web server. When hosting the application on an external server (IIS, Tomcat, Jetty, etc), the embedded web server should not be used. |
| ESB | An Enterprise Service Bus is a platform that allows many separate systems (databases, business applications, file exchange systems) to talk to each other. Arc provides a simple and modular solution for integrating these data processing tools. |
| Events | Events are triggered when a connector processes a Message (e.g. Sending or Receiving a file). Events provide an opportunity to write ArcScript to implement custom logic when these triggers occur. |
| Flow | A Flow is a connected series of connectors. Connections between connectors are displayed via blue flow arrows in the Flows Designer. Files are automatically passed from the Output Folder of one connector to the Input Folder of the next connector. This creates a logical chain of data processing. Multiple Flows can be configured in the same canvas, or they can be split into separate Workspaces. |
| Flows Designer | The Flows page of the application displays the visual Flows Designer, a canvas where Flows are configured. Create Flows by dragging connectors from the toolbox on the left into the canvas. Configure connectors by clicking on them within the canvas, and connect connectors by dragging the blue dot on the right side of the connector onto the left side of another connector. |
| Input Folder | All connectors have an Input Folder called ‘Send’ where files are processed from. Connecting connectors in the Flow causes files to automatically pass from the Output Folder of the first connector to the Input Folder for the next connector. Files can also be placed directly in the Send folder to accomplish the same thing. The Input folder for a connector is held within the connector-specific folder, which is itself a subfolder of the Data Directory. |
| Input Mapping | Database Connectors (and similar connectors like MySQL, SQL Server, CData) use Input Mappings to insert data into back-end systems. Each Input Mapping targets a single table/view (or virtual table/view) within the database/application. Input Mappings determine which columns within the table to insert data, and support advanced insert logic like UPSERTs (inserting or updating depending on a column value), lookup queries (fetching a value before inserting it in the table), and simultaneously inserting into multiple tables that are related via foreign key relationships. Input Mappings are modeled as XML, so data should be formatted as XML before being processed/sent by database-like connectors. |
| Installation Directory | The folder that contains Arc executables. For the Windows edition of Arc, this directory also contains www and www_services folders. The Java edition includes the Uninstaller and webapp folders. |
| Mapping | There are several kinds of mappings in Arc: Input Mappings, Output Mappings, and XML Mappings. Typically, ‘mapping’ refers to XML Mappings, which are how Arc handles data transformation within the bus. Many connectors can translate files into XML and vice versa, and the powerful XML Map Connector transforms one XML structure into another. A combination of these connectors allows for transforming between arbitrary data formats using XML as an intermediary format. |
| Message | Arc processes raw data files, and also maintains metadata (headers) containing information about how the file has been processed within the application. The combination of the raw data file (payload) and metadata headers is called a message. Message headers can be viewed by clicking on the filename of any transaction entry in the Transaction Log or the Input/Output tabs in a specific connector. |
| MFT | MFT is an acronym for Managed File Transfer, and refers to any standard protocol to securely send and receive data to and from other parties. Common MFT protocols are AS2, AS4, OFTP, FTP, and SFTP. Arc includes many MFT connectors that often serve as the entry point or exit point for data in a Flow. |
| Output Folder | All connectors have an Output Folder called ‘Receive’ where output files are written to. Connecting connectors in the Flow causes files to automatically pass from the Output Folder of the first connector to the Input Folder for the next connector. Files outputted by the connector can be viewed directly on disk in the Receive folder as well as the Output tab for the connector. The Output folder for a connector is held within the connector-specific folder, which is itself a subfolder of the Data Directory. |
| Output Mapping | Database Connectors (and similar connectors like MySQL, SQL Server, CData) use Output Mappings to pull data from back-end systems. Each Output Mapping targets a single table/view (or virtual table/view) within the database/application. Output Mappings determine which columns within the table should be returned, and support WHERE clauses (rules), pulling data from multiple tables, and the ability to only fetch new or recently modified records. Output Mappings are modeled as XML, so data returned from a database-like connector are formatted as an XML file. |
| NodeID | The NodeID is a one-way hash of the machine name (or hostname in Java) that is used for licensing purposes. Each standard (non-cloud) license is tied to a single NodeID. The NodeID value is included in a license file (arc.lic) that the application checks to verify licensing status. |
| Profile | The Profile page allows for configuring global settings that are used across the application. Some file transfer protocols like AS2, AS4, and OFTP require configuring a local profile to send and receive files. The Profile also includes security settings, a list of Users permitted to consume the Admin API, and global alerts for errors that occur in the application. |
| Receive | Receiving is the action performed by connectors when generating an output file (Message). For networked connectors like AS2, FTP, and SFTP, Receiving means a file was received passively (e.g. AS2) or actively downloaded (e.g. SFTP) over the network. For local transformation connectors like X12, EDIFACT, CSV, and XML Map, Receiving means writing an output file after processing (translating/transforming) a local input file. |
| Receive Automation | Some connectors can be scheduled to generate output files (e.g. poll a remote server for files to download or execute an output procedure at a specified interval). When enabled, a Receive Interval must be configured to determine when the connector Receives. Receive Intervals can be scheduled every X minutes, every X hours, daily at a specific time, weekly on a specific day, or via cron expression to maintain full granular control of the schedule. |
| Receive Folder | The name of the Output Folder for a connector. Please see Output Folder for more details. |
| Send | Sending is the action performed by a connector when processing incoming files. For networked connectors like AS2, FTP, and SFTP, Sending means the file is sent or uploaded to a remote system or host. For local connectors like X12, EDIFACT, CSV, and XML Map, Sending means processing the file within the bus, transforming or translating it. |
| Send Automation | Connectors support Send Automation settings to determine when and how input files will be processed/sent. When enabled, files that enter the connector’s Input Folder will automatically be sent out or processed. Some networked connectors support Retry settings for retrying failed outgoing transmissions before raising an error in the application; this helps endure temporary network issues without causing a blocking failure. |
| Send Folder | The name of the Input Folder for a connector. Please see Input Folder for more details. |
| Transaction | A Transaction is any time a connector sends, receives, or processes a file. For local transformation connectors, a Transaction includes both a Send and a Receive (the connector Sends the original input file and Receives the output file once it has been transformed/translated). For networked connectors, a Transaction is typically a single Send (sending/uploading a file over the network) or a single Receive (receiving or downloading a file over the network). |
| Transaction Log | The Transaction Log stores metadata about each Transaction processed by the application. The Transaction Log can be viewed on the Status page, and clicking on a filename within the Transaction Log brings up metadata about the Message that was processed and allows for downloading the raw data file or all logfiles generated during the Transaction. |
| View | The Flows Designer allows for saving a particular position (a set of coordinates and zoom level) as a View when navigating the canvas. Clicking on a saved View returns the display to the same position that was shown when the View was saved. Saving Views helps navigate between different configured Flows when many connectors populate the canvas. |
| Workspace | Workspaces allow for the separation of processes for organizational purposes. For example, the connectors required for an automated trading process with Walmart could be separated out into a new workspace that is separate from the connectors required for an automated trading process with Target. |
| Workspaces Directory | A folder within the Application Directory that contains configuration files, raw data files, and logfiles for any non-default Workspaces in the application. |