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:
- 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.
- 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:
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.
We like to help you visualize how a log is processed. In the Redox dashboard, we show this as three- or six-block stages, depending on the log type. Stages show high-level events of log processing.
Log stages give you an idea of how data passes from a source, through Redox, to a destination (and potentially back again). However, a more detailed view of log processing is conveyed through operations.
Operations are individual steps in log processing, where a payload is altered in some way (e.g., cleansed, tagged, translated, filtered). Learn about operations.
To summarize, operations are the way work gets done, while stages are how we bucket the work. Most importantly, stages show high-level events and don't have a strong ordering of step-by-step events like operations.
Every log has a distinct status that reflects its current or final state:
Status | Description |
|---|---|
SUCCEEDED | The request was successfully processed and delivered to the designated destination. |
FAILED | 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. |
FILTERED | Redox filtered the data payload based on your filter settings for the related data model or FHIR® notification. |
PENDING | 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.
Selecting a processing stage opens the log details, which includes metadata, payload snapshots, and any data operations.
A payload snapshot is a captured copy of the log at a specific point during processing. It's often a JSON object. 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 log processing stage has operations you manage linked to it (i.e., filters, translations, or config modifiers), there are icons for them. If an icon is grayed out, it means it didn't take effect in this processing stage.
Selecting the processing stage allows you to see which customer-managed operations were applied to the log.
The log details show an outcome for translations, which indicates what happened to each defined field path:
Outcome | Definition |
|---|---|
Translated | 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. |
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.
Outcome | Notes |
|---|---|
Satisfied | The criteria for this filter rule was met. The next filter rule was evaluated. |
Unsatisfied | The criteria for the filter rule wasn't met. Any subsequent filter rules weren't evaluated. |
Skipped | A previous filter rule was unsatisfied, so this rule wasn't checked at all. |
The config modifier details show the outcome for any config modifier(s) at a particular processing stage.
Under the Operations section on the lefthand side, you'll see tabs for config modifiers managed by either the source or destination. Clicking either tab shows details for the config modifier(s) managed by the respective organization at that processing stage. If your organization doesn't own both source and destination, you won't see expanded details, but you'll see the names, flavors, and statuses.
Number | Detail | Notes |
|---|---|---|
1 | Managed by... | Hover over this icon to see which organization owns this set of config modifiers. |
2 | Expand | Click this to view the payload snapshots before and after this config modifier was applied to see what changed. This option is only available for PUT config modifiers that your organization manages. Otherwise, it's hidden to protect potential confidential data. |
Potential statuses include:
Outcome | Definition |
|---|---|
Succeeded | We found the selector path and executed the instructions defined by the config modifier. The icon on the processing stage is bolded to show it applied successfully. |
Field not found | We didn't find the selector path specified in the config modifier. The icon on the processing stage is grayed out to show it wasn't applied. |
Failed | A PUT config modifier didn't execute for some reason. This only occurs on very rare occasions, so you shouldn't expect to see this status. |
Learn more about config modifiers.
While logs show message processing, they're limited to showing only what was delivered and when.
Not every message delivers smoothly, though, and you might want to dig into the details of unexpected errors or unsuccessful deliveries / receipts. Log inspector shows you a detailed, ordered set of operations (read about operations) which a given log underwent during processing. This empowers you to do your own troubleshooting to find where or what might have gone wrong.
A user assigned to a support or engineer role can run the log inspector either in the Redox dashboard or with the Platform API. Running log inspector shows a nitty gritty view of each step in log processing, along with the input and output payload snapshots, and the result of each step.