Introduction to the Profiles Page

Arc's Profile page is where application-wide settings are configured:

• Local Profiles
• Performance
• Alerts
• Logging and Cleanup
• User Management

This guide will discuss each of the available features within the Profile page.

Local Profiles

Most file transfer protocols require setting up a local profile in Arc:

• AS2
• AS4
• OFTP
• FTP (server-side)
• SFTP (server-side)
• RosettaNet
• GISB

For these protocols, the local profile stores local connection settings that remain the same across different remote parties (trading partners), for example:

• Identifiers (e.g. AS2 Identifier, Odette Identifier)
• Private Certificate
• Listening port

The settings that are specific to a particular remote party (trading partner) are configured via the Flows page, within a particular instance of a connector. For example, to establish an AS2 connection with a single trading partner you would first configure a local AS2 Profile, then configure an AS2 Connector (in the Flows page) with the connection details specific to that trading partner.

Local profile settings can also be overridden for a specific trading partner within the connector that is configured for that partner (via Advanced -> Alternate Local Profile).

AS2 Profile

The required settings in a local AS2 Profile are:

• AS2 Identifier - The arbitrary ID that identifies you during an AS2 exchange
• Private Certificate and Certificate Password - The digital certificate (.pfx, .p12) used for AS2 decryption and signatures
• Public Domain - Your public domain that partners use to access your system from the public internet

The remaining settings are not required to establish an AS2 trading relationship:

• Rollover Private Certificate - An old private certificate that has been replaced; used to allow for multiple decryption certificates during a transition period
• Asynchronous MDN URL - Where partners should send MDNs if asynchronous MDNs are enabled; it is strongly recommended to not change this setting, and to use synchronous MDNs instead of asynchronous
• Public URL - A link where trading partners can view your AS2 profile details and download the Public Certificate (this certificate should match the Private Certificate but with a '.cer' extension)

AS4 Profile

The required settings in a local AS4 Profile are:

• Party Identifier - The ID that identifies you during an AS4 exchange
• Private Certificate and Certificate Password - The digital certificate (.pfx, .p12) used for AS4 decryption and signatures
• Public Domain - Your public domain that partners use to access your system from the public internet

The Party Identifier Type setting is not typically required, and helps qualify the Party Identifier by specifying its type. If set, this value should be the domain to which the identifier belongs (e.g. 'urn:oasis:names:tc:ebcore:partyid-type:D-U-N-SNumber:0060').

OFTP Profile

The required settings in a local OFTP Profile are:

• Odette Identifier (SSID Code) - The value that identifies you during an OFTP transmission, assigned by Odette
• Password (SSID Password) - An arbitrary (mutually agreed upon) password for the identifier
• Data Decryption Certificate and Certificate Password - The digital certificate (.pfx, .p12) used for decryption
• Port - The port on which the OFTP server will listen for incoming connections (the default 6619 is strongly recommended)

The remaining settings are not required to establish an AS2 trading relationship:

• Use SSL/TLS and SSL Private Certificate - Whether incoming connections must be encrypted via TLS; if enabled, an SSL certificate (.pfx, .p12) is required to host the server
• Enable Server Log - Whether to maintain server-side logs for OFTP connections; the LogLevel and log cleanup settings help determine how much space these logs consume on the filesystem
• Auth Challenge Private Certificate - An additional certificate used to verify a client's identity via asymmetric digital encryption; not typically required to establish an OFTP connection
• Sign Private Certificate - An additional certificate to use only for digital signatures; most OFTP connections do not require a dedicate signature certificate

SFTP Server

The required settings for hosting an SFTP server are:

• Port - The port on which the server will listen for incoming connections
• Server Certificate - The private digital certificate used to secure the SSH channel and verify the server's identity
• Root Directory - The path on the filesystem that will serve as the root of the server; the default path is recommended.

The remaining settings are not required to for hosting an SFTP Server:

