Trading configuration > Community trading pickups and partner deliveries > Fields for modifying community pickups and partner deliveries > Modify an HTTP transport

Modify an HTTP transport

The following topics document the fields on the maintenance pages for HTTP transports.

The maintenance pages display all of the transport fields that can be changed, while the exchange wizard has only the most commonly used. The following are the fields on the Settings and Advanced tabs.

If you require information about SSL authentication, see SSL authentication.

For information about managing cXML user lockouts, see Lockout settings for cXML (embedded HTTP) users.

When Activator sends a message via HTTP, it is the HTTP client. The endpoint Activator is connecting to is the HTTP server.

HTTP error codes are reported in Activator log files. When you see an HTTP code in a log file, Activator merely is echoing the code returned by an HTTP server, firewall, proxy server or load balancer.

The response code for a successfully sent message is 200 (meaning “OK”). When a 503 code is returned, this may be due to action by Activator system throttle. A 503 code indicates service temporarily is unavailable. The throttle attempts to monitor the message load by looking at available memory and the depth of internal queues. When a loaded condition is detected, consumption of new work is halted. This means two things: exchange points stop polling and embedded servers return a 503 code.

For a complete list of HTTP codes, go to http://www.ietf.org/rfc/rfc2616.txt and see section 10 of the document.

Embedded HTTP settings tab

Embedded HTTP server – A link is provided to view the settings for a particular embedded server or for the global embedded server. If a particular server, you can change servers.
Local URL – This URL describes the local port and path the embedded HTTP server uses. A server starts on each computer in the cluster using this information. If you have only one computer, only one server is started.
URL used by partners – This is the URL your partners use to send messages to this delivery exchange. When you export your community profile as a partner profile, the URL becomes part of your exported partner profile. The host, port and path may be different than the values in the local URL. If your network uses a load balancer or firewall, contact your network administrator for the correct value. This URL should include the fully qualified host name or IP address, port number and path where partners must connect to send messages.
If your local URL is HTTP and you use an SSL terminator in the DMZ for inbound connections, the partner must send messages to the terminator and not to Activator. You must specify the HTTPS URL of the terminator as the URL used by partners. Make sure the terminator can forward messages to Activator. Your partner also must import and trust the public-key certificate from your SSL terminator. Activator cannot include this certificate when the community profile is exported as a partner profile.

Advanced tab (community)

Back up the files that go through this transport – Indicates whether the system backs up copies of the messages it retrieves from integration or receives from partners. Backing up files is strongly recommended. This is required for the system to perform fail-over operations such as attempting to send messages again (retries) in case of a transport connection failure. Without backups, a message in process cannot be recovered if the server or a processing node stops or restarts. Backups also are needed if you want the ability to resubmit messages to back-end applications or resend messages to partners.
Backup files are stored in \<install directory>\common\data\backup, unless you specify otherwise.
Restrict maximum file size for this transport – Optionally lets you specify the maximum size of files a transport can handle.
If Activator receives a file larger than the maximum, the file is rejected and a message is written to the events log. If received via HTTP, a 413 response also is sent and the connection is closed. A 413 message is Request Entity Too Large.
The maximum size must be expressed in bytes. Do not use commas. For instance, a kilobyte is 1024 bytes, a megabyte is 1048576 bytes, a gigabyte is 1073741824 bytes.
The smallest maximum allowed is 1000 bytes. On the opposite extreme, you can enter the largest number the field can accommodate.
This control is available only for transports used for picking up messages from integration or receiving messages from partners.

HTTP or HTTPS settings tab (partner)

URL – The URL for connecting to the server. If Encode and Decode buttons display, click Encode if the URL contains spaces or non-alphanumeric characters to encode the characters. Click Decode to reverse the transformation. For example, if you enter http://foo.com/foo= bar and click Encode the URL becomes http://foo.com/foo%3D%20%20bar.
Clients must use SSL to connect to this server – Select this to have Secure Sockets Layer protocol in use during connections. The server presents a certificate for verification. To do this, a certificate in a Community or Partner definition must be designated as the SSL certificate. The server must support SSL. If this is not selected, connections are not encrypted.
Enable host name verification – If selected, Activator compares the name of the SSL server to the name in the server’s certificate to ensure they are the same.
This server requires a user name and password – If selected, type a user name and password to connect to the server.

Advanced tab (partner)

Retries – This is the number of times Activator will retry connecting to the partner’s transport if the initial attempt to connect and send the message failed. The following are common reasons for triggering retries.
- The connection attempt failed immediately for a reason such as host not found.
- The host was found, but the connection process took longer than the connect timeout interval specified on the Advanced tab.
- The connection was successful, but the partner’s HTTP server took longer than the response timeout interval to return a 200 OK response indicating the message was successfully received. A 200 OK response is a transport response, separate from a message protocol response such as an AS2 receipt.
In the last case, the 200 OK response also includes the receipt if synchronous receipts are requested. Otherwise, it is a simple 200 OK response with no payload. And if an asynchronous receipt is requested, the partner connects later to send it.
Retries occur according to an algorithm that starts at 5 minutes. The interval between retries increases with each subsequent retry in this pattern: 10 minutes, 15 minutes, 30 minutes, 60 minutes. The interval plateaus at 60 minutes. This means if the retry value is greater than 5, the fifth and each subsequent retry occurs at 60 minute intervals.
For example, if retries is 3, the system will try connecting again in 5 minutes if the initial connection attempt fails. If this retry attempt also fails, the system attempts a second retry in 10 minutes. The third retry attempt is made 15 minutes later. If the third retry attempt fails, the message is given a failed status. So after four attempts (the first attempt plus 3 retries), the message fails. You can search for and manually resubmit failed messages in Message Tracker.
Retries do not occur precisely at these intervals because each connection attempt takes some seconds, which varies by computer. So retries actually occur after the connection attempt time plus the interval.
This control applies only to retrying to send messages, not receiving. It applies only to retrying to send related to transport issues. It does not apply to successfully sent messages for which receipts have not been received as expected. Another control, resends, determines how many times the system will resend a message when a receipt is not received from the partner. For information about resends, see reliable messaging in the collaboration settings chapter.
Connect timeout (seconds) – Time in seconds Activator waits for a connection to the delivery exchange before the attempt times out. Although the default value is 30 seconds, this may be longer than the interval allowed by your operating system (OS). For example, Windows XP by default allows a maximum timeout of 20 seconds. The actual connect timeout interval is the lesser of the OS timeout and the value set in Activator.
Read timeout (seconds) – Time in seconds Activator waits to read data from the delivery exchange before terminating the connection.
Response timeout (seconds) – The limit in seconds that Activator waits for the delivery exchange to respond to a request before terminating the connection.
If the business protocol is AS2, the response timeout value is dynamically computed by Activator before the file is sent from the HTTP client partner to the receiving HTTP server. This value is directly related to the file size; a larger file size results in a larger response timeout value. This dynamic computation allows the receiving HTTP server more time to process a larger file.
Enable HTTP chunking – If you are sending files larger than 2 gigabytes, select this to turn on chunking. A chunked message is a large message broken into smaller pieces for sending to a partner over the Internet or to back-end integration.
Although primarily for handling large messages, chunking can be enabled for small messages, too. However, if your partners use a trading engine other than Activator or use an external or staged HTTP server, they may be unable to accept messages larger than 2 gigabytes, even if the messages are chunked.
Also, in rare cases a partner’s HTTP server may be unable to handle chunked messages, regardless of message size. You should perform tests to determine whether a partner’s server can handle chunked messages. If not, the partner must use Activator with the embedded server to receive large chunked messages successfully.
If you enable chunking because of large messages, you should also request that receipts be sent over an asynchronous connection. See the chapter on collaboration settings for details.
Attempt restarts – Select this to turn on checkpoint-restart. A checkpoint is information saved to disk that is a recovery point in the event of a transport failure. The restart program uses the last saved checkpoint and starts again, ensuring no loss of data.
The checkpoint files are saved on the server under the [install directory]/common/data/http/restartable, which is normally common to all nodes in the cluster. Thus, if a transfer is interrupted and the load balancer directs the restart request to a different node, the restart file will be accessible to the new node even though it did not process the original request.
To reduce unnecessary overhead when processing small files, checkpoint files are only created for messages that are at least 100 KB in size. Also, if a restart is attempted for a message whose checkpoint file on the server is more than four hours old, the checkpoint file will be discarded and the entire message will be retransmitted.
The restart logic is used only during transport retries, such as might occur when a transfer is interrupted due to network problems. If you resubmit a message in Message Tracker, no attempt is made to perform a checkpoint-restart.
This feature only works if your partner uses Activator and its embedded HTTP server. Do not select this option if a partner uses an external or staged HTTP server or uses a trading engine other than Activator.
Enable use of 102-processing – This option is available to ensure the connection between the client and server does not become idle and fail while message processing is in progress. For example, this makes sure the connection remains active when the client is sending a multi-gigabyte message. Or, to prevent a firewall from disconnecting an idle connection before the server receives the entire message and returns a 200 OK response. Most often this setting is useful when the client requests a synchronous receipt, but also could be recommended in some cases for an asynchronous receipt.
Selecting this option directs Activator to add the following to the header of an outbound message: Expect: 102-processing. This is an HTTP response code that indicates processing is in progress. If the receiving server supports 102 responses, the header triggers the server to send 102 responses to the client repeatedly until the server has completely processed the inbound message.
Before selecting this option, make sure the server supports 102 responses. If you turn on 102 processing and the server does not support it, the server will return a 417 message (the server could not meet the expectation given in the Expect header) and the connection may fail. If the receiving partner uses the embedded HTTP server in Interchange 5.5.1 or later, 102 responses are supported. This also is supported if your partner uses Jetty 6 or later.
Receiver is Axway Gateway – This field appears only when an HTTP or HTTPS transport under the secure file message protocol has been added to a partner profile.
Selecting this option enables Activator to send messages successfully to Axway Gateway via secure file HTTP.
Upon receiving a secure file HTTP message from Activator, Axway Gateway expects to find the payload’s file name in the HTTP POST request URL. Normally, Activator does not include this. But when the option is selected, Activator appends ?filename=name to the URL, where name is the production file name.
Override SSL and TLS cipher suites – Select this option and then use the Add and Remove buttons to specify the cipher suites supported for the embedded server. If not selected, all cipher suites are supported by default.
Keeping the default cipher list is less secure than specifying a restricted set of cipher suites.
The cipher suites that are displayed in the "Available" column depend on your runtime environment (JRE version, IACK or FIPS enablement,configuration, ....).
The default order in the "Available" column is the preferred order of use. Once ciphers are moved to the Selected column, you can arrange the order. Activator uses the ciphers in the order listed.
A cipher suite is a collection of security algorithms used in making connections via Secure Sockets Layer or Transport Layer Security. For example, an SSL or TLS protocol requires signing messages using a message digest algorithm. But the choice of algorithm is determined by the particular cipher suite being used for the connection. Typically, you can select an MD5 or SHA digest algorithm.
Of the many algorithms for encrypting data and computing the message authentication code, there are varying levels of security. Some provide the highest levels of security, but require a large amount of computation for encryption and decryption. Others are less secure, but provide rapid encryption and decryption. The length of the key used for encryption affects the level of security. The longer the key, the more secure the data.
The option for overriding cipher suites lets you select the level of security that suits your needs and enables communicating with others who might have different security requirements. For example, when an SSL connection is established, the client and server exchange information about the cipher suites they have in common. Then they communicate using the common cipher suite that offers the highest level of security. If they do not have a cipher suite in common, secure communication is not possible.
In versions of Activator earlier than Interchange 5.9, cipher suites configuration was handled by a file named sslciphersuites.xml. As data in that file is saved in the database, the custom cipher suites configuration is retained upon upgrading and is displayed in the Selected list under the option in the user interface. The sslciphersuites.xml file is no longer used.
Back up the files that go through this transport – Indicates whether the system backs up copies of the messages it retrieves from integration or receives from partners.
Backing up files is strongly recommended. This is required for the system to perform fail-over operations such as attempting to send messages again (retries) in case of a transport connection failure. Without backups, a message in process cannot be recovered if the server or a processing node stops or restarts. Backups also are needed if you want the ability to resubmit messages to back-end applications or resend messages to partners.
Backup files are stored in \<install directory>\common\data\backup, unless you specify otherwise.
Post-processing script – The full path to an executable file that contains post-processing commands. This field is available for community integration delivery exchanges and partner trading delivery exchanges.