Use the Schedule tab to set times for making a pickup or delivery exchange inactive while keeping the transport in an enabled state. For example, you could set a schedule to turn off the exchange for a few hours once a week to perform maintenance on a transport server. Note, however, that the Schedules tab is dependent upon the configuration of the Advanced tab.
By default exchanges are active continuously. Schedules are added by day of the week and time of day. For instance, if you select Monday 0:00 - 23:59, the exchange is on all day every Monday. If you select Monday 8:30 - 11:30, the exchange is on from 8:30 to 11:30 a.m. and off all other times on Mondays.
Times are expressed in 24-hour format: hh:mm or h:mm. Times are the time zone for your server. Your server’s time zone is displayed in parentheses following the sentence Times are in your server’s time on the Schedule tab.
When determining the length of time to set for a Schedule's "on" time, allow for a minimum of three to four polling intervals to fully complete during that "on" time.
If you schedule down times for a pickup used by a community to receive messages from partners, you may want to inform partners when the transport is inactive.
If you want an exchange to be active most of the time but turned off only some of the time, you may need many schedules specifying the daily times you want the transport to be on or off. For example, to schedule a transport to turn off between 1 and 2 p.m. each Saturday, eight schedules are needed as follows: six daily schedules calling for the transport to run continuously Sunday through Friday and two Saturday schedules, the first specifying the transport is on from midnight to 1 p.m. and the second specifying the transport is on from 2 p.m. to midnight.
Messages in queue when a transport turns off are suspended until the transport turns back on. For example, if a message is picked up from an application while the transport for sending to a partner is turned off, Message Tracker reports the status for the message as “scheduled production.” When the transport turns on again, processing of the message continues. Similarly, retries and resends for messages are suspended while the transport is off, but they resume at the point where they were suspended when the transport turns back on.
To use schedules, make sure message backups are enabled for the affected transports. Unless backups are enabled, messages in process when a transport turns off cannot be queued to resume processing when the transport turns on again.
If you trade via the AS2 message protocol and request asynchronous receipts, your community cannot receive receipts from partners when the sending transport is turned off. To avoid this, request synchronous receipts or schedule a transport to be off when no messages are in process.