Configuring a RESTful HTTP or HTTPS receiver

You can configure a RESTful HTTP or HTTPS receiver as an endpoint for receiving data from a trading partner in a RESTful HTTP or HTTPS exchange. Use Receivers to create and configure a new RESTful HTTP or HTTPS receiver.

To create a RESTful HTTP or HTTPS receiver:

1. Log in to AS4 Microservice as a user with the permissions to create a RESTful HTTP or HTTPS receiver.
2. Click Exchanges > Receivers.
3. On the Receivers page, click New and select RESTful HTTP or HTTPS.
4. On the Create RESTful HTTP or HTTPS Receiver page, specify values for the applicable fields as follows:

   Name

   Enter a unique name for the new RESTful HTTP or HTTPS receiver.

   Description

   Optional: Enter a description for the new RESTful HTTP or HTTPS receiver.

   URL

   Type the URL of the HTTP or HTTPS server. The URL is shared with the trading partners. The trading partners configure the URL in their exchange profile

   Host server

   Select the host server (HTTP or HTTPS) on which you want the RESTful HTTP or HTTPS receiver to be available.

   When the host server receives a message, it checks the RESTful HTTP or HTTPS receiver path, and routes the message to the specified RESTful HTTP or HTTPS receiver.

   Note: Any HTTP or HTTPS servers that do not have either basic authentication or SSL client authentication enable are not displayed.

   Thread pool

   Select a thread pool. A thread pool is a collection of threads. A thread pool manages the threads in the pool to process the tasks. To handle large volumes of files or large files, you can create a thread pool with more number of threads and associate the thread pool to the HTTPS server.

   Virtual file system

   Select a virtual reference point to which an organization writes a request.

   Request size limit

   Optional: Specify a size limit for inbound messages. If the messages that are received exceed the specified limit, the HTTP or HTTPS receiver rejects the messages.

   The default is blank. The HTTP or HTTPS receiver does not reject any messages because of the message size if the size limit is not specified, though a counter tracks the number of bytes received.

   Remember: If the request size limit is reached, the process fails and the system sends an HTTP error code.

   Payload threshold

   Optional: Specify data storage options for the payload.

   If the size of the payload exceeds the threshold size, the payload is stored in storage and a reference to the payload is provided in the message.

   If the size of the payload is equal to or less than the threshold size, the payload is transferred inline with the message.

   Audit store threshold

   Optional: Specify audit store option for when the size of the received raw request is greater than the configured threshold to put the message is put into storage in the audit store. When this occurs, the reference of the storage blob is provided in the visibility event. If the received raw request size is less than the configured threshold, the visibility event is emitted inline with the message.

   User exits

   Optional: User exits provide a call to an external program during the process flow of an HTTP or HTTPS receiver message. You must develop user exits with the provided user exit Java APIs and deploy the OSGi bundles with the user exit commands.

   To add a user exit, click Add New User Exits. On the New user exits page, specify values for the applicable fields as follows:

   Name

   Name of the user exit.

   Description

   Description of the user exit.

   Service ID

   Unique identifier that must start with a letter or an underscore and it cannot contain spaces or special characters.

   Exit point

   Point in the receiver process flow when the user exit is started.

   Pre-process

   With the Pre-process value selected, the user exit is started before the message enters the receiver process flow. User exits started in Pre-process can have a negative impact on performance and slow the progress of the messages through the system. You must include performance testing of your OSGi user exit bundles as part of your user exit development process.

   Post-process

   With the Post-process value selected, the user exit is started after the message exits the receiver process flow. User exits started in Post-process can have a negative impact on performance and slow the progress of the exiting messages through the system. You must include performance testing of your OSGi user exit bundles as part of your user exit development process.

   Click Save. The new user exit is now listed on the User Exit Collection page.

   To select a user exit from the User Exit Collection page, click Select User Exits and select the appropriate Pre-process or Post- process user exit from the drop-down.

5. Click Save to save the RESTful HTTP or HTTPS receiver configuration. Alternatively, click Cancel to cancel your configuration. The RESTful HTTP or HTTPS receiver is automatically started after the configuration is saved.