Chapter 2. Web Connection Management

Table of Contents

2.1. Overview
2.2. Components
2.2.1. Listeners
2.2.2. Connectors
2.2.3. Worker Thread Pool
2.3. Configuring Web Connections
2.3.1. Common Listener Settings
2.3.2. AJP Listeners
2.3.3. HTTP Listeners
2.3.4. TCP Listeners
2.3.5. WebtoB Connectors
2.3.6. Tmax Connectors
2.3.7. Automatic Thread Pool Management (Thread State Notification)
2.4. Configuring Web Server Load Balancing
2.4.1. Load Balancing Structure
2.4.2. Apache
2.4.3. IIS and Iplanet
2.4.4. Load Balancing with WebtoB
2.5. Using TCP Listeners
2.5.1. Defining Custom Communication Protocols
2.5.2. Implementing Dispatcher Configuration Classes
2.5.3. Implementing TCP Servlets
2.5.4. TCP Listeners for Custom Protocols
2.5.5. TCP Client Implementation
2.5.6. TCP Client Compilation and Execution
2.6. Controlling Connectors
2.7. Tuning Listeners

This chapter describes how to manage and set listeners and connectors provided by the web engine.

JEUS calls both web connectors and web listeners web connections. Starting from JEUS 7, the concepts of listener and connector are distinguished based on what created the connection.

The connections provided by a web engine includes connections to WebtoB and other web servers, direct connections to HTTP/TCP clients, and connections to Tmax. The web server receives an HTTP request from a client and delivers it to the corresponding web engine.

WebtoB and Apache are the typical web servers that are used. They provide the following connectors.

The web engine provides the following listeners and connectors to directly create and manage connections for each client.

Since listeners operate according to the JEUS server configurations, configure JEUS server and its listeners to use secure listeners (SSL).

This section describes thread pools that are used by the listeners and connectors that are provided by the web engine.

Listeners and connectors have a worker thread pool that is required to process client requests. The worker thread pool manages worker threads.

When a listener receives a request, a worker thread is allocated to process the request. For a connector, an individual connection to WebtoB or Tmax is created, and a worker thread is allocated to that connection. Since the minimum and maximum values of the worker thread pool affects the service processing performance, set appropriate min and max values when configuring listeners and connectors.

Note

Starting from JEUS v7.0 Fix#1, the result of executing the thread pool management using the web engine monitoring thread is not logged. Each thread pool manages its own status and the monitoring thread logs the result periodically. Hence, the changes in the log can be different from the actual changes of the thread pool.

Active-Management and Status Notification

The worker thread pool contains configurations for active management.

The administrator can configure active management to allow the web engine to send a warning message via e-mail or to recommend restarting the server of the engine.

To requires configuring the number of blocked worker threads that will trigger an action like sending a warning message via e-mail or a recommendation to restart the server.

Caution

If the recommendation to restart is displayed, the administrator must determine whether to restart the server because it is likely that the server cannot process requests normally.

Separate vendor-specific configurations are required to use an AJP listener, a WebtoB connector, or a Tmax connector. Since all web connections are managed by the engines, this section only describes the web engine configurations.

For more information about configuring web servers, refer to "2.4. Configuring Web Server Load Balancing".

Note

1. Starting from JEUS 7, context groups are no longer supported. Most items that were managed by the context group are now managed by the web engine.

2. Starting from JEUS 7, a unified service listener provided by the server is used as web listener, so AJP, HTTP, and TCP listeners are configured on the server and the they are referenced for use. 'Server Listener Ref' has been added to the configuration for this purpose. However, JEUS uses the current configuration for WebtoB and Tmax connectors because JEUS functions as a client when using these connectors.

Connectors are added, changed, or deleted in WebAdmin and the console tool. It is recommended to configure connectors by in WebAdmin which is described in this section. Refer to JEUS Reference Book. "4.2.8. Web Engine Commands" for detailed information about configuring connectors by using the console tool.

This section describes the common listener settings.

AJP listeners can be added, modified, or deleted in WebAdmin or the console tool.

Using WebAdmin

Using the Console Tool

The following shows how to add, modify, and delete AJP listeners using the console tool.

HTTP listeners can be added, modified, and deleted in WebAdmin or the console tool. Using HTTP listeners is only recommended for internal management.

Using WebAdmin

Using the Console Tool

Similar to AJP listeners, HTTP listeners can be added, modified, or deleted using the console tool. For more information, refer to "Using the Console Tool" in "2.3.2. AJP Listeners".

A TCP listener is a special listener that allows custom protocols to communicate with each other. TCP listener cannot share server listeners with other web listeners, so a dedicated listener for the TCP listener must be added to the server. TCP listeners can be added or modified in WebAdmin or the console tool.

Using WebAdmin

Using the Console Tool

Similar to AJP listeners, HTTP listeners can be added, modified, or deleted using the console tool. For more information, refer to "Using the Console Tool" in "2.3.2. AJP Listeners".

Since JEUS acts as a client when a WebtoB connector creates a connection, the address and port of WebtoB are required. WebtoB connectors can be added, modified, and deleted in WebAdmin or the console tool.

Note

Starting from JEUS 7 Fix#2, the version of the WJP, the communication protocol between WebtoB and JEUS, has been upgraded from 1 to 2(hereafter WJPv1 and WJPv2). WJPv2 uses a smaller packet sizes than WJPv1 and provides various additional functions. If the WebtoB that JEUS will connect to does not provide WJPv2, WJPv1 is used instead. Since WebtoB cannot obtain the WJP version information, it must be configured in the <wjp-version> option of JEUS. WJP means "WebtoB-JEUS Protocol".

If <use-nio> is set to true, the Java NIO Selector can be used for WebtoB-JEUS communication. Since WJP connection is not managed by the servlet request thread but the thread that is in charge of the selector, there are separate WJP connection and servlet request threads. This way, HTTP requests from WebtoB can be processed by using less number of threads. The threadinfo and list-webtob-connections commands must be used to check the state of WJP connections.

Using WebAdmin

Using the Console Tool

The following shows how to add, modify, and delete WebtoB connectors.

Like with WebtoB connectors, since JEUS functions as a client when a Tmax connector creates a connection, the address and port of Tmax are required.

Tmax connectors can be added, modified, and deleted in WebAdmin or the console tool.

Using WebAdmin

Using the Console Tool

The following shows how to add, modify, and delete a Tmax connector using the console tool.

Thread state notification setting defines the minimum number of worker threads that will trigger a notification via e-mail or to recommend restarting the server. Configure the Thread State Notify setting from the listener or connector configuration screen.

If automatic thread pool management is configured, worker threads are managed based on the 'Max Thread Active Time' value.

Threads for which the request processing time exceeds the Max Thread Active value are considered as blocked threads. If the number of threads, excluding blocked threads, is less than the minimum thread pool size, enough new worker threads are created to maintain the minimum value.

Since WebtoB connectors are not configured with a minimum value but only a total number of connections, they operate differently from other listeners and connectors. For WebtoB connectors, the sum of blocked threads and regular threads must be same as the number of connections. As soon as a blocked thread completes a request, it will be deleted and any new requests will use a new worker thread.

Thread state notifications can be configured in the thread pool to receive notifications.

The following example configures an e-mail notifier for an AJP listener. For more information about configuring an e-mail using the e-mail notifier, refer to the SMTP handler configuration in JEUS Server Guide. "8.3. Logging Configuration".


The following describes each configuration option.

ItemDescription
Max Thread Active Time

Maximum time before a worker thread is considered blocked.

This time is measured from when the worker thread starts processing the client request (when a servlet starts). The time expires when the processing time exceeds the specified time or when the thread is returned to the thread pool (when thread is not blocked).

If this value is less than 1, it will be ignored.

Notify Threshold Ratio

Allowed maximum ratio of blocked threads. If the ratio of blocked threads to worker threads reaches the specified value, an error message will be sent via e-mail.

This value must be a real number that is greater than 0 and less than or equal to 1. If the value is less than or equal to 0, the configuration will be ignored.

Restart Threshold Ratio

Allowed maximum ratio of blocked threads. If the ratio of blocked threads to worker threads reaches the specified value, an error message will be sent via e-mail and a message that recommends restarting is recorded in the server logs.

This value is a real number that is greater than 0 and less than or equal to 1. If the value is less than or equal to 0, the configuration will be ignored.

Notify SubjectOption to send a warning message via e-mail.
Restart SubjectUsed for sending an e-mail notification and recording engine logs.
Interrupt ThreadOption to interrupt the thread if an active timeout occurs. In other words, if the worker thread is processing a request for longer than the 'Max Thread Active Time' value (Default value: false). If set to true, an interrupt event will occur.
Active Timeout Notification

