Types of Server Processes

The Automation Engine uses four main types of server processes: work processes (WP) and Java work processes (JWP), communication processes (CP), and the Java communication process (JCP) 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.

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 identified with a different letter:

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:

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.

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:

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 precess (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), agents, the Automic Web Interface, Java APIs, and so on. They are also assigned a process number that reflects the order in which they start.

The communication between agents and instances of the Automic Web Interface is exclusively performed through communication processes (CPs). 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:

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

Java Work Process

The Java work process (JWP) is a special kind of work process (WP). Implemented in Java, it is used to host special services, which have been developed in Java.

The Java work process (JWP) 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:

Notes:

Java Communication Process

The Java communication process (JCP) is a hybrid with the technical configuration from a Java work process (JWP) and the logical configuration in part of a work process (WP) and in part of a communication process (CP). 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:

The Java communication process also 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 or a range of ports.

Note: Several important functions in the Automation Engine, such as triggering and monitoring executions and the advanced object search, depend on the JCP being installed and running. Therefore, the JCP installation is mandatory.

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

You can also set up a system with multiple Java communication processes (JCPs). In this case, two Java communication processes (JCPs) are used in a cluster but only one of both is available at the time.

Important! When using multiple Java communication processes (JCPs), it is imperative that each one uses its own Automation Engine configuration file (ucsrv.ini, see Automation Engine). If only one INI file is used for more than one Java communication process (JCP), 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 JCP stating the reason for termination.

Setting up a system with multiple Java communication processes (JCPs) can be convenient for balancing and to provide failover capabilities, because the REST requests are sent and distributed only to available Java communication processes (JCPs).

For more information, see AE REST API - General Info.

See also: