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.

In this topic:

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 overridden 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 the trading engine earlier Activator versions, 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 later versions of Activator or who use an EDIINT-compliant trading engine other than Activator.
    • MIME/GZIP – Select to trade with partners who use ealier versions of Activator. 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.
    • 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 who uses later versions of Activator 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

PGP default settings

The PGP tab shows default outbound message settings for PGP encrypted messages. The settings affect all outbound documents for all communities, unless overridden by community-level, category-level, partner-level or partner delivery-level settings. You can change these settings as you need.

  • Message compression – (Not used for PGP over SMTP) 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 – (Default) 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.
  • Payload location – (For PGP over SMTP only) Specify the location of the email payload:
    • Attachment
    • Body
  • Encrypt messages – Select this option to encrypt the messages you send.
    • Message encryption algorithm – If you select encrypt messages, select an algorithm.
    • Encrypt email body – (For PGP over SMTP only.) Select this option to encrypt the body of email messages. You can optionally combine this option with the encryption of attachments.
    • Encrypt attachments – (For PGP over SMTP only.) Select this option to encrypt attachments to email messages. You can optionally combine this option with the encryption of email bodies.
  • 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 – Select 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 email body – (For PGP over SMTP only.) Select this option to sign the body of email messages.
    • Sign email attachments – (For PGP over SMTP only.) Select this option to sign attachments of email messages.
  • Armor – (Always active for PGP over SMTP.) 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.
  • 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.
  • 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 who uses Interchange 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

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 overridden 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 (Fields for modifying application pickups and application deliveries).

  • 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 Links