CData Arc maintains multiple separate logs: the Transaction Log, the Application Log, the Access Log, and the Audit Log. These logs can all be viewed on the Status page of the application UI. Each log is stored as a separate table in the single Application Database.
The Access Log records web requests made to the application’s public endpoints. This includes any requests made to the AS2 and AS4 endpoint (/pub/Receive.rsb) and any API calls (both the built-in Admin API and any custom-defined API’s made with the API connector).
The Access Log can be used to verify that external trading partners’ web requests are reaching the web server hosting the application. If a partner attempts to send a message over an HTTP-based protocol (AS2, AS4, etc) and this request does not appear in the Access Log, then the message is not reaching the application web server. This might indicate a basic connectivity error like firewall interference, incorrect connection parameters, or network outage.
The Application Log records any application-level errors that occur during processing and any requests made to application resources. The error messages in the Application Log may help provide context to errors for specific transactions.
The Application Log can be used to verify that external trading partners’ web requests are successfully routed to a connector within the Arc flow. When the application receives a web request at a public endpoint, it attempts to route the message to a specific connector based on message headers (e.g. AS2 Identifiers). If an error prevents the application from routing the message successfully, this error will appear in the Application Log.
The Transaction Log contains detailed information regarding all incoming and outgoing file transfers and all files processed locally by data transformation connectors. For example, AS2 transaction logs contain HTTP request and response headers, the MDN response to the AS2 request, and any communication errors.
The Transaction Log includes a separate row for each file processed by the application, and each row can be expanded to download the log file. Transaction information for a particular connector can also be found in that connector’s Input and Output tabs.
The Transaction Log includes both successful and failed transactions. Successful transactions will have a Status value of ‘Sent’ or ‘Received’, while failed transactions will report a status of ‘Error’.
Searching the Logs
Entering a search query in the Transaction Logs will return transactions that match the search criteria.
Basic search options include the following:
For example, if a file named
reports.csv was processed by multiple connectors, then searching for “reports.csv” would return the transactions involving this file.
Custom Searchable Headers
Arc supports adding additional searchable metadata in the Settings page under the Advanced tab. The Searchable Headers field can be set to a comma-delimited list of custom header names. Then, these custom headers can be searched in the Transaction Log by setting the query string to “headername:value”.
For example, if the ‘AS2-From’ header is added to Searchable Headers, files with an ‘AS2-From’ value of ‘test’ could be found with the following search string:
Arc will add metadata headers to files as they are processed in the flow, and these headers can be viewed in the Message Info modal by clicking on the filename for a Transaction Log entry (either in the Transaction Log itself or in the Input/Output tabs for a particular connector). Custom headers can be added to files using the Arc scripting functionality, either in a dedicated Script Connector or in the Event Scripting of another connector in the flow.
Advanced Search Queries
Advanced search queries can take advantage of two additional values:
The option value narrows searches down to specific workspaces or connectors (the only valid values for option are “workspace” and “connectorid”). The header value searches for transactions where the message that was processed includes a specific header name and value pair.
Advanced search queries should use the following syntax:
[option:optionValue] [headerName:headerValue] [<remaining search text>]
Below is an example query following this syntax:
workspace:Dev customer_number:12345 test.csv
This query would return transactions involving a file named “test.csv” from the workspace “Dev” where the file/message included a header called “customer_number” with the value set to “12345.”
The search syntax uses the following logic to determine the option and header: if the first term in the search includes a colon, it is considered either a header or an option; if the value to the left of the colon is either “workspace” or “connectorid” then this term is treated as the option, otherwise the term is treated as a header name-value pair.
Adding Custom Headers
ArcScript can be used to add custom headers to files in the Arc flow. These custom headers can be made searchable in the transaction log by navigating to the Profile page, selecting the Advanced tab, and entering the header name(s) in the Searchable Headers field.
Headers are added to files in a scripting context by setting the Header:header_name attribute of the file item that is pushed out by the connector. For clarity, begin with a script that pushes an output file that is an unmodified version of the input file:
<arc:set attr="outfile.FilePath" value="[FilePath]" /> <arc:push item="outfile" />
The [FilePath] variable resolves to the full path (and filename) of the input file, so this script is simply making the output file the same as the input file.
The following addition to this script adds custom headers to the file before pushing it:
<arc:set attr="outfile.FilePath" value="[FilePath]" /> <arc:set attr="outfile.Header:myHeaderName" value="myValue" /> <arc:push item="outfile" />
If ‘myHeaderName’ is then added to Advanced -> Searchable Headers in the Profile page, then searching the Transaction Log for ‘myValue’ would return this file.
Web Server Logs
Arc also maintains logs for the underlying web server hosting the application. These logs are only applicable when using the embedded web server for the Windows Edition of Arc (when hosting with another web server, consult that server’s documentation for information on server logs).
Embedded web server logs can help in diagnosing connectivity problems as well as configuration issues related to the web server itself. To access the server logs for the embedded web server:
- Right-click the Arc icon in the Windows system tray and select Server Options.
- Navigate to the ‘Other’ tab of the embedded web server UI.
- Enable ‘Write Log to a File’ and enter a filepath on disk.
- Set the log verbosity to include the desired level of detail and the log rotation options as necessary.
When run as a service, the application writes web server logs to a service.log file in the application installation directory.
Some connectors have settings in the Advanced configuration tab to enhance the verbosity of transaction logs. These detailed logs are useful when debugging, and are often necessary when requesting support from firstname.lastname@example.org.
The most common Advanced configuration setting is Log Level. When set to Debug, additional information is added to the transaction logs that are already generated when processing a transaction.
Some connectors that send outgoing requests also have a Log Requests setting. When set to True, transaction logs will include a copy of the request as it was sent to the remote server. This may be useful in narrowing the scope of any issues receiving server responses.
Some connectors that issue queries against remote systems have Verbosity and/or Logfile settings. The Verbosity should be set between 1 and 5 (where 5 is the most verbose, and recommended in most cases). When Logfile is an available setting, it should be set to a path on disk to write the dedicated logfile; this file can be provided for support in addition to the transaction logs generated when processing a transaction.
Arc stores each change made to the application configuration in the Audit Log. This includes all actions like creating connectors, configuring connectors, updating profile settings, etc.
The Audit Log includes the user that performed the change, the timestamp of the change, and the resource used to make the change. The resource refers to either the Admin Console (the web UI that serves as the typical interface for managing and configuring the application) and the Admin API (the REST-based API that can be consumed to manage and configure the application).
The Audit Log can be queried to perform audits of the application configuration.