X.400 (embedded) servers

After setting up an exchange that uses an embedded server, you can change the server’s settings.

There are various places in the user interface where you can open the maintenance page for an embedded server. But the embedded servers page is the primary page for managing these servers. On this page you can view a list of all embedded servers and open the maintenance page of any server by clicking its name.

Not only can you use this page to manage embedded servers, but your DMZ or network administrator may find it a useful guide for configuring ports for load balancers and firewalls. Text on the page describes how an administrator should use the displayed information.

The following are ways to open the embedded servers page:

  • Select System management > Manage embedded servers on the toolbar.
  • Click Trading configuration on the toolbar. On the Communities page, click the link near the bottom named Manage all embedded servers.
  • Click System management on the toolbar. On the System management page, click the link near the bottom named Manage embedded servers.

Another path to perform embedded server maintenance is to open a community summary page and click the link near the bottom named Change an embedded transport server. This opens a page that lists all servers used by that community only.

Lastly, you can open an embedded server’s maintenance page by opening the maintenance page of a delivery exchange that references the embedded server. On a community summary page, click Delivery exchanges in the navigation graphic at the top of the page. Click an embedded transport to open the maintenance page for the delivery exchange. On the settings tab click the link for opening the maintenance page of the embedded server.

Related topics

About X.400 over X.25

The X.400 subsystem supports sending and receiving messages over X.25 in addition to TCP. You can select the X.25 option when editing an X.420 or X.435 embedded server (see Subsystem settings for X.400 server, Network protocol type). You cannot elect X.25 in the delivery exchange wizard when adding an X.420 or X.435 transport.

X.25 over X.400 in Interchange has been tested only on AIX and Windows operating systems. An AIX computer must have an AIX-compliant X.25 card. A Windows computer must have an Eicon X.25 card. In addition, properties in files under common\subsystems\X400 must be edited. Editing the files requires expert technical knowledge of Interchange and X.25. You may need the help of an Axway professional services consultant to implement X.25 over X.400.

Subsystem settings for X.400 server

The subsystem settings fields for X.420 and X.435 embedded servers are the same except as noted.

  • Name – The name of the server. This was set in the delivery exchange wizard. You cannot change this name.
  • Host – The computer on which the server runs. You cannot change this. When B2Bi runs in a clustered environment, X.400 subsystems are distributed dynamically across the cluster. This means this host value can change on its own.
  • Network protocol type – Select whether the server transports over TCP, X.25 or both. The fields on the tab adjust according to the option selected. See for X.400 (embedded) servers more information about X.25.

TCP settings

  • Port – The port used by partners to connect to your X.400 subsystem.

X.25 settings

  • X.25 gateway port – The internal subsystem port for communicating to its X.25 process. This can be any port not already in use. Click the field to display a list of ports in use.
  • Bind to host – If you run B2Bi in a cluster of multiple computers, you can select a single computer in the cluster as the designated host. This field is available for users who may not have multiple X.25 cards for each computer in the cluster and need to lock the X.25-enabled subsystem to the one computer with an X.25 card. If you have a clustered environment and do not use this field, you may need an X.25 load balancer to compensate.
  • Incoming X.121 address – The listening X.121 address, including sub-address, for incoming X.25 calls. The X.121 address is often referred to as the X.25 network user address (X.25 NUA).) Your DNIC code should not be defined unless you also define the network prefix.
  • Outgoing X.121 address – The X.121 address for outgoing calls.
  • Link ID – The name of the X.25 card.
  • Call user data – Used for outgoing and incoming connections. call user data (CUD) is appended to a call request for outgoing connections. If a CUD is specified, this CUD is required for all incoming connections. For use with X.400, this value must always be set to 03010100.
  • Min poll interval (ms) – The minimum time in milliseconds between samplings. This applies only to AIX computers.
  • Max poll interval (ms) – The maximum time in milliseconds between X.25 samplings. This applies only to AIX computers. If set to a small value, X.25 traffic is handled faster at the cost of higher CPU load. As long as there is regular X.25 traffic, this time automatically adjusts, so that only the first package can be delayed by the value of this parameter.
  • Poll increment – The number of steps to increment between maximum and minimum polling intervals. This applies only to AIX computers.
  • Log size (bytes) – The maximum size of the log file. When the X.25 log file reaches the maximum size, logging continues in a new file.A value 0 indicates the size of the log file is unlimited.
  • Clear log on restart – Select whether to clear the log file when the system is restarted.
  • Log level – Select the level of events to write to the log file. Options are listed from the least to most verbose logging levels.

