Managing gateway configurations

Gateways manage the transport information used in routing documents to their proper destination in the hub community. The outbound Transport protocol determines which information is used during gateway configuration. For information on creating gateways, see the Hub Configuration Guide.

Required information for gateway configuration

The transport type determines the parameter information needed for gateway setup. In Table 3, the boxes marked with an X require configuration information, boxes marked with the letter O are optional. See Table 4 for the gateway parameter descriptions.

Note:
The ability to edit certain gateway configuration values varies with the permission level of the user.
Table 3. Required transport information
Required transport information HTTP transport HTTPS transport FTP transport FTPS transport FTP Scripting transport File Directory transport JMS transport SMTP transport

Authent..
Required

O

O

Auto Queue

O

O

O

O

O

O

Connection
Timeout

X

X

X

X

X

FTPS Mode

O

JMS Factory
Name

X

JMS JNDI
Factory
Name

X

JMS Message
Class

X

JMS Message
Type

O

JMS Queue
Name

X

Lock User

O

Number of
Threads

X

X

X

X

X

X

Password

O

O

O

O

O

O

O

O

Provider
URL Package

O

Retry Count

X

X

X

X

X

X

X

X

Retry Interval

X

X

X

X

X

X

X

X

Server IP

X

Target URI

X

X

X

X

X

X

X

User Id

O

User Name

O

O

O

O

O

O

O

Validate
Client IP

O

O

O

O

Validate
Client SSL
Cert

O

Notes:
  1. When a gateway's Authentication Required option is on, and the User Name and Password are provided, the gateway will pass the User Name and Password to the external system that it connects to for document delivery. The gateway does not enforce authentication, it simply passes these authentication credentials to the system that it is trying to connect to. For a JMS gateway, the User Name and Password are used as the credentials for JNDI look up of the JMS Queue Connection Factory. Note that JMS over Websphere MQ does not enforce JNDI authentication when file-based JNDI is used to connect to a JMS queue.
  2. Username and password are required for FTPS authentication unless the FTPS server you are negotiating with is mapping the user, based on a presented client certificate. Check with the FTPS server administrator for implementation details.

Viewing and editing gateways

