Frequently Asked Questions

This page provides the answers to many commonly asked questions. For questions that are not addressed on this page, please reach out to our support team at support@arcesb.com.

• How does ArcESB handle high transaction volumes? Is this performance scalable?
• What is the maximum file size that can be sent/received using ArcESB’s file transfer tools and APIs?
• What is the ratio between the size of files that ArcESB processes and the application’s memory usage?

• Is there a trial version of ArcESB that I can use to evaluate before purchasing?
• What features are included in the three different editions of ArcESB: Core, MFT, and EDI?
• ArcESB licenses include a certain number of ‘connections,’ what is a connection?
• If I want to host ArcESB on multiple machines, do I need multiple licenses?

• Should ArcESB be managed by a technical team or a business team?
• Is ArcESB cross-platform?
• Can ArcESB run on multiple machines in a cluster?
• Can I manage ArcESB from an external machine using an API?
• Does ArcESB support AD Integration and SSO?

• When processing EDI files, does ArcESB perform document validation?
• Can ArcESB help enforce HIPAA regulations on my EDI data?
• Can ArcESB handle fixed-width and position-delimited files?
• Can ArcESB translate EDI files to and from different EDI versions? For example, X12 4010 into 5010?
• Can ArcESB handle JSON in addition to XML?
• In the XML Map Connector, there aren’t any lines between the elements that are mapped to each other. Why?

• Can we use a different/custom hostname for APIs and other endpoints in ArcESB?
• Is there any limit on concurrent API calls for managing ArcESB?
• Can I make outbound REST requests within ArcESB?
• Does ArcESB support OAuth for API endpoints and other access URLs in the application?

• Will features of ArcESB be removed or retired in future versions of the application?
• How can I keep ArcESB’s configuration in a version control system for backup and redundancy?
• Can I get notifications when errors occur in ArcESB and use custom logic to respond to them
• How frequently are new versions released? Is it mandatory to install new versions as they come out?
• Is there way to clean up connector files and database log entries?
• What technologies does ArcESB use?

Throughput performance in Arc is dependent upon the hardware used to host the application, so the below throughput figures and associated hardware are provided as a benchmark. Arc can be hosted on multiple machines in a cluster to achieve higher total throughput, as described in our documentation here.

Connector throughput can be divided into two categories: EDI connectors, that translate EDI data into XML (or vice versa), and Routing connectors that move files through the flow according to some logical constraint. Through put numbers for both categories are provided below.

• EDI Connectors: 1100-1220 files/min
• Routing Connectors: 1580-1700 files/min

These tests were performed on an Intel i7 6-core machine with 16GB of RAM and an SSD.

Performance for networked connectors, like AS2 and SFTP, are too dependent upon network conditions to provide a file throughput estimation. It is recommended to utilize Arc’s free trial to undergo performance testing for a specific environment.

Note that some settings in Arc influence the amount of hardware resources assigned to any given connector. These settings are described below:

• Worker Pool The total number of workers (threads) that will be assigned to connectors to process files
• Max Workers Per Connector The maximum number of workers (threads) assigned to any single connector every clock tick (i.e. every 500 milliseconds)
• Max Files Per Connector The maximum number of files that workers assigned a connector, collectively, should process before being recycled into the pool

The figures provided above were gathered using a Worker Pool of size 100, with Max Workers set to 100, and Max Files set to 200.

Arc does not impose any external constraints on file size, and there is no practical limit on the size of datasets transferred through web requests (so long as the remote side supports chunked encoding for data streaming). Arc supports protocols, such as SFTP and AS2, that are built to efficiently transfer large amounts of data.

Arc’s data transformation operations, like EDI translation and XML mapping, utilize streaming so that the full input file is never in memory at the same time. As a result, the memory requirements are low, typically smaller than the size of the files being processed.

Yes, after downloading and installing ArcESB, simply navigate to the About page in the web UI to find the ‘Activate Trial License’ button. This will install a 30-day trial license, and this trial period can be extended by contacting the support team at support@arcesb.com.

Arc’s editions can be thought of as three tiers, where each tier provides new functionality while including the functionality from all previous tiers. The tier list goes: Core, then MFT (which includes all of Core), then EDI (which includes MFT and Core).

Since Arc’s features set is provided as a set of tools called Connectors, the difference between tiers is simply which sets of connectors are available. An overview of the features introduced at each tier is provided below, and a full list of connectors at each tier can be found in the documentation.

Core

The Core edition of Arc includes all data transformation and mapping features, logical connectors that route files throughout the flow, API integration features like REST and SOAP connectors, custom scripting, and client-side FTP and SFTP file transfer.

MFT

