Integration Server Deployment Checklist

Introduction

This appendix contains a useful checklist for setting up your webMethods Integration Server. It describes the steps to perform to put an Integration Server into production. The process is comprised of several stages. You should complete one stage before advancing to the next.

Stage 1: Installation

Complete the following steps to install, run, and test the Integration Server.

Step Action Done?
1. Install the Integration Server.

For instructions, see Installing Software AG Products.

Note: You can install the Integration Server as either a Windows application or a Windows service. After installation, if you want, you can switch from a Windows application to a Window service, or vice versa. For instructions, see Running Integration Server as a Windows Application vs. a Windows Service.
 
2. Change default passwords.

Use the Integration Server Administrator to assign new passwords to the following user accounts:

  • The "Administrator" user account.
  • The "Developer" user account.
  • The "Central" user account.
  • The "Replicator" user account.

For instructions on how to change passwords, refer to Adding an Administrator User.

Use the Integration Server Administrator to assign a new master password for the Integration Server to use when encrypting outbound passwords before storing them. For instructions on changing the master password, refer to Changing the Master Password.

 
3. Determine a strategy for outbound passwords and the master password.

Before you launch and configure your Integration Server the first time, determine how you want the Integration Server to handle the outbound passwords and master password with respect to where they are stored, how they are encrypted, and how often they must be changed. If you change these settings after the Integration Server has been configured, the master password and outbound passwords can become out of sync. See Configuring Integration Server for Secure Communications for more information.

 
4. Determine whether to use a JDK or JRE and specify the Java location.

If you intend to use Designer and/or Developer to develop and compile Java services on Integration Server, specify the location of the JDK. If you will not be using this installation of Integration Server to compile Java services, you can specify the location of a JRE or a JDK. For information about specifying the Java location, see Passing Java System Properties to Integration Server.

 

Stage 2: Basic Configuration

Use the Integration Server Administrator to configure the way in which the server will send outbound requests, accept inbound requests, expire sessions, and issue error messages.

Step Action Done?
1. Set up the ports.

Use the Ports page to specify the ports on which the server will listen for requests.

If you will receive HTTP and/or HTTPS requests on multiple ports, you may want to disable all but one port (the one you will use to interact with the Integration Server Administrator) until the server is ready for production.

For instructions on how to set up and disable ports, see Setting Up Aliases for Remote Integration Servers.

 
2. Specify the proxy servers.

Use the Proxy Servers page to specify the proxy server(s) (if any) through which this server will issue outbound requests.

Specify which URLs (if any) can bypass the proxy server.

For instructions on how to specify proxy servers and bypass lists, see Setting Up Aliases for Remote Integration Servers.

 
3. Configure session timeouts.

Use the Resources page to set the timeout value you want the server to use.

For instructions, see Managing Server Sessions.

 
4. Specify the error message recipients and an SMTP server.

Use the Logging page to specify the e-mail address where you want the server to send error messages when an exception (a critical server error or a binding failure) occurs and the name of the SMTP server to use for this purpose.

For instructions, see Configuring Where the Integration Server Writes Logging, Status, and Other Information.

 
5. Set up logging.

For instructions, see the webMethods Audit Logging Guide and Setting Up the Server Log.

 

Stage 3: Setting Up Users, Groups, and ACLs

Use the Integration Server Administrator to identify user accounts, groups, and access control lists (ACLs) to provide appropriate levels of access to the services that will run on this server.

Step Action Done?
1. Identify service security requirements.

Services are implicitly blocked from access by anyone other than Administrators and Developers. Determine what level of access is required, whether limited to one group of users, all authenticated users, or even unauthenticated users, and apply the appropriate ACL to the service.

 
2. Create user IDs and groups or configure an external directory.

If you have secure services, identify users and/or client applications that are authorized to access those services and create groups that contain the authorized members.

If your site uses an external directory (LDAP or central user management), you can configure the server to access the user and group information from the external directory.

For instructions for creating user IDs, see Adding User Accounts. For instruction for creating groups, see Adding Groups. For instructions for using an external directory, see Configuring a Central User Directory or LDAP.

 
3. Create ACLs.

Create the ACLs needed to meet your services' security requirements and assign the groups you have created to these ACLs. For instructions, see Creating ACLs.

 
4. Identify backup administrators.

Select one or two users who can act as a backup administrator when the primary administrator is unavailable. Use the Users and Groups page to add these users to the “Administrators” group.

For instructions on how to grant a user administrator privileges, see Adding an Administrator User.

 

Stage 4: Publishing Packages

Install and configure the packages that will run on this server.

Step Action Done?
1. Install services on the server.

Use one of the following methods to publish your services to the production server:

  • Method 1. Use the Packages > Publishing page to replicate the packages from the development server to the production server.

    For instructions, see Copying Packages from One Server to Another.

  • Method 2. Use the Integration Server Administrator of the publishing server to create a zip file containing each package you want to publish; then:

    1. Copy the zip file to following directory on the target server:

      Integration Server_directory \instances\instance_name\replicate\inbound

    2. Use the Packages > Management page to install each package.
 
2. Configure the services on the server.

Ensure that each service is enabled. Then, configure the following operating parameters for each:

 

Stage 5: Installing Run-Time Classes

If your services use run-time classes beyond those provided by Java or the Integration Server (e.g., CORBA or MQ Series classes), install those classes on the server.

Step Action Done?
1. Install run-time classes.

Obtain the zip or jar file from the vendor, and then copy the zip or jar file to a device or directory that your Integration Server can access.

 
2. Update the classpath.

Update the classpath statement in the wrapper.java.additional property of the custom_wrapper.conf file so that it points to the directory in which you have installed the run-time classes.

For Microservices Runtime, update the Java system properties in setenv.bat/sh.

For more information about updating the class path, see Adding Classes to the Server Classpath.

 

Stage 6: Preparing Clients for Communication with the Server

If you have applications (for example, Java or C/C++ programs) that you want to be Integration Server clients, you must prepare the clients for communication with Integration Server.

Step Action Done?
1. The Integration Server client.jar file contains classes that clients need to communicate with Integration Server. If you have clients on the same machine as Integration Server or Designer, set the classpath on the machine to include the wm-isclient.jar file. The wm-isclient.jar file is located in the common\lib directory, so set the classpath to %CLASSPATH%; Software AG_directory \common\lib\wm-isclient.jar.  
2. If you have clients on machines that do not also host either Integration Server or Designer, do the following for each machine:
  1. Navigate to the Software AG_directory \common\lib directory and copy the wm-isclient.jar file to any directory on the client machine.
  2. If you want the client to use SSL to communicate with Integration Server, navigate to the Software AG_directory \common\lib\ext directory and copy the enttoolkit.jar file to any directory on the client machine.
  3. Set the classpath on the client machine to include the wm-isclient.jar file and, if applicable, the enttoolkit.jar file. For example, if you put the wm-isclient.jar file and the enttoolkit.jar file in the c:\myapp directory, you would set the classpath to %CLASSPATH%;c:\myapp\client.jar;c:\myapp\enttoolkit.jar.
 

Stage 7: Setting Up Security

Take the following steps to ensure that the security measures you want to use are in place.

Step Action Done?
1. Check passwords.

Verify that the passwords for the Administrator and Replicator accounts and the master password for outbound password encryption have been changed from the default values assigned by webMethods Integration Server.

 
2. Edit the index.html file to prevent access to Integration Server Administrator.

If you want to prevent a user from inadvertently accessing the Integration Server Administrator, edit the following file:

Integration Server_directory \instances\instance_name\packages\Default\pub\index.html

Change the SRC in the <frame src="/WmRoot/index.dsp"\> tag to some innocuous page you have created (perhaps one that displays an error message with alternate links).

You can prevent users from seeing all DSP files on Integration Server by using the watt.server.displayDirectories server configuration parameter.

Note that if you edit the index.html file, you will not be able to invoke the Integration Server Administrator in the standard way (i.e., simply connecting to the Integration Server's listening port). Instead, you will need to type the Integration Server Administrator's complete URL as shown below: 

http://Server:Port /WmRoot/index.dsp

where:

Server is the name of the Integration Server, and

Port is the port on which it listens for HTTP requests.

 
3. Check user accounts.

Verify that all user accounts have passwords as required.

 
4. Check ACL assignments.

Verify that all secure services have correct ACL assignments.

 
5. Check proxy server settings.

Verify that proxy server settings and bypass list are correct.

 
6. Restrict access.

Configure allow/deny lists to restrict inbound requests as necessary.

 
7. Install and configure digital certificates.  
8. Configure HTTP routing systems.

If your server sits behind a routing, load-balancing, or URL-filtering system, consult with the administrator of that system to ensure that it will pass inbound requests to the Integration Server.

 
9. Configure write permissions for specific administrator users to the maskSessionID.properties file.

Provide only specific administrator users with write permissions to the maskSessionID.properties file. The remaining administrator users must have only read permissions to the particular file.

 
10. Ensure security of operating system.

The security of your Integration Server depends on the security of your operating system. Therefore, make sure your operating system is properly configured, that all security patches have been applied, and that unnecessary network services, such as telnet or mail, have been removed.

 

Stage 8: Startup and Test

Start the server and test services to ensure that they operate as expected.

Step Action Done?
1. Verify that ports are enabled.

If you disabled the ports to prevent access to the server during the setup phase, use the Ports page to enable them now.

Tip: After you enable a port, ping it to verify that it is operational.
 
2. Restart the server.

Use the Integration Server Administrator to restart the server to ensure all settings that you have made are in effect.

For instructions, see Restarting the Integration Server.

 
3. Test services.

Perform tests to ensure that user/client applications can access the server successfully.

Note: During this test you may also want to verify that your current license will accommodate the expected concurrency demands on this server. Contact Software AG to increase number of licensed sessions if necessary.
 
4. Go Live!  

Stage 9: Archive Sources

Archive a master copy of the packages on the server and the source files that were used to build them.

Step Action Done?
1. Copy the contents of the server\packages directory to another device for backup and archival purposes.  
2. Archive a copy of all the source files that went into producing the services deployed on this server.