Http Sender Usage (16.1)

In v16.1, the Http Sender device has been updated to include more functionality. This document outlines some of the updated functionality.

Some virtual methods in the v16.0 custom code have been removed.

Verbs & Encoding

In 16.1 now includes support for the PUT and DELETE HTTP verbs, as well as the ability to select an encoding if the verb is POST or PUT. The available encodings are:

Raw: The current message is sent as a string. If the message is not already a string type, it will be serialized to a string (with a fall-back to JSON-serialization if no string serializer is available). This was the default encoding in prior versions.
Binary: The current message, if it is a byte-array.
Form Data (Multi-part): Has the ability to send the current message, attachments, and arbitrary key-value string data. This is the only encoding that supports sending attachments. See below for more details.
Url-Encoded Form Data: Has the ability to send the current message and arbitrary key-value string data. Attachments are not supported.

Http verb and encoding improvements

When the encoding is set to either Form Data or x-www-form-Url-Encoded, a ‘Form Keys & Values’ UI is shown. Use this UI to select what data you would like included in the form. A Data Type column is displayed which lets you select the type of form item for the given row.

By default, an entry for the primary message is included (the Data Type column is set to Message). When the Data Type is set to message, the value column is disabled (and displays a cross-hatch pattern). You can include one or more attachments within the form data by clicking the Add Form Data button followed by setting the Data Type to attachment.

In the above screenshot, they key has been set to attachments and the value set to *. When the Data Type is set to attachment, the string in the value column is interpreted as a pattern-match string, similar to file matching. For example, if you wish to include all attachments, you can use the * or *.* wildcards. If you wish to only include a specific extension, you can use *.txt, or match a specific name with foo.*.

If you wish to include arbitrary key-value string data, you can set the Data Type to String.

If you have attachments configured but the encoding set to x-www-form-urlEncoded, the attachments will be ignored.

Replace Message

A new feature has been added which allows you to replace the current message with the value returned from the web server. Select Replace Message to enable this feature.

Headers

A new UI has been added to let you enter arbitrary header key-value pairs. By default, the Content-Type header is automatically set. You can override this value by entering your own Content-Type, as well as any other headers.

Custom Code

The main override method has been updated to the following signature (although the previous signature continues to work):

public override async Task ProcessHttpRequestAsync(RequestContext request)
{      
  await SendAsync(request);
}

The request object has been updated to include more related data, including most of the device configuration. For example, you can now set configurations prior to calling the SendAsync method.

    public override async Task ProcessHttpRequestAsync(RequestContext request)
    {
      // form data
      request.FormData.Add(new FormDataItem("mykey", "somevalue", FormDataType.String));      
      // headers
      request.StaticHeaders.Add(new ObservableKeyValue("Content-Type", "Variable"));
      // other config
      request.SetMessageToResponsePayload = true;
      
      await SendAsync(request);
    }

An additional override has been added to allow you to inject your own logic for server certificate validation.

//    optionally implement your own certificate validation logic
//    public override bool ServerCertificateValidationCallback(HttpSenderConfiguration configuration, X509Certificate certificate, X509Chain chain, System.Net.Security.SslPolicyErrors errors)
//    {
//      return base.ServerCertificateValidationCallback(configuration, certificate, chain, errors);
//    }

It is important to not use the static ServicePointManager class as it may alter the behavior of other Connexion / Remote Agent functionality.

Error Handling

A new error-handling call back has been added to allow cleaner custom error logic (previously, error handling could be incorporated directly into the ProcessHttpRequestAsync method). This error callback is called for any exception thrown in ProcessHttpRequestAsync, including when non success (2XX) codes are returned from the server (this requires the Ensure Success checkbox to be checked).

By default, any exception thrown in ProcessHttpRequestAsync will be logged and the message retried indefinitely. If you do not wish to retry indefinitely, you can add custom logic as follows:

In the above example, we are inspecting the HttpResponse object (which is contained in the HttpErrorEventArgs.RequestContext property) for the status code. If it’s InternalServerError (500) and the TotalRetries is at least 3, then we set ShouldRetry to false. This causes the message to be moved to the error queue.