Procedure object

Defines a program or routine that implements an algorithm, including database access, data updates, and printing.

Description

A Procedure object lets you define non-interactive processes for database queries and updates. It also allows you to generate a PDF file to enable list data on screen or printed copies. As its name suggests, the programming style supported is imperative, although it also contains declarative parts (i.e., the Layout).

Each Procedure object contains several selectors:

Source: This is the main section because the code corresponding to the Procedure logic is written here. You have to write the code procedurally (imperative). The sequence for the execution is defined by you (including commands to access/update the database, filtering, evaluating whatever you need, printing, etc.). At the end of the code, Subroutines may also be defined to be invoked from the code itself.
Layout: In this section, you can define the output presentation. Not every Procedure is meant to have an output. In other words, if the Procedure prints information, you have to design the corresponding output (the information to be printed along with its format) in this section.
Rules: Only a few rules can be defined in a Procedure object. For example, the Parm rule to declare the parameters received by the object.
Conditions: In this section, you may define conditions that must match the data to be retrieved (general filters). There are other alternatives to define filters.
Variables: Like most objects, it also has a section for defining variables, which are local to the object.
Help: A detailed description can be written for the Procedure, to act as online help for the end user at execution time.
Documentation: A detailed description of the Procedure can be written to document it.

Like most objects, it also has a Properties Editor to configure general aspects of the object.

Summing up, a Procedure object allows:

Generating a visual output (typical listings or reports). Here the Layout section is mandatory.
Updating the database (insert, update, delete records of the tables, directly with commands or using Business Components).
Solving complex calculations (Consider the alternative of defining Formulas).
Having a non-structured output (although a Procedure object can have a hierarchical output, it is best and easier to achieve with a Data Provider object).

Samples

Consider the following Transaction object defined in your Knowledge Base:

Airline
{
  AirlineId*
  AirlineName
}

Suppose you need to define a PDF report to list the airlines a Travel Agency works with.

The Procedure that implements this requirement could have the following Layout (for a complete explanation go to Procedure Layout):

The logic must be written in the Source selector, for example, as follows:

Header
    Print Pb_Header
End
For each Airline
    Print Pb_Body
Endfor

Here the Header command indicates the header that each page of the resulting report will have, the For each command is used to access the database, and the Print command indicates the name of the Printblock control (included in the Procedure Layout) to be printed in the output.