Modify a PeSIT partner delivery

When you add a pickup or delivery, the wizard prompts you to provide a basic set of parameters. After you create the pickup or delivery you can open the maintenance page to view and manage a comprehensive set of parameters. Some of these parameters were automatically set when you added the object, and can only be modified after you add the object.

Procedure

  1. In the B2Bi user interface, select Partners > Manage partners.
  2. From the list of partners, click the name of a partner to display the Summary page for that partner.
  3. Click Partner delivery in the navigation graphic to open the Delivery exchanges page.
  4. From the list of available exchanges, click the name of a PeSIT partner delivery to open the maintenance page for the delivery.
  5. View and modify fields as required. The fields are described in the following section.
  6. If you make any changes, click Save Changes.

PeSIT partner delivery exchange maintenance fields

PeSIT settings tab

  • Hostname – The IP address or the network name of the trading partner PeSIT server to connect to. This must be the fully qualified domain name or IP address of the PeSIT server your community connects to for sending messages.
  • Port – The port on which the partner PeSIT server listens for connection requests.
  • Hold all outbound messages for pickup up by the remote client:
    • Not selected: The messages sent to this delivery are produced and sent to the server.
    • Selected: The messages sent to this delivery stop in HeldForPickup state, available for the remote client to fetch them.
  • Clients must use SSL to connect to this server – Select this option If the partner server is configured to transfer over SSL/TLS. You must import the root certificate of the remote server to the community trusted SSL root certificates.
    • Enable host name verification – If you select this option, B2Bi verifies that the certificate sent by the server during the TLS handshake is the same as one registered on the trading partner. You must have imported the server certificate chain in the partner’s personal certificates and selected the option Trust this for SSL server and/or client authentication. The trading engine automatically adds the root certificate to the linked community's trusted SSL root certificates.
    • If you do not select this option, the trading engine only verifies that the server certificate is signed by a certificate that is included in the community’s trusted SSL root certificates. This means that you must have imported the root certificate of the remote server in the community’s trusted SSL root certificates.
    • Enable CFT compatibility – When you select this option, the trading engine aligns the PeSIT record size on TLS packets. This is the only method handled by Axway Transfer CFT until version 3.0, and the default method for the Axway product is Gateway and Interpel. Attention: If you are using Secure Relay, this is not compatible with SSL security termination in DMZ.
    • If you do not select this option, the trading engine adds the record size as a header of the record, as it does for non TLS communications. This is the default behavior and the recommended setting (when the remote partner handles it, and when it is compatible with Secure Relay’s security termination in DMZ).
  • Override community settings (caller) – This controls the caller’s protocol identity (PI3). Select the following, as needed.
    • Allow any valid community routing ID – Select this option to use the message’s SenderRoutingID as the community (caller) identifier (PI3). If you select this option, the trading engine does not check the sender identity for the transfer.
    • Restrict to specific community routing ID –Select this option and then choose a community routing ID from the list of available IDs to identify the community (caller) identifier to use. When you select this option, if the SenderRoutingId from the message is different then the selected value, the trading engine rejects the transfer.
    • Use Password (This is the password the server expects) – Select this option and enter a password if the remote partner server expects a password from you.
    • Change password – If you need to change the password for connection to the remote partner server, enter and confirm the new password.
  • Remote partner settings – In this section you set the partner server’s protocol identity (PI4) and password requirements.
    • Allow any valid partner routing ID– Select this option to use the message’s ReceiverRoutingId as the partner (server) identifier (PI4). If you select this option, the trading engine does not check the receiver identity for the transfer.
    • Restrict to specific partner routing ID – Select this option and then choose a partner routing ID from the list of available IDs to set the partner (receiver) identifier to use. When you select this option, if the ReciverRoutingId from the message is different from the selected value, the trading engine rejects the transfer.
    • Override password settings – Select this option to override the expected password setting on the PeSIT community pickups. Either force to not expect a password from the partner’s server, or set a specific password that is expected from the partner’s server.

PeSIT parameters tab

This tab is identical for PeSIT application and trading delivery exchanges.

Use this tab to modify the basic default PeSIT parameters for this delivery exchange. These values are only used if no corresponding attribute is found in the message.

The initial settings that are displayed on this tab represent the default settings for the protocol. If you change any settings on this tab, you replace the protocol defaults.

If you use any of the supported PeSIT metadata elements in a message handler action or other process, those elements will override the settings on this tab. For example, if you use the pesit.filelabel metadata element in a message handler action, that setting overrides the setting on this tab for Filename (nfname). For a list of the PeSIT metadata elements, see Message metadata.

  • File name (PI12) – Name of the file, forced to uppercase at runtime. Often, the real name of the file is shipped in File label.
  • Maximum length = 76 characters. If the name is longer, it is truncated to 71 characters and prefixed with a unique 4 digit counter in the format xxxx_<71 first char of filename>.
  • At runtime, the file name takes the first non-empty value from the following list:
    • pesit.filename.out
    • UI value
    • pesit.filename.in
    • pesit.filelabel.out
    • « NOT-SPECIFIED » – if nothing was set
  • File type (PI11) – This is the file type, which is used by some monitors. The default value is 0.
  • If pesit.filetype.out is set in the message, at runtime it overrides the value you set in this UI field.
  • File label (PI37) – Logical name of the file.
  • Maximum length = 80 characters. If the label is longer, it is truncated to 76 characters and prefixed with a unique 3 digit counter in the format xxx_<76 first char of filelabel>.
  •  At runtime, the file label takes the first non-empty value from the following list:
    •  pesit.filelabel.out
    • UI value if Use original is not selected
    • Production file name
    • Consumption file name 
  • Expect acknowledgments – Select this option if you expect the remote application or partner to send a receipt to acknowledge receiving each message sent. In this case, the message is marked "to be acknowledged", until the remote sends the expected acknowledgment.
  • You can additionally select whether to Support negative acknowledgments.
  • Free text (PI99) – Free text often used to transfer metadata.
  • Maximum length = 4096 characters
  • If pesit.serviceParam.out is set in the message, at runtime it overrides the value you set in this UI field.
  • Data encoding (PI16)Text for ASCII files, and Binary for all others (including EBCDIC).
  • Protocol values: Text = 0, Binary = 2
  • If pesit.fileEncoding.out is set in the message, at runtime it overrides the value you set in this UI field (the attribute uses the numeric value).
  • Record format (PI31) – Select Fixed for fixed length records and Variable for variable length records
  • Protocol values: Fixed = 0, Variable = 128
  • If pesit.recordFormat.out is set in the message, at runtime it overrides the value you set in this UI field (the attribute uses the numeric value).
  • If you set an On the Fly transformation, the transformation overrides pesit.recordFormat.out
  • Record length (PI32) – Record length for fixed records, or maximum record length for variable records.
  • If pesit.recordLength.out is set in the message, at runtime it overrides the value you set in this UI field.
  • If you set an On the Fly transformation, the transformation overrides pesit.recordLength.out.
  • Compression (PI21) – Controls the compression of the file during the transfer (compression on the fly). Select a compression method:
    • None (0) – (default) No compression.
    • Horizontal (1) – Compresses the consecutive identical characters in the records.
    • Vertical (2) – Records are compared to one another and the consecutive identical columns are compressed.
    • Both (3) – Combination of the above two compression methods.
  • If pesit.compressionType.out is set in the message, at runtime it overrides the value you select in this UI field (the attribute uses the numeric value).
  • Note: The compression is negotiated between the caller and the server. If the server can’t handle the compression setting, a lower type of compression or no compression is applied.
  • Priority (PI17) – Select an option:
    • High (0) – Highest priority
    • Medium (1) – Default
    • Low (2) – Lowest priority
  • If pesit.priority.out is set in the message, at runtime it overrides the value you set in this UI field (the attribute uses the numeric value).