The MFT edition of Arc includes all of Core, as well as secure file transfer protocols like AS2, AS4, OFTP, and RNIF. The MFT edition also supports server-side SFTP and FTP transfer (while the Core edition only provides client-side support for these protocols). Finally, the MFT edition allows for connecting to a wide array of cloud storage services like S3 and Google Drive.

EDI

The EDI edition of Arc includes all of Core and MFT, as well as EDI translation connectors that enable integrating EDI data with backend systems, remote hosts, and more. The EDI tier includes both inbound & outbound EDI documents. Arc uses XML as an intermediary medium to streamline EDI document conversion to and from any arbitrary format.

In broad terms, each connection should represent a trading partner or other external system with which Arc needs to integrate.

At the MFT tier, each connector within the MFT category (e.g. AS2, SFTP Server, Amazon S3) counts as a connection. The expectation is that each separate MFT connector establishes a connection with a unique external party.

At the EDI tier, a connection encompasses three individual connectors:

• An EDI Connector (e.g. X12, EDIFACT) to process inbound documents (translates EDI into XML) from a single trading partner
• An EDI Connector to process outbound documents (translates XML into EDI) for a single trading partner
• An MFT Connector to send/receive EDI documents with a single trading partner

Since a single EDI Connector can handle multiple different EDI document types, these three connectors should be all that is necessary to establish an end-to-end EDI integration with a single trading partner, regardless of how many document types are exchanged. However, EDI Connectors cannot be shared across multiple trading partners, since each connector is configured with Identifiers for a particular remote party.

Note that Unlimited licenses are available for Arc integrations that include a large number of trading partners or other external systems.

Yes, each server hosting the application will need a dedicated license. Significant discounts are provided for non-production instances like test, development, and passive failover servers. Contact the licensing team at sales@arcesb.com for up-to-date information on discounts.

Arc is typically managed by a technical team, but it depends on how technical the business team can get. Arc’s design provides a code-free approach to mapping and workflows, so managing the application does not require a team of developers. However, application management is likely to require an understanding of the data formats involved, and/or a basic understanding of connection parameters for transferring data to and from external systems.

Yes, Arc has a Windows version for Windows systems and a Java version for Linux/OSX environments.

The Windows edition of Arc requires a Windows OS no older than Vista/Server 2008 and the presence of .NET 4.5 or greater. We recommend at least 1GB of RAM and adequate free space for transmission logging and writing application data. The specific disk usage depends on the volume of transactions processed by the application.

The Java version requires JDK 1.5 or higher, at least 1 GB of RAM, and adequate disk space for transmission logging and writing application data.

Yes, Arc supports clustering as described in our dedicated documentation page here

Yes, Arc includes a REST API, called the Admin API, through which any and all management actions can be taken. These include adding connectors, configuring connectors, uploading files, triggering flows, and more. The Admin API is documented here.

The Windows Edition of Arc supports Windows Authentication in two places: logging onto the Administration Console (web UI), and accessing Arc’s SFTP Server.

Accessing the UI via Windows Authentication requires the use of Arc’s embedded web server, which enables configuring Forms Authentication (logging on via a web portal) and Windows Authentication. More information on configuring the Windows embedded web server can be found in the documentation here

Once Windows Authentication is enabled, the Web.Config file can be edited to specify the users/groups permitted to access the application:

<authentication mode="Windows">
      <forms name="ArcESB" loginUrl="~/login.rst" defaultUrl="~/default.rst"
        protection="All" timeout="30" path="/">
        <credentials passwordFormat="Clear">
          <user name="admin" password="admin123" />
        </credentials>
      </forms>
    </authentication>
    <authorization>
      <allow users="LAPTOP-6F6IASTA\James" />
      <deny users="*" />
    </authorization>

Accessing Arc’s SFTP Server via Windows Authentication is enabled via a simple checkbox in the SFTP Profile configuration page.

Yes, Arc compares inbound EDI files against the EDI schema files stored within the Application Directory. Arc comes pre-packaged with all document types for the common EDI versions, and additional schemas can be downloaded for free from our website here.

EDI Connectors include a Strict Validation setting to enable checking for the appropriate number of repeated elements, the presence of required segments, etc. With strict validation disabled, the connector will still validate that the EDI document is syntactically correct such that it can be successfully parsed into XML for further processing.

Yes, Arc provides built-in support for the common SNIP Validation Types required by HIPAA. Additional validation can be performed as part of a larger workflow. More information on HIPAA constraints can be found in our knowledge base here.

Yes, the Flat File Connector translates position-delimited files to and from XML, and it is documented here.

Yes, since each EDI connector is configured to use a specific EDI version. For example, a Flow might have two X12 Connectors: one that converts 4010 X12 documents into XML, and another that converts XML into 5010 X12 documents. This would effectively translate an EDI document into a different version, though you would need an XML mapping step between the X12 Connectors to account for the different data structures between the versions.

