About Process Servers

Process Servers are responsible for running and monitoring processes, watching for file events, and monitoring system performance. They run processes in local and remote systems. Process Servers host services, which allow them to run processes of different types. The types of processes supported by RunMyJobs include the following.

  • SAP ABAP jobs (via XBP) in R/3 and InfoPackages and Process Chains (via BW-SCH) in BI and Mass Activities in IS/U
  • System processes (locally) for maintenance tasks
  • SAPPI jobs with SAPPI Process Servers
  • Platform Process Servers
    • UNIX shell scripts
    • Windows CMD scripts
    • HP OpenVMS scripts
  • Perl scripts
  • AS/400 jobs
  • z/OS jobs via JES (FTP)

Note: Some Process Definitions are part of a module and require a specific license.

Process Servers are made up of two independent but interacting parts.

  • A process running on the RunMyJobs server. The Process Server process is usually started when the central RunMyJobs server is started, but can also be started with a Start command issued via an API or the GUI.
  • A Platform Agent running on a computer inside the customer network. The Platform Agent is usually started as part of the operating system boot sequence.
    • On Windows, a service controls the Platform Agent and automatically restarts it when it stops.
    • On UNIX, the native init system controls and restarts the Platform Agent, and the platform-agent script makes sure all necessary OS processes are running.

Both parts are started independently. Although either can run alone, the system works only when both parts are running and the Process Server has established a TCP connection to the Platform Agent.

Note: If the connection is interrupted, the Process Server will attempt to reconnect to the Platform Agent. Processes on the Platform Agent will continue to run, but RunMyJobs will not be able to set the process to completed until the connection is restored.

Most settings for a Platform Agent are stored in the RunMyJobs repository as Process Server parameters. However, settings that control what the Platform Agent can do on the computer where it was running must be configured on that computer.

The Platform Agent logs its operation status records to a file. For more information, see Platform Agent Logging.

Platform Process Servers that schedule workload or use file events require at least one of the following license keys:

  • ProcessServerService.External.limit - the total number of external Process Servers (Platform Agents, distinct web service endpoints, and SAP connectors).
  • ProcessServerService.OS.limit - the total number of Platform Agent Process Servers

How Process Servers Work

To understand Process Servers (Environment > Process Servers), you need to understand how the various parts of process execution fit together.

  • A Process Definition or Chain Definition defines what a process does.

  • A Queue determines when and where the process runs.

  • A Process Server is in charge of running the process.

  • A Service is a tool used by a Process Server to do the actual work. There are different Services for different kinds of work. For example, if you have a process that runs an Oracle job, it needs access to the OracleJobService.

Each Process Server is associated with one or more specific Services. The Services assigned to a Process Server determine what kinds of processes that Process Server can run. So it is critical that each process is routed to a Process Server that has the Service the process needs.

This routing is accomplished via Queues. Each Queue is associated with one or more Process Servers. When you submit a process, you submit it to a particular Queue. That Queue looks through its Process Servers to see if it has one with a matching Service. If it does, it sends the process to that Process Server. If it doesn’t, the process cannot execute.

Some Process Definitions are designed to (for example) run scripts on client computers. For those Process Definitions, an additional piece is necessary.

  • A Platform Agent is software that runs on a computer inside the customer network and executes tasks on that computer.

To use a Platform Agent, a Process Server must be able to communicate with the Platform Agent that will execute the tasks. Consequently, the Process Server must be configured with a PlatformAgentService, which can talk to a Platform Agent.

Each Service you associate with a Process Server can in turn be associated with one or more Definition Types. Each Definition Type provides a capability to the Service. For example, if you add a PlatformAgentService to a Process Server (as in the above diagram), it may have options for several Definition Types, each representing a type of operation the Platform Server can perform with a Platform Agent.

If you create a Linux, UNIX, or Windows Process Server, the PlatformAgentService is automatically added to the Process Server. You can then choose which particular Definition Types you want that Process Server to support.

If you create a Process Definition that uses a particular scripting language (for example, CMD), you need a Process Server that has the CMD Definition Type selected.

Process Server Responsibilities

Process Servers are responsible for the following activities.

  • Scheduling, executing, and monitoring processes in local and remote systems
  • Watching for file events
  • Monitoring system performance
  • Providing resources
  • Accepting processes from a Queue via a Queue provider
  • Using Services to execute processes

A Process Server can also represent a remote system (for example, an SAP system or a UNIX server).

Note: Some Process Servers require a specific license key.

Note: To configure Process Servers that connect to SAP systems, use the SAP System object.

Assigning Services to Process Servers

As described above, Process Servers use Services, which allow processes of different types to be run. The types of processes supported by RunMyJobs include:

  • SAP ABAP jobs (via XBP) in R/3 and InfoPackages and Process Chains (via BW-SCH) in BI and Mass Activities in IS/U
  • System processes (locally) for maintenance tasks
  • SAPPI jobs with SAPPI Process Servers
  • Platform Agent processes:
    • UNIX shell scripts
    • Windows Command scripts
    • HP OpenVMS scripts
  • Perl scripts
  • AS/400 jobs
  • z/OS jobs via JES (FTP)

When you initially select a type for a Process Server, the required Services are automatically assigned to it. For example, assume you create an AS/400 Process Server.

When you click Next, you can see that AS400Service has been automatically added to the Process Server.

In some circumstances, you might want to assign a service but no Definition Type to a Process Server. For example, you might want to do this with a Process Server that is used only used for file events.

Starting and Stopping Process Server Services

When you start a Process Server, all of its services start automatically, and when you stop the Process Server, all of its Services stop automatically. You can also start and stop Services independently.

Changing Process Server Parameters

If you need to make changes to Process Server parameters, be aware that the updated parameters will not take effect until the Process Server is restarted.

SAP Process Servers

There can be one or more Process Servers for every instance of an SAP System in your system. For example, you might have one per interface (XBP, XMW, XAL, or PI) or one per instance/client. This allows SAP Systems and interfaces to be managed in a granular manner, and makes it possible to manage scheduling on both a per-system and a per-interface basis.

To create an SAP Process Server, define an SAP System object in Redwood Server.

Worker Queues

By default, a Process Server has 100 worker Queues, which means that it can execute 100 concurrent processes. You can set the maximum number of worker Queues using the registry, as follows:

/configuration/requestQueueSize/<process_server_partition>/<process_server>/<service>

For example, to set the maximum workers for the ScriptService (RedwoodScript) to 20 for the Process Server named PS_TEST in the GLOBAL Partition, you would set this registry key:

/configuration/requestQueueSize/GLOBAL/PS_TEST/ScriptService=20

Forcing a Process to Run on a Specific Process Server

You can force a process to run on a specific Process Server by using the <job>.setForcedProcessServer(<process_server>) RedwoodScript method. This is used in pre-running actions and triggers, for example, to force a Chain Process to run on the same host as another Chain Process in a Chain. You can recognize Chain Processes that have been forced to run on a given Process Server in the processes monitor by the Forced Process Server property, which is set to the name of the Process Server.

Errors and Operator Messages

Process Servers raise Operator Messages for warnings and errors under Monitoring > Operator Messages. Check this screen if a Process Server appears to be behaving incorrectly or does not start.