Option to send a message via e-mail when an active timeout occurs. (Default value: false)

If set to true, an e-mail will be sent.

This section describes how to configure web servers and how to connect web connections to the web engine.

Web servers and web engines (servlet engines) can be organized to improve the system performance when processing HTTP requests.

First, web servers distribute the HTTP requests to the web engines. After that, they direct the same connections or session requests to the web engine that processed the first request by using HTTP session clustering services to improve service processing efficiency.

If an error occurs in the web engine that first processed the request, requests that are received after the error occurrence will be sent to another web engine to provide seamless services. A cluster is required to perform this task. For more information about HTTP session clustering, refer to JEUS Session Management Guide. "Chapter 2. Distributed Session Servers".

Even if web engines are used without web servers, equipment or software that can deliver further requests to the web engine that processed the first request can be used to increase efficiency like when using web servers. However, JEUS neither provides this kind of software nor recommends using one.

Warning

Web server and mod_jk configurations can differ according to the web server version. The configuration method described here is used for enhancing the understanding of JEUS. When configuring web servers in the production environment, refer to each relevant web server documentations and configuration examples provided by local/overseas communities.

Execute the following steps to integrate Apache with the web engines.

  1. Install the mod_jk library in Apache.

  2. Configure an AJP13 listener in the JEUS web engine.

  3. Create and modify the workers.properties file.

  4. Insert the integration settings in the httpd.conf file for the Apache web server.

  5. Restart the Apache web server.

Note

Apache and mod_jk 1.2.20 is described based on 1.2.20.

Installing the mod_jk Library

To use Apache web servers with web engines, the mod_jk module must be added to Apache. The mod_jk module implements the Apache JServ Protocol 1.3(AJP 1.3), a communication protocol between servers and engines.

Note

Download the source from http://tomcat.apache.org/download-connectors.cgi, and compile it on the server. Starting from April 2014, an executable file for Windows is provided from the site.

Configuring AJP13 Listeners

After the mod_jk library has been installed, configure the AJP13 listener in the JEUS web engine. For more information about configuring AJP13 listeners, refer to "2.3.2. AJP Listeners".

Configuring the workers.properties File

The workers.properties file is a configuration file for mod_jk.

As an example, there are two JEUS servers named server1 and server2 and the host names are server1 and server2. The name of the web engine for each server is server_servelt and server2_servlet. The AJP listeners configured on each web engine are 9901 and 9902.

The following is an example of the workers.properties file in the JEUS environment.


The workers.properties file uses the "worker.<worker_name>.<directive>=<value>" format to define most settings. The following describe the major configuration options.

Warning

Since this configuration information may not be current for the latest version of mod_jk, use the examples in this section only for reference. To configure the settings, mod_jk related descriptions in the Tomcat site must be followed.

Configuring httpd.conf

To use the mod_jk module, add the following to the httpd.conf file:


Warning

Since this configuration information may not be current for the latest version of Apache, use the examples in this section only for reference. Refer to the Apache manuals.

This section describes how to configure load balancing between WebtoB and JEUS, and provides examples.

The following shows the server structure of the example. Each engine is connected a WebtoB server. In the following example, there are two WebtoB servers and each one is connected to two web engines.


The same context must be deployed to each server.

In general, in a structure like the previous figure, servers A through D become clustered and distributed session servers are used accordingly. Clustering is not necessary if user sessions are not used.

The following diagram shows the dotted box in detail and displays each WebtoB connector configurations.


When configuring WebtoB connectors, consider the number of WebtoB HTH processes.

A WebtoB HTH process functions as if it has multiple sub-processes. It is connected to a worker thread of WebtoB connector as one to one. Choose appropriate values for the WebtoB connector's 'Worker Thread Pool Max' setting and the WebtoB server's 'MaxProc' setting.

The number of HTH processes in the WebtoB configuration can be set in the 'Hth Count' setting of the WebtoB connector. The 'MaxProc' value of WebtoB and the 'Worker Thread Pool Max' value of the WebtoB connector can be expressed using the following formulas.

MinProc = 
Listener A number threads + Listener B number threads + … + Listener X number threads setting.
MaxProc = 
Listener A number threads + Listener B number threads + … + Listener X number threads setting.