Yes, Arc’s JSON Connector facilitates JSON integration in a Flow. Since Arc uses XML as the common medium for data integration, the role of the JSON Connector is to translate inbound JSON into XML, or translate XML into an outbound JSON file. Thus, Arc supports JSON input and/or JSON output to a Flow, but any data transformation or mapping is performed while the data is in XML format.

The JSON Connector is documented here.

Our approach to visually depicting the mapping relationship between elements is the following: clicking on an element in the XML Map Connector’s mapping panel will automatically highlight the element it is mapped to. We find that this approach minimizes clutter and potential visual confusion compared to a spiderweb of lines amidst a complex document mapping.

Yes, as long as the hostname maps to the machine on which Arc is hosted. Arc will generate URIs for specific endpoints in the application (e.g. the endpoint for receiving AS2 and AS4 messages), however the base URL is determined by how the application is hosted and what domain name or IP address is publicly accessible.

Arc’s Admin API does not limit the number of concurrent API calls. For APIs exposed through the API Connector, rate limits can be set per-user (as described in the API Connector documentation here.

Yes, the REST Connector supports generating dynamic REST requests, as documented here.

In addition, the SOAP Connector supports generating SOAP requests from a WSDL definition, as documented here.

Arc can be hosted on standard external web servers, such as IIS, and secured via OAuth and other security mechanisms through these servers. Arc does not include an internal implementation of OAuth.

All of Arc’s configuration data is held in folders on disk:

• A ‘data’ folder for profile and certificate data
• Subfolders for each connector
• A Workspace folder for each workspace

Versioning the configuration of Arc simply requires versioning these files.

Arc also includes an import/export tool in the web UI to easily transfer configuration data for as many connectors as desired.

Any additions or changes within the application are made with a primary concern for backward-compatibility. As new features are introduced, older features are not removed from the application but rather are made less visible in the application UI. This helps our users intuitively understand the recommended approach without breaking older integration implementations.

Yes, Arc offers both global alerts as well as error handling for specific connectors. Details on handling errors and receiving notifications can be found in our documentation here

New builds of Arc are published online 4 times a year to maintain a continuous progression of features, performance enhancements, and bug fixes. Arc’s support team can also provide production-ready builds in-between publishing dates for time-sensitive updates.

Arc’s build process is fully cumulative, so newer builds will always include the same features of older builds. Thus, newer builds can be installed “on top of” existing installations without disrupting the configured behavior of the application.

Installing new builds as they are published is recommended, but not required. The documentation will always reference the most current build, so discrepancies in the features listed in the help and an existing installation are resolved by installing the latest build from our website.

New major versions of Arc are released annually. Major versions may have more significant changes from prior versions, however we still maintain our commitment to backward-compatibility between versions. Installing a new version of Arc will not disrupt the integrations configured in prior versions.

New builds within the same major version do not require additional licensing, however each major version of Arc is licensed separately. An active subscription is required to upgrade major versions without additional licenses.

In general, Arc is designed so that a working configuration never needs to be updated if the usage requirements never change. However, since the upgrade process is seamless, and since updating Arc grants access to new features and enhancements, updating to the latest build is always recommended.

Arc will clean up files and log entries according to the Cleanup Options settings in the Advanced tab of the Profile page. Arc includes the option to delete files according to a specific interval, and/or move them into an archive location.

Output files are an exception to this. Files in the Output folder for a connector are assumed to be at the terminal point of processing in Arc, since files will only remain in the Output folder if the connector is at the end of a configured Arc Flow. When a connector is connected to further connectors in the Flow, files will not remain in the Output folder and will instead be passed along to the Input folder for the next connector in the Flow.

Arc comes packaged with an embedded web server to host the application, which in the Java edition is a Jetty server and in the Windows edition is a custom server using .NET libraries. Arc can also be deployed to an external server like any standard web application.

Arc also comes with a default database for backend storage, which is Derby in Java and SQLite in Windows. Arc can be configured to use an enterprise database like MySQL or SQL Server instead.

Arc uses networking components from /n software for file transfer, APIs, and other MFT operations. ArcESB is a spin-off company of /n software, and we work directly with the engineers who develop and maintain these components.

Arc uses data connectivity drivers from CData for integrating with cloud applications and backend systems like CRMs, ERPs, and accounting systems. ArcESB is a division of CData, and we similarly work directly with the engineers behind these integration drivers.

Arc’s message processing engine uses our own technology, with a simple file-based approach to messaging.

Finally, Arc’s web UI is built with Bootstrap and JavaScript.