To view and edit gateways, follow these steps:

  1. Click Account Admin > Profiles > Gateways.
  2. Click Online or Offline in the Access column to change the access of a gateway.
  3. Click Enabled or Disabled in the Status column to change the status of a gateway.
  4. Click the View details icon to view gateway details.
  5. Click the Edit icon.
  6. On the Gateway Detail window, edit the gateway parameters that are described in Table 4.
  7. Click Save.

    You can also delete the gateway by clicking Delete.

    Table 4. Gateway parameter descriptions
    Parameter Description

    Authentication Required

    If enabled, user name and password are supplied with JMS or SMTP messages.

    Auto Queue

    If enabled, documents are placed in a temporary repository if the gateway is placed offline. If disabled and the gateway is placed offline, the document fails to route and an error occurs.

    Calendar Based Scheduling

    When this option is selected, the documents associated with that gateway are processed based on the selected schedule.

    Configuration Point Handlers

    Used to specify which handlers are used for preprocessing and postprocessing.

    Connection Timeout

    Number of seconds a socket will remain open with no traffic. Default value is 120 (2 minutes).

    Description

    Optional description of the gateway.

    FTPS Mode

    Select Yes or No to control whether a secure connection is used.

    Gateway Name

    Name used to identify the gateway.

    Note: Gateway Name is a user-defined free format field. While uniqueness is not required, users should use different names for individual gateways to avoid potential confusion.

    Interval Based Scheduling

    When this option is selected, the gateway processes the document at the specified interval time.

    JMS Factory Name

    Name of the Java(TM) class the JMS provider will use to generate connection to the JMS queue.

    JMS JNDI Factory Name

    Factory name used to connect to the name service.

    JMS Message Class

    Class of message.

    JMS Message Type

    Type of JMS message.

    JMS Queue Name

    Queue name where JMS messages are stored.

    Lock Retry Interval (Seconds)

    Amount of time that the FTP Script component will wait between lock retry attempts.

    Lock Retry Count

    Number of times that the FTP Script component will attempt to obtain the lock.

    Lock User

    Select Yes or No to control whether or not concurrent connections are allowed.

    Maximum Lock Time (Seconds)

    Maximum amount of time that the FTP Script component will hold the lock. After the maximum time, the lock is returned to the database.

    Maximum Queue Age (Seconds

    Maximum amount of time that the FTP Script component remains in the lock request queue. It is placed in the lock request queue when it is denied a lock request.

    Number of Threads

    Number of threads allocated for routing a document. Default value is 3. This parameter is available to Hub Admin users only.

    Online / Offline

    Indicate whether the gateway is online or offline. If offline, documents are queued until the gateway is placed online.

    Password

    Password for secure access through the participant firewall.

    Provider URL Package

    Name of classes or JAR file that Java uses to understand JMS Context URL.

    Retry Count

    Maximum number of times the system tries to send a document before it fails. Default value is 3.

    Retry Interval

    Amount of time that the gateway should wait in between retry attempts. Default value is 300 (5 minutes).

    Script File

    The FTP script that contains the FTP commands.

    Server IP

    Server IP address.

    Status

    Indicates whether the gateway is enabled or disabled. If disabled, documents passing through the gateway fail processing.

    Target URI

    Uniform Resource Identifier (URI) of the participant.

    Thread Nbr

    Number of documents that should be processed simultaneously.

    Transport

    Protocol for routing documents (see Required information for gateway configuration).

    Use Unique File Name

    Creates a unique file name when the document is received at the target location. The original file name is stored in the database.

    User defined attributes

    For FTP script files, users can add their own attributes, which can be defined in the console. These attributes are read at the gateway and replaced in the script file.

    User Id

    Required to access the FTP server.

    User Name

    User name for secure access through the participant firewall.

    Validate Client IP

    Validates the IP address of the sending partner before processing the document. Used with the Gateway that is selected as a source Gateway for a connection.

    Validate Client SSL Cert

    Validates the sending participant's digital certificate against the business id associated with the document before processing the document. Used with the Gateway that is selected as a source Gateway for a connection.

Viewing and editing default gateways

Follow these steps to view default gateways configured for the system and edit them:

  1. Click Account Admin > Profiles > Gateways.
  2. Click View Default Gateways in the upper right corner of the window. The Console displays a list of all gateway types with their associated gateway.
  3. To view information associated with a default gateway, click the View details icon next to the gateway.
  4. Edit the information as desired, then click Save.

Deleting gateway configurations

If you no longer need a gateway configuration, use the following procedure to delete it. A precautionary message does not appear before you delete a gateway configuration. Therefore, be sure you do not need the gateway configuration before you delete it.

  1. Click Account Admin > Profiles > Gateways.
  2. Click the View details icon next to the gateway you want to delete.
  3. Click the Edit icon.
  4. Click Delete.

Uploading transports

Use the following procedure to upload a transport.

  1. Click Account Admin > Profiles > Gateways.
  2. Select Manage Transport Type.
  3. Click Browse and select the transport.
  4. Select whether or not to commit the new transport to the database.
  5. Select whether or not to overwrite the existing data.
  6. Click Upload.

Deleting transports

If you no longer need a transport, use the following procedure to delete it.

  1. Click Account Admin > Profiles > Gateways.
  2. Select Manage Transport Type.
  3. Click the Delete icon next to the listed transport.

Transport and gateway retries

When delivery of a document to a participant gateway fails, WebSphere Partner Gateway attempts to deliver the document again. Each attempt is called a retry. Retry functionality exists at two levels in WebSphere Partner Gateway: transport and gateway.

Transport retries

Transport retries are built-in, low-level retries that are always applied regardless of the gateway specification. The motivation for low-level retries is that transient failures are inherent in the networks over which delivery is attempted, particularly the Internet. Thus, the delivery system is designed to retry automatically without requiring the user to define the retry parameters explicitly. The number of transport retries (bcg.delivery.gwTransportMaxRetries) and the time interval between retries (bcg.delivery.gwTransportRetryInterval) are defined in the document manager bcg.properties file and apply to all gateways. The default values are three retries at three second intervals.

Gateway retries (also called document retries)

Gateway retry parameters (the number of retries allowed and the interval between retries) are configured by the user in the gateway properties. Usually the gateway retry interval is longer than the built-in transport retries. The intent is to allow sufficient time for the user to correct the problem that is preventing delivery. For example, the destination Web server might be down, or the destination URL might be incorrect. Setting the parameter values requires that the user assign values for each gateway.

For each gateway retry (user defined), WebSphere Partner Gateway will automatically perform the transport retries. For example, if three gateway retries are specified, the system retry pattern is:

Every failed delivery attempt generates a warning event that is visible in the Community Console.

Forward proxy support

For the HTTP and HTTPS transports, you can set up forward proxy support so that documents are sent through a configured proxy server. With WebSphere Partner Gateway you can set up the following support types:

After you set up a forward proxy, you can make it global for the transport by making it the default forward proxy gateway (for example, all HTTP gateways make use of the forward proxy). For each individual gateway you can then choose not to use the default Forward proxy server or you can select to use a different Forward proxy server. See the Hub Configuration Guide for more information on Forward proxy support.

Copyright IBM Corp. 2003, 2005