The 'Hth Count' of the WebtoB connector must be the same as the number of HTH processes of the *NODE configuration in the WebtoB configuration file. For more information about configuring WebtoB connectors, refer to "2.3.5. WebtoB Connectors".

The following example of the http.m file configures WebtoB A from the previous example.


Note the values of min and max. The min and max values are set as in the following.

HTH MinProc = 6 = 2 thread + 4 thread, HTH MaxProc = 25 = 10 thread + 15 thread

TCP listeners can define a communication protocol between TCP clients and TCP servlets, but they are only recommended when the HTTP and HTTPS protocols are not sufficient.

Execute the following steps to use a TCP listener.

  1. Define a customized communication protocol.

  2. Implement the dispatcher config class (Protocol configuration)

  3. Implement the TCP handler servlet (Protocol implementation)

  4. Set the TCP listener to implement the custom protocol.

  5. Implement the TCP client.

  6. Compile and execute the TCP client.

The following are the terms used in this section.

TermDescription
Protocol (Communication Protocol)Defines the message structure and contents that are exchanged between the TCP client and TCP handler (TCP listener is a mediator)
MessageData that is exchanged between the TCP client and TCP handler. Must follow the structure defined in the protocol.
TCP ClientExternal application, which is processed by the TCP handler, that communicates and exchanges messages with the TCP listener. A standard socket is used to exchange messages.
TCP HandlerReceives messages from the TCP listener and processes them. The TCP handler is implemented as a subclass of jeus.servlet.tcp.TCPServlet and is registered in the web engine like regular servlets. The TCP handler works as if it is the provider or implementation class of the custom protocol that exist above the TCP protocol.
TCP Dispatcher Configuration Class

Extended class of jeus.servlet.tcp.TCPDispatcherConfig. This class sends the custom protocol information to the TCP listener and processes non-HTTP messages.

Put the class in the 'DOMAIN_HOME/lib/application' directory, and configure 'Dispatcher Config Class' for the TCP listener in the web engine configuration. Refer to "2.3.4. TCP Listeners".

TCP Listener

Interprets custom messages and provides the routing infrastructure. This acts as a non-HTTP mediator between the TCP client and TCP handler.

Similar to other HTTP listeners, this exists in the web engine.

A dispatcher configuration class is a subclass of the jeus.servlet.tcp.TCPDispatcherConfig class. The abstract method of the class must implement the information required for the TCP listener to deliver messages to the appropriate TCP handler. The methods are described in the JEUS_HOME/docs/api/jeusapi/index.html file.

Starting from JEUS v7.0 Fix#1, the getBodyLengthLong method has been added. If the TCP Body is 2GB or more, the Body length can be set to 8Byte by using this method.

The following code shows how the dispatcher configuration class is implemented based on the defined protocol. Refer to the comments to understand how the methods are used.

[Example 2.4] TCPDispatcherConfig Implementation: <<SampleConfig.java>>

package sample.config;

import javax.servlet.*;
import javax.servlet.http.*;
import jeus.servlet.tcp.*;

/*
  This class extends the abstract class jeus.servlet.tcp.
  TCPDispatcherConfig class. This implementation provides
  routing and handling information to the TCP listener
  according to our defined communications protocol.
*/
public class SampleConfig extends TCPDispatcherConfig {
    /*
      Any init code goes into this method. This method will be    
      Called once after starting the TCP listener.
      We leave this method empty for our simple example.
    */
    public void init() {}

    /*
      This method returns the fixed-length of the header so                  
      that the TCP listener knows when to stop                                   
      reading the header. The header length for 
      our example is 41 (bytes): 4 (magic) + 1 
      (type) + 4 (body length) + 32 (service name).
    */
    public int getHeaderLength() {
        return 41; 
    }
    
    /*
      This method must return the length of the body.
      For our example, this length is represented as an 
      “int” in the header, starting at position “5” 
      (see the protocol definition above).
    */
    public int getBodyLength(byte[] header) {
        return getInt(header, 5);
    }

    /**)
     * Returns the long-size length of request body of
     * incoming request packet.
     * If you don't need to support long, you may map to
     * {@link #getBodyLength(byte[])}.
     */
    public long getBodyLengthLong(byte[] header) {
        return getBodyLength(header);
    }

    /*
      This method must return the context path so that the
      request can be routed by the TCP listener to the context
      that contains the TCP handler (TCPServlet implementation).
      For our example, we always use the context path “/tcptest”.
    */
    public String getContextPath(byte[] header) {
        return "/tcptest";
    }

    /*
      This method must return the name (path) of the TCP 
      handler(TCPServlet) relative to the context path. 
      For our example, we fetch this name from the 9th position
      in the header.
    */
    public String getServletPath(byte[] header) {
        return "/" + getString(header, 9, 32);
    }

    /*
      This method returns some path info from the header.
      It is not used in our example and thus returns “null”.
    */
    public String getPathInfo(byte[] header) {
        return null;
    }

    /*
      This method returns any session ID embedded in the header.
      It is not used in our example and thus returns “null”.
    */
    public String getSessionId(byte[] header) {
        return null;
    }

    /*
      This method determines whether the TCP listener 
      should keep the socket connection open after the TCP handler
      has delivered its response. If it returns “false”, the
      connection will be dropped like in HTTP communications.
      If it returns “true” the connection will be kept open
      like in the Telnet or FTP protocols. For our example,
      we choose to make it persistent (connection not closed
      by the TCP listener).
    */
    public boolean isPersistentConnection() {
        return true;
    }
}


TCP servlets are always a subclass of the jeus.servlet.tcp.TCPServlet class. The handler always contains the abstract void service(TCPServletRequest req, TCPServletResponse, res) method that is overridden.

The service method must be implemented to process messages that follow the custom protocol. The web container reads a header and sends it to the TCPServletRequest object, and the TCP servlet writes a response to an output stream of the TCPServletResponse object.

The following is an implementation of the TCP servlet that processes the message that follows the custom protocol.

[Example 2.5] TCPServlet Implementation: <<SampleTCPServlet.java>>

package sample.servlet;

import java.io.*;
import javax.servlet.*;
import javax.servlet.http.*;
import jeus.servlet.tcp.*;

/**
 * Sample TCPServlet implementation
 *
 * Protocol scheme:
 * 
 * common header (for request and response) : total 41 byte
 * 
 *   magic field: length = 4 byte, value = 7777
 *   type field : length = 1 byte, 0 : request, 1:response
 *   body length field : length = 4, value = 128
 *   service name field : length = 32
 * 
 * request and response body
 *  
 *   message1 field : length = 64
 *   message2 field : length = 64
 * 
 */

public class SampleTCPServlet extends TCPServlet {

    public void init(ServletConfig config) throws ServletException {
    }

    public void service(TCPServletRequest req, TCPServletResponse res)
        throws ServletException, IOException {
        ServletContext context = req.getServletContext();
        byte[] header = req.getHeader();
        byte[] body = new byte[req.getContentLength()];
        int read = req.getInputStream().read(body);
        if (read < body.length) {
            throw new IOException("The client sent the wrong content.");
        }

        String encoding = res.getCharacterEncoding();
        if (encoding == null)
            encoding = "euc-kr";

        DataInputStream in = new DataInputStream(new ByteArrayInputStream(header));
        int magic = in.readInt();
        context.log("[SampleTCPServlet] received magic = " + magic);

        byte type = (byte)in.read();
        context.log("[SampleTCPServlet] received type = " + type);

        int len = in.readInt();
        context.log("[SampleTCPServlet] received body length = " + len);

        byte[] svcname = new byte[32];
        in.readFully(svcname);
        context.log("[SampleTCPServlet] received service name = " 
                     + (new String(svcname)).trim());

        String rcvmsg = null;
        rcvmsg = (new String(body, 0, 64)).trim();
        context.log("[SampleTCPServlet] received msg1 = " + rcvmsg);

        try {
            rcvmsg = (new String(body, 64, 64, encoding)).trim();
        } catch (Exception e) {}
        context.log("[SampleTCPServlet] received msg2 = " + rcvmsg);

        String msg1 = "test response";
        String msg2 = "test response2";

        byte[] result1 = null;
        byte[] result2 = null;
        if (encoding != null) {
            try {
                result1 = msg1.getBytes(encoding);
                result2 = msg2.getBytes(encoding);
            } catch (UnsupportedEncodingException uee) {
                result1 = msg1.getBytes();
                result2 = msg2.getBytes();
            }
        } else {
            result1 = msg1.getBytes();
            result2 = msg2.getBytes();
        }

        header[4] = (byte)1; // mark as response

        ServletOutputStream out = res.getOutputStream();
        out.write(header);

        byte[] buf1 = new byte[64];
        System.arraycopy(result1, 0, buf1, 0, result1.length);
        out.write(buf1);

        byte[] buf2 = new byte[64];
        System.arraycopy(result2, 0, buf2, 0, result2.length);
        out.write(buf2);

        out.flush();
    }