• Login Banner - The message that clients see after connecting to the server
• Allowed Files Filter - A glob pattern (e.g. *.txt) for the files that clients are allowed to upload (multiple patterns can be specified in a comma-delimited list); files not matching the pattern will be rejected by the server prior to upload
• Enable Server Log - Whether to maintain server-side logs for OFTP connections; the LogLevel and log cleanup settings help determine how much space these logs consume on the filesystem
• Inactivity Timeout - The length of time (in seconds) the server will allow a client to sit, inactive, before forcibly terminating the connection

FTP Server

The required settings for hosting an FTP server are:

• Port - The port on which the server will listen for incoming connections
• FTP Over TLS - Whether incoming FTP connections must be secured via SSL/TLS.
• Server SSL Certificate - If FTP Over TLS is enabled, this must be the private digital certificate used to negotiate SSL/TLS and verify the server's identity
• Root Directory - The path on the filesystem that will serve as the root of the server; the default path is recommended.

The remaining settings are not required to for hosting an FFTP Server:

• Welcome Message - The message that clients see after connecting to the server
• Allowed Files Filter - A glob pattern (e.g. *.txt) for the files that clients are allowed to upload (multiple patterns can be specified in a comma-delimited list); files not matching the pattern will be rejected by the server prior to upload
• Enable Server Log - Whether to maintain server-side logs for OFTP connections; the LogLevel and log cleanup settings help determine how much space these logs consume on the filesystem
• Inactivity Timeout - The length of time (in seconds) the server will allow a client to sit, inactive, before forcibly terminating the connection
• Passive Port Range - When the server initiates passive mode (i.e. clients initiate transfer), the server will pick any available port on which to listen; this setting restricts the possible ports and is specified as: [start]-[end] (e.g. 1024-8000, 2000-, -4096)

Performance

The Advanced tab of the Profile page contains Performance settings, which are only relevant if Parallel Processing is enabled. Note that Parallel Processing is included in Professional and Enterprise-tier licenses.

The following settings govern application performance:

• Worker Pool - The total number of workers (threads) available to distribute among connectors
• Max Workers Per Connector - The maximum number of workers that will be assigned to any single connector to process input files
• Max Files Per Connector - The maximum number of files that assigned worker will process (combined) before being recycled back into the worker pool

The Max Workers Per Connector and Max Files Per Connector can be overridden for specific connectors within those connector's Advanced settings tabs.

Alerts

The Advanced tab of the Profile page contains Alert settings, which determine whether the application will send notification emails when errors occur within the application.

Configuring email alerts requires specifying the SMTP server used ot send the outgoing emails. The Subject and Recipient(s) of the emails are configurable, and the contents (body) of the email will be the error thrown by the application.

Note that Alert emails are not sent if Retry settings are enabled in the connector where the error is thrown, and the error does not persist when retried. Only when a connector has exhausted all retries will it raise an error in the application and cause an Alert email to be sent.

Logging and Cleanup

Arc maintains log files for each transaction processed by the application. To prevent the accumulation of log files from becoming too large for the log folder (which may decrease application performance), log files can be archived (compressed and moved to an archive folder) or deleted.

The Cleanup Options settings in the Advanced tab govern whether Arc will archive or delete logs, and the interval according to which this cleanup occurs.

User Management

Arc includes an Administration API that you can use to manage the application via RESTful API calls. Anything that can be configured or executed in Arc's web UI can also be accomplished via the Admin API.

The Security tab of the Profile page contains the list of users authorized to consume the Admin API, and the list of whitelisted IP addresses from which these API requests can be sent.

After creating a user in the Security tab, the user is assigned an Authtoken. The Authtoken should be provided during any API calls in one of the following ways:

• HTTP Basic Authentication (the Authoken is the password for the user)
• Include a x-arc-authtoken header in the HTTP request with the value set to the Authoken string
• Include the Authtoken string in the URL as the '@authtoken' query parameter (note that this requires enabling Allow Authtoken in URL)