Modify an OFTP pickup or delivery
The following topics document the fields on the maintenance pages for Odette File Transfer Protocol V1 and V2.
The maintenance pages display the transport fields that can be changed, while the delivery or pickup exchange wizard has only the most commonly used. The following are the fields on the settings and advanced tabs.
For general information about pickup and delivery maintenance see:
The fields for configuring OFTP V1 and OFTP V2 are the same, except as noted.
Field descriptions:
Embedded OFTP and OFTP TLS settings tab (community)
- Server name – The name for the embedded OFTP server. This can be any name you want.
- View settings for this embedded server – Click this link to manage the embedded server. For details, see the embedded transport servers chapter.
- Local connection string – The port and path of the embedded server. You cannot edit this field.
- Connection string used by partners – When you export your community profile as a partner profile and give it to partners, this is the string partners use to connect to your embedded server. If your network uses a load balancer or a firewall, you may need the help of your network administrator to edit this field.
- SSID identification code – The start session identification (SSID) of the local or remote party. Trading partners exchange SSIDs to identify each other in the protocol handshake and session setup.
- OFTP protocol version – The protocol version.
- Partner uses RFC 2204, not RFC 5024 – For OFTP V1 only when protocol version is 1.3, this check box tells Activator the protocol release level (SSIDLEV) to use for the trading partner. Select the check box if the partner uses the RFC 2204 implementation. This means the SSIDLEV field in the start session (SSID) command has a value of 1. Do not select the check box if the partner uses the RFC 5024 implementation. This means the SSIDLEV field in the SSID command has a value of 2. (Note that in either case the exchange point is being defined for OFTP protocol revision level 1.3.)
- Require secure OFTP authentication – For OFTP V2 only, this is an extra layer of security to enable senders and receivers to validate each other as genuine. There are two requirements to enable secure OFTP authentication:
- Both the sender and receiver must enable secure OFTP authentication. If one party turns it on and the other party does not, a protocol error is generated and the session between the parties is disconnected.
- Both the sender and receiver must be using certificates. These are the normal certificates used by a community and its partners to securely exchange messages. These are not TLS certificates, which are additional certificates needed if TLS is configured for a delivery exchange.
- This is how the authentication works: The initiator of the connection uses the partner’s public key to encrypt and send a short, random message to the partner. The partner decrypts the message with its private key and sends the message back. The initiator compares the response to the original message. If the messages match, the initiator has authenticated the partner. The partner repeats the process to validate the initiator.
- Set OFTP session password – Enter a password only when required. The password can be no longer than eight alphanumeric characters and is case sensitive.
- If this is an exchange for receiving messages from a partner, your community presents this password to the partner. The password is compared to the one the partner has stored for your community.
- If this is an exchange for sending messages to a partner, the partner must present this password to your community. The password is compared to the one your community has stored for the partner.
- In either case, the passwords must match to establish the connection.
Embedded OFTP X.25 and embedded OFTP X.25 over ISDN settings tab (community)
- Server name – The name for the embedded OFTP server. This can be any name you want.
- View settings for this embedded server – Click this link to manage the embedded server. For details, see the embedded transport servers chapter.
- Connection string used by partners – When you export your community profile as a partner profile and give it to partners, this is the string partners use to connect to your embedded server. If your network uses a load balancer or a firewall, you may need the help of your network administrator to edit this field.
- SSID identification code – The start session identification (SSID) of the local or remote party. Trading partners exchange SSIDs to identify each other in the protocol handshake and session setup.
- OFTP protocol version – The protocol version being used (1.3 or 1.4).
- Partner uses RFC 2204, not RFC 5024 – For OFTP V1 only when protocol version is 1.3, this check box tells Activator the protocol release level (SSIDLEV) to use for the trading partner. Select the check box if the partner uses the RFC 2204 implementation. This means the SSIDLEV field in the start session (SSID) command has a value of 1. Do not select the check box if the partner uses the RFC 5024 implementation. This means the SSIDLEV field in the SSID command has a value of 2. (Note that in either case the exchange point is being defined for OFTP protocol revision level 1.3.)
- Set OFTP session password – Enter a password only when required. The password can be no longer than eight alphanumeric characters and is case sensitive.
- If this is an exchange for receiving messages from a partner, your community presents this password to the partner. The password is compared to the one the partner has stored for your community.
- If this is an exchange for sending messages to a partner, the partner must present this password to your community. The password is compared to the one your community has stored for the partner.
- In either case, the passwords must match to establish the connection.
OFTP and OFTP TLS settings tab (partner)
- Hostname – If TCP, the fully qualified domain name or IP address of the OFTP server.
- Port – The TCP port on which the server listens for connection requests. This field does not apply to OFTP V1 X.25.
- SSID identification code – The start session identification (SSID) of the local or remote party. Trading partners exchange SSIDs to identify each other in the protocol handshake and session setup.
- OFTP protocol version – The protocol version.
- Partner uses RFC 2204, not RFC 5024 – For OFTP V1 only when protocol version is 1.3, this check box tells Activator the protocol release level (SSIDLEV) to use for the trading partner. Select the check box if the partner uses the RFC 2204 implementation. This means the SSIDLEV field in the start session (SSID) command has a value of 1. Do not select the check box if the partner uses the RFC 5024 implementation. This means the SSIDLEV field in the SSID command has a value of 2. (Note that in either case the exchange point is being defined for OFTP protocol revision level 1.3.)
- Require secure OFTP authentication – For OFTP V2 only, this is an extra layer of security to enable senders and receivers to validate each other as genuine. There are two requirements to enable secure OFTP authentication:
- Both the sender and receiver must enable secure OFTP authentication. If one party turns it on and the other party does not, a protocol error is generated and the session between the parties is disconnected.
- Both the sender and receiver must be using certificates. These are the normal certificates used by a community and its partners to securely exchange messages. These are not TLS certificates, which are additional certificates needed if TLS is configured for a delivery exchange.
- This is how the authentication works: The initiator of the connection uses the partner’s public key to encrypt and send a short, random message to the partner. The partner decrypts the message with its private key and sends the message back. The initiator compares the response to the original message. If the messages match, the initiator has authenticated the partner. The partner repeats the process to validate the initiator.
- Select a different encryption certificate for secure authentication – Select the partner certificate to use for secure authentication other than the default certificate.
- Clients must use TLS to connect to this server – Select this to set up Transport Layer Security for the OFTP delivery exchange. When selected, the following sub-field displays.
- Note: If the sub-field is selected, you cannot clear the check box.
- Enable host name verification – If selected, Activator compares the name of the TLS server to the name in the server’s certificate to ensure they are the same.
- Set OFTP session password – Enter a password only when required. The password can be no longer than eight alphanumeric characters and is case sensitive.
- If this is an exchange for receiving messages from a partner, your community presents this password to the partner. The password is compared to the one the partner has stored for your community.
- If this is an exchange for sending messages to a partner, the partner must present this password to your community. The password is compared to the one your community has stored for the partner.
- In either case, the passwords must match to establish the connection.
OFTP X.25 settings tab (partner)
- Remote network user address – The NUA of the remote partner’s server to connect to (OFTP V1 X.25 only).
- Protocol identifier – Custom data to send to the partner along with the call establishment request. The data is only meaningful for the remote party. It is usually used to distinguish between calls that are addressed to the same NUA. You must enter a hexadecimal value.
- Call user data – Custom data to send to the partner along with the call establishment request. The data is only meaningful for the remote party. It is usually used to distinguish between calls that are addressed to the same NUA. You must enter a hexadecimal value.
- X.25 router – The name of the X.25 router specified for the delivery exchange.
- Charge called party instead of caller – When this check box is select, and when supported by the carrier and accepted by the partner upon call establishment, the called party is charged for the call instead of the caller (OFTP V1 X.25 only).
- SSID identification code – The start session identification (SSID) of the local or remote party. Trading partners exchange SSIDs to identify each other in the protocol handshake and session setup.
- OFTP protocol version – The protocol version being used (1.3 or 1.4).
- Partner uses RFC 2204, not RFC 5024 – For OFTP V1 only when protocol version is 1.3, this check box tells Activator the protocol release level (SSIDLEV) to use for the trading partner. Select the check box if the partner uses the RFC 2204 implementation. This means the SSIDLEV field in the start session (SSID) command has a value of 1. Do not select the check box if the partner uses the RFC 5024 implementation. This means the SSIDLEV field in the SSID command has a value of 2. (Note that in either case the exchange point is being defined for OFTP protocol revision level 1.3.)
- Set OFTP session password – Enter a password only when required. The password can be no longer than eight alphanumeric characters and is case sensitive.
- If this is an exchange for receiving messages from a partner, your community presents this password to the partner. The password is compared to the one the partner has stored for your community.
- If this is an exchange for sending messages to a partner, the partner must present this password to your community. The password is compared to the one your community has stored for the partner.
- In either case, the passwords must match to establish the connection.
OFTP X.25 over ISDN settings tab (partner)
- ISDN controller – The ISDN controller, selected from a drop-down list, to use for the outgoing call.
- Partner ISDN number – For ISDN, the partner’s ISDN number. If prefixes are required to access an external line or an international number, include those in the number.
- Remote X.25 network user address – The X.121 address of the partner if the call is to be routed over X.25. If the call is established directly to the partner’s ISDN number, this number may be optional depending on its access control configuration.
- X.25 call user data – This value is passed to the X.25 connection request. Depending on the configuration on the partner’s side, this may be used to select the software responsible for answering the call. You must enter a hexadecimal value.
- SSID identification code – The start session identification (SSID) of the local or remote party. Trading partners exchange SSIDs to identify each other in the protocol handshake and session setup.
- OFTP protocol version – The protocol version being used (1.3 or 1.4).
- Partner uses RFC 2204, not RFC 5024 – For OFTP V1 only when protocol version is 1.3, this check box tells Activator the protocol release level (SSIDLEV) to use for the trading partner. Select the check box if the partner uses the RFC 2204 implementation. This means the SSIDLEV field in the start session (SSID) command has a value of 1. Do not select the check box if the partner uses the RFC 5024 implementation. This means the SSIDLEV field in the SSID command has a value of 2. (Note that in either case the exchange point is being defined for OFTP protocol revision level 1.3.)
- Set OFTP session password – Enter a password only when required. The password can be no longer than eight alphanumeric characters and is case sensitive.
- If this is an exchange for receiving messages from a partner, your community presents this password to the partner. The password is compared to the one the partner has stored for your community.
- If this is an exchange for sending messages to a partner, the partner must present this password to your community. The password is compared to the one your community has stored for the partner.
- In either case, the passwords must match to establish the connection.
OFTP shared settings tab (partner)
This tab applies only to an OFTP delivery exchange that was set up by one partner but also is used by, or shared with, another partner. It displays only for the partner sharing the exchange and not the partner with the original delivery exchange.
The tab displays a link to the delivery exchange being shared. The link includes the name of the partner that owns the exchange point. Click the link to display the original delivery exchange. If the name is not an active hyperlink, you do not have permissions to view or change the original delivery exchange.
The Advanced tab for a shared delivery exchange only displays the fields the sharing partner can change. Other advanced settings only can be changed by changing the Advanced settings in the original delivery exchange. If your user is associated with a role that restricts access to partners, it is possible you may lack permissions to change settings of the original delivery exchange.
Sharing partners tab (partner)
This tab applies only to an OFTP delivery exchange that was set up by one partner but also is used by, or shared with, another partner. It displays only for the partner who owns the original delivery exchange.
The tab lists the names of the other partners who also use the exchange. If the exchange is not being shared, no partners are listed. Click the name of the partner to go to the partner’s maintenance page for the shared delivery exchange.
If the delivery exchange is shared, any changes on the OFTP settings tab or to settings on the Advanced tab unique to the original exchange also affect any partners that share the exchange. In addition, an exchange that is shared cannot be deleted unless the exchanges of the sharing partners are deleted first.
Advanced tab (community)
- Read timeout (seconds) – The maximum number of seconds the server waits when reading data from a partner.
- Credit counter – The number of consecutive data exchange buffers sent by the speaker before it must wait for a credit (CDT) command from the listener.The credit value is only applied to data flow in the data transfer phase. The speaker's available credit is initialized to SSIDCRED when it receives a start file positive answer (SFPA) command from the listener. It is zeroed by the end file (EFID) command. After negotiation, the smallest size must be selected in the answer of the responder or a protocol error aborts the session.
- Data exchange buffer – The length in octets of the largest acceptable data exchange buffer. The length includes the command octet, but not the stream transmission header. After negotiation, the smallest size is selected. The value in this field maps to the SSIDSDEB field in the SSID OFTP protocol command.
- Backend will generate receipts (EERPs and NERPs) – Select this option if Activator should pause before generating and sending EERPs (signed end-to-end responses) and NERPs (signed negative end responses). Activator waits for a back-end system to submit messages containing the correct metadata for generating EERPs and NERPs. If not selected, Activator synchronously generates and sends EERPs and NERPs without waiting for the back-end system to respond.
- 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 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.
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.
- An OFTP protocol error occurred. For example, the partner returned a negative response to a query on whether to start the file transfer.
- 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.
- 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.
- Read timeout (seconds) – The maximum number of seconds the server waits when reading data from a partner.
- Credit counter – The number of consecutive data exchange buffers sent by the speaker before it must wait for a credit (CDT) command from the listener.
- The credit value is only applied to data flow in the data transfer phase.
- The speaker's available credit is initialized to SSIDCRED when it receives a start file positive answer (SFPA) command from the listener. It is zeroed by the end file (EFID) command.
- After negotiation, the smallest size must be selected in the answer of the responder or a protocol error aborts the session.
- Data exchange buffer – The length in octets of the largest acceptable data exchange buffer. The length includes the command octet, but not the stream transmission header. After negotiation, the smallest size is selected. The value in this field maps to the SSIDSDEB field in the SSID OFTP protocol command.
- Override local SSID code and password – Select this check box to have this partner exchange use an SSID code and password different than the values set on a community’s OFTP delivery exchange. If selected, you must enter the override SSID code. Entering an override password is optional. This password overrides the password in the field named “This server requires a session password,” which is an optional field for a community OFTP delivery exchange.
- 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 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.
Advanced tab for X.25 (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.
- An OFTP protocol error occurred. For example, the partner returned a negative response to a query on whether to start the file transfer.
- 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.
- 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.
- Packet size – For OFTP X.25, the size of the X.25 packet. If the value is blank the network’s default value is used. You must enter a hexadecimal value.
- Window size – For OFTP X.25, the number of X.25 packets that can be sent without acknowledgment. If the value is blank the network’s default value is used. You must enter a hexadecimal value.
- Credit counter – The number of consecutive data exchange buffers sent by the speaker before it must wait for a credit (CDT) command from the listener.
- The credit value is only applied to data flow in the data transfer phase.
- The speaker's available credit is initialized to SSIDCRED when it receives a start file positive answer (SFPA) command from the listener. It is zeroed by the end file (EFID) command.
- After negotiation, the smallest size must be selected in the answer of the responder or a protocol error aborts the session.
- Data exchange buffer – The length in octets of the largest acceptable data exchange buffer. The length includes the command octet, but not the stream transmission header. After negotiation, the smallest size is selected. The value in this field maps to the SSIDSDEB field in the SSID OFTP protocol command.
- Override local SSID code and password – Select this check box to have this partner exchange use an SSID code and password different than the values set on a community’s OFTP delivery exchange. If selected, you must enter the override SSID code. Entering an override password is optional. This password overrides the password in the field named “This server requires a session password,” which is an optional field for a community OFTP delivery exchange.
- 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 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.
Advanced tab for X.25 over ISDN (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.
- An OFTP protocol error occurred. For example, the partner returned a negative response to a query on whether to start the file transfer.
- 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.
- 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.
- Local ISDN number – The ISDN number identifying the caller (the instance of Activator). Depending on the telecom operator’s configuration, you must set this to your number or let the telecom equipment fill it in for you.
- Limit bandwidth to 56 kbps – Select this when a provider uses 56 kbps-bit transparent operation with byte-framing from the network as its physical layer protocol instead of the default 64-kbps with HDLC framing. For such cases, this check box must be selected for the ISDN connection to be properly established.
- Layer 2 window size – Specifies how many layer 2 (ISO 7776) packets can be sent before an acknowledgment is required from the partner. If blank, use the network’s default value.
- Layer 3 window size – Specifies how many layer 3 (ISO 8208) packets can be sent before an acknowledgment is required from the partner. If blank, use the network’s default value.
- Layer 3 packet size – Specifies the size of the layer 3 packets. If blank, use the network’s default value.
- Lowest incoming channel – The starting value for the incoming channels identifier counter. If blank, use the network’s default value.
- Highest incoming channel – The highest value for the incoming channels identifier counter. If blank, use the network’s default value.
- Lowest outgoing channel – The starting value for the outgoing channels identifier counter. If blank, use the network’s default value.
- Highest outgoing channel – The highest value for the outgoing channels identifier’s counter. If blank, use the network’s default value.
- Lowest two-way channel – The starting value for the two-way channels identifier’s counter. If blank, use the network’s default value.
- Highest two-way channel – The highest value for the two-way channels identifier’s counter. If blank, use the network’s default value.
- Local X.25 network user address – The X.25 address identifying the caller (the instance of Activator). Complete this field if the call is routed over an X.25 network that requires it or if the remote partner uses X.25 access control based on the originating address.
- X.25 window size – The number of X.25 packets that can be sent without acknowledgment. If the value is blank the network’s default value is used.
- X.25 packet size – The size of the X.25 packets to be sent over the network. If the value is blank the network’s default value is used.
- Credit counter – The number of consecutive data exchange buffers sent by the speaker before it must wait for a credit (CDT) command from the listener.
- The credit value is only applied to data flow in the data transfer phase.
- The speaker's available credit is initialized to SSIDCRED when it receives a start file positive answer (SFPA) command from the listener. It is zeroed by the end file (EFID) command.
- After negotiation, the smallest size must be selected in the answer of the responder or a protocol error aborts the session.
- Data exchange buffer – The length in octets of the largest acceptable data exchange buffer. The length includes the command octet, but not the stream transmission header. After negotiation, the smallest size is selected. The value in this field maps to the SSIDSDEB field in the SSID OFTP protocol command.
- Override local SSID code and password – Select this check box to have this partner exchange use an SSID code and password different than the values set on a community’s OFTP delivery exchange. If selected, you must enter the override SSID code. Entering an override password is optional. This password overrides the password in the field named “This server requires a session password,” which is an optional field for a community OFTP delivery exchange.
- 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 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.
OFTP polling settings tab (community)
- OFTP partner to poll – The name of the partner whose server the community polls for inbound messages.
- URL to poll – The URL of the server being polled for messages.
Advanced tab (OFTP polling)
- 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 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.
- Polling interval (seconds) – The interval in seconds Activator waits before polling for messages to retrieve.
- Specify preferred nodes – If there are one or more nodes for Activator, you can select one or more as the preferred nodes for consuming messages. If the preferred nodes are running, these are used to process messages. If the preferred nodes are stopped, work is distributed among the remaining running available nodes. Selecting preferred nodes lets you manage work distribution among nodes.
- This option is available for integration pickup and trading delivery exchanges that poll for messages.
- In general, this setting should not be used. Usually it is best to let Activator automatically determine which node should be responsible for initiating the polling of which exchange point.
Related topics