Mirth HTTP Sender对接C# Web API的三类错误处理配置疑问

Hey there, let's break down your Mirth Connect HTTP Sender issues step by step—this is a super common setup for REST API integrations, so I’ve got some practical fixes tailored to your three scenarios:

Scenario 1: Server Offline (Upgrade/Maintenance) #

Your current approach of setting a retry interval (10 seconds) with a 1-hour total window is correct, and here’s why:

• When the server is fully offline (no HTTP response at all—timeouts, connection refusals, etc.), Mirth’s response transformer won’t trigger because there’s no response to process. The "Fail Queue" setting alone doesn’t handle automatic retries for these network-level failures—it just parks the message after the first failed attempt.
• Adding a retry policy ensures Mirth keeps attempting to send until the server comes back online, or until the retry window expires. For extra safety, you can enable "Fail Queue" as a fallback: if the 1-hour retry window ends and the server is still down, messages will move to the queue for manual or scheduled later retries.

Scenario 2: 4xx Bad Requests (No Retry Needed) #

Your problem here is that Mirth’s default retry logic runs before the response transformer, so it’s wasting time retrying 4xx errors before your code can intervene. Here’s how to fix it:

1. Adjust the Sender’s Retry Condition
   In your HTTP Sender settings, set the "Retry Condition" to a custom JavaScript expression that excludes 4xx errors:

   var statusCode = responseStatus.getStatusCode();
   // Only retry on 5xx errors or no response (offline scenarios)
   return (statusCode >= 500 && statusCode < 600) || (statusCode == -1);
   

2. Add Response Transformer Logic for 4xx
   In the HTTP Sender’s Response Transformer, add this code to mark 4xx messages as completed and log the failure:

   var statusCode = responseStatus.getStatusCode();
   var messageId = message.getMessageId();
   
   if (statusCode >= 400 && statusCode < 500) {
       // Force Mirth to mark the message as sent (no more retries)
       responseStatus = SENT;
       // Log detailed info for debugging
       logger.error(`Bad Request (HTTP ${statusCode}) for message ID ${messageId}. Payload: ${message.getRawData()}`);
   }
   

Scenario 3: 5xx Server Errors (Continuous Retry) #

This ties directly into the retry condition we set above. Here’s how to make it work seamlessly:

1. Configure Retry Settings
   Keep your retry interval (10 seconds) and set "Max Retries" to -1 (unlimited) or a large number if you want a cap. This ensures Mirth keeps retrying 5xx errors until the server recovers.
2. Add Logging in the Transformer
   In the same Response Transformer as above, add code to log 5xx retries for visibility:

   var statusCode = responseStatus.getStatusCode();
   var messageId = message.getMessageId();
   
   if (statusCode >= 500 && statusCode < 600) {
       logger.warn(`Server Error (HTTP ${statusCode}) for message ID ${messageId}. Retrying in 10 seconds...`);
   }
   

Quick Notes to Avoid Gotchas #

• Make sure your HTTP Sender’s "Response Timeout" is set reasonably (e.g., 30 seconds) so Mirth doesn’t hang too long on each failed attempt.
• For messages that end up in the fail queue, you can configure your channel’s queue settings to auto-retry queued messages on a schedule (e.g., every 5 minutes) if needed.

内容的提问来源于stack exchange，提问作者Dean Bostic