Default collaboration fields
The following sections describe the default collaboration settings. These settings control how messages are sent for each message protocol. There also are settings for reliable messaging, which control message resending.
Depending on the message protocols your license supports, some of these collaboration settings may not be displayed.
For the procedure for opening this page, see Manage default collaboration settings.
Related topics
AS1 default settings
The AS1 tab shows default outbound message settings for the AS1 message protocol. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings. You can change these as you need.
- Request receipts from partners – Select this option to have your partners send receipts to you upon receiving your messages. The receipts are signed or unsigned, depending on your selection in the request signed receipts check box.
- Request receipts to be redirected – Select this option to request that receipts sent by partners use the address in the Receipt-Delivery-Option line in the MIME header of outbound AS1 messages. You must type the alternate address in the return email address field.
- Request signed receipts – Select this option to have your partners sign the receipts they send you.
- Receipt signing algorithm – This is the algorithm you want partners’ trading engines to use when creating a hash of the unencrypted receipt. This hash is a number that is encrypted with the partner’s private key. It is decrypted by the community using the partner’s public key. The community rehashes the decrypted receipt and compares the result with the hash that came with the receipt. If the two are identical, it ensures the contents have not been altered.
- Message compression – Select a method for compressing the messages you send. This is optional. Compressing data before sending increases throughput. You might want to consult with your partner about compressing and uncompressing as pre- and post-processing steps. You and your partner can compress or not independently, as long as the receiver’s system supports uncompressing.
- The compression options are:
- None – Select this if you do not want compression. Also, you must select this to exchange messages with partners whose interoperable software cannot uncompress documents.
- EDIINT/ZLIB – Select to trade with partners who use version 4.2 or later of Activator or who use an EDIINT-compliant trading engine other than Activator.
- MIME/GZIP – Select to trade with partners who use versions of Activator earlier than 4.2. You also can select this if your partner uses a trading engine other than Activator that supports GZIP compression.
- Encrypt messages – Select this option to encrypt the messages you send.
- Message encryption algorithm – If you select to encrypt messages, select an algorithm.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered.
- Specify message attributes to be packaged with message – This option is available only if your software license supports
allowCustomMetadataInMessageHeaders. Select Help > License information in the user interface to check whether this license key is enabled.
- Select this option to include any metadata elements you want in the MIME headers of the messages your community sends. This can serve several purposes. It lets your community forward payload-related information to a partner. It also lets a community or partner use such data to trigger message handling actions.
- The metadata elements that can be added are in addition to the metadata already in MIME headers, such as sender and receiver, content type, disposition notification and so on. There are several ways to add metadata elements to the available attributes list on this tab. You can type an attribute name in the field below the available attributes list and click Add new. Or, you can go to the message handler area of the user interface and add an attribute (see the chapter on message handling). Any attributes added in the message handler area appear on the available attributes list on this tab
- Recommendations: Make attribute names a single text string. For names that use multiple words, do not use spaces between the words. Use camel case for names that include two or more words (for example,
AttributeName). Do not use non-alphanumeric characters in attribute names (for example, commas, periods, hyphens, asterisks, ampersands and so on).
- To add attributes to headers of outbound documents, use the Add button on this tab to move a selected attribute from the available attributes list to the selected attributes list. Click Save changes when done.
- In addition to selecting metadata elements to include in headers, you must separately establish the values for the attributes. There are several ways to do this, including:
- Message attributes tab – Use the message attributes tab on a transport maintenance page to set attribute values by use of directory mapping or fixed values. For more information see the message attributes tab topic in the transport maintenance chapter.
- Message handler – In the message handler area, you can set a fixed value for an attribute. If the payload is an XML document, the value can be parsed by specifying an XPath. For more information see the chapter on message handling.
- Upon receiving and unpackaging a message with extra metadata, a partner who uses Activator 5.3.2 or later can use the added-metadata for post processing, inline processing or file system integration. Inform the partner of the metadata elements you add to outbound messages.
- The added metadata in the header of the outbound document is in the following format:
X-Cyclone-Metadata-AttributeName: Value
Related topics
AS2 default settings
The AS2 tab shows default outbound message settings for the AS2 message protocol. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings. You can change these as you need.
- Request receipts from partners – Select this option to have your partners send receipts to you upon receiving your messages. The receipts are signed or unsigned, depending on your selection in the request signed receipts check box.
- Request receipts be sent over a synchronous connection – Select this option if you want synchronous receipts in accord with the AS2 standard. A synchronous receipt is returned to the sender during the same HTTP session as the sender's original message. If you trade messages larger than 10 megabytes, we recommend sending receipts over an asynchronous connection to avoid tying up system resources. If you have a partner who uses a version of Activator earlier than 5.0, the default setting is asynchronous. Coordinate with your partner to make sure both of you have the same setting.
- Request receipts be sent over an asynchronous connection – Select this option if you want asynchronous receipts. If you select this, you must complete the next field. An asynchronous receipt is returned to the sender on a different communication session than the sender's original message session. If you trade messages larger than 10 megabytes, we recommend sending receipts over an asynchronous connection to avoid tying up system resources.
- Disposition notification URL – Type the URL for the partner to use when sending asynchronous receipts to acknowledge receiving payloads from your community. You must enter a URL if you request receipts over an asynchronous connection. The system does not provide this value for you. Commonly, the URL to use is the URL used by partners for the HTTP or HTTPS delivery exchange your community has for receiving messages from partners. To get this value, click Application delivery on the navigation graphic at the top of the community summary page to open the Application delivery exchanges page. Copy the URL from the Location column for the desired transport. Return to the collaboration settings page and paste the URL in the Disposition notification URL field. Instead of an HTTP or HTTPS URL, you can use an email address for an inbound SMTP delivery exchange, but it must be in URL format. For example, mailto:community@mail.com.
- Request signed receipts – Select this option to have your partners sign the receipts they send you.
- Receipt signing algorithm – This is the algorithm you want partners’ trading engines to use when creating a hash of the unencrypted receipt. This hash is a number that is encrypted with the partner’s private key. It is decrypted by the community using the partner’s public key. The community rehashes the decrypted receipt and compares the result with the hash that came with the receipt. If the two are identical, it ensures the contents have not been altered.
- Message compression – Select a method for compressing the messages you send. This is optional. Compressing data before sending increases throughput. You might want to consult with your partner about compressing and uncompressing as pre- and post-processing steps. You and your partner can compress or not independently, as long as the receiver’s system supports uncompressing.
- The compression options are:
- None – Select this if you do not want compression. Also, you must select this to exchange messages with partners whose interoperable software cannot uncompress documents.
- EDIINT/ZLIB – Select to trade with partners who use version 4.2 or later of Activator or who use an EDIINT-compliant trading engine other than Activator.
- MIME/GZIP – Select to trade with partners who use versions of Activator earlier than 4.2. You also can select this if your partner uses a trading engine other than Activator that supports GZIP compression.
- Encrypt messages – Select this option to encrypt the messages you send.
- Message encryption algorithm – If you select encrypt messages, select an algorithm.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered.
- When receiving messages, return asynchronous receipts to the first enabled AS2 delivery exchange for the partner instead of the disposition notification URL from the message – Select this option to override the disposition notification URL for receipts that your partner set in the message your community received. When selected, the partner’s disposition notification URL in the MIME header of the inbound message is ignored, and your community sends the receipt via the first enabled AS2 delivery listed for the partner.
- Specify message attributes to be packaged with message – This option is available only if your software license supports
allowCustomMetadataInMessageHeaders. Select Help > License information in the user interface to check whether this license key is enabled.
- Checking this enables you to include any metadata elements you want in the MIME headers of the messages your community sends. This can serve several purposes. It lets your community forward payload-related information to a partner. It also lets a community or partner use such data to trigger message handling actions.
- The metadata that can be added are in addition to the metadata already in MIME headers, such as sender and receiver, content type, disposition notification and so on. There are several ways to add metadata elements to the available attributes list on this tab. You can type an attribute name in the field below the available attributes list and click Add new. Or, you can go to the message handler area of the user interface and add an attribute (see the chapter on message handling). Any attributes added in the message handler area appear on the available attributes list on this tab.
- We recommend these guidelines for attribute names: Make attribute names a single text string. For names that use multiple words, do not use spaces between the words. Use camel case for names that include two or more words (for example,
AttributeName). Do not use non-alphanumeric characters in attribute names (for example, commas, periods, hyphens, asterisks, ampersands and so on).
- To add attributes to headers of outbound documents, use the Add button on this tab to move a selected attribute from the available attributes list to the selected attributes list. Click Save changes when done.
- In addition to selecting metadata elements to include in headers, you must separately establish the values for the attributes. There are several ways to do this, including:
- Message attributes tab – Use the message attributes tab on a transport maintenance page to set attribute values by use of directory mapping or fixed values. For more information see the message attributes tab topic in the transport maintenance chapter.
- Message handler – In the message handler area, you can set a fixed value for an attribute. If the payload is an XML document, the value can be parsed by specifying an XPath. For more information see the chapter on message handling.
Related topics
AS3 default settings
The AS3 tab shows default outbound message settings for the AS3 message protocol. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings. You can change these as you need.
- Request receipts from partners – Select this option to have your partners send receipts to you upon receiving your messages. The receipts are signed or unsigned, depending on your selection in the request signed receipts check box.
- Request signed receipts – Select this option to have your partners sign the receipts they send you.
- Receipt signing algorithm – This is the algorithm you want partners’ trading engines to use when creating a hash of the unencrypted receipt. This hash is a number that is encrypted with the partner’s private key. It is decrypted by the community using the partner’s public key. The community rehashes the decrypted receipt and compares the result with the hash that came with the receipt. If the two are identical, it ensures the contents have not been altered.
- Message compression – Select a method for compressing the messages you send. This is optional. Compressing data before sending increases throughput. You might want to consult with your partner about compressing and uncompressing as pre- and post-processing steps. You and your partner can compress or not independently, as long as the receiver’s system supports uncompressing.
- The compression options are:
- None – Select this if you do not want compression. Also, you must select this to exchange messages with partners whose interoperable software cannot uncompress documents.
- EDIINT/ZLIB – Select for trading with partners who use version 4.2 or later of Activator or who use an EDIINT-compliant trading engine other than Activator.
- MIME/GZIP – Select for trading with partners who use versions of Activator earlier than 4.2. You also can select this if your partner uses a trading engine other than Activator that supports GZIP compression.
- Encrypt messages – Select this option to encrypt the messages you send.
- Message encryption algorithm – If you select encrypt messages, select an algorithm.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered.
- Specify message attributes to be packaged with message – This option is available only if your software license supports
allowCustomMetadataInMessageHeaders. Select Help > License information in the user interface to check whether this license key is enabled.
- Checking this enables you to include any metadata elements you want in the MIME headers of the messages your community sends. This can serve several purposes. It lets your community forward payload-related information to a partner. It also lets a community or partner use such data to trigger message handling actions.
- The metadata that can be added are in addition to the metadata already in MIME headers, such as sender and receiver, content type, disposition notification and so on. There are several ways to add metadata elements to the available attributes list on this tab. You can type an attribute name in the field below the available attributes list and click Add new. Or, you can go to the message handler area of the user interface and add an attribute (see the chapter on message handling). Any attributes added in the message handler area appear on the available attributes list on this tab.
- We recommend these guidelines for attribute names: Make attribute names a single text string. For names that use multiple words, do not use spaces between the words. Use camel case for names that include two or more words (for example,
AttributeName). Do not use non-alphanumeric characters in attribute names (for example, commas, periods, hyphens, asterisks, ampersands and so on).
- To add attributes to headers of outbound documents, use the Add button on this tab to move a selected attribute from the available attributes list to the selected attributes list. Click Save changes when done.
- In addition to selecting metadata elements to include in headers, you must separately establish the values for the attributes. There are several ways to do this, including:
- Message attributes tab – Use the message attributes tab on a transport maintenance page to set attribute values by use of directory mapping or fixed values. For more information see the message attributes tab topic in the transport maintenance chapter.
- Message handler – In the message handler area, you can set a fixed value for an attribute. If the payload is an XML document, the value can be parsed by specifying an XPath. For more information see the chapter on message handling.
- Upon receiving and unpackaging a message with extra metadata, a partner who uses Activator (any version) or Activator 5.3.2 or later can use the added-metadata for post processing, inline processing or file system integration. Inform the partner of the metadata elements you add to outbound messages.
- The added metadata in the header of the outbound document is in the following format:
X-Cyclone-Metadata-AttributeName: Value
Related topics
AS4 default settings
The AS4 tab shows default outbound message settings for the AS4 message protocol. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings. You can change these as you need.
- Expect receipts from partners – Select this option to have your partners send receipts to you upon receiving your messages. The receipts are signed or unsigned, depending on the user message for which receipt is generated.
- Payload location – The payload transferred in a SOAP message can be in the SOAP body or packaged as a MIME attachment. By default outbound payloads are placed in the SOAP body of the packaged message. The payload also can be packaged as an attachment by changing this field value. Setting the payload location to None has the effect of neither attaching the payload as an attachment nor in the SOAP body. In the None case, a SOAP handler must be configured to attach the payload where desired. To use the default configuration, set the payload location to SOAP body.
- Message compression – Select this option to compress the messages you send. messages are compressed using MIME/GZIP algorithm. Compressing data before sending increases throughput. You might want to consult with your partner about compressing and uncompressing as pre- and post-processing steps. You and your partner can compress or not independently, as long as the receiver’s system supports uncompressing.
- Split messages – Select this option to enable sending of large messages split into smaller units
- Mime envelope compression (None, MIME/GZIP)
- Encrypt messages – Select this option to encrypt the messages you send.
- Message encryption algorithm – If you select encrypt messages, select an algorithm.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered. Supported encryption algorithms are Triple DES (default) and AES.
- Use MTOM to encode messages – Select this option to specify parts of the payload to use Message Transmission Optimization Mechanism (MTOM) encoding of outbound messages. This is base 64-encoding for preserving the integrity of non-ASCII parts of payloads (for example, blank spaces). To use MTOM encoding of outbound messages, the receiving partner must be able to auto-detect the encoded parts and decode them.
- Activator auto-detects and decodes such messages when it receives payloads from partners.
- When you select this option, you can also select the following options:
- Xpaths to encode – Click Add to specify one or more xPaths
- ID refs to encode – Click Add to specify one or more ID refs
- Use username token when sending – Select this option to enable the embedding of user name tokens within the message. When you select this option you must provide a user name and password. The user name must be the name of an AS4 account that you create on an AS4 pickup. The user name and password information you use must be shared with the remote partner you are trading with and the remote partner must use identical authentication information, or message pull request will fail. For information on creating AS4 user accounts, see Modify an AS4 embedded pickup / Accounts tab.
- Use password digest in place of plain text during authentication (optional)
- User name and password (required)
- Specify message attributes to be packaged with message – This option is available only if your software license supports
allowCustomMetadataInMessageHeaders. Select Help > License information in the user interface to check whether this license key is enabled.
- When you select this option, you can include any metadata elements you want in the MIME headers of the messages your community sends. This can serve several purposes. It lets your community forward payload-related information to a partner. It also lets a community or partner use such data to trigger message handling actions.
- The metadata that can be added are in addition to the metadata already in MIME headers, such as sender and receiver, content type, disposition notification and so on. There are several ways to add metadata elements to the available attributes list on this tab. You can type an attribute name in the field below the available attributes list and click Add new. Or, you can go to the message handler area of the user interface and add an attribute (see the chapter on message handling). Any attributes added in the message handler area appear on the available attributes list on this tab.
- We recommend the following guidelines for attribute names:
-
- Make attribute names a single text string.
- For names that use multiple words, do not use spaces between the words.
- Use camel case for names that include two or more words (for example,
AttributeName).
- Do not use non-alphanumeric characters in attribute names (for example, commas, periods, hyphens, asterisks, ampersands and so on).
- To add attributes to headers of outbound documents, use the Add button to move a selected attribute from the available attributes list to the selected attributes list. Click Save changes when done.
- In addition to selecting metadata elements to include in headers, you must separately establish the values for the attributes. There are several ways to do this, including:
- Message attributes tab – Use the message attributes tab on a transport maintenance page to set attribute values by use of directory mapping or fixed values. For more information see the message attributes tab topic in the transport maintenance chapter.
- Message handler – In the message handler area, you can set a fixed value for an attribute. If the payload is an XML document, the value can be parsed by specifying an XPath. For more information see the chapter on message handling.
- Upon receiving and unpackaging a message with extra metadata, a partner who uses Axway products B2Bi, Interchange or Activator can use the added-metadata for post processing, inline processing or file system integration. Inform the partner of the metadata elements you add to outbound messages.
- The added metadata in the header of the outbound document is in the following format:
X-Cyclone-Metadata-AttributeName: Value
- Pull response retry attempts – The maximum number of times Activator can try to deliver a user message in response to a pull request, when the delivery fails (if it shares the reliable messaging resend interval for timeout processing).
Secure file default settings
The secure file tab shows default outbound message settings for the secure file message protocol. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings. You can change these as you need.
- Request receipts from partners – Select this option to have your partners send receipts to you upon receiving your messages. The receipts are signed or unsigned, depending on your selection in the request signed receipts check box.
- Request signed receipts – Select this option to have your partners sign the receipts they send you.
- Receipt signing algorithm – This is the algorithm you want partners’ trading engines to use when creating a hash of the unencrypted receipt. This hash is a number that is encrypted with the partner’s private key. It is decrypted by the community using the partner’s public key. The community rehashes the decrypted receipt and compares the result with the hash that came with the receipt. If the two are identical, it ensures the contents have not been altered.
- Message compression – Select a method for compressing the messages you send. This is optional. Compressing data before sending increases throughput. You might want to consult with your partner about compressing and uncompressing as pre- and post-processing steps. You and your partner can compress or not independently, as long as the receiver’s system supports uncompressing.
- The compression options are:
- None – Select this if you do not want compression. Also, you must select this to exchange messages with partners whose interoperable software cannot uncompress documents.
- EDIINT/ZLIB is for trading with partners who use version 4.2 or later of Activator or who use an EDIINT-compliant trading engine other than Activator.
- MIME/GZIP is for trading with partners who use versions of Activator earlier than 4.2. You also can select this if your partner uses a trading engine other than Activator that supports GZIP compression.
- Encrypt messages – Select this option to encrypt the messages you send.
- Message encryption algorithm – If you select encrypt messages, select an algorithm.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered.
- Specify message attributes to be packaged with message – This option is available only if your software license supports
allowCustomMetadataInMessageHeaders. Select Help > License information in the user interface to check whether this license key is enabled.
- Checking this enables you to include any metadata elements you want in the MIME headers of the messages your community sends. This can serve several purposes. It lets your community forward payload-related information to a partner. It also lets a community or partner use such data to trigger message handling actions.
- The metadata that can be added are in addition to the metadata already in MIME headers, such as sender and receiver, content type, disposition notification and so on. There are several ways to add metadata elements to the available attributes list on this tab. You can type an attribute name in the field below the available attributes list and click Add new. Or, you can go to the message handler area of the user interface and add an attribute (see the chapter on message handling). Any attributes added in the message handler area appear on the available attributes list on this tab.
- We recommend these guidelines for attribute names: Make attribute names a single text string. For names that use multiple words, do not use spaces between the words. Use camel case for names that include two or more words (for example,
AttributeName). Do not use non-alphanumeric characters in attribute names (for example, commas, periods, hyphens, asterisks, ampersands and so on).
- To add attributes to headers of outbound documents, use the Add button on this tab to move a selected attribute from the available attributes list to the selected attributes list. Click Save changes when done.
- In addition to selecting metadata elements to include in headers, you must separately establish the values for the attributes. There are several ways to do this, including:
- Message attributes tab. Use the message attributes tab on a transport maintenance page to set attribute values by use of directory mapping or fixed values. For more information see the message attributes tab topic in the transport maintenance chapter.
- Message handler. In the message handler area, you can set a fixed value for an attribute. If the payload is an XML document, the value can be parsed by specifying an XPath. For more information see the chapter on message handling.
Related topics
Generic email default settings
The generic email tab shows default outbound message settings for the Generic email message protocol. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings. You can change these as you need.
- Request receipts from partners – Select this option to have your partners send receipts to you upon receiving your messages. The receipts are unsigned.
- Encrypt messages – Select this option to encrypt the messages you send.
- Message encryption algorithm – If you select encrypt messages, select an algorithm.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered.
Related topics
Odette FTP V2 default settings
The OFTP V2 tab shows default outbound message settings for ODETTE File Transfer Protocol 2.x. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings. You can change these as you need.
- Request signed receipts – Select this option to have your partners sign the receipts they send you.
- Receipt signing algorithm – This is the algorithm you want partners’ trading engines to use when creating a hash of the unencrypted receipt. This hash is a number that is encrypted with the partner’s private key. It is decrypted by the community using the partner’s public key. The community rehashes the decrypted receipt and compares the result with the hash that came with the receipt. If the two are identical, it ensures the contents have not been altered.
- Encrypt messages – Select this option to encrypt the messages you send.
- Message encryption algorithm – If you select encrypt messages, select an algorithm.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered.
- Message compression – Select a method for compressing the messages you send. This is optional. Compressing data before sending increases throughput. You might want to consult with your partner about compressing and uncompressing as pre- and post-processing steps. You and your partner can compress or not independently, as long as the receiver’s system supports uncompressing.
- The compression options are:
- None. Select this if you do not want compression. Also, you must select this to exchange messages with partners whose interoperable software cannot uncompress documents.
- EDIINT/ZLIB is for trading with partners who use version 4.2 or later of Activator or who use an EDIINT-compliant trading engine other than Activator.
Related topics
PGP default settings
The PGP tab shows default outbound message settings for the PGP message protocol. The settings affect all outbound documents for all communities, unless superseded by community-level, category-level, partner-level or partner delivery-level settings. You can change these settings as you need.
- Message compression – Select a method for compressing the messages you send. This is optional. Compressing data before sending increases throughput. You might want to consult with your partner about compressing and decompressing as pre- and post-processing steps. You and your partner can compress or not independently, as long as the receiver’s system supports decompressing.
- The compression options are:
- Uncompressed– Select this if you do not want compression. Also, you must select this to exchange messages with partners whose interoperable software cannot decompress documents.
- ZIP – ZIP is a data compression and archive format. A ZIP file contains one or more files that have been compressed to reduce file size.
- ZLIB – ZLIB is a software library used for data compression. ZLIB is an abstraction of the DEFLATE compression algorithm used in the GZIP file compression program.
- Encrypt messages – Select this option to encrypt the messages you send.
- Message encryption algorithm – If you select encrypt messages, select an algorithm.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered.
- Armor – Select this option to enable ASCII armor. Like base 64 encoding, this is for encoding binary data to send over a 7-bit transport as text.
- Specify message attributes to be packaged with message – This option is available only if your software license supports
allowCustomMetadataInMessageHeaders. Select Help > License information in the user interface to check whether this license key is enabled.
- Checking this enables you to include any metadata elements you want in the MIME headers of the messages your community sends. This can serve several purposes. It lets your community forward payload-related information to a partner. It also lets a community or partner use such data to trigger message handling actions.
- The metadata that can be added are in addition to the metadata already in MIME headers, such as sender and receiver, content type, disposition notification and so on. There are several ways to add metadata elements to the available attributes list on this tab. You can type an attribute name in the field below the available attributes list and click Add new. Or, you can go to the message handler area of the user interface and add an attribute (see the chapter on message handling). Any attributes added in the message handler area appear on the available attributes list on this tab.
- We recommend these guidelines for attribute names: Make attribute names a single text string. For names that use multiple words, do not use spaces between the words. Use camel case for names that include two or more words (for example,
AttributeName). Do not use non-alphanumeric characters in attribute names (for example, commas, periods, hyphens, asterisks, ampersands and so on).
- To add attributes to headers of outbound documents, use the Add button on this tab to move a selected attribute from the available attributes list to the selected attributes list. Click Save changes when done.
- In addition to selecting metadata elements to include in headers, you must separately establish the values for the attributes. There are several ways to do this, including:
- Message attributes tab. Use the message attributes tab on a transport maintenance page to set attribute values by use of directory mapping or fixed values. For more information see the message attributes tab topic in the transport maintenance chapter.
- Message handler. In the message handler area, you can set a fixed value for an attribute. If the payload is an XML document, the value can be parsed by specifying an XPath. For more information see the chapter on message handling.
RNIF 1.1 default settings
The RNIF 1.1 tab shows default outbound message settings for the RosettaNet 1.1 message protocol. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings. You can change these as you need.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered.
- Sign Signals – Sign the signals you send to partners.
- Signal signing algorithm – If you choose to sign signals, the signing algorithm to use.
- Base-64 Encode HTTP Messages – Convert outbound messages to base 64. If not selected, messages are sent in binary format.
Related topics
RNIF 2.0 default settings
The RNIF 2.0 tab shows default outbound message settings for the RosettaNet 2.0 message protocol. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings. You can change these as you need.
- Encrypt messages – Select this option to encrypt the messages you send.
- Message encryption algorithm – If you select encrypt messages, select an algorithm.
- Encrypt service content and attachments – If encrypt messages is also selected, the payload is encrypted (service-content and attachments).
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered.
- Sign Signals – Sign the signals you send to partners.
- Signal signing algorithm – If you choose to sign signals, the signing algorithm to use.
- Compress Messages – Compress outbound messages.
- Base-64 Encode HTTP Messages – Convert outbound messages to base 64. If not selected, messages are sent in binary format.
Related topics
Web Services default settings
The Web Services tab shows default outbound message settings for the Web Services message protocol. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings.
The default settings enable trading of secure XML payloads between two instances of B2Bi, Interchange or Activator. The default configuration is somewhat arbitrary, but useful to get two instances of B2Bi, Interchange or Activator trading quickly. If you want a different configuration, engage a professional services consultant, obtain the optional Software Development Kit or both.
- Send handler config file – Name of the file in
<install directory>\conf used when packaging a message. Activator provides two versions of this file:axis2.xml – (Default) This file has handlers for adding routing information to the SOAP header and interpreting routing information. If you want to use WS-addressing you must use this file.axis2NoWSAddressing.xml – This file disables WS-Addressing. If you do not want to use WS-addressing, select this file.
- You can optionally create a customized version of this file, and select it for use with outbound messages. However, doing so requires engaging a professional services consultant, obtaining the optional Software Development Kit, or both.
- Payload location – The payload transferred in a SOAP message can be in the SOAP body or packaged as a MIME attachment. By default outbound payloads are placed in the SOAP body of the packaged message. The payload also can be packaged as an attachment by changing this field value. Setting the payload location to none has the effect of not attaching the payload as an attachment or in the SOAP body. In the none case, a SOAP handler must be configured to attach the payload where desired. To use the default configuration, set the payload location to SOAP body.
- SOAP action – The SOAP action header value. If specified for outbound messages, the value is used when packaging. If no value is specified, SOAPAction defaults to a blank string. To use the default configuration, use the default value of handleMessage.
- SOAP version – Specifies whether Activator, acting as a web service client, uses SOAP 1.1 (default) or SOAP 1.2 to trade with a remote trading partner. You can override this setting by using the SOAPVersion metadata attribute.
- Encrypt messages – Select this option to encrypt outbound messages. To use the default configuration, make sure this check box is selected and do not change values of any of the related fields.
- Message encryption algorithm – Supported encryption algorithms are Triple DES (default) and AES.
- Encrypt attachments – Sets whether attachments are encrypted (on by default).
- Encrypt SOAP body – Sets whether the SOAP body is encrypted (on by default).
- XPaths to encrypt – You can add specific SOAP envelope elements and sub-elements to be encrypted. For each you add, specify the
namespace prefix, namespace URI and local XPath. - XPath example:
Namespace prefix: soapenv
Namespace URI: http://schemas.xmlsoap.org/soap/envelope/
Local XPath: /soapenv:Envelope/soapenv:Body
|
- ID refs to encrypt – You can add specific SOAP envelope elements and sub-elements to be encrypted.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send. To use the default configuration, make sure this check box is selected and do not change values of any of the related fields.
- Sign attachments – Sets whether attachments are signed (on by default).
- Sign SOAP body – Sets whether the SOAP body is signed (on by default).
- XPaths to sign – You can add specific SOAP envelope elements and sub-elements to be signed. For each you add, specify the
namespace prefix, namespace URI and local XPath. - XPath examples:
Namespace prefix: soapenv
Namespace URI: http://schemas.xmlsoap.org/soap/envelope/
Local XPath: /soapenv:Envelope/soapenv:Header
-
Namespace prefix: soapenv
Namespace URI: http://schemas.xmlsoap.org/soap/envelope/
Local XPath: /soapenv:Envelope/soapenv:Body
|
- ID refs to sign – You can add specific SOAP envelope elements and sub-elements to be signed.
- Use MTOM to encode messages – Select this option to specify parts of the payload to use Message Transmission Optimization Mechanism (MTOM) encoding of outbound messages. This is base 64-encoding for preserving the integrity of non-ASCII parts of payloads (for example, blank spaces). To use MTOM encoding of outbound messages, the receiving partner must be able to auto-detect the encoded parts and decode them. Activator auto-detects and decodes such messages when it receives payloads from partners.
- Use username token when sending – When this option is selected at the default level, a global requirement is set that all messages sent via web services delivery exchanges contain a UsernameToken element in the SOAP header. The element includes the user name and password specified here. When you also select Require password digest in place of plain text during authentication, Activator converts the password to digest form. The digest is a hash of the password that is base 64-encoded.
- When selected on a per-partner basis, the collaboration setting overrides the parallel control within partners on the Advanced tab of web services delivery exchanges for sending messages.
Related topics
cXML default settings
The cXML tab shows default outbound message settings for the cXML message protocol. The settings affect all outbound documents for all communities, unless superseded by community-, category- or partner-level settings. You can change these as you need.
- Sign messages. Partners use your certificate to verify you as the sender – Select this option to digitally sign the messages you send.
- Message signing algorithm – The algorithm for creating a hash of the unencrypted message. This hash is a number that is encrypted with your community’s private key. It is decrypted by the partner using the community’s public key. The partner rehashes the decrypted message and compares the result with the hash that came with the message. If the two are identical, it ensures the contents have not been altered.
- Use shared secret for outbound cXML messages – Select this option if you must provide a shared secret on outbound cXML messages to partners. If you select this option you must enter the shared secret in the accompanying field.
- Specify message attributes to be packaged with message – This option is available only if your software license supports
allowCustomMetadataInMessageHeaders. Select Help > License information in the user interface to check whether this license key is enabled.
- Select this option to include any metadata elements you want in the MIME headers of the messages your community sends. This can serve several purposes. It lets your community forward payload-related information to a partner. It also lets a community or partner use such data to trigger message handling actions.
- The metadata that can be added are in addition to the metadata already in MIME headers, such as sender and receiver, content type, disposition notification and so on. There are several ways to add metadata elements to the available attributes list on this tab. You can type an attribute name in the field below the available attributes list and click Add new. Or, you can go to the message handler area of the user interface and add an attribute (see the chapter on message handling). Any attributes added in the message handler area appear on the available attributes list on this tab.
- We recommend these guidelines for attribute names: Make attribute names a single text string. For names that use multiple words, do not use spaces between the words. Use camel case for names that include two or more words (for example,
AttributeName). Do not use non-alphanumeric characters in attribute names (for example, commas, periods, hyphens, asterisks, ampersands and so on).
- To add attributes to headers of outbound documents, use the Add button on this tab to move a selected attribute from the available attributes list to the selected attributes list. Click Save changes when done.
- In addition to selecting metadata elements to include in headers, you must separately establish the values for the attributes. There are several ways to do this, including:
- Message attributes tab – Use the message attributes tab on a transport maintenance page to set attribute values by use of directory mapping or fixed values. For more information see the message attributes tab topic in the transport maintenance chapter.
- Message handler – In the message handler area, you can set a fixed value for an attribute. If the payload is an XML document, the value can be parsed by specifying an XPath. For more information see the chapter on message handling.
- Inline processing – If you are a licensed SDK user, you can build a Java class and use it to provide attribute values or perform other message actions.
- Upon receiving and unpackaging a message with extra metadata, a partner can use the added-metadata for post processing, inline processing or file system integration. Inform the partner of the metadata elements you add to outbound messages.
- The added metadata in the header of the outbound document is in the following format:
X-Cyclone-Metadata-AttributeName: Value
Related topics
Reliable messaging default settings
The Reliable messaging tab shows default outbound settings for message resend attempts. The tab applies only to messages for which receipts are expected. The settings affect all outbound documents for all communities, unless superseded by community-, category-, partner- or partner delivery-level settings. You can change these as you need.
The tab controls how long the system waits for a message receipt and the maximum times it re-sends the message if a receipt has not been received. For example, if a receipt is not received within the time in the resend interval field, the system sends the message again. It continues resending until a receipt is received or the resend limit is reached.
If the resend limit is reached and a receipt has not been received, the message is given a failed status. You can search for and manually resubmit failed messages in Message Tracker.
This tab only applies to successfully sent messages for which receipts are expected. It does not apply to messages that fail to send due to a transport problem. For information about resending due to transport issues, see information about the Retries field on the Advanced tab of a transport maintenance page (Modify an application pickup or delivery).
- Resend attempts – The maximum number of times Activator should resend a message if a receipt has not been received.
- Resend interval in minutes – The time the system waits for a receipt before resending the message.
Related topics