Starting and Ending Server Processes

An AE system consists of server processes which run on one or several computers. You can easily start and end them by using the ServiceManager - Dialog Program, or by using the Automation Engine scripting language which also provides script elements for starting and ending server processes. For more information, see ServiceManager - Dialog Program.

This page includes the following:

Starting Server Processes

It is recommended to start server processes with a time delay regardless if you cold-start or warm-start your system.

  1. Start the work process (WP) that should serve as the primary work process (PWP). Wait until you see the following message printed in the log file:

    U0003471 The Server 'AUTOMIC#WP001' has successfully been initialized, *** R E A D Y   F O R   R U N ***

  2. Now start all other work processes (JWPs/WPs) and the REST process with a time delay of about 10 seconds.
  3. Start the communication processes (JCPs/CPs).
  4. Start all other components such as agents only when all server processes are active. Also keep a time delay of about 10 seconds between the individual starts.

Note: A time delay option is available for each component in the settings of the ServiceManager dialog.

Possible Messages

You will see many messages when you start the Automation Engine. Some of these messages refer to possible errors but most of them only log information about the starting procedure in the log file:

  • Starting a communication process (JCP/CP) or work process (JWP/WP) causes several socket error messages that are output

    Explanation: Each server process attempts to open one port number after the other until it finds an empty port as specified in the INI file. The server process name is then defined via this port. It is normal that some ports are already occupied when several server processes start at the same time. This fact causes socket error messages, but there is no error.

  • Following a cold start, database error messages referring to the MQCPnnn tables are always displayed.

    Explanation: You can define several communication processes. The primary work process deletes their MQCPnnn tables one after the other when a cold start is made. This behavior is normal and there is no error.

Ending Server Processes

You can either end server processes collectively or individually. Ending particular ones is especially useful when server processes are distributed on several computers and when you want to end only the server processes of a particular computer.

  • Ending a particular server process

    • Context-menu command in the ServiceManager

      Immediately single process

    • Available Scripting Element

      :TERMINATE

  • Ending all JCPs/CPs, JWPs/WPs and REST processes

    • Context-menu command in the ServiceManager

      Shutdown (AE system)

    • Available Scripting Element

      :SHUTDOWN

It is recommended to use the following procedure if you want to end all server processes individually:

  1. End all work processes (JWP/sWPs) except for the primary work process (PWP)
  2. End all communication processes (JCPs/CPs)
  3. End the primary work process (PWP)

What happens when a particular server process ends?

  • Communication Process (CP)

    The communication process (CP) informs the instances of the Automic Web Interface and agents that are connected so that these can establish a connection to a different communication process (CP). Then the process completes its report and ends.

  • Work Process (WP)

    The work processes (WPs) write their reports and then they end. If a primary work process (PWP) ends, one of the other work processes (WPs) assumes the role of a primary work process (PWP).

What happens when the AE system (all CPs and WPs) is shut down?

The primary work process (PWP) is instructed to shut down the system and it handles the smooth ending of all server processes. Basically, the same procedure applies as described above when you end a particular server process. Additionally, the primary work process (PWP) handles the message queue. It will end once the message queue has been processed. This includes that it may take some time until the primary work process (PWP) ends.

Important! You can also end server processes abnormally. In this case, they end immediately. The processes described above do not take place. Only use this way of ending server processes if you cannot end them by using one of the other options.

Starting Server Processes with Arguments

You can start all types of Server Processes through command line arguments, thus allowing you to pass properties without having to rewrite the configuration (INI) file of the Automation Engine. For more information, see Types of Server Processes and Automation Engine.

These arguments allow you to substitute values in the INI file of the Automation Engine with variables by using ${ENV_KEY:default}. You cannot substitute sections or whole keys of the INI file.

Examples

  • name=

    • Environment setting: no setting

    • Command line argument: no argument

    • Configuration after substitution: name=

    There is no value defined in the INI file and no substitution is triggered. There is no change in the configuration file.

  • name=${NAME}

    • Environment setting: no setting

    • Command line argument: no argument

    • Configuration after substitution: name=

    No substitution is triggered. There is no change in the configuration file.

  • name=${NAME}

    • Environment setting: export NAME=mysystem

    • Command line argument: no argument

    • Configuration after substitution: name=mysystem

    The value defined in the INI file is substituted with the value defined in the environment variable.

  • name=${NAME}

    • Environment setting: export NAME=mysystem

    • Command line argument: -E NAME=yoursystem

    • Configuration after substitution: name=yoursystem

    The value defined in the INI file is substituted with the value defined in the command line argument.

  • name=${NAME:AE}

    • Environment setting: no setting

    • Command line argument: no argument

    • Configuration after substitution: name=AE

    No substitution is triggered. The configuration file uses the default value.

  • name=AE

    • Environment setting: export NAME=mysystem

    • Command line argument: -E NAME=yoursystem

    • Configuration after substitution: name=AE

    No variable is used. There is no change in the configuration file even though a substitution is triggered.

Replacement Key with Different Default Values

If two or more values use the same key but different default values, the following substitution logic applies:

name=${NAME:AE}

  • Environment setting: no setting

  • Command line argument: no argument

  • Configuration after substitution: name=AE

name2=${NAME:CA}

  • Environment setting: no setting

  • Command line argument: no argument

  • Configuration after substitution: name=CA

Note: Comments are skipped and not taken into account for any replacement.

See also: