Understanding Process Type Definitions

The primary purpose of the process type definition is to globally define the command line, parameter list, working directory, and other general parameters for a specific process type. Consequently, the information doesn’t need to be duplicated for each process definition of the same type, and you can vary these global parameters as needed, depending on the target operating system and database platform.

PeopleSoft Process Scheduler supports all operating systems and database environments that are supported by PeopleSoft. However, not every operating system and database environment combination supports every process type. For example, process types like PS/nVision are supported on Microsoft Windows operating systems only, but SQR, COBOL, and PeopleSoft Application Engine can run on other operating systems, as well.

PeopleSoft Process Scheduler uses the following variables during runtime:

• Meta-strings.

  Meta-strings provide runtime values to the definition and support the management of sensitive data, such as passwords, which are not written to the database.

• In-line bind variables.

• Client and server variables.

For each process request, all defined variables are evaluated and expanded, if possible. (For security reasons, %%OPRID%% is not expanded.) All variables that are not resolved through any of these sources might cause the process request to fail. You can detect unresolved variables easily by reviewing the Process Request Detail page for the failed request.

Meta-Strings

The predefined meta-strings must be enclosed in a set of double percent signs. When processing a request, if PeopleSoft Process Scheduler encounters a string that is enclosed inside a set of double percent signs, it compares the variable name with an internal list of predefined meta-strings. If the variable name is not one of these meta-strings, it is assumed to be a server-based environment variable.

The following table includes all predefined meta-strings and their associated runtime values.

Predefined Meta-String	Runtime Value
%%ACCESSID%%	Database Access ID.
%%ACCESSPSWD%%	Database Access Password.
%%DBNAME%%	Database Name.
%%INSTANCE%%	Process Instance.
%%OPRID%%	User’s Signon ID.
%%OPRPSWD%%	User’s Password (encrypted).
%%OUTDEST%%	Output Destination. For example, C:\%TEMP%; \\PrintServer1\Printer1.
%%OUTDESTTYPE%%	Output Type. For example, File, Printer; Web, Window, Email.
%%OUTDESTFORMAT%%	Output Format. For example, SPF; HTM; PDF; TXT.
%%PRCSNAME%%	Process Name. For example, XRFAPFL, GLPJEDIT.
%%RUNCNTLID%%	Run Control ID. For example, NTClient.
%%SERVER%%	Reference the Database Server Name.
%%EMAILID%%	User's email address that is stored in the user profile.
%%CLIENTTIMEZONE%%	Time zone that is specified for the client initiating the request.
%%APPSERVER%%	Application Server (used for three-tier).
%%LOG/OUTPUTDIRECTORY%%	Directory in the PeopleSoft Process Scheduler Server Agent to which a file that is generated from a process request is written.
%%DEFAULTPRINTER%%	Default printer defined in the Process Scheduler Configuration file.

In-Line Bind Variables

The parameter list may contain in-line bind variables. In-line bind variables represent any field (record.field) that is used in the current page and they are defined like this:

:RECORD.FIELD

For example, specify the following code to pass the value of the User ID field from the RPT_RQST_WRK record as a parameter:

:RPT_RQST_WRK.OPRID

Variables must be enclosed in a set of double percent signs, as in %%OutputDirectory%%. At runtime, Process Scheduler first looks at all double-percent variables to determine whether these represent a predefined meta-string value, such as %%OPRID%%. Because the meta-string is predefined, it can resolve the variable at initiation of each request. If the variable is not defined as a meta-string, Process Scheduler tries to find it in the Process Scheduler configuration file. If none is found, it leaves the value unresolved.

Note:

This documentation is not a substitute for the PeopleSoft Application Engine, COBOL, SQR reports documentation. If you need additional information about parameters that are discussed here, the documentation from the appropriate vendor is your best reference.

Parameter List Formatting

The parameter list consists of a series of tokens that make up the parameters to be used for the process. Tokens are separated by unquoted space characters. Single or double quote characters can be used for quoting. Both types of quotes are treated equivalently, but the starting and ending quotes for a quoted portion of a token must match. A quoted string may not contain quotes of the same type but a single quoted string can contain double quote characters and vice versa. A single token may consist of multiple adjacent quoted characters however no spaces are permitted between the quoted fragments. Unterminated quoted fragments will result in an error.

This table shows examples of parameter lists that require formatting:

Example Parameter Value	Format
A parameter that contains spaces. parameter value = 1 2 3	“1 2 3” or '1 2 3' Note: Use either single or double quotes.
A parameter that contains space and apostrophe (single quote) characters. parameter value = customer's update	“customer's update” Note: Use double quotes for the parameter so that the apostrophe (single quote) and space characters are passed correctly.
A parameter that contains space, apostrophe (single quote), and double quote characters. Parameter value = John's comments “Hello There”	“John's comments” '“Hello There”' Note: The first fragment is enclosed in double quotes so that the single quote and space characters are passed correctly and the second fragment is enclosed in single quotes so that the double quote and space characters are passed correctly. Note that there are no spaces between the quoted fragments.

Meta-variables can be used either quoted or unquoted and may contain quoted fragments themselves. Meta-variables are expanded before quotes are processed.

This table shows examples of parameter lists containing meta-variables that require formatting:

Example Parameter Values	Parameter List Format	Explanation
1st parameter = -p 2nd parameter = Param 2 3rd parameter = Param 3	-p %%METASTRING%%	METASTRING = ”Param 2” ‘Param 3’ This parameter list that uses a single meta-variable to pass multiple parameters containing spaces. Note: The meta-variable contains quotes so that the single meta-variable can be used to pass multiple parameters containing spaces.
1st parameter = -p 2nd parameter = Param 2	-p “%%METASTRING1%% %%METASTRING2%%”	METASTRING1 = Param METASTRING2 = 2 This parameter list uses two meta-variable to pass a single parameter containing spaces. Note: The meta-variables are enclosed in quotes in order to pass the expanded meta-variables as part of a single parameter.
1st Parameter = -p 2nd Parameter = Param 3rd Parameter = 1 4th Parameter = John’s comment	-p “%%METASTRING1%%” “%%METASTRING2%%”	METASTRING1 = “Param 1” METASTRING2 = John’s comment This parameter list demonstrates behavior that can occur when meta-variables are quoted and themselves contains quotes. Care must be taken when quoting meta-variables or using meta-variables containing space, single quote, or double quote characters to ensure parameters are passed as intended. Note: The double quotes around METASTRING1 and in its value cancel each other out resulting in the contents of METASTRING1 becoming two parameters. Additionally, note that if METASTRING2 were not quoted with double quotes, an error would occur as the single quote in METASTRING2 would be seen as the start of an unterminated quote