    public void destroy() {
    }
}


Note

Starting from JEUS 7 Fix#2, it is not recommended to use the TCPServletRequest.getBody() method. This method may cause a memory issue if the request body is too big. It is recommended to use the ServletInputStream class defined in the servlet standard instead. This object can be obtained by using the TCPServletRequest.getInputStream() method.

TCP clients connect to TCP listeners using a socket and uses the connection to send messages. The messages are byte streams that follow the custom protocol defined in "2.5.1. Defining Custom Communication Protocols".

The TCP listener receives the messages and calls the service() method of the SampleTCPservlet class based on dispatch information defined in the SampleConfig class. The SampleTCPServlet creates the response based on the client data and delivers it. The client receives the response and outputs it using System.out.

The following is an example of a TCP client implementation.

[Example 2.7] TCP Client Implementation: <<Client.java>>

package sample.client;

import java.io.*;
import java.net.*;

public class Client {
    private String address;
    private int port;

    private int magic = 7777;
    private byte type = 0;
    private int bodyLength = 128;
    private byte[] serviceName="sample".getBytes();

    public Client(String host, int port) {
        this.address = host;
        this.port = port;
    }

    public void test()
        throws IOException, UnsupportedEncodingException {
        Socket socket = new Socket(address, port);
        DataOutputStream out = new DataOutputStream(
            new BufferedOutputStream(socket.getOutputStream()));
        DataInputStream in = new DataInputStream(
            new BufferedInputStream(socket.getInputStream()));

        out.writeInt(7777);
        out.write(type);
        out.writeInt(bodyLength);
        byte[] buf = new byte[32];
        System.arraycopy(serviceName, 0, buf, 0, serviceName.length);
        out.write(buf);
        byte[] msg1 = "test request".getBytes();
        byte[] msg2 = "test request2".getBytes();
        buf = new byte[64];
        System.arraycopy(msg1, 0, buf, 0, msg1.length);
        out.write(buf);
        buf = new byte[64];
        System.arraycopy(msg2, 0, buf, 0, msg2.length);
        out.write(buf);

        out.flush();

        // rx msg
        int magic = in.readInt();
        System.out.println("[Client] received magic = " + magic);

        byte type = (byte)in.read();
        System.out.println("[Client] received type = " + type);

        int len = in.readInt();
        System.out.println("[Client] received body length = " + len);

        byte[] svcname = new byte[32];
        in.readFully(svcname);
        System.out.println("[Client] received service name = " +
                           (new String(svcname)).trim());

        byte[] body = new byte[128];
        in.readFully(body);
        String rcvmsg = null;
        rcvmsg = (new String(body, 0, 64)).trim();
        System.out.println("[Client] received msg1 = " + rcvmsg);
        rcvmsg = (new String(body, 64, 64, "euc-kr")).trim();
        System.out.println("[Client] received msg2 = " + rcvmsg);

        out.close();
        in.close();
        socket.close();
    }

    public static void main(String[] argv) throws Exception {
        Client client = new Client("localhost", 5555);
        client.test();
    }
}


In the previous client code, note the various field configurations of the header that are required for the protocol.

The 'magic' number is set to '7777', the 'type' is set to '0' (request), the 'body length' is set to '128 bytes', and the 'service name' is set to 'sample', which is the name in web.xml. After creating two messages, the header information is sent and the messages are sent to the TCP listener. Finally, the 'hostname' is set to 'localhost' and the port number is set to '5555'.

When using a WebtoB connector, JEUS receives requests through WebtoB. If the administrator wants to temporarily disable requests from WebtoB, WebtoB can be stopped from sending requests to JEUS based on the rules defined between JEUS and WebtoB.

JEUS can control WebtoB connectors by using the following tools.

  • Using WebAdmin

  • Using the console tool

Using WebAdmin

Connectors can be controlled in WebAdmin using the following steps.

Using the Console Tool

The console tool can be used to control the connectors.

Consider the following when configuring listeners for optimal performance