Updating an HTTP or HTTPS destination

AS4 Microservices delivers a payload to the HTTP or HTTPS destination, as specified by the trading partner. Updating an HTTP or HTTPS destination may include specifying the destination URL, the certificates to be used for the secure connection, and the connection timeout period. You must have master account administrator permissions to update an HTTPS destination.

1. Log in to AS4 Microservice.
2. Click Exchanges and select Destinations.
3. On the Destinations page, click the destination name link (in the Name column) that you want to update.
   In addition to the basic properties that you configured when you created the destination, HTTP properties and HTTPS properties are displayed.
4. Click Edit next to the section you want to update, make necessary changes and click Save. Click Cancel to cancel the updates.
   The following table provides information about HTTP and HTTPS properties.

   Associated Organization

   Click Select and select the owner organization with which the HTTPS destination is associated.

   Name

   Type a name for the destination.

   Description

   Optional: Type a description for the destination.

   Usage availability

   Optional: The Usage availability option has two use cases:

   • Enable destination check box is selected by default. Clear the selection to disable a destination. You might choose to disable a destination according on your requirements.

   • To stop the store and forward service from retrying to send a message when the trading partner destination is down, the communications component in AS4 Microservice might disable a destination. In this case, you must enable the destination by selecting the Enable destination check box.

   Service URL

   Type a service URL. Service URL is the URL of the trading partner destination to where AS4 Microservice delivers the payload in an outbound transaction.

   URL overriding

   Optional: Select the Allow URL to be overriden check box if you want AS4 Microservice to override the HTTP or HTTPS destination that is specified in the exchange profile and use the HTTP or HTTPS destination that is specified in the DestinationAddress element of the business document object (BDO), sent by the business application.

   When you select to override the URL, the HTTP or HTTPS destination URL that is specified in the exchange profile is replaced with the HTTP or HTTPS destination URL specified in the BDO in the message that is sent.

   Based on the agreement with your trading partner, you can choose to override a URL when you are sending a message to a gateway that in turn routes the message to the actual trading partner destination. With the URL overriding function, it is not required for you to configure multiple trading partner profiles in AS4 Microservice.

   Note: You cannot override an HTTP destination to an HTTPS destination or an HTTPS destination to an HTTP destination.

   Important: If the user exit is not configured, you cannot override the HTTP destination for scheduled pull requests for one-way pull and two-way push pull exchanges. For information about configuring user exits, see Configuring user exits.

   Perimeter server

   Select the Enable perimeter server check box to enable the perimeter server that is configured for a particular operational member.

   When the perimeter server is enabled, a document is routed through the perimeter server that is configured for a particular member.

   Based on your requirement, you can use either the perimeter server or the proxy server, and not both.

   Forward proxy

   Optional: Select the Enable forward proxy check box to route the outbound request through a proxy server.

   Typically, the proxy server would be in a less secure zone (demilitarized zone) than AS4 Microservice. The proxy server has access to internet and serves as a single point to apply security settings on the components in the internal network. Additionally, the proxy server serves as a means to hide the components in the internal network from the internet. Responses to requests from AS4 Microservice are routed back through the proxy server. To a destination configured for a forward proxy, AS4 Microservice sends the entire HTTP URL for forwarding to the destination. HTTP CONNECT tunneling is used for both HTTP and for HTTPS destinations.

   After you select Enable forward proxy, enter the Host and Port number for the proxy server.

   Note: Based on your requirement, you can use either the perimeter server or the proxy server as a forward proxy, but not both.

   Enable forward proxy authentication

   Optional: If you have enabled forward proxy, you can choose to enable user authentication for the proxy server.

   Select Enable forward proxy authentication and select the required credential, or click Add Credential to add an organization credential.

   Basic authentication

   Optional: Select the Enable basic authentication check box to enable basic authentication at the transport layer (HTTP or HTTPS) level.

   To add a credential that can be used for authentication, click Add credential.

   To select a credential, click the Credential drop-down list.

   The user name and password is owned by the trading partner organization and provided to the owner organization outside the scope of AS4 Microservice.

   SSL connection options

   Optional: Select the Enable SSL check box and select a certificate that must be used for SSL connection.

   To add a certificate, click Add Certificate.

   Optional: Select the Enable client authentication check box and select a Client authentication certificate that must be used client authentication.

   Select one of the following SSL connection options:

   • Use the global trust store - Select the option to use the global trust store to secure the connection with the destination.
   • Select the Root/Intermediate certificates or a self-signed certificate to use - Select the option to add a certificate that must be used to secure the connection with the destination.

   Select the connection protocol or configuration to securely transfer messages from SSL protocol. Default value is TLSv1.2 for AS4 Microservice version 1.0.0.5 and higher.

   Select the level of security attributed to the connection protocol from Security level. The default value is HIGH.

   Important: Selecting an SSL protocol for message exchanges, including such configurations as SSL_TLS, SSL_TLSv2, SSL, SSLv2, SSLv3, is not suggested. A security risk exists for all SSL protocols. Available TLS connection protocols include TLS, TLSv1, TLSv1.1, and TLSv1.2.

   Important: If you are using a custom system certificate using SHA-1 or MD5, you must replace it with a certificate that uses SHA-2.

   Connection timeout

   Type the number of seconds AS4 Microservice must wait for a response from the HTTP or HTTPS destination before the connection times out. The default is 60 seconds.

   Thread pool

   Select the thread pool to be used by AS4 Microservice to optimize task execution when delivering to the destination.

   Retry policy

   Select the retry policy to be used by AS4 Microservice. The default is Aggressive Retry Policy. The retry policy defines the retransmission options for the destination.

   Retries are performed in the following situations:

   • The destination is not available (for example, if your trading partner's server is down)
   • The destination is unreachable (for example, if the URL or port is invalid)
   • An SSL failure occurred
   • A certificate issue occurred (for example, if the certificate is invalid)

   Important: If the data is transmitted and the data transfer is broken, retry is not performed.

   Payload threshold size

   The payload threshold size setting, specified in kilobytes, is applied for packaged raw request (audit threshold) or any response or receipt that is received from the trading partner (payload threshold). In the HTTPS destination, the field has the following use cases:

   • If the size of the packaged raw request is greater than the threshold, the message is put into storage (audit store) and a reference of the storage blob is provided in the visibility event. If the packaged raw request size is less than the threshold, a visibility event is emitted with the data inline.
   • If the size of the response payload that is received from the trading partner is more than the threshold size, the payload is stored in storage and a reference is provided in the message data that is sent to the business application. If the size of the response payload is equal to or less than the threshold size, the payload is sent to the business application inline with the message data.

   Chunked encoding threshold size

   The Chunked Encoding threshold size is a value 0 - 2097151 KB (approximately 2 GB) that represents the total message file size.

   If the size of a message is greater than the threshold, the message is transmitted with Chunked Transfer-Encoding (CTE). If the size of the message is less than the threshold, the message is transmitted without CTE.

   To enable Chunked Transfer-Encoding for all messages to this destination, leave the field blank. If the field stays blank, the threshold size defaults to 0, and all messages are transmitted with CTE to the HTTP or HTTPS destination.

   User exits

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

   To select a user exit, click Select User Exit. To add a user exit, click Add New User Exit. 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 destination process flow when the user exit is started.

   Pre-delivery

   With the Pre-delivery value selected, the user exit is started before the message enters the destination process flow. User exits started in Pre-delivery 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-delivery

   With the Post-delivery value selected, the user exit is started after the message exits the destination process flow. User exits started in Post-delivery 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-delivery or Post-delivery user exit from the drop-down.

   Read timeout

   Specify the period of time, in seconds, that can elapse while the HTTP transport channel waits on a socket for each portion of response data to be read. Specifically, if the server fails to send a byte <timeout> seconds after the last byte, a read time out error will be raised. The default is 60 seconds.

   Write timeout

   Specify the period of time, in seconds, that can elapse while the HTTP transport channel waits on a socket for each portion of response data to be transmitted. This timeout typically occurs in situations where responses lag behind new requests. The default is 60 seconds.

   Keep-alive enabled

   Optional: To specify that keep-alive be used for persistent connections, select Enable keep-alive for persistent connections. Keep-Alive is a header that maintains a persistent connection between client and server, preventing a connection from breaking intermittently by allowing the same TCP connection for HTTP communication instead of opening a new connection for each new request.

   Use keep-alive

   Optional: Enable the use of the keep-alive connection.

   Keep-alive value

   Optional: Specify the period of time, in seconds, that the persistent keep-alive connection can be maintained. The default is 60 seconds.