Logs for data exchange

Last updated: Apr 1, 2024

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
Log filters
Log filters

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.

Log types

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.

Asynchronous requests

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:

Synchronous requests

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.

Log statuses

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

The request was successfully processed and delivered to the designated destination.
The request didn't process correctly or couldn't be delivered to the designated destination. For a failed asynchronous request to a production environment, this could also mean that retries have been attempted but weren't successful.
Redox filtered the data payload based on your filter settings for the related data model or FHIR® notification.
The request is either a) queued for processing, b) currently processing, or c) queued for or currently attempting a retry.

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.

Log details

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

Log details
Log details

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.

Translations and filter operations

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

Filter and translation icons
Filter and translation icons

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.

Translation details

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

We found the value at the specified field path and translated it based on the related value set mapping.
Value not found
We found a value at the specified path, but it wasn't the value we expected from the related value set mapping. So we didn't translate it.
Field not found
We didn't find the field path you specified in the translation set.
Successful translation
Successful translation
Unsuccessful translations
Unsuccessful translations

Filter details

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

"Block all" outcome
"Block all" outcome

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.

"Send if" outcomes
"Send if" outcomes
The criteria for this filter rule was met. The next filter rule was evaluated.
The criteria for the filter rule wasn't met. Any subsequent filter rules weren't evaluated.
A previous filter rule was unsatisfied, so this rule wasn't checked at all.

Learn more about filters.