You may want your clients to enqueue messages by posting an HTTP request, or you may need to send messages to their web server by posting an HTTP request. Platform supports HTTP/S enqueue/dequeue for this purpose.

Enqueue

Clients can enqueue a Message by calling the REST resource at http://hostname/oms/rest/queue/enqueue. See the javadocs for PlatformRestClient for details on how to authenticate when connecting.

The body of the request should contain the payload for the Message. Several other query arguments are required on the URL to successfully enqueue the message:

QueueName (required): identifies the queue into which the new message will be enqueued
Id (optional): unique message ID provided by the sender. (If not provided, one is generated automatically. Users are recommended to provide this field to increase traceability.)
Sender (required): string that identifies the sender
InboundInterface (required): what interface to use to process the message
InboundInterfaceVersion (required): what version of the interface to use to process the message
InboundQueueEnterpriseName (optional): identifies the enterprise with which the inbound queue is associated.

Dequeue

As with File and SFTP dequeuing, one can configure Platform to send to an HTTP or HTTPS destination through the configuration of a MessageDestination.

A MessageDestination of DestinationType HTTP is used to configure the final destination for a message being dequeued to HTTP or HTTPS. To connect through HTTP, we need parameters like URL, HTTP Method (GET or POST), request headers, and request parameters.

<MessageDestination>
	<ValueChainId>9123</ValueChainId>
	<Name>outbox/Orders/HTTP</Name>
	<DestinationType>HTTP</DestinationType>
	<Config>{'url': 'https://integration.mydomain.com/path', 'method':'POST', 'params': {'message':'%{payload}'}}</Config>
</MessageDestination>

Note that the string %{payload} will be replaced with the actual contents of the Message payload when submitting the HTTP request when used within params or body configuration.

The Config is a JSON object containing:

url (required): HTTP or HTTPS URL
method (required): GET or POST
headers (optional): JSON Object containing request header names and values
params (optional): JSON Object containing request parameter names and values. For GET, these will be submitted as query arguments. For POST, they will be submitted in the POST body.
body (optional): the content of the request body to be submitted (POST only)
keystoreFile (optional): A JKS (Java KeyStore) file that contains the client's key pair. Must be in JKS format; no other keystore formats are supported. It is best to place this file on the shared filesystem; that way all NEO servers can access it from the same location and it isn't necessary to create multiple copies for a single NEO cluster.
keystorePass (optional): The password to access the keystoreFile.

There is a password for both the keystoreFile and each key pair inside the keystoreFile. ONE assumes the password of the keystoreFile matches the password on each key pair inside the file. If they mismatch, authentication will fail.
truststoreFile (optional): A JKS (Java KeyStore) file that contains the public keys of the server and the public keys against which the client's key is signed. Must be in JKS format; no other keystore formats are supported. It is best to place this file on the shared filesystem; that way all NEO servers can access it from the same location and it isn't necessary to create multiple copies for a single NEO cluster.
truststorePass (optional): The password to access the truststoreFile. Unlike the keystoreFile, there are no passwords for individual items inside the truststore.