Subsystem internal ports

  • System starter port – The port used by B2Bi and the X.400 subsystem to monitor the status of each other. If B2Bi loses the connection on this port, it tries to restart the X.400 subsystem. If the X.400 subsystem loses the connection, it assumes B2Bi has shut down and shuts itself down as well.
  • OSITP port – The listening port for the lower layer OSI stack process within the X.400 subsystem.
  • User agent port – The API port used by B2Bi and the X.400 subsystem user agent. All messages exchanged between B2Bi and the UA go through this port.

Subsystem security (X.435 only)

  • Private key – If specified, this is the key for verifying signatures of receipts or messages when collaboration settings specify class 3 or class 4 (see X.435 default settings). The signing is performed by the corresponding public key, which your community must provide to your trading partner. The public key is specified on the X.435 settings tab of the partner X.435 delivery exchange.
    • Private key file – The path of the private key file to upload. If you upload a private key, click Save changes.
    • Private key description – Optionally, a description of the private key.

User agent

  • Delivery timeout (minutes) – Minutes a delivered message can stay in the UA’s in-queue. If the UA does not read the message but accepts responsibility for it, the MTA removes the message from the in-queue and sends a non-delivery notification to the message originator.
  • A value of 0 means the UA has a retrieval queue. This imposes responsibility for the message on the UA once the message is placed in the UA’s in-queue. The MTA does not supervise this queue.
  • Anonymous addressing – When set at Allowed the UA accepts messages from a sender with an O/R address that does not match any of the remote nodes. Forbidden is the default setting.
  • Change UA password – Select to type a new password to authenticate communication between B2Bi and the X.400 subsystem. The original password was randomly generated. There is no need to remember this password, as it is only used internally. This field is provided in case the password should be changed for some reason.
  • Default time notification expected within (minutes) (X.435 only) – If EDI notifications are requested for a transfer, the maximum time to wait. If exceeded without an EDIN, the original message is marked NACKED.
  • Time notification expected within (minutes) (X.420 only) – If notifications are requested for a transfer, the maximum time to wait. If exceeded without a notification, the original message is marked NACKED.
  • Log size (bytes) – The maximum size the log file can grow to before an action specified in the next field is triggered.
  • Log full action – When the log file reaches the maximum size specified in the preceding field, one of the following actions is taken.
    • Stop logging. Logging is stopped.
    • Rename log file. The log rolls to a new file and logging continues.
  • Log level – Use the drop-down list to select the kind of information to log.

Advanced OSITP

  • Maximum transport connections – The maximum number of transport connections the transport module can accept. The memory required for transport connections is calculated as Max transport connections * Buffer size. Memory is reserved for each new transport connection at connection time. If memory cannot be reserved, the connection is not established.
  • Maximum network connections – The maximum number of network connections the transport module can handle.
  • Maximum connection response time (ms) – Maximum time in milliseconds the transport protocol layer waits for a connection accept or reject response from the application after receiving an incoming connection request and passing the request to the application.
  • TS1 time (ms) – The time in milliseconds to wait for an answer to a transport connect request. If an answer is not received within this time, the network connection is disconnected.
  • Buffer size (bytes) – The memory each transport connection can use for transport protocol data unit (TPDU) buffers.
  • Maximum TPDU size (bytes) – The maximum TPDU size proposed on an outbound connect request.

Local message transfer agent

  • MTA name – The name of the message transfer agent.
  • TSAP – The transport services access point.
  • Country name – The two-character ISO country code. For a community delivery exchange, this should be the code of the community’s country. If a partner delivery exchange, this should be the code of the partner’s country.
  • For a list of codes, see ISO (International Organization for Standardization): http://www.iso.org/iso/home.html.
  • Connect to an Administration Management Domain (ADMD) – When selected, the following field displays.
    • Administration domain name – Identifies an administrative domain name (ADMD). This is the name of an ADMD service provider for client organizations (PRMDs) that subscribe to an ADMD provider for X.400 message routing and related services. For clients who connect directly to other PRMDs, bypassing an ADMD, set the name to a single space character. For a community delivery exchange, this should be the code of the community’s ADMD. If a partner delivery exchange, this should be the code of the partner’s ADMD.
  • Private domain name – Identifies a private domain name (PRNM) relative to the administration domain name or country. Typically, this is a company name.
  • Organization – Identifies an organization relative to the PRNM.
  • Organization unit – Identifies units such as divisions and departments within the organization.
  • Delivery period (seconds) – The interval the MTA process checks the inbound queues of UAs. If the receiving UA does not read an inbound message, the MTA removes the message from the UA delivery queue and sends a non-delivery message to the sender, if requested.
  • Poll period (seconds) – The interval the MTA polls for inbound messages. Messages from UAs and the MTC process are put in the in-queue. The poll interval is used only when the queue is empty. If the queue is not empty, all messages are processed before polling restarts.
  • Transfer time (seconds) – The maximum time allowed for a message to send from one MTA to another. If the time is exceeded, the transmission fails and the connection is released.
  • Maximum number of connection attempts – The maximum times the MTC process should try to connect to an MTA. If the connection fails, a non-delivery message is sent to the UA that had this MTA as the destination for messages. If the value is 0 or 1, only one attempt is made.
  • Maximum attempt timer (seconds) – When a connection attempt fails, this value specifies how long to wait before attempting again to connect.
  • Maximum inbound connections – The maximum number of simultaneous incoming connections the MTC can accept. If reached, any new connection are rejected with a reason code indicating temporary congestion.
  • Maximum outbound connections – The maximum number of simultaneous outgoing connections the MTC can make.
  • Note: Maximum inbound connections and Maximum outbound connections distribute network resources when using X.25. Every X.25 subscription has a limited number of logical channels available. Logical channels enable multiple simultaneous virtual circuits (connections) to exist across one physical link. In short, the X.25 supplier limits the number of simultaneous connections. The fields specify the number of logical channels to use in each direction to:
    • Make sure a heavy workload in one direction does not block traffic in the opposite direction. For example, assume an X.25 subscription allows a maximum of connections to 8 logical channels. If Maximum inbound is set to 6 and Maximum outbound to 2, heavy incoming traffic does not block outgoing traffic because there always are two logical channels available for outgoing transfers.
    • Divide X.25 resources between processes. For example, if an X25 subscription provides 8 logical channels, setting both Maximum inbound and Maximum outbound to 2 makes sure at least 4 logical channels are always available for other processes.
  • Bandwidth is not limited by these parameters. If Maximum inbound is 6 and Maximum outbound is 2, an outgoing connection receives full bandwidth if it is the only current connection.
    Although primarily for distributing X.25 resources, the parameters can be used to distribute TCP/IP resources. With TCP/IP:
    • The limit on the number of concurrent connections typically is higher than for X.25.
    • The system administrator can change these limits locally on the computer. The network supplier does not influence these limits.
  • Maximum queued messages – The maximum number of messages that can be queued for the local MTA routing. If reached, a new incoming connection is rejected with a code indicating temporary congestion.
  • RTS window size – Specifies the number of checkpoints that can be transmitted without receiving an acknowledgment from the remote MTA. Checkpoints are used to synchronize a sending MTA with a receiving MTA. This value must be larger than 0.
  • RTS checkpoint size – Specifies the maximum amount of data that can be transmitted between two checkpoints. Valid values are within the range of 0 to 100 KB. 0 means check pointing is disabled.
  • RTS recovery – Determines whether recovery should be carried out on broken connections. As recovery is seldom enabled, the default selection is disabled.
  • Keep delivery reports time (hours) – Instructs the MTC process not to discard delivery reports when the maximum number of connection attempts has been reached. When the MTC process fails to connect to a remote MTA after the configured number of attempts:
    • All messages, notifications and reports are removed from the message-out queue.
    • A non-delivery report is sent for all messages and UA notifications.
    • All reports are discarded.
  • If this parameter is used, all reports are kept in the message-out queue. The MTC process keeps trying to connect to the remote MTA once an hour.
  • The value of the hours argument specifies the number of hours during which the MTC process attempts to re-send delivery reports. The value must be a whole number greater than zero.
  • Keep notifications time (hours) – Instructs the MTC process not to remove any X.420 or X.435 notifications from the message-out queue when the maximum number of connection attempts is reached. When the MTC process fails to connect to a remote MTA after the configured number of attempts:
    • All messages, notifications and reports are removed from the message-out queue.
    • A non-delivery report is sent for all messages and notifications.
    • All reports are discarded.
  • If this option is used, all X.420 or X.435 notifications sent from the local UAs are kept in the message-out queue, and the MTC process keeps trying to connect to the remote MTA once every hour. The value of the hours argument specifies the number of hours during which the MTC process attempts to re-send notifications. The value must be a whole number greater than zero.
  • Minimum transfer speed (bytes/second) – Specifies the lowest expected network transfer speed. The process to calculate maximum transfer times uses this value. A message transfer is aborted when the maximum transfer time is exceeded. Use this option only when there is a problem with transfer time-outs and the value should not be increased.
  • MTC usage – Indicates whether messages can be sent in one or both directions on the same connection between two MTAs. Most often used is the monolog (one direction) option. Seldom used is two way.