Advanced tab

This tab is identical for PeSIT application delivery and for PeSIT trading delivery exchanges.

This tab enables you to view and modify advanced parameters. In most cases the default values are the correct values. Do not modify values without first consulting with the administrator of the remote server.

  • Maximum concurrent connections – Default = 100. The maximum number of concurrent connections B2Bi client can open to a partner or back-end application.
  • For example, if the value is 100 connections and there are 150 messages to send, B2Bi opens only 100 connections to that partner. The remaining 50 messages are queued until connections become available.
  • If you are operating in a cluster environment, this is the total number across the entire cluster, no matter how many nodes are running.
  • The default value is suitable in most cases. However, if a partner or application administrator reports that your B2Bi configuration is overrunning the receiving system, decrease the value.
  • PeSIT tries to reuse open sessions so that connections are not closed and reopened too often.
  • If you are sending files to Axway Transfer CFT, the value in this field must be less than the CFTTCP setting in Transfer CFT.
  • Retries – The number of times B2Bi retries connecting to the back-end application if the initial attempt to connect and send the message fails.
  • Retries occur according to an algorithm that starts at 5 minutes. The interval between retries increases with each subsequent retry in this pattern: 10 minutes, 15 minutes, 30 minutes, 60 minutes. The interval plateaus at 60 minutes. This means if the retry value is greater than 5, the fifth and each subsequent retry occurs at 60 minute intervals.
  • Use custom retry intervals – Select this option to override the default retry intervals with intervals of your choice for this delivery exchange. Default intervals are 5, 10, 15, 30, and 60 minutes. When you select this option, you must enter at least one interval (in minutes) in the Custom retry intervals field. You can enter as many intervals as you like, separated by commas. B2Bi applies the intervals between successive retry attempts. If necessary, the last interval you list is repeated until either the delivery is successful or the number of permitted retries is reached.
  • Destination file size delta for transformed files (+/- in %) – If you configure an “on the fly” transformation, you can use this setting to adjust the file size info sent with the PeSIT CREATE order. That is because the “on the fly” transformation changes the file size while sending. If no transformation is configured, this value is ignored.
  • Considerations:
    • This value applies only for size units in Kb (PI41=0), and not in records (PI41=1)
    • This value is useful for receivers that run on a system that needs to pre-allocate the file on the disk (not Windows or UNIX). Because these systems allow a margin, the file size info can be approximate.
    • The sent file size is: local file size * (1 + percentage/100) (rounded to Kb and put in PI42).
    • If the transformed file is likely to be bigger than the original file, enter a positive percentage.
    • If the transformed file is likely to be smaller than the original file, enter a negative percentage.
    • In most situations, you can accept the default value 0.
  • Max data unit size in bytes (PI25) – The largest of chunk of data, in bytes, to be transferred at one time. For high-speed networks, use the default 32700 bytes.
  • This value is related to the client setting for record length on the PeSIT parameters tab.
  • The value of this field must be the same or larger than the value of the record length field. Do not change this value unless advised by the administrator of the back-end PeSIT application you are trading with.
  • Synchronization option (PI7)
    • Interval between sync points (Kbytes): – Each time an amount of data equal to this value has been sent, the client is expected to ask the server to confirm whether data totaling this value has been received. The server responds optionally with a confirmation. This represents a check point in the progress of a file transfer. If a connection is lost before a file transfer has been completed, the transfer resumes, upon restart of the transport, at the point of the last successful check point.
    • The default value is 1024 kilobytes (1 megabyte).
    • This setting corresponds to the pacing setting in Axway Transfer CFT.
    • Sync acknowledgement window – The number of check-point cycles that the client waits for the server to respond to a request to confirm file-transfer progress.
    • For example, if the value of Kb per sync point (pacing) is 1024 (1 megabyte) and the value of this field is 1, the client stops sending data after 1024 kilobytes unless the server responds, although the transfer remains active.
    • If this value is 2, the client keeps sending until 2 megabytes (1024 x 2) of data are sent, and so on.
    • If the client’s value for this field is 0 (zero), the client does not ask the server to confirm at intervals the amount of data received.
    • If the server’s value for this field is 0, the server does not send confirmations at intervals of data received.
    • The default value is 3. In most situation this is the correct value.
    • This setting corresponds to chkw setting in Axway Transfer CFT.
  • Read timeout (seconds) – Time in seconds B2Bi waits to read data from the delivery exchange before terminating the connection.
  • Connection timeout (seconds) – PeSIT Tc timeout. The time the caller waits for a connection acknowledgment from the server.
  • Transfer timeout - caller mode (seconds) – PeSIT Td timeout. The time the caller keeps the connection open, waiting for another message to send.
  • Network timeout (seconds) – PeSIT Tr timeout. The time the caller waits for an expected and effective network disconnection, before forcing it.
  • Protocol timeout (seconds) – PeSIT Tp timeout. The time the caller waits for the response of the remote, in the middle of a protocol action (such as a transfer).
  • Override SSL and TLS cipher suites – Select this option and then use the Add and Remove buttons to specify the cipher suites supported for the embedded server.
  • If you do not select this option, all cipher suites are supported by default. Keeping the default cipher list is less secure than specifying a restricted set of cipher suites.
  • The cipher suites that are displayed in the "Available" column depend on your runtime environment (JRE version, FIPS, or IACK enablement, Secure Relay configuration, ....).
  • The default order in the "Available" column is the preferred order of use. Once ciphers are moved to the Selected column, you can arrange the order. B2Bi uses the ciphers in the order listed.
  • A cipher suite is a collection of security algorithms used in making connections via Secure Sockets Layer or Transport Layer Security. For example, an SSL or TLS protocol requires signing messages using a message digest algorithm. But the choice of algorithm is determined by the particular cipher suite being used for the connection. Typically, you can select an MD5 or SHA digest algorithm.
  • Of the many algorithms for encrypting data and computing the message authentication code, there are varying levels of security. Some provide the highest levels of security, but require a large amount of computation for encryption and decryption. Others are less secure, but provide rapid encryption and decryption. The length of the key used for encryption affects the level of security. The longer the key, the more secure the data.
  • The option for overriding cipher suites lets you select the level of security that suits your needs and enables communicating with others who might have different security requirements. For example, when an SSL connection is established, the client and server exchange information about the cipher suites they have in common. Then they communicate using the common cipher suite that offers the highest level of security. If they do not have a cipher suite in common, secure communication is not possible.
  • In versions of B2Bi earlier than Interchange 5.9, cipher suites configuration was handled by a file named sslciphersuites.xml. As data in that file is saved in the database, the custom cipher suites configuration is retained upon upgrading and is displayed in the Selected list under the option in the user interface. The sslciphersuites.xml file is no longer used.
  • Disable Nagle's Algorithm on TCP connection – Nagle's algorithm improves TCP/IP network efficiency by combining a number of small outgoing messages and sending them all at once. However, activating both "Nagle's algorithm" and "TCP delayed acknowledgements" on your network can lead to unacceptable ack delays. To correct this delay issue, select this option.
  • Back up the files that go through this transport – Indicates whether the system backs up copies of the messages it exchanges with partners and back-end applications. This is required for the system to perform fail-over operations such as attempting to send messages again (retries) in case of a transport connection failure. Without backups, a message in process cannot be recovered if the server or a processing node stops or restarts. Backups are needed to resubmit messages to applications or resend messages to partners.
  • Post-processing script – The full path to an executable file that contains post-processing commands. This field is available for community application delivery exchanges and partner trading delivery exchanges.
  • See Post-processing of consumed messages.

Related Links