Modify a WebDAV pickup or delivery

The following are the fields on the maintenance pages for the WebDAV transport.

The maintenance pages display the transport fields that can be changed, while the pickup or delivery exchange wizard has only the most commonly used. The following are the fields on the settings and advanced tabs.

Embedded WebDAV settings tab (community)

• Embedded HTTP or HTTPS server – A link is provided to view the settings for the embedded server. You also can change servers.
• Local URL – This URL describes the local port and path the embedded HTTP server uses.
• 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.

Directories tab (community)

Aside from using this tab, you can manage WebDAV users owned by communities or partners by clicking WebDAV users in the navigation graphic at the top of a community or partner summary page.

• Accounts owned by this community – A list of the users and associated directory paths belonging to this community. A specific combination of user and directory can be associated with only one exchange. You can add, change or delete users.
• Accounts owned by partners – A list of the users and associated directory paths belonging to partners. A specific combination of user and directory can be associated with only one exchange. You can add, change or delete users.
• Specify what to do when partners upload messages to subdirectories of the directories listed above
  
  • The Allow option allows the user to write files to any subdirectory under the root path.
  • The Do not allow option allows writing files to a subdirectory under the root path only when a message attribute is set up for each subdirectory level.

See Message attributes tab.

Directories tab (partner)

Aside from using this tab, you can manage WebDAV users owned by communities or partners by clicking WebDAV users in the navigation graphic at the top of a community or partner summary page.

Click Modify to change the user or directory path.

• WebDAV user – The name of the user.
• Directory path – The directory associated with the user. A specific combination of user and directory can be associated with only one exchange.

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. 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 stops or restarts. Backups are needed 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.

Advanced tab (partner)

• Maximum concurrent connections – The number of total open connections Activator server can make to a 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.
  • Note that in the last case, the 200 OK response also will include the receipt if synchronous receipts were requested. Otherwise, it will be a simple 200 OK response with no payload. And if an asynchronous receipt was requested, the partner will connect 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.
• Delete file after it is downloaded – Select this if you want the embedded server to delete files after they have been downloaded from it.
• 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. 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 are needed 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.