Application and Web Servers
See the Third Party Support matrix for details.
Supported Web Application Servers
TeamConnect supports and is certified on the following application servers:
| Supported Versions | Certified On | Drivers |
|---|---|---|
| Oracle Weblogic 12c | 12.2.1.4 |
Note: For WebLogic 9.2+ version, follow the instructions while Deployment. |
| WebSphere Liberty | 21.0.0.12 |
|
| Tomcat | 9.0.22 |
|
Supported Application Server Platforms
TeamConnect supports the hardware platforms and operating systems that are certified by your application server software vendor. Consult the application server documentation for a list of compatible web servers and details regarding application and web server installation:
- Apache Tomcat— tomcat.apache.org
- Oracle WebLogic— www.oracle.com
- IBM WebSphere—pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp
Additional Requirements for TomCat
For Tomcat, add the following for Connector in the server.xml file (found in root/conf):
relaxedQueryChars=""<>[\]^`\{|}"
Application Server Hardware Requirements
To provide TeamConnect with sufficient Java heap space to operate optimally, the TeamConnect server must have enough memory and CPU capacity available to support the usage pattern and the number of users.
- These requirements are based on out of the box TeamConnect design.
- Additional customization might change the system requirements needed for the application to run efficiently.
| Number of Concurrent Users | <100 | 100-300 | 300-500 | 500-1000 |
|---|---|---|---|---|
| Processor | 64-bit Single CPU 2-4 Cores 2+ GHz |
64-bit 2x Dual Core or Single Quad Core 2+ GHz |
64-bit 2x Quad Core 2+ GHz |
64-bit 4x Quad Core 2+ GHz |
| Java Heap Size | 2-4 GB | 2-4 GB | 4-8 GB | 8-16 GB |
Application Server Performance Considerations
- The required Java minimum heap size setting is at least 2 GB for TeamConnect, but more may be required depending on your environment and usage. Monitor JVM heap utilization during the test cycle and perform a load test to validate that the settings you are planning to use in production can handle the expected user scenarios and load.
- For optimal performance, refer to the performance tuning documentation provided by your application server vendor and database vendor for more information on other environmental and configuration considerations that should be taken into account when setting up TeamConnect.
- Mitratech recommends that you configure your web server to "keep alive" the TeamConnect session. This is particularly recommended if you are using a single sign-on method of authentication. "Keep alive" improves the performance of TeamConnect.
- Mitratech recommends enabling http compression if you are using the interactive grids with a large max search results value (> 1000) to improve performance.
Testing Your Environment's Support for TeamConnect Features
TeamConnect uses network features that require support from the database, application, and web servers on which it is deployed. Three test applications are provided with TeamConnect that can quickly confirm that your environment supports these features.
All three test applications are run by issuing Java commands from the command line, using tcutility.jar, a file that is found in the utilities/test subfolder of your installation directory. In some cases, you need to use two machines when testing - one as a server and one as a client.
Before testing, copy tcutility.jar to a local directory on the test machines, then start a command- prompt session.
For Windows execute the following command:
set CLASSPATH=<location>/tcutility.jar
For UNIX:
Export CLASSPATH = $CLASSPATH:<location>/tcutility.jar
JDBC Latency Test
This application measures database server response time.
To test SQL Server, execute this command. Type the entire command on a single line:
java -classpath tcutility.jar;sqljdbc.jar teamconnect.jdbc.JdbcLatencyTest arg0 arg1 arg2 arg3 arg4 arg5 To test Oracle:
java -classpath tcutility.jar;ojdbc5.jar teamconnect.jdbc.JdbcLatencyTestarg0 arg1 arg2 arg3 arg4 arg5
The argument definitions are:
- 0: JDBC URL (e.g.,
jdbc:sqlserver://10.0.0.127;databaseName=TEST_DBorjdbc:oracle:thin:@10.0.0.127:1521:test_db) - 1: class name for database driver (e.g.
oracle.jdbc.OracleDriver or com.microsoft.sqlserver.jdbc.SQLServerDriver) - 2: Database username
- 3: Database password
- 4: Number of iterations in the test
- 5: Text of the SQL query (e.g. select * from Y_USER)
The output from the app states the time, in microseconds, required to execute this simple query. Expected acceptable range for this query is 0.6 to 0.8 seconds. Longer times may indicate a database issue that should be resolved before installation.
UDP Test
This application tests clustered server environments. Both UDP and RMI (described below) must work properly for TeamConnect to run on clustered servers.
Login to Machine1 and run these commands:
set CLASSPATH=tcutility.jar
java -classpath tcutility.jar teamconnect.udp.UDPServer 239.192.16.15 6018 5
The argument values shown are examples only. The argument definitions are:
- arg0: UDP address
- arg1: UDP port
- arg2: Time to live (number of hops)
The application responds with message "waiting..."
Login to Machine2 and run these commands:
set CLASSPATH=tcutility.jar
java -classpath tcutility.jar teamconnect.udp.UDPClient 239.192.16.15 6018 Hello 55
The argument values shown are examples only. The argument definitions are:
- arg0: UDP address
- arg1: UDP port
- arg2: Message string to be sent
- arg3: Message count
- arg4: Time to live (number of hops)
The application will respond with messages showing the test string and the status of the send request. These messages will repeat for as many times as are specified in the arg3 value. The server application on Machine1 should display messages, one for each send request, containing the text of the sent string.
Repeat the process by terminating the server application on Machine1, then changing Machine2 to Server and Machine1 to Client.
RMI Test
This application tests clustered server environments. Both UDP (described above) and RMI must work properly for TeamConnect to run on clustered servers.
Note: The RMI registry should not already be running when you begin this test. It is important that the CLASSPATH value be set before the registry is started.
Login to Machine1 and run these commands:
set CLASSPATH=tcutility.jar rmiregistry <port>
java -classpath tcutility.jar teamconnect.rmi.Server <port>
The application responds with "Server ready". Login to Machine2 and run these commands:
set CLASSPATH=tcutility.jar
java -classpath tcutility.jar teamconnect.rmi.Client <IP addr of RMI server> <port>
The application responds with the message "Hello, World" and with the run time that was required to execute the test. Repeat the process by terminating the server application on Machine1, then changing Machine2 to Server and Machine1 to Client, then rerunning the test.
Web Proxy Settings
To provide access to TeamConnect via your organization's URL (for example, http:// www.yourcompany.com/TeamConnect/), set up the appropriate plug-in for your company's web server to proxy (redirect) the HTTP requests to the application server. You must specify the proxy URL (/ TeamConnect in this example) and the hostname and port used by your application server.
Each web server will have a different procedure and syntax for configuring the plug-in. Refer to your web server's documentation for details