This documentation supports the 9.1 version of Remedy Action Request System.

To view the latest version, select the version from the Product version menu.

Retrieving data from applications with Run Process

Another type of action, Set Fields, enables you to include workflow that automatically sets the contents of fields from a variety of data sources.

These data sources include fixed values, values read from other forms (possibly in other databases), values from arithmetic operations or functions, and values returned by external applications. Using the $PROCESS$ keyword of the Set Fields action, BMC Remedy AR System can execute an application and set the output of the application in various data fields. You can run only a process that behaves as follows:

  • Runs in a console (such as a .bat script or runmacro.exe ), but not in a GUI application.
  • Returns 0 if successful. (In this case, stdout is pushed to the field.) If the process returns anything other than 0, stdout displays an error message.

Whether you use an active link, filter, or escalation depends on the purpose of the external application. Active links can execute locally on the client machines or on the server. Filters and escalations execute only on the server.

Retrieving data from another application


When an external application is run on the server, BMC Remedy AR System waits for the process to terminate so that it can capture and interpret the output of the process. To avoid situations where BMC Remedy AR System waits indefinitely for a process that fails to terminate, a process time-out is built into BMC Remedy AR System. This time-out can be configured for between 1 and 60 seconds, using the AR System Administration: Server Information form.

In a Set Fields definition, the keyword $PROCESS$ indicates that all following text is a command. Use the full path name to the executable. AR System data field values can be passed as parameters. When using active links, remember that they run with the access control of the user, so access to form fields might be limited.

When workflow that performs a Set Fields action is fired, the process starts, and the web client waits for it to complete. (In UNIX, the process runs in a Bourne shell.) All returned data is read by the web client and processed according to the return status of the process:

  • If the return status is zero, the data is used as the new value for the field.
  • If the process returns with a status other than zero, the web client assumes the process failed and does not update the field contents. Instead, the output from the process is used as an error message and displayed to the user.

When designing an active link that uses a $PROCESS$ Set Fields action on the client, always consider the variety of client platforms that users will use. The keywords $HARDWARE$ and $OS$ can be used in the Run If expression for the active link to verify that the client is on an appropriate platform. If the active link is supported on multiple platforms, each platform requires its own active link with an appropriate qualification.

Note

You can run a process on a server by inserting @ serverName: before the process name in an active link. For example, $PROCESS$ @ServerA: C:/temp/process.exe If it is the current server, you can use @@ instead of @ serverName.



An example of a Set Fields action for a filter is shown in the following figure. In this example, the action sets the values of two fields by executing a separate utility program for each one, passing values of existing fields as parameters. If the programs execute correctly (that is, return with an exit code of zero), their outputs are assigned to the respective fields.

Defining a Set Fields action using $PROCESS$
(Click the image to expand it.)

Was this page helpful? Yes No Submitting... Thank you

Comments