MTA logging

  • Log size (bytes) – The maximum size the log file can grow to before an action specified in the next field is triggered.
  • Log full action – When the log file reaches the maximum size specified in the preceding field, one of the following actions is taken.
    • Stop logging. Logging is stopped.
    • Rename log file. The log rolls to a new file and logging continues.
  • Log level – Use the drop-down list to select the kind of information to log.

MTC logging

  • Log size (bytes) – The maximum size the log file can grow to before an action specified in the next field is triggered.
  • Log full action – When the log file reaches the maximum size specified in the preceding field, one of the following actions is taken.
    • Stop logging. Logging is stopped.
    • Rename log file. The log rolls to a new file and logging continues.
  • Log level – Use the drop-down list to select the kind of information to log.

Advanced MS

  • Maximum message size (bytes) – The maximum size of messages to retrieve from the message store (MS). If a larger message is found, it is deleted from the MS.
  • Message fetch limit – Maximum number of messages retrieved per MS poll. This an be used to control flow at peak hours. When the limit is 0, no messages are retrieved, which can be useful when testing the MS connection without retrieving any messages.
  • Minimum transfer speed (bytes/second) – Specifies the lowest expected network transfer speed. This value is used to calculate maximum transfer times. A message transfer is aborted when the maximum transfer time is exceeded.
  • Transport class – Transport class proposed when a connection is made.
  • Time to keep sending notifications (hours) – Instructs the MS client task not to remove any X.420 or X.435 notifications from the message-out queue when the maximum number of connection attempts is reached. When the MS client task fails to connect to a remote MS after the configured number of attempts:
    • All messages and notifications are removed from the message-out queue.
    • An internal non-delivery report is sent for all messages and notifications.
  • If this option is used, all X.420 or X.435 notifications sent from the local UAs are kept in the message-out queue. The MS client task keeps trying to connect to the remote MS once an hour. The value specifies the number of hours during which the MS client task attempts to re-send notifications.
  • Log size (bytes) – The maximum size the log file can grow to before an action specified in the next field is triggered.
  • Log full action – When the log file reaches the maximum size specified in the preceding field, one of the following actions is taken.
    • Stop logging. Logging is stopped.
    • Rename log file. The log rolls to a new file and logging continues.
  • Log level – Use the drop-down list to select the kind of information to log.

External MSs

Lists the external message stores that have been set up for the server. If there are none, click Add and see MSP7 for an X.400 server.

Remote MTAs

Lists the remote message transfer agents that have been set up for the server. If there are none, click Add and see Remote MTA for an X.400 server.

DMZ ports tab

Note   This tab displays in the user interface only if your software license enables Secure Relay DMZ nodes. The tab only applies to servers used for trading and not integration.
  • Enable DMZ port forwarding – Select this option if you want the external firewall or load balancer to send inbound connections to Secure Relay DMZ nodes rather than directly to embedded servers in the protected network.
  • In the simplest case there is one DMZ port with the same value as the corresponding embedded server port in the protected network. If you add a machine to your cluster and return to the DMZ ports tab, another DMZ port automatically is added in sequence. This happens because every machine in the cluster that can host the embedded server must be assigned a unique corresponding port in the DMZ.
  • Click the port field to display a list of ports already in use.
  • Zone – If you want to receive messages through a Secure Relay DMZ zone, select a zone. This drop-down field is available only if zones have been set up.

See Enable port forwarding for an exchange for more information.

Related topics

Related Links