Starting and Stopping the Server

Starting the webMethods Integration Server

The webMethods Integration Server must be running in order for clients to execute services. If you are using the server in a development environment, it must be running in order for your developers to build, update, and test services using the Software AG Designer.

Keep the following points in mind when starting Integration Server:

Integration Server stores some configuration files and log files on disk. Make sure that there is enough free disk space on the Integration Server machine to accommodate these files. Running out of disk space can affect performance and can lead to errors.
Make sure that the external database to which Integration Server connects is available before staring Integration Server. If the database is unavailable at Integration Server startup, some components, such as the scheduler, will not be initialized and will not work properly.

Note: During installation of Integration Server, an option can be set requiring that the password for the Administrator user account be changed immediately upon successful log in to Integration Server Administrator. If so, the Administrator user account password must be changed before the server can do anything else. Any requests sent to Integration Server before the Administrator password is changed will be rejected.

For information about starting Microservices Runtime, see Starting Microservices Runtime and Microservices Runtime Administrator .

Starting an Integration Server Instance on Windows

About this task

Start an instance of Integration Server from the Windows Start menu as described below.

Note: If you are running the Windows Server operating system with the User Account Control (UAC) security feature enabled, you may need to start Integration Server with full Administrator privileges. To start Integration Server with full Administrator privileges, navigate to the list of programs or applications for Software AG. Right-click Start instanceName, and select the Run as Administrator option. If you are not logged into the operating system with Administrator privileges, you will be prompted to supply Administrator credentials.

To start Integration Server on Windows

Procedure

Click Start.
In the All Programs menu, click the Software AG folder.
Click the Start Servers folder.
Click Start Integration Server.
Click Start Integration Server instanceName .

Note: If your Integration Server has been configured to request a master password for outbound password encryption, you will be prompted for this password in a popup window or from the server console. Refer to Managing Outbound Passwords for more information about this password.

Starting Integration Server on UNIX

About this task

Keep the following points in mind when starting Integration Server on UNIX using the startup.sh script file:

Run the startup.sh script only when logged in as a non-root user. Running the script as root might reduce the security of your system.
The server can consume more files and sockets on a UNIX system than on other systems. Therefore, if you are running the server on a UNIX system, Software AG recommends that run it with at least 1024 file descriptors. You can increase the number of available file descriptors by entering the following command from the UNIX command prompt before starting the server:
```
ulimit -n number
                     
```

To start Integration Server on UNIX

Procedure

Navigate to the following directory:

Software AG_directory \profiles\IS_instance_name\bin

where instance_name is the name of the Integration Server instance.

Note: The startup.bat/sh and shutdown.bat/sh scripts contained in the Integration Server_directory \instances\instance_name\bin directory are deprecated. Software AG recommends the use of the scripts contained in the Software AG_directory \profiles\IS_instance_name\bin directory. If you will manage Integration Server through Command Central, you must use the scripts located in the Software AG_directory \profiles\IS_instance_name\bin directory.
Execute the startup.sh script file.

Note: If your Integration Server has been configured to request a master password for outbound password encryption, you will be prompted for this password in a popup window or from the server console. Refer to Managing Outbound Passwords for more information about this password.

Starting a Server Instance from the Command Prompt

About this task

You can start server instances from the command prompt. When you start a server instance from the command prompt, you have the option of overriding certain settings in the configuration file. You can also start the server instance in "debug" mode, so you can record or display server activity.

Note: If you are running the Windows Server operating system with the User Account Control (UAC) security feature enabled, the command prompt you use to run the startup.bat service must be launched with full Administrator privileges. To launch the command prompt with full Administrator privileges, navigate to All Programs > Accessories, right-click on the Command Prompt listing, and select the Run as Administrator option. If you are not logged into the operating system with Administrator privileges, you will be prompted to supply Administrator credentials.

To start a server instance from the command prompt in Integration Server

Procedure

At a command prompt, type the following command:
```
cd Software AG_directory\profiles\IS_instance_name\bin
```
where instance_name is the name of the Integration Server instance.
Note: The startup.bat/sh and shutdown.bat/sh scripts contained in the Integration Server_directory \instances\instance_name\bin directory are deprecated. Software AG recommends the use of the scripts contained in the Software AG_directory \profiles\IS_instance_name\bin directory. If you will manage Integration Server through Command Central, you must use the scripts located in the Software AG_directory \profiles\IS_instance_name\bin directory.

Type the following command to start the server instance:

For Windows:	`bin\startup.bat -switch -switch ...`
For UNIX:	`bin/startup.sh -switch-switch ...`

where switch is optional and can be one of the following :

switch	Description
`-port portNumber`	Specifies the port on which the server listens for HTTP requests. `portNumber` specifies the TCP/IP port number Example: `-port 8080` This switch overrides the value assigned to watt.server.port. Note: In addition to overriding the value of watt.server.port, the `-port` switch permanently adds a new HTTP port to the WmRoot package. This new port is added as the primary port and contains default values. If a port with the same TCP/IP number already exists in the WmRoot package, the `-port` switch overrides its settings with the new default values. In effect, deleting the existing port and then adding a new port with default settings. Note: To use port 80 (the standard for HTTP) or port 443 (the standard for HTTPS), UNIX users must be running as "root." For security reasons, a better method is to use a higher number port (5555 for HTTP and 5543 for HTTPS), and if necessary have the firewall remap port 80 to the desired port. See Architecture for a discussion of remapping ports.
`-secureport portNumber`	Specifies the port number for the DefaultSecure (HTTPS) port. `portNumber` specifies the TCP/IP port number Example: `-secureport 4355` This switch overrides the value assigned to watt.server.securePort. Note: In addition to overriding the value of watt.server.securePort, the `-secureport` switch permanently adds a new HTTPS port to the WmRoot package. This new port is added as the DefaultSecure port and contains default values.
`-debug level`	Specifies the level of detail you want the server to maintain in its server log for this session. `level` indicates the level of detail you want to record in the log.
	Specify...	To record...
	`Fatal`	Fatal messages only.
	`Error`	Error and fatal messages.
	`Warn`	Warning, error, and fatal messages.
	`Info`	Informational, warning, error, and fatal messages.
	`Debug`	Debug, informational, warning, error, and fatal messages.
	`Trace`	Trace, debug, informational, warning, error, and fatal messages.
	For this session, this switch overrides the value specified for the Default facility on the Logs > Logging configuration > View server logger details page and assigned to watt.debug.level.
	Note: Prior to Integration Server 7.1, Integration Server used a number-based system to set the level of debug information written to the server log. Integration Server maintains backward compatibility with this system. For more information about the number-based logging levels, see the description of the watt.debug.level parameter in Server Configuration Parameters.
`-log destination`	Specifies where you want the server to write its server log information for this session. Specify one of the following for `destination`:
	Option	Description
	`filename`	Specify the fully qualified path or relative path to the file in which you want the server to write server log information for this session. Relative path is relative to the Integration Server home directory: `Integration Server_directory` \instances\`instance_name` The `filename` must specify a directory and filename. The default destination is controlled by the watt.debug.logfile server configuration parameter.
	`none`	Write server log information to the computer screen (STDOUT). Server log messages written to STDOUT include the identifier “ISSERVER” to help differentiate server log messages from other messages written to the console.
	`both`	Write server log information to the computer screen (STDOUT) and to the destination specified by the watt.debug.logfile parameter.
	The `filename` and `none` values override the value assigned to watt.debug.logfile for this session.
	Note: For SSL session logging, a`-log` switch value specifies where Integration Server writes the SSL session information. For a `-log` switch value of `none`, Integration Server writes the SSL session information to a separate file (inboundSSLSessions.log). For a switch value of `both`, Integration Server writes the SSL session information to the inboundSSLSessions.log file and to the console. For more information on SSL session logging, see Setting Up SSL Session Logging . Note: A `-log` switch value of `none` or `both` also determines where Microservices Runtime or an Integration Server equipped with an Microservices Runtime license writes the configuration variables log. However, Microservices Runtime ignores a filename value. If you specify a filename, Microservices Runtime writes the configuration variables log file to this location only: `Integration Server_directory` /instances/`instanceName`/logs/configurationvariables.log. For more information about configuration variable templates and the associated logging, see Developing Microservices with webMethods Microservices Runtime .
`-logformat type`	Specifies the format to which Integration Server converts the server log and audit log entries written to the console (STDOUT or computer screen). Specify 'type' as json. Integration Server supports only "json" type. To send the audit log entries in the JSON format to the console, in addition to setting the -logformat switch, set the SAG_IS_AUDIT_STDOUT_LOGGERS environment variable to a comma-separated list of the audit loggers that log entries to STDOUT. For example, WMSESSION, WMERROR. For more information, see Environment Variables Defined in and. Note: This switch applies when you start Integration Server with the `-log both` switch. Using the `-logformat` switch does not affect log files such as server.log and error.log. Note: The support for conversion of logs into JSON format is introduced for PIE-77050 in IS_10.11_Core_Fix6.
`-quiesce`	Specifies to start the server in quiesce mode. For more information about quiesce mode, see Quiescing the Server for Maintenance. Note: If the server cannot disable or suspend an asset or activity as it enters quiesce mode, the server displays a warning message and continues the quiesce process. If the condition stated in the warning interferes with a maintenance task you intend to perform, resolve the issue stated in the warning and then restart the server in quiesce mode.

What Happens When You Start the Server?

When you start Integration Server, it performs a series of initialization steps to make itself ready for client requests. The server:

Establishes the operating environment by using the configuration parameters located in the configuration file ( Integration Server_directory \instances\instance_name\config\server.cnf).
Initializes processes that perform internal management.
Loads information about all the enabled packages and their services that reside in the Integration Server_directory \instances\instance_name\packages directory. If a package depends on other packages, the server loads the prerequisite packages first. The server does not load disabled packages.
Executes the startup services for each loaded package.
Initializes the guaranteed delivery engine. The server checks the job store for pending guaranteed delivery transactions. It retries the pending transactions as the guaranteed delivery configuration settings specify. For more information, refer to Configuring Guaranteed Delivery.
Schedules internal system tasks.

How to Tell if the Server Is Running Correctly

To determine whether your server is running, start your browser and point it to the Integration Server instance. (See Starting Integration Server Administrator if you need instructions for this step.)

If the server is running, you will be prompted for a name and password.

If the server is not running, your browser will issue an error message similar to the following:

"Cannot open the Internet site http://localhost:5555."  
"A connection with the server could not be established."

If Integration Server detects a problem with the master password or outbound passwords at startup, it will place you in safe mode, which is a special mode from which you can diagnose and correct problems. When Integration Server is in safe mode, it displays the Integration Server Administrator, but Integration Server is not connected to any external resources.

When you are placed into safe mode because of problems with the master password or outbound passwords, you will see the following message in the upper left corner of the Server Statistics page of the Integration Server Administrator:

SERVER IS RUNNING IN SAFE MODE. Master password sanity check failed -- invalid 
master password provided.

These problems can be caused by a corrupted master password file, a corrupted outbound password file, or by simply mis-typing the master password when you are prompted for it. If you suspect you have mis-typed the password, shut down the server and restart it, this time entering the correct password. If this does not correct the problem, refer to When Problems Exist with the Master Password or Outbound Passwords at Startup... for instructions.

Running Integration Server as a Windows Application vs. a Windows Service

Integration Server can run as either a Windows application or a Windows service.

Use a Windows application if you want to control when the Integration Server initializes. When Integration Server is a Windows application, you must manually start it.
If you installed the Integration Server as a Windows service and now want it to be a Windows application, you can manually remove the Windows service for the Integration Server. After removing the Windows service, the Integration Server will still be available as a Windows application. See Switching the Server from a Windows Service to a Windows Application.
Use a Windows service to have Integration Server automatically initialize when the machine on which it is installed initializes. When you use a Windows service, you do not have to manually restart Integration Server following a machine restart.
If you installed Integration Server as a Windows application and now want it to be a Windows service, you can manually register the Integration Server service.

See Switching the Server from a Windows Application to a Windows Service.

Note: If you want the Integration Server to prompt for the master password for outbound passwords at server initialization, do not run it as a Windows service. For more information about outbound passwords and the master password, refer to Configuring Integration Server for Secure Communications.

You can run multiple Integration Server instances as applications and multiple Integration Server instances as services on a single machine. For example, you can run two instances of Integration Server as an application and two instances of Integration Server as services on the same machine.

Note: Microservices Runtime cannot be registered as a Windows service. An Integration Server equipped with an Microservices Runtime license can be registered as a Windows service.

Switching the Server from a Windows Service to a Windows Application

About this task

If Integration Server was installed as a Windows service, and you want Integration Server to run as a Windows application, you must remove the Windows service for the Integration Server.

To manually remove the Windows service for the Integration Server

Procedure

If the Windows service is running, stop it. You can stop the Windows service by either using the Integration Server Administrator to shut down the Integration Server or from the Services dialog box in the Microsoft Windows Control Panel.
Open a command prompt, navigate to the Software AG_directory \profiles\IS_instance_name\bin directory and run the following command to remove the Integration Server service:

service.bat -remove

Note: The installSvc.bat file located in Integration Server_directory \instances\instance_name \support\win32 directory is deprecated. Software AG recommends using the service.bat file from the Software AG_directory \profiles\IS_instance_name\bin directory.

Switching the Server from a Windows Application to a Windows Service

About this task

To switch the server from a Windows application to a Windows service, you must manually register the Integration Server instance to run as a Windows service.

Note: The user whose identity will be used to run the Integration Server as a Windows service must be a Windows Administrator or member of the Windows Administrators group.

To manually register an Integration Server instance to run as a Windows service

Procedure

Edit the custom_wrapper.conf file to fit your environment.

For example, you might change the Java minimum heap size by updating the wrapper.java.initmemory property. The custom_wrapper.conf file is located in the Software AG_directory \profiles\IS_instance_name\configuration directory.

For more information about setting values in the custom_wrapper.conf file, see Software AG Infrastructure Administrator's Guide .
Open a command prompt, navigate to the Software AG_directory \profiles\IS_instance_name\bin directory and run the following command to create the Integration Server service:

service.bat -install

Note: The installSvc.bat file located in Integration Server_directory \instances\instance_name \support\win32 directory is deprecated. Software AG recommends using the service.bat file from the Software AG_directory \profiles\IS_instance_name\bin directory.

In the Microsoft Windows Control Panel in the Services dialog box, verify that the service for Integration Server has been created.
Start the service from one of the following places:
- Services dialog box in the Microsoft Windows Control Panel
- Command prompt using the following command:
```
net start <SVCNAME>
                        
```
  where <SVCNAME> is the name of the service created in the previous step.

Increasing File Descriptors on Mac OS X or Other UNIX System

The ability of Integration Server to handle traffic is constrained by the number of file descriptors available to the Integration Server process. On most systems, 64 file descriptors are available to each process by default. If Integration Server is running on a Mac OS X or other UNIX system, Software AG recommends that you increase the number of file descriptors available to the Integration Server process to at least 1024.

Note: You might have to increase this number depending on the number of files Integration Server needs to have open at one time. It is dangerous to set the rlim_fd_max value higher than 1024 because of limitations with the select function, so if Integration Server requires more file descriptors, set the setrlimit value directly.

Changing Settings in the Configuration File custom_wrapper.conf

About this task

The custom_wrapper.conf, which is used at Integration Server startup, contains configuration settings. You can override these settings for a single Integration Server session by starting Integration Server from the command prompt and using switches to override values in the custom_wrapper.conf file. However, you might want to permanently change some of the configuration values in the custom_wrapper.conf so that all sessions use the modified configuration values.

Note: Microservices Runtime does not use the custom_wrapper.conf. For Microservices Runtime, set configuration information in the following file: Integration Server_directory /bin/setenv.bat(sh)

To override settings in the configuration file

Procedure

In a text editor, open the custom_wrapper.conf file from the following directory:

Software AG_directory \profiles\IS_instance_name\configuration

where instance_name is the name of the Integration Server instance.

Add the following property to custom_wrapper.conf:

wrapper.app.parameter.n=switch

where n is the next unused sequential number for the wrapper.app.parameter properties in the file and switch is the switch command.

wrapper.app.parameter.n=switch_parameter

where n is the sequential number and switch_parameter is the value of the switch.

Most switches require that you add an additional property to custom_wrapper.conf as the very next property in the sequence, as follows:

For example, to change the default port number to 8080, you would enter the following to custom_wrapper.conf:

wrapper.app.parameter.7=-port 
wrapper.app.parameter.8=8080

For more information about the wrapper.app.parameter property, see Software AG Infrastructure Administrator's Guide .

The following table describes the switches you can use to override settings in the configuration file:

switch	Description
`-port`	Specifies the port on which the server listens for HTTP requests. If you add a `wrapper.app.parameter` property to custom_wrapper.conf for the `-port` switch, you must also add a `wrapper.app.parameter` property in which you specify the TCP/IP port number to use. The first `wrapper.app.parameter` property specifies that you want to override the port by using the `-port` switch, and the next `wrapper.app.parameter` property specifies the port number to use. For example: `wrapper.app.parameter.7=-port wrapper.app.parameter.8=8080` Note: Keep the following points in mind when overriding the port number: This switch overrides the value assigned to watt.server.port. The `-port` switch permanently adds a new HTTP port to the WmRoot package. This new port is added as the primary port and contains default values. If a port with the same TCP/IP number already exists in the WmRoot package, the `-port` switch overrides its settings with the new default values. In effect, deleting the existing port and then adding a new port with default settings. To use port 80 (the standard for HTTP) or port 443 (the standard for HTTPS), UNIX users must be running as "root." For security reasons, a better method is to use a higher number port (5555 for HTTP and 8080 for HTTPS), and if necessary have the firewall remap port 80 to the desired port. See Architecture for a discussion of remapping ports.
`-debug`	Specifies the level of detail you want the server to maintain in its server log for this session. The `-debug` switch overrides the value specified for the Default facility on the Logs > Logging configuration > View server logger details page and assigned to watt.debug.level. If you add a `wrapper.app.parameter` property to custom_wrapper.conf for the `-debug` switch, you must also add a `wrapper.app.parameter` property in which you specify the level of detail you want to record in the log. You can specify the following levels:
	Specify	To record
	`Fatal`	Fatal messages only.
	`Error`	Error and fatal messages.
	`Warn`	Warning, error, and fatal messages.
	`Info`	Informational, warning, error, and fatal messages.
	`Debug`	Debug, informational, warning, error, and fatal messages.
	`Trace`	Trace, debug, informational, warning, error, and fatal messages.
	The first `wrapper.app.parameter` property specifies that you want to override the debug level by specifying the `-debug` switch, and the next `wrapper.app.parameter` property specifies the level of detail you want to record in the log. For example: `wrapper.app.parameter.11=-debug wrapper.app.parameter.12=fatal` Note: Prior to Integration Server 7.1, Integration Server used a number-based system to set the level of debug information written to the server log. Integration Server maintains backward compatibility with this system. For more information about the number-based logging levels, see the description of the watt.debug.level property in Server Configuration Parameters.
`-log`	Specifies where you want the server to write its server log information for this session. If you add a `wrapper.app.parameter` property to custom_wrapper.conf for the `-log` switch, you must also add a `wrapper.app.parameter` property in which you specify the destination of the log information. You can specify the following destinations:
	Option	Description
	`filename`	Specify the fully qualified path or relative path to the file in which you want the server to write server log information for this session. Relative path is relative to the Integration Server home directory: `Integration Server_directory` \instances\`instance_name` The `filename` must specify a directory and filename. The default destination is controlled by the watt.debug.logfile server configuration parameter.
	`none`	Write server log information to the computer screen (STDOUT).
	`both`	Write server log information to the computer screen (STDOUT) and to the destination specified by the watt.debug.logfile parameter.
	The first `wrapper.app.parameter` property specifies that you want to override the destination of the log information by specifying the `-log` switch, and the next `wrapper.app.parameter` property specifies either the complete path for the home directory or none. For example: `wrapper.app.parameter.13=-log wrapper.app.parameter.14=none` Note: A switch value of `filename` or `none` overrides the value assigned to watt.debug.logfile for this session.
	Note: A `-log` switch value of `none` or `both` also determines where Microservices Runtime or an Integration Server equipped with an Microservices Runtime license writes the configuration variables log. However, Microservices Runtime ignores a filename value. If you specify a filename,Microservices Runtime writes the configuration variables log file to this location only: `Integration Server_directory` /instances/`instanceName`/logs/configurationvariables.log.
`-quiesce`	Specifies that Integration Server starts the server in quiesce mode. When you add a `wrapper.app.parameter` property to custom_wrapper.conf for the `-quiesce` switch, Integration Server starts in quiesce mode. The `-quiesce` switch does not require an additional `wrapper.app.parameter` property. For example: `wrapper.app.parameter.15=-quiesce` For more information about quiesce mode, see Quiescing the Server for Maintenance.

In the custom_wrapper.conf, update the wrapper.app.parameter.2 property to reflect the total number of wrapper.app.parameter properties that you added in the previous steps.

For example, if wrapper.app.parameter.2 is set to 4 (the default) and you add two wrapper.app.parameter properties, you would increase the value of wrapper.app.parameter.2 by two. After making your edits, the wrapper.app.parameter.2 would appear as follows:

wrapper.app.parameter.2=6

For more information about the wrapper.app.parameter property, see Software AG Infrastructure Administrator's Guide .
Save and close custom_wrapper.conf.

Passing Java System Properties to Integration Server

About this task

You can pass Java system properties to Integration Server by modifying the custom_wrapper.conf file.

Note: Microservices Runtime does not use the custom_wrapper.conf. For Microservices Runtime, set Java system properties in the following file using the JAVA_CUSTOM_OPTS property: Integration Server_directory /bin/setenv.bat(sh)

To pass Java system properties to Integration Server

Procedure

Open the custom_wrapper.conf file in a text editor. You can find the custom_wrapper.conf file in the following directory:

Software AG_directory \profiles\IS_instance_name\configuration
Add a wrapper.java.additional. n property that specifies the property name and value that you want to pass to Integration Server, where n is a unique sequence number. The property name must be preceded by -D.
For example, the wrapper.java.additional properties in the custom_wrapper.conf file would look similar to the following:
```
wrapper.java.additional.11=-Dmy.prop1=value1 
wrapper.java.additional.12=-Dmy.prop2=value2
```
For more information about setting values in the custom_wrapper.conf file, see Software AG Infrastructure Administrator's Guide .
Save and close the file.
Restart the server for the changes to take effect.

Shutting Down the Integration Server

You can shut down the server to stop the Integration Server and all active sessions. You can perform this task from Integration Server Administrator or from the command prompt.

For information about shutting down Microservices Runtime, see Shutting Down Microservices Runtime .

Shutting Down the Integration Server from Integration Server Administrator

About this task

Use this procedure to shut down the Integration Server and all active sessions from Integration Server Administrator.

To shut down the server

Procedure

Open the Integration Server Administrator if it is not already open.
Click > Shut down or restart.
Select whether you want the server to wait before shutting down or to shut down immediately.

Delay number minutes or until all client sessions are complete. Specify the number of minutes you want the Integration Server to wait before shutting down. It then begins monitoring user activity and automatically shuts down when all non-administrator sessions complete or when the time you specify elapses (whichever comes first).

Perform action immediately. The server and all active sessions terminate immediately.
For instructions on how to view the active sessions, refer to Viewing Active Sessions.
Click Shutdown.

Shutting Down Integration Server from Windows

About this task

You can shut down any instance of Integration Server and all active session from the Windows start menu.

Note: If you are running the Windows Server 2008 r2 operating system or Windows Server 2012 with the User Account Control security feature enabled, you must shut down Integration Server with full Administrator privileges. To shut down Integration Server with full Administrator privileges, navigate to the list of programs or applications for Software AG. For example, in Windows Server 2008, navigate to All Programs > Software AG. Right-click Stop instanceName, and select the Run as Administrator option. If you are not logged into the operating system with Administrator privileges, you will be prompted to supply Administrator credentials.

To shut down Integration Server on Windows

Procedure

Click Start.
In the All Programs menu, click the Software AG folder.
Click the Stop Servers folder.
Click Stop Integration Server.
Click Stop Integration Server instanceName .

Shutting Down Integration Server from the Command Prompt

About this task

Use this procedure to shut down the server and all active sessions from the command prompt.

To shut down the server from the command prompt

Procedure

At a command prompt, type the following command to switch to the server instance's home directory:
```
cd Software AG_directory\profiles\IS_instance_name\bin
```
where instance_name is the name of the Integration Server instance.
Note: The startup.bat/sh and shutdown.bat/sh scripts contained in the Integration Server_directory \instances\instance_name\bin directory are deprecated. Software AG recommends the use of the scripts contained in the Software AG_directory \profiles\IS_instance_name\bin directory. If you will manage Integration Server through Command Central, you must use the scripts located in the Software AG_directory \profiles\IS_instance_name\bin directory.

Type the following command to stop the server:

For Windows:	`shutdown.bat`
For UNIX:	`shutdown.sh`

Viewing Active Sessions

About this task

When Integration Server is running, you can view the sessions that are currently active.

To view active sessions

Procedure

Open the Integration Server Administrator if it is not already open.
Go to Server > Statistics.
Click on the current number of sessions.

Killing Sessions

About this task

You can kill a single session or all sessions except the session you are currently running.

To kill sessions

Procedure

Open the Integration Server Administrator if it is not already open.
Go to Server > Statistics.
In the Total Sessions field, in the Current column, click the current number of sessions.

Integration Server displays the Sessions page.
Click in the Kill column of the session you want to kill.

Note: Alternatively, you can click Kill All Except Your Session above Current Sessions to kill all sessions except the session you are currently running.

Integration Server kills the current sessions that are registered in the Integration Server database and not the in-flight sessions. Integration Server does not kill active JMS trigger sessions. The icon, in the Kill column is disabled for active JMS trigger sessions until the sessions expire.

Viewing the Integration Server Process ID

About this task

Each instance of Integration Server runs on an operating system as a separate JVM process. There are times when it is necessary to perform a thread dump or stop a particular instance of Integration Server (for example, in Windows Task Manager). In order to do this, it is necessary to know the process ID of the Integration Server process (or server process ID) on which to perform the particular operation. You can view the server process ID in the Integration Server Administrator About page.

To view the process ID

Procedure

Open the Integration Server Administrator if it is not already open.
Click > About.
Scroll down to the Server Process ID field in the Server environment area.

Restarting the Integration Server

About this task

Restart the server when you need to stop and reload Integration Server. You should restart the server when:

You make certain configuration changes. Some configuration changes require the server to be restarted before they take effect. Integration Server Administrator displays a notification if a configuration change was made that requires a server restart for the change to take effect.
You want to incorporate updated services that cannot be dynamically reloaded. This typically occurs for non-Java services.

To restart the server

Procedure

Open the Integration Server Administrator if it is not already open.
Click > Shut down or restart.
Select whether you want the server to wait before restarting or to restart immediately.
- Delay number minutes or until all client sessions are complete. Specify the number of minutes you want the Integration Server to wait before restarting. It then begins monitoring user activity and automatically restarts when all non-administrator sessions complete or when the time you specify elapses (whichever comes first).
- Perform action immediately. The server and all active sessions terminate immediately. Then the server restarts.
  
  For instructions on how to view the active sessions, refer to Viewing Active Sessions.
Click Restart.

Server Recovery

If a hardware or software problem causes Integration Server to fail, restart the server using the normal startup procedure. The server will attempt to perform cleanup and initialization processes to reset the operating environment.

As part of the recovery process, the server automatically:

Reloads the cache environment to its pre-failure state.
Restores the transaction manager's guaranteed delivery queues. See Configuring Guaranteed Delivery for additional information about guaranteed delivery recovery options.

Services that your site has created might have their own unique recovery requirements. Consult with your developers for information about these requirements.

Some circumstances might require manual intervention to restart the server.

Tip: Before restarting Integration Server, you can collect diagnostic data to troubleshoot run-time issues. For information about using the diagnostic port and utility, see Diagnosing the Integration Server. Also refer to this chapter for information on generating thread dump to troubleshoot reasons for server slowdown or unresponsiveness.

Unapplied Changes to Integration Server Configuration Files

If Integration Server shut down improperly while you were making changes that affect configuration files (*.cnf), Integration Server might display the following message upon restart:

[ISS.0025.0070C] Integration Server detected files in config/work directory which suggests unapplied configuration changes.

When saving changes to configuration files, Integration Server first saves the configuration changes in a temporary file in the Integration Server_directory /instances/instanceName/config/work directory. After saving the changes in a temporary file, Integration Server moves the temporary file to the actual configuration file. This ensures that if unexpected behavior occurs before the configuration changes are initially saved to the temporary file, only the temporary file is impacted. The actual configuration file is not corrupted. At start up, if Integration Server detects files in the Integration Server_directory /instances/instanceName/config/work, it suggests that changes to a configuration file were not saved to the temporary file and that, therefore, the changes were not made to the actual configuration file. Use the contents of the Integration Server_directory /instances/instanceName/config/work directory to determine which configuration files were in the process of being changed. Decide whether or not you want to redo the changes to the configuration files. Delete the files under the directory and redo the configuration change if you so choose.

Integration Server Data Integrity and Recoverability Considerations

The Integration Server utilizes a webMethods physical storage technology to persist critical operational data. This storage technology employs database-like technology of logging and transactional management. Under normal operations these facilities maintain the integrity, consistency, and recoverability of data persisted to these files. However, even with these safeguards, abnormal server shutdown and catastrophic failures can occur, which could result in these files being left in an unrecoverable state.

Shutting down Integration Server by any means other than the Integration Server Administrator may result in critical data files being left in an unrecoverable state. This will result in the inability to restart the Integration Server without manual intervention to remove or recover the damaged data files.

Important: Establish site-specific backup and restore procedures to protect these critical data files.

The mission-critical nature of the data stored in the Integration Server's data files requires that it be backed up periodically for disaster recovery. As in all critical data resources, the potential exists for a physical failure to leave the Integration Server data files in a corrupted state. In these situations the method of recovery is to replace these data files with the most current backup. The frequency and nature of these backups depends on the critical nature of the data being stored. Backups of these data files should be an offline process with the Integration Server in an idle or shutdown state, i.e. no disk activity.

Important: Implement site-specific procedures to periodically backup the critical Integration Server data files. You can use any file-system backup utility. Perform the backup process only when the Integration Server is shutdown or in a quiesce state, (no disk activity). This restriction ensures that the backup will capture these critical data files in a consistent state. Backing up an active Integration Server may result in capturing a snapshot of the data files that are in an inconsistent state and therefore unusable for recovery purposes.

Critical Integration Server Data Files

There are two subdirectories in Integration Server's currently working directory that contain critical data files that must be backed up for recovery purposes. These subdirectories are:

./DocumentStore

The files in this subdirectory contain the locally persisted documents being processed by Integration Server. The loss of these files will result in the loss of any persisted documents. Back up these six files:
- ISResubmitStoredata0000000
- ISResubmitStorelog0000000
- ISTransStoredata0000000
- ISTransStorelog0000000
- TriggerStoredata0000000
- TriggerStorelog0000000
./WmRepository4

The files in this subdirectory contain metadata for Integration Server. The loss of these files could result in loss of configuration information and may require manual reconfiguration. Back up these two files:
- FSDdata0000000
- FSDlog0000000

The Java Service Wrapper

webMethods Integration Server runs on the on the Software AG Common Platform, which in turn runs in a Java Virtual Machine (JVM). The Java Service Wrapper is an application developed by Tanuki Software, Ltd. It is a utility program that launches the JVM in which Integration Server runs.

In addition to launching the JVM, the Java Service Wrapper offers features for monitoring the JVM, logging console output, and generating thread dumps. The following sections describe how Integration Server uses the features of the Java Service Wrapper. For an overview of the Java Service Wrapper, see the webMethods cross-product document, Software AG Infrastructure Administrator's Guide .

Note: Microservices Runtime does not use the Java Service Wrapper.

The Java Service Wrapper Configuration Files

For Integration Server, the configuration files for the Java Service Wrapper reside in the following directory.

Software AG_directory \profiles\IS_instanceName\configuration

When you start Integration Server, property settings in the following files determine the configuration of the JVM and the behavior of the logging and monitoring features of the Java Service Wrapper.

File name	Description
wrapper.conf	Contains property settings that are installed by Integration Server. Important: Do not modify the contents of this file unless asked to do so by Software AG.
custom_wrapper.conf	Contains properties that modify the installed settings in wrapper.conf. If you need to modify the property settings for the Java Service Wrapper, you make your changes in this file. Note: Beginning with Integration Server version 9.7, Integration Server no longer obtains settings from setenv.bat/sh or server.bat/sh. At startup, Integration Server obtains all classpath modifications from custom_wrapper.conf. For more information about how Integration Server builds classpaths, see How the Integration Server Classpath Is Set.

File name

Description

wrapper.conf

Contains property settings that are installed by Integration Server.

Important: Do not modify the contents of this file unless asked to do so by Software AG.

custom_wrapper.conf

Contains properties that modify the installed settings in wrapper.conf.

If you need to modify the property settings for the Java Service Wrapper, you make your changes in this file.

Note: Beginning with Integration Server version 9.7, Integration Server no longer obtains settings from setenv.bat/sh or server.bat/sh. At startup, Integration Server obtains all classpath modifications from custom_wrapper.conf. For more information about how Integration Server builds classpaths, see How the Integration Server Classpath Is Set.

The following sections describe configuration changes that Integration Server supports for Java Service Wrapper. For Integration Server, do not make any configuration changes to the Java Service Wrapper other than the ones described in the following sections.

JVM Configuration

When the Java Service Wrapper launches the JVM, it provides configuration settings that, among other things, specify memory settings and the directories in the classpath. When you start Integration Server, the Java Service Wrapper receives these configuration settings from the wrapper.conf and custom_wrapper.conf files in the Software AG_directory \profiles\IS_instance_name\configuration folder.

If you need to modify the default property settings for Integration Server, you can override the settings using the custom_wrapper.conf file, which is located in the Software AG_directory \profiles\IS_instance_name\configuration. For more information for configuring custom_wrapper.conf properties for Integration Server, see Configuring the Server. For general information about the Java Service Wrapper, see Software AG Infrastructure Administrator's Guide .

The Wrapper Log

The Java Service Wrapper records console output in a log file. The log contains the output sent to the console by the wrapper itself and by the JVM in which Integration Server is running. The wrapper log is especially useful when you run Integration Server as a Windows service, because console output is normally not available to you in this mode.

The Java Service Wrapper log for Integration Server is located in the following file:

Software AG_directory \profiles\IS_instanceName\logs\wrapper.log

To view the log, open the log file in a text editor.

Logging Properties

The wrapper.console and wrapper.log properties in the wrapper configuration files determine the content, format, and behavior of the wrapper log.

The logging settings that Integration Server installs are suitable for most environments. However, you can modify the following properties if the installed settings do not suit your needs. For procedures and additional information, see the webMethods cross-product document, Software AG Infrastructure Administrator's Guide .

Property	Value
wrapper.console.format	The format of the messages displayed in the console.
wrapper.console.loglevel	The level of detail displayed in the console.
wrapper.logfile	The file into which console output for Integration Server is logged.
wrapper.logfile.format	The format of the messages recorded in the wrapper log file.
wrapper.logfile.loglevel	The level of detail recorded in the wrapper log file. This setting must be a level that is equal to or lower than the setting in wrapper.console.loglevel.
wrapper.logfile.maxsize	The maximum size to which the log can grow.
wrapper.logfile.maxfiles	The number of old logs the Java Service Wrapper retains.
wrapper.syslog.loglevel	Which messages are written to the Event Log on Windows systems, or the syslog on UNIX systems.

Fault Monitoring

The Java Service Wrapper can monitor the JVM for the certain conditions and then restart the JVM or perform other actions when it detects these conditions.

The following table describes the fault-monitoring features Integration Server uses or allows you to configure. To learn more about these features, see the webMethods cross-product document, Software AG Infrastructure Administrator's Guide .

Feature	Enabled?	User configurable?
JVM timeout	Yes	No. Do not modify the wrapper.ping properties unless asked to do so by Software AG.
Deadlock detection	No	No. Do not enable this feature.
Console filtering	No	No. Do not enable this feature.

Generating a Thread Dump

The Java Service Wrapper provides a utility for generating a thread dump of the JVM. A thread dump can help you locate thread contention issues that can cause thread blocks or deadlocks.

For information about generating a thread dump using the Java Wrapper Service, see the webMethods cross-product document, Software AG Infrastructure Administrator's Guide .

Re-registering a Windows Service after Installing a New Version of the Java Service Wrapper

About this task

If you are running Integration Server as a Windows service, you must re-register the service when the version of the Java Service Wrapper changes. Software AG may provide updated versions of the Java Service Wrapper in a webMethods Shared Libraries Tanuki fix or in a new release. Re-registering the service involves removing the Windows service and then registering (installing) it again.

To re-register the Windows service for Integration Server

Procedure

If the Windows service is running, stop it. You can stop the Windows service by either using the Integration Server Administrator to shut down the Integration Server or from the Services dialog box in the Microsoft Windows Control Panel.
Open a command prompt, navigate to the Software AG_directory \profiles\IS_instance_name\bin directory and run the following command to remove the Integration Server service:

service.bat -remove
Run the following command to register the Windows service for Integration Server:

service.bat -install