Creating Actions that Run Applications on Remote Systems
When discussing actions and remote execution, there are two terms that are used frequently:
database host—the system containing the action definition
execution host—the system where the executable runs
In most situations, actions and their applications are located on the same system; since the default execution host for an action is the database host, no special syntax is required.
However, when the execution host is different from the database host, the action definition must specify where the execution string should be run.
The ability to locate actions and applications on different systems is part of the client/server architecture of the desktop. For a more in-depth discussion of networked applications, see Administering Application Services.
Creating an Action that Runs a Remote Application
Use the EXEC_HOST field in the action definition to specify the location of the application.
Valid values for EXEC_HOST are:
%DatabaseHost%—the host where the action is defined.
%LocalHost%—the host where the action is invoked (the session server).
%DisplayHost%—the host running the X server (not allowed for X terminals).
%SessionHost%—the host where the controlling Login Manager is running.
hostname—the named host. Use this value for environments in which the action should always be invoked on one particular host.
%"prompt"%—prompts the user for the host name each time the action is invoked.
The default value is %DatabaseHost%, %LocalHost%. Thus, when the EXEC_HOST field is omitted, the action first attempts to run the command on the host containing the action definition. If this fails, the action attempts to run the command on the session server.
Examples
- © 2010, Oracle Corporation and/or its affiliates