Logs for data exchange

Logs show how data is processed (whether synchronously or asynchronously) and delivered via Redox. Specifically, a log is an aggregation of small transactional components that contain the data payload or request sent from your system to your connection's.

On the Redox dashboard, the Logs page allows you to search for logs using these filters:

• Connection
• Sources / Destinations
• Date range
• Data model
• Event type
• Log type
• Status

Redox sorts resulting logs by timestamp with the most recent log at the top. Just note that if you're new to Redox, the Logs page will be empty until your organization starts using any of the developer tools in the dashboard to send test messages. Learn how to search for logs.

There are four log types: SEND, RECEIVE, REQUEST, or RESPOND. The log type describes the:

• source (i.e., the system that initiated the request); and
• event type, either asynchronous (SEND/RECEIVE) or synchronous (REQUEST/RESPOND).

We create a log for every attempted request.

A log with type SEND or RECEIVE describes an asynchronous request. Asynchronous requests can be duplicated and sent to multiple destinations, or endpoints. This depends on how many integrations you have and how many destinations you designate within the request.

Redox creates a log for every attempted request. So if one asynchronous request routes to 10 destinations, it generates 10 logs entries.

Asynchronous requests may try processing multiple times before getting a successful delivery. Here are some reasons asynchronous requests may fail:

1. Parallel processing: Redox sometimes processes requests in parallel, and errors can occur while processing requests simultaneously. If this happens, Redox pauses your queue of asynchronous requests until we resolve the issue. You can manually retry sending the request (learn how to initiate a retry), but Redox also watches paused queues to resolve issues. If the manual retry isn’t successful or you need more immediate support from us, submit a ticket via our Help Desk.
2. Failed delivery: Other times, Redox successfully processes your request, but the destination doesn’t accept it. This would be like if a mail carrier gets your package to the right address with the right contents, but the recipient doesn’t open the door. We automatically retry sending in this case, but you can also manually retry sending the request.

Learn more about:

• asynchronous message responses
• automatic retries
• manual retries

A log with type REQUEST or RESPOND describes a synchronous request. This type of log passes through Redox twice: once on its way from the source and back again from the destination.

If either side of the subscription fails to process the request, it can’t be retried like an asynchronous request. This is because the request waits for a response.

To use another mail carrier analogy, this is like a mail carrier delivering a package but waiting for the recipient to write back to the sender before leaving. Since we don’t want our faithful mail carrier—or Redox—to wait around forever, a synchronous request simply fails if there’s not a response. So if the request fails, you must send a duplicate request to successfully deliver the request and receive the expected response.

Every log has a distinct status that reflects its current or final state:

Of these statuses, PENDING is the only one that represents an interim state; the others are final states and won't change. A pending state is most common for asynchronous requests.

For more details on FILTERED, read about filters.

Selecting a processing stage opens the log details, which includes metadata, payload snapshots, and any data operations.

To view payload snapshots, users must have a support or engineer role in the environment.

Data operations, however, are visible to any users in the environment. To edit a related operation, a user must have a support or engineer role.

If a processing stage has data operations like filters or translations linked to it, there are icons for the related data operation.

Selecting the processing stage allows you to see what operations occurred. Then, you can click the operation to see what specific translations or filters were applied to the log.

For translations, there are different labels to indicate what happened to each defined field path:

For Block all rules, the filter details show that the message was blocked due to the defined filter rule.

For Send if rules, the log details show an outcome for each rule.

If you have multiple Send if rules, the rules are evaluated in the order they're defined. If a filter rule isn't met, any subsequent rules aren't evaluated.

Learn more about filters.