Types of Server Processes

The Automation Engine uses five main types of server processes: work processes (WP) and Java work processes (JWP), communication processes (CP), Java communication process (JCP), and the REST process, which hosts special services such as the REST API. The dialog process (DWP) is a special work process that is used for Automic Web Interface messages.

Until version 12.3, the Java communication process (JCP) was used partly to provide a REST endpoint for the Automation Engine. The new REST process covers this functionality now while the new Java communication process (JCP) functions as a communication process (CP) for components that use TLS/SSL and WebSockets.

This page includes the following:

Automation Engine Management Page

The Processes and Utilization page in the Administration perspective lists all types of server processes of the AE system. For more information, see Processes and Utilization. Each process is clearly identifiable:

  • PWP: Primary Work Process

  • WP: Work Process

  • CP: Communication Process

  • DP: Dialog Work Process

  • JWP: Java Work Process

  • REST: REST Process

  • JCP: Java Communication Process

Note: You can also use the script function GET_UC_SETTING to find out the type of a server process.

Work Processes (WP) and Primary Work Process (PWP)

Work processes (WP) do the actual server work. They activate, generate and execute tasks, and monitor them until they are finished. The primary work process (PWP) is used for special tasks. It performs central work process (WP) tasks that must not be distributed such as the time basis or process administration.

At system start, the work process (WP) that starts first becomes the primary work process (PWP). If the primary work process (PWP) fails, one of the remaining work processes (WPs) turns into a primary work process (PWP). All relevant information is either regularly updated for all work processes (WPs) or stored in the database.

The primary work process (PWP) is the only work process (WP) that has a port assigned. This port is specified in the pwpPort= parameter in the [TCP/IP] section of the INI file of the Automation Engine. For more information, see Automation Engine.

The rest of the work processes (WPs) connect to the primary work process (PWP) and to the communication processes (CPs). Therefore, they do not need a port assigned and establish the connection through the port assigned to the process (PWP or CP) they connect to.

Work processes are also assigned a process number that reflects the order in which they start.

Example

In a system with four work processes (WPs), the processes are assigned as follows:

  • WP001 - PWP (primary work process)

  • WP002 - OWP (work process with server role)

  • WP003 - RWP (work process with server role)

  • WP004 - DWP (dialog process)

If WP001 stops for any reason, another work process (WP) assumes the role of the primary work process (PWP). However, that work process keeps the process number assigned upon starting. The system has only three work processes (WP002, WP003, WP004); WP001 is available again after a restart.

The same reasoning applies to all other processes. If WP002 ends for some reason, the system has only WP001, WP003, and WP004. WP002 is available again after a restart.

WP Server Roles

Some tasks require more attention than others when they are processed. For this reason, and to avoid negative impacts on the performance of your system, they obtain a server role. Each server role has its own queue in which the corresponding tasks are stored.

The following server roles are available:

  • O for outputs
    • Stores log messages of server processes and agents to the AE database
    • Stores activation reports of ERP and Java agents of the Automation Engine
  • R for resource calculations
    • Checks Sync objects
    • Calculates Calendar objects
    • Maximum number of simultaneous object executions
    • Console-type events
    • Automatic FILE events
    • Deadlock avoidance

The Role column of the Processes and Utilization page in the Administration perspective shows whether a work process (WP) has a server role assigned and which one this is. For more information, see Processes and Utilization.

Each server role is only assigned once. When the Automation Engine starts, the primary work process (PWP) obtains both server roles. When a second work process (WP) starts, the primary work process (PWP) assigns the first server role to this work process (WP). The work process (WP) that starts third obtains the second server role. If a work process (WP) ends, the primary work process (PWP) takes this server role again and assigns it to another work process (WP) that does not have a server role assigned yet. If there is no such work process (WP), the primary work process (PWP) keeps the server role.

A work process (WP) always processes the tasks of its own server role first. If there are no tasks for this role, it processes tasks of the general work process (WP) queue.

Starting a work process (WP) in cold-start mode results in all requests that are still available being deleted.

Note: Ignore the following error messages that are written to the log file when the first work process (PWP) starts in cold-start mode:

U0029108 SQL_ERROR Database-Handles  DB-HENV: 6d92d0  DB-HDBC: 6d93a0

U0003591 DB error info: Opc: 'SQLExecDirect' Return code: 'ERROR'

U0003594 UCUDB Ret: '3590' OpCode: 'EXEC' SQL-Stmnt: '{call UC_Truncate_Table('MQCP006')}'

U0003590 DB error: 'SQLExecDirect', 'ERROR  ', '42S02', 'Cannot find the object "MQCP006" because it does not exist or you do not have permissions.'

Dialog Processes

Dialog processes (DWPs) are a special form of work process (WP). They work in the same way as work processes (WPs) but are used exclusively for Automic Web Interface messages. It is recommended to change a particular number of work processes (WPs) to dialog processes (DWPs) to improve performance in case the primary work process (PWP) has to deal with complex queries or large amounts of data.

Important! Neither the primary work process (PWP) nor work processes (WPs) that have a server role assigned can be changed to a dialog process (DWP). This means that the primary work process (PWP) plus at least two work processes (WPs) must be active before a dialog process (DWP) is available.

When the last dialog process (DWP) is ended, the work process (WP) takes over the Automic Web Interface messages. This means that an Automation Engine system can operate without using dialog processes (DWPs).

Changing Work Processes

You can change the server mode a work process (WP) to a dialog process (DWP). You can also change the server mode of a dialog process (DWP) to a work process (WP) or a primary work process (PWP).

In the Processes and Utilization page of the Administration perspective, right-click the relevant process and select Server Mode > Change Server Mode to <xxx> accordingly. For more information, see Processes and Utilization.

Alternatively, you can also use the script statement :SET_UC_SETTING to change the server mode of work processes (WPs).

System Settings

You can define a default value to control the number of work processes (WPs). Use the WP_MIN_NUMBER key in the UC_SYSTEM_SETTINGS variable to define a node name and the minimum number of work processes (WPs). The work processes (WPs) that exceed this number become dialog processes (DWPs). For more information, see WP_MIN_NUMBER.

Note: This does not affect the PWP.

The name that you specify as the node name must also be defined in the corresponding section of the INI file of the Automation Engine (see Automation Engine). If your server processes are distributed among several computers, you can define one node name per computer. If you use the same node name in several INI files, this name applies throughout the system.

Examples

The server processes of an AE system are shared between two computers. Each computer has three work processes (WPs). AUTOMIC is used as the node name in the INI files of both Automation Engine instances, so that the two computers have the same settings. Add the following entry to the system variable UC_SYSTEM_SETTINGS to ensure that there are at least two WPs:

WP_MIN_NUMBERAUTOMIC=2

If all three work processes (WPs) are active, one of them is changed to a dialog process (DWP).

If you want to use different minimum numbers of work processes (WPs) on each computer, you have to adapt the content of the system variable as follows:

WP_MIN_NUMBERAE_1=2;AE_2=1

Note: You must also specify the terms AE_1 and AE_2 in the node name section of the INI file of the Automation Engine.

Communication Processes (CP)

The communication processes wait to be contacted by work processes (WPs), other communication processes (CPs), and non-TLS/SSL agents. They are also assigned a process number that reflects the order in which they start. After the start, the primary work process establishes a connection to a communication process (CP). 

The ports assigned to the communication processes (CPs) are defined in the CP.PORTS= parameter in the [PORTS] section of the Automation Engine INI file. It can be defined in different ways:

  • as single ports separated by semicolons

    [PORTS]

    CP.PORTS=2217;2218;2219;2220

  • as a port range

    [PORTS]

    CP.PORTS=2220-2237

  • as a combination of single ports and a port range

    [PORTS]

    CP.PORTS=2217;2218;2219;2220-2237

Note: Agents use port numbers as keys.

As with the process numbers, the port numbers used by communication processes (CPs) must be unique in the entire system. Communication processes (CPs) connect to ports in the order of their declaration.

Example

If the port range for communication processes (CPs) is 2217-2221, the first communication process (CP) to start receives the process number 001 and uses port 2217 (CP001:2217).

In a multi-host system, all communication processes (CPs) must use a different port, regardless of the host in which they run. In a system with two hosts, using two separate INI files, you can use different sets of ports. This ensures that the communication processes (CPs) use the same ports after restart.

Example

  • INI file definition for Host A

    [PORTS]

    CP.PORTS=2220;2033;2040-2250;2061

  • INI file definition for Host B

    [PORTS]

    CP.PORTS=3030;3031;3040-3050:3061

Depending on the number of clients (non-TLS/SSL Agents, CallAPIs), it is recommended using a corresponding number of CPs per node.

More information:

Java Work Process

The Java work process (JWP) is a special kind of work process (WP). It executes the tasks in the JWP relevant queues (MQnJWP, MQnAUT, MQnUTL). Also, it is contacted by other work processes (WPs) to carry out sync calls.

The process numbers assigned to Java work processes also reflect the order in which they start and have the same format as other work processes (WPs). Work processes (WPs) look up the address of a Java work process (JWP) in the server management table (MQSRV) when they have to carry out a sync call. Therefore, the Java work process (JWP) can connect to any available port. However, you can define specific ports for the Java work processes using the JWP.SYNC.PORTS= parameter in the [PORTS] section of the INI file of the Automation Engine (see Automation Engine). These ports can be defined in different ways:

  • as single ports separated by semicolons

    [PORTS]

    JWP.SYNC.PORTS=2220;2033;2040

  • as a port range

    [PORTS]

    JWP.SYNC.PORTS=2040-2050

  • as a combination of single ports and a port range

    [PORTS]

    JWP.SYNC.PORTS=2220;2033;2040-2050;2061

Notes:

  • The Java work process (JWP) installation is mandatory. For more information, see Installing the JWP.

  • You have to start more than one Java work process (JWP) for Automic Web Interface services. Currently there is no work load distribution of the listed services implemented between the active Java work processes (JWPs) of an Automation Engine system. Unlike other kinds of work processes (WPs).

  • If no JWP is available at login, the login fails and an error message is displayed. The system also notifies you if, for any reason, the minimum number of processes is not fulfilled during a session. The notification disappears once the process is running again.

JWP Server Roles

While the JWP processes the corresponding queues and handles ACL checks, sync calls, forecasting tasks, ERT and so on, you can assign a server role to a JWP so that it processes a specific queue or assignment. This allows you to distribute the load among JWPs, thus avoiding bottlenecks that can have a negative impact on the performance of your system.

The following JWP server roles are available:

  • AUT for Authentication

    • TLS/SSL agent authentication
    • LDAP user authentication
    • SAML user authentication
    • Kerberos user authentication

  • PER for Periodic

    • SLA
    • Telemetry
    • Performance management

  • UTL for Utilities

    • Client deletion

  • IDX for Indexing

    • Object indexing (Lucene search)

The JWP Roles page of the Automation Engine Management section in the Administration perspective allows you to define the number of processes that you want to assign to a role and rank them. For more information, see JWP Roles.

The Role column of the Processes and Utilization page in the Administration perspective shows whether a Java work process (JWP) has a server role assigned and which one this is. If a Java work process has more than one role assigned, these are listed separated by a comma. For more information, see Processes and Utilization.

REST Process

The REST process provides a REST endpoint for the Automation Engine. The port assigned for this purpose is defined in the port= parameter in the [REST] section of the INI file of the Automation Engine (see Automation Engine). There is only one port assigned to REST request. Therefore, it is not possible to assign more than a single port.

Notes:

  • Several important functions in the Automation Engine, such as triggering and monitoring executions and the advanced object search, depend on the REST process being installed and running. Therefore, the installation of the REST process is mandatory.
  • If no REST process is available at login, the login fails and an error message is displayed. The system also notifies you if, for any reason, the minimum number of processes is not fulfilled during a session. The notification disappears once the process is running again.

The REST process installation is relevant for the AE REST API and for the advanced object search. You can install a single REST process (REST). In this case, all REST requests are sent to this single AE REST API instance and no REST API is available if the REST process is down.

You can also set up a system with multiple REST processes. In this case, two REST processes are used in a cluster but only one of them is available at the time.

It is recommended using one REST process per node. However, you can also set up a system with multiple REST processes, which can be convenient for load balancing capabilities and to provide failover capabilities, because the REST requests are sent and distributed only to available REST processes. For more information, see AE REST API - General Info.

Important!

  • When setting up a system with multiple REST processes, it is imperative that each one uses its own Automation Engine configuration file (ucsrv.ini, see Automation Engine) and that different ports are assigned for each REST process. Otherwise, the first one connects successfully while the others terminated upon trying to register the same REST port if both run on the same node. An error message is written to the log file of the REST process stating the reason for termination.

  • If no REST process is available at login, the login fails and an error message is displayed. The system also notifies you if, for any reason, the minimum number of processes is not fulfilled during a session. The notification disappears once the process is running again.

Java Communication Process

As any other communication process (CP), the Java communication process (JCP) is also contacted by work processes (WPs). The ports assigned to the Java communication process (JCP) are defined in the JCP.PORTS= parameter in the [PORTS] section of the INI file of the Automation Engine (see Automation Engine) and can be defined in the same way as any communication process:

  • as single ports separated by semicolons

    [PORTS]

    JCP.PORTS=2317;2319

  • as a port range

    [PORTS]

    JCP.PORTS=2320-2337

  • as a combination of single ports and a port range

    [PORTS]

    JCP.PORTS=2317;2319;2320-2337

The installation of the Java Communication Process (JCP) is also relevant for the TLS/SSL connection to the UNIX, Windows, and Java based agents, the Automic Web Interface, and the Java API. This connection is done through secure WebSockets (WSS).

The port or port range assigned for this connection is defined in the WS.PORT= parameter in the [PORTS] section of the INI file of the Automation Engine (see Automation Engine). If you have installed a JCP per host, you can use the same WSS port definition in each instance.

Notes:

  • The processes require a keystore (in PKCS12 format) to work with the corresponding certificates. Make sure you have created a keystore beforehand. For more information, see Securing Connections to the AE (TLS/SSL).

    You also have to define the following parameters in the [TLS] section of the INI file of the Automation Engine (ucsrv.ini):

    • keystore= Path and file where the keystore for the TLS/SSL certificate is stored

      Default value: ./httpsKeyfile

      This parameter is mandatory and must point to the correct target; otherwise, the process server will terminate.

    • keystorePassword= Password for the keystore file

      Default value: changeit

      If the value is not defined or is left empty, the system uses the default value.

    • keyPassword=Password for the key

      Default value: changeit

      If the value is not defined or is left empty, the system uses the default value.

    • keyAlias= Alias used for the key

      Default value: jetty

      If the value is not defined or is left empty, the system uses the default value.

    The keystorePassword and the keyPassword can be encrypted with the UCYBCRYP Utility. For more information, see Encoding Passwords.

  • When the JCP is initiated, it binds to two ports:

    • The WS.PORT which is configurable in the INI file and is used by the Agents to communicate with the JCP.

    • To the port you have defined in the JCP.PORTS parameter in the [PORTS] section of the AE INI file. If there are no ports defined in this section, the JPC binds randomly to another port, which is necessary for the internal communication between WP and JCP/CP. When the JCP starts, it opens a random port and sends it internally via the database to the WPs so that WPs can reach the JCPs/CPs.

    • For more information, see Configuring Firewall and Ports.

See also: