4.2.2.15.5. HTTP Client IN Troubleshooting and Error Handling

Troubleshooting calls

Troubleshooting is always complex, but can quickly get particularly complex on the HTTP client IN if you don't follow some basic first tips. Thus, if you are going to set up an inbound and outbound flow with the same server, then start with the outbound flow first. Make sure you configure and troubleshoot your calls one by one as opposed to drawing out a complex setup prior to testing. Identifying the origin of the problem can be much more difficult in a large flow.

Build Your First Call

Whatever you do, start with the simplest smallest call you have. If you have authentication needs, start with checking your authentication on a very basic call that doesn't require complex data. In your calls:

- add HTTP error codes as Valid Http Return codes in your call settings.

Successful runs can produce messages and go into post result actions allowing you to gather more information about the issue. Unexpected HTTP return codes interrupt the run with an error message that may be insufficient to troubleshoot your errors.

- add message creation as "Post Result" to your call with no condition at all:

It doesn't matter if you are planning to create a message there in the end or not. When a message is created, it has a matching zip file with all the exchanges:

Thus, if you find you have an error in your runtime, add the error code you received to the valid return codes so that a message can be created providing you with all the debugging information. This is why we suggest adding all error codes to the list of valid HTTP return codes while you are building and debugging your flow.

- If you are computing your HTTP Authorization headers, add the same script/metadata also to an Authorization2 header. Authorization headers are hidden in the zip export for security reasons but when troubleshooting authentication errors, checking that your Authorization header has the expected content can be useful. Make sure to remove this duplicate header later but in the meantime it will allow you to check your values.

Running a test

Use a Blank Channel

Gateway runs can only be tested in a live channel. So, if you haven't already added your gateway to a channel, do so. For testing purposes, we recommend using a "blank" channel to start with:

Your HTTP gateway > Not defined > No transform > Not defined > Null

That way, your message list will not be polluted with error messages tied to various component failures. The test messages produced will not be charged to your account (because they do not leave the platform). Once your gateway is fully functional then you can move on to completing your channel with 

Test and check results

When you are ready to test, browse to the General tab of your gateway information (Gateway in > more info > General):

To run your flow: click on "poll now". This is an asynchronous process so your gateway will be added to the polling list of our servers and will take a moment to run. You will see the result of this run in a frame that pops up when you click on "Run infos". Thus you will run and check results from this screen and fix issues in the HTTP Flow tab in parallel. We recommend opening your browser to both pages in parallel. 

A successful run will look like this:

This run produced an error:

In this case, the remote server didn't appreciate our file extension "message.edi" in our first call. This could be very easy to fix but, as you can see, a lot of the context of the flow is missing from the error message. It may be hard for you to identify which call produced the error. If you haven't already, add the 404 http code to your list of valid HTTP return codes and add a post action to create a message. The run will be flagged as successful and the message will contain a zip with detailed information on which calls were executed, which ones failed, and the detailed response from the server:

Your message IN will then contain the error the server responded with:

{"errorCode":"unknownFormat","errorMessage":"Unknown format 'edi'. Only 'json', 'xml' and 'csv' are supported."}

Error handling

Any time an error occurs, your run will be interrupted. The flow will not resume. The next run will attempt exactly the same actions. This can be a real issue if you are iterating on a list of items and a single one gets in the way of a successful completion of your requests.

In that case, make sure you handle errors appropriately. You will want to fill in the successful HTTP error codes with all expected failures: 

You will then want to adapt your next step to this reality:

Example: 

I want to update a product if it already exists and create it if it doesn't.

if(responseCode == 404) "createProduct" else "updateProduct"