Parameter Name

Enter a unique name for the parameter. This name is never visible to users. The name is an identifier used by the software to cache user-entered filter values and for a variety of other purposes. When the user fills in a value for a specific prompt, for example, “Acme”, the value is defaulted to “Acme” when the user returns to that prompt. (Note that the caching persists for a user's session. The cache is cleared when the session terminates.)

The form of a parameter name should be TableAlias.COLUMN_NAME. (An identifier in this format is called a “table column name”.) This is important for the proper behavior of the dynamic selection of fields for display and filtering.

Examples include the following:

A second use of the parameter name relates to reports. Each report is defined as a Query Group, and the query group can contain multiple queries. For example, you might define an initial query that produced summary header information, followed by another query that returned the detailed information. Consider a report showing RFP activity in a specific commodity category. The initial query might show the count of events and the total dollar amount budgeted and spent, with a second query listing the date, owner and amounts for each RFP in that category. Both queries will require the category ID as an input parameter. If the two queries in the query group for the report use the same filter prompt name for the category ID, the user will only be prompted once for the value. This is an important usability consideration when naming parameters within report query groups.

Prompt Message Resource

Select the system resource to be displayed as a message to the user when prompting for the filter parameters.

Default Value

Enter a default value for the prompt. The value is entered and stored in string form and converted to the appropriate data type when needed. If you do not provide a default value, the user is prompted for one at runtime.

If the prompt Data Type is an Object Reference, a default identifying the class of the object to be picked is required. The format of the default object reference is null:classid:null. For example, for a Contact Object Reference, the class ID of Contacts is 600, so the default value would be null:600:null. For a list of class IDs, see the online Reference Guide (RG).

A value list value prompt control is a drop-down list. Providing a default value for a value list value in a standard query should be avoided if there is no guarantee that the values in that list will not be changed by the customer. If the default value is not in the list, the drop-down list will not have a value preselected (which is acceptable), but a valid selection for this parameter will not be required. This means that the absence of a valid selection will not stop the query from being executed with the invalid default value.

Data Type

Select the input parameter type to ensure the correct prompt presentation. The following types are supported:

Get Token

This field accepts a token in the following format: <%GET(CurrentDocument|CurrentBO)%>

The token is resolved with the value of the field corresponding to the field ID, in the context of the current Business Object (BO) or the root document of the the current BO. For example, an RFx document has the subordinate collection of RFx suppliers. If a picker is invoked on the RFx supplier UI page, the CurrentDocument refers to the RFx root document and CurrentBo refers to the RFx supplier subordinate object. If the picker is invoked on a UI page that represents the root document (such as the RFx header page), then CurrentDocument and CurrentBo resolve to the same BO, which is the RFx root document.

The use of CurrentBo is appropriate only for queries that are executed in a picker window. The use of CurrentDocument is appropriate only for queries that are executed in a picker window and for queries in a document report. CurrentBo is not supported for queries in a document report, because there is no way to enforce what page in the document UI is current when the report is launched from the document toolbar.

The second parameter of the GET token is a business object field ID. The field ID identifies that field of the current business object or its root document that will provide its value as the query parameter value. Therefore, the data type of the field must match the Data Type of the query parameter. The field must be defined in the metadata of the business object. The field IDs can be found in the Reference Guide. Extension fields are also supported by the GET token.

When a query parameter with the GET token is saved, the Prefill value from cache field is forced to be unchecked and the Locked field is forced to be checked. This causes the current field value to be retrieved every time the query is executed.

Query Group Name

By default, the UI picker control (with the ellipsis icon) for an object reference parameter on a list, picker, or report page will use the default query group for the target object type when the picker window is launched. By specifying Query Group Name, a different query group will be used in the picker window. The Query Group Name is the unique Internal Name of a Query Group, starting with “FCI-“ for standard query groups. The query group is expected to have the “Selection” purpose (as opposed to “Picker”, which is the purpose of the default query group). Note: When the Query Group Name is specified, the target object type of the named query group must match the class ID that is set in the Default Value field. If the Query Name is set, then the named query must be in the specified query group.

Query Name

The UI picker control for an object reference parameter will use a default query group or the query group that is named in Query Group Name. One of the query definitions in the query group will be executed initially. This is the “default query” in the query group. (After the query executes, another query in the group can be selected for execution in the same picker window.)

Query Name can be used to specify a different query definition to be executed initially. The value of this field is the Internal Name of a Query Definition.

String Matching

Select the type of matching to be done for string parameters. The type of match is controlled by the query string. If the query string uses an equality format, for example, DISPLAY_NAME = ?, an exact match will be performed. If instead, the query string uses a like format, for example, DISPLAY_NAME LIKE ?, wildcarding will be honored. The String Matching field controls the software's wildcard behavior as follows:

The Oracle wildcards are % for matching any number of positions and _ for matching a single position. Typically, users are more familiar with * for multiple positions and ? for a single position (the DOS and UNIX standards). The software will honor the Oracle characters if entered, but will also translate * and ? so that they are also treated as wildcards. Users should be trained to use * and ?. Note that string matching is case-sensitive by default. There are methods for performing case-insensitive matching, and while they have a performance impact, they can be used where appropriate. One technique is to have a WHERE clause that uses the pattern "WHERE UPPER(DISPLAY_NAME) = ?". The corresponding string parameter should have the option checked to Convert to Upper Case.

Default Operator

Checkbox Options

Define Required Filters to Handle High-Volume Result Sets

Query definers should consider the potential number of rows that could be returned in a query result set. High-volume result sets should probably have one or more required filters to avoid the query being automatically executed with no filters. Database and application server resources are wasted when returning a huge number of rows that will just need to be filtered in subsequent executions.

By default, there is no number of maximum rows retrieved. Aside from the fact that no single number would be appropriate for all objects, this limit still does not prevent the database from gathering all the rows in a work table just to sort them before returning the specified number of rows from the beginning of the result set.

Setting a maximum number of rows also prevents the query framework from doing an initial in-memory sort of the rows (in lieu of the database performing the sort). An in-memory sort is desired when a resource ID is one of the columns being sorted. This just increases the importance of setting reasonable limits by filtering results when querying high-volume data.