The workers are background threads of the System Manager, which work asynchronously. The following workers are currently available:
Running Tasks are long-term processes or daemons. The System Manager can start and control these. The main parts that are controlled are
handling of standard and error output,
handling of abnormal termination and
support of normal termination.
The SAP R/3 Gateway is delivered with several predefined Running Tasks. These are described in the section Overview of Running Tasks.
Other pages are supported by the function Configuration of all Running Tasks; choose from the menu (or http://YourGateway:8080/sapr3gateway/manager/parameter) :
The following table describes the links and the command links:
| Running Task Environment | Go to the configuration of the selected running task. |
| Copy to | Copy all configuration settings of the one
selected to a new one. The new running task has the old name with prefix
Copy-Of. It is appended to the end of the list.
Note: |
| Delete | Delete the configuration of the selected running task. It cannot be deleted if it is already running. |
| Down | Set this after the next one. |
| Up | Set this before the previous one. |
| Create new Running Task Environment | Create a new empty running task. You will get a dialog which asks for a name and a type. |
To create a new running task, choose one of the following types. The type later defines which environment parameters will be available.
| Rpc2Rfc | Environment for an Rpc2Rfc kernel |
| Rfc2Rpc | Environment for an Rfc2Rfc kernel |
| Java (PMQ) Server | Environment for a Java server process. |
| Natural RPC Server | Environment for a Natural RPC Server |
| Starts server with shell script | Environment for any shell script that starts a
controlled process with exec.
|
For each running task, you must define the command to start the process. The process is created as a child process of Application Server with
fork() and exec() on UNIX or
CreateProcess() on Windows.
The System Manager can only control the progress of its next child. It
is not possible to control a process which was started as the child process of
a shell script (the child of a child process). In this case, use the
exec shell script command to replace the parent and give process
control to the System Manager.
The standard and error output are redirected to a file. The name of this file consists of:
Current directory path
Kernel task name
A timestamp
The extension ".log"
A new file is evaluated by the Scheduler in Timer Task NewLog. If a running task is started or stopped, the command button is available, see Overview of Running Tasks. This command will display the output content on the next page.
Tip:
Before creating a running task of your own, consider copying an
existing one.
Tip:
Define the environment and parameter with the placeholder and
replacement definition on the System
Constants page.
Tip:
Set the log level to debug, if you want to display your
environment and parameter definition when a running task is started, see
System Log.
The scheduler is a collection of timer tasks. A timer task has a time and/or a period of time. If this time is scheduled, an HTTP Get request with a specific URL will be executed.
There are several predefined timer tasks.
| Name | Description | At | Period | URL |
|---|---|---|---|---|
| NewLog | Set new log file for System Manager Log and all running tasks | 00:00 | 86400 sec. or 24h | SM_URL/timerTaskResponse?operation=setnewlog |
| CleanUpLog | Delete old log files whose lifetime has expired. The lifetime is configured on theSystem Constants page. See Clean up Log Files. | 00:05 | 86400 sec. or 24h | SM_URL/cleanup |
| CleanUpHistory | Delete old System Manager configuration files. See Undo Changes. | 00:10 | 86400 sec. or 24h | SM_URL/configHistory |
It is possible to create your own timer task. To do this you must
decide whether you want to create a temporary or a persistent task. Tempory
timer tasks are not stored in the configuration file. The definitions will be
lost when the System Manager is restarted. The definition of a persistent timer
task is saved in the configuration file. A persistent timer task also has the
attribute Startup. The Startup type auto starts the timer when the
system is started. With manual, you can start the timer task
later. The following parameters are available for a timer task:
| Name | Name of timer task. |
| Startup | For persistent timer tasks only:
auto creates this timer task when the System Manager is
started.
|
| Start at | Defines the starting time. |
| Period | Defines the interval in seconds. |
| At fixed rate | In fixed-rate execution, each execution is scheduled relative to the scheduled execution time of the initial execution. |
| Write Response to System Log | true writes the response of the
scheduled request to the System
Log.
|
| Command | HTTP Get request URL. |
| User ID | HTTP Basic Authentication user ID. |
| Password | HTTP Basic Authentication password. |
Depending on its state, several operations are available to a timer task.
| Start | The persistent timer task can start. |
| Stop | The timer task is stopped. No more scheduled events will be created. |
| Simulate | If you do not want to wait until Start-at time, you can simulate the scheduled event. This operation makes a test of all parameters. |
| Delete | Delete timer tasks that have not yet started. If the timer task is persistent, it will also be deleted from the configuration file. |
After running a scheduled event, the output will be available with the following links:
| Show | Displays the results in a new browser window. |
| Text | Displays the results at the end of the next page as text. |
| Exception | This link will be available if an error occurs while an event is running. The message is displayed at the end of the next page. |
The webMethods EntireX Attach Manager in this System Manager is implemented as an asynchronous thread, which is informed by the connected webMethods EntireX Broker if a server is missing. For example, a client sends a message to the webMethods EntireX Broker. There is no server connected to the Broker, but there is a registered Attach Manager. The Attach Manager thread receives the event and implements several dispatchers to forward this event.
| Dispatcher | Description |
|---|---|
| Attach Tasks | The missing server event will be forwarded to start a configured running task, see Overview of Running Tasks. |
| HTTP Request | The event will be forwarded to make a specific
HTTP-Get request. The broker ID and service are passed as HTTP-Get variables
broker and service. The Attach Manager thread waits
until the HTTP-Get command proceeds. When the HTTP-Get command is finished, the
Attach Manager performs a wait-for-receive command on the EntireX Broker to
retrieve the next event.
|
| Mediator Sequences | The event will be forwarded to make a specific
HTTP-Get request. The specific URL will start a Service
Orchestrator (Mediator) sequence. The BrokerID, service, user ID
and password are passed as HTTP-Get variables xbd.pmq.broker,
xbd.pmq.service, xbd.pmq.userid and
xbd.pmq.password.
|
Depending on its state, several operations are available to an Attach Manager.
| Start | The Attach Manager can start. |
| Stop | The Attach Manager is stopped. |
| Simulate | If you do not want to wait, you can simulate the attach event. This operation makes a test of all parameters. This operation works only when the Attach Manager has been started once. |
| Delete | Delete Attach Managers that have not yet started. |
| Restart | Stop and start Attach Manager. |
| Copy to | Copy all parameters to a new instance. |
Each Attach Manager has the following parameters:
| Name | The Attach Manager's name in the System Manager. |
| Broker address | IP or DNS Name of webMethods EntireX Broker. |
| User ID | User ID registered with webMethods EntireX Broker . |
| Token | Registered Token. |
| Password | User ID's password with webMethods EntireX Security. |
| Trace level | Trace calls with level 1,2,3 or switched off. |
| Startup | auto starts the Attach Manager when
the System Manager is started.
|
| Sleep before automatic restart | Wait this period of time between termination and the next start. |
| Shutdown on broker request | true terminates the Attach Manager
if a shutdown event is received. The Value false will restart
it.
|
| Simulate on start event | When the Attach Manager is started, each service will get a missing server event. Each service will then look in its queue and process any messages that have been received in the meantime. |
| Dispatcher | Select the dispatcher. |
| Service | List of attached services. |
Each service has the following operation or parameters:
| Queue | The queue name: CLASS/SERVER/SERVICE |
| Simulate | This service gets a missing server event to process the message in its queue. |
| Delete | Delete this service. |
The dispatcher's HTTP Requests and Mediator
Sequences have additional parameters:
| URL | Perform this HTTP-Get request if a server event is missing. |
| Log response | true writes the output of an
attached event to the System Log.
|
| Sleep interval between 2 events | Wait this period of time between 2 processed events. |
| Synchronize parallel requests |
|
