22 Understanding Report Processing
This chapter contains the following topics:
22.1 Batch Processing
Reports run using a batch process; they processes automatically without user interaction. When the system pauses, the engine executes the logic attached to that event within the batch process. After a batch process is launched, the flow of the attached logic proceeds on a fixed path, which is based on the data being processed. If you need to change the flow of the logic, you must modify the batch process using Oracle's JD Edwards EnterpriseOne Report Design Aid (RDA). Examples of batch processes include reports, subsystem jobs, database output, and table conversions.
Subsystem jobs are batch processes that constantly run in the background and off-load processor resources. Subsystem jobs can also be used to move activities through a process, such as an escalation process in Oracle's JD Edwards EnterpriseOne Workflow, which moves unanswered messages from one user to another after a defined period of time.
See Chapter 29, "Working with Subsystem Jobs".
Use the database output function within RDA to update or insert records within tables.
See Chapter 19, "Working with Database Output".
You use table conversions to:
-
Transfer data from one table to one or more tables.
-
Change the data or schema of an Oracle's JD Edwards EnterpriseOne table.
-
Transfer data from a single business view to one or more tables.
See "Converting Tables" in the JD Edwards EnterpriseOne Tools Development Tools: Data Access Tools Guide.
22.1.1 Batch Processes
You use RDA to create reports and batch processes. You can associate individual reports and batch processes with applicable menus to allow users access from the Oracle's JD Edwards EnterpriseOne web client.
You use batch processes to update tables or to print reports indicating the results of the batch process. Reports are just one kind of batch process that generates output. Many batch processes do not generate output.
JD Edwards EnterpriseOne reports contain all of the specifications for a report: section layout, business views, event rules, data selection, data sequencing, and database output.
Each report includes one or more sections; sections are self-contained elements that are the building blocks of reports. You can join sections to one another or use them as standalone groups of information. You can also use sections for special purposes, such as headers and footers.
22.2 Section Processing
JD Edwards EnterpriseOne report sections include headers, footers, and detail sections. Detail sections can be columnar, group, or tabular. Detail report sections can be considered mini reports or batch processes, with each section using its own business view. Because other sections in the report can contain different business views, you must add data sequencing and data selection to each section using RDA.
Some report sections are dependent on other sections of the report. Dependent sections provide supporting information and do not necessarily make sense on their own. Other report sections are independent and address the business purpose of the report.
Independent sections are also referred to as level-one sections, and they include these types:
-
Group
-
Columnar
-
Tabular
Level-one sections can also be parent sections.
Dependent sections are called from a level-one section. Dependent sections are also referred to as level-two sections, and they can contain:
-
Level break headers.
-
Level break footers.
-
Total sections (used in non-tabular reports).
-
Subsections.
-
Customized content.
The order in which the sections appear in the RDA workspace is not necessarily the order in which the system processes them. This diagram illustrates how the batch engine processes sections within a report:
22.2.1 Processing Sequence
The sequence in which the level-one sections of the report appear in the RDA workspace determines the process flow of the level-one sections. For example, if a report has multiple level-one sections and each has its own business view, then the first level-one section executes before the next level-one section executes. Any level-two sections that exist between the level-one sections are processed when and if they are called from a level-one section. If the report includes a subsection join following the level-one sections, which creates a parent/child relationship, then the parent/child sections are processed independently of the first level-two section.
If level-one sections are moved within the report template, the execution sequence is affected. In report processing, the system processes all level-one sections in the order in which they appear. Level-two sections, however, are processed as dependents of level-one sections. Moving conditional sections, subsections, level break sections, page headers, page footers, and report headers does not affect the sequence of execution. Report execution takes place from top-to-bottom for sections; and from top-to-bottom and left-to-right for objects within a section.
The system reads and processes all records in a section from beginning to end based on the defined data selection. If you do not specify data selection, then the system reads all of the records in the table until it reaches the end of the file.
Note:
Data sequencing and data selection defined at runtime affects only the first level-one section of the report or batch process. Therefore, when you design a report or batch process, consider how users will be affected since they cannot easily change data selection and sequencing for additional level-one sections.A level-one section is executed at least once whether or not it has a business view attached to it. Consider this fact in your decision to execute special event rule logic using the Do Section event of that section.
22.2.2 Subsection Joins
The parent/child relationship shown in the previous graphic illustrates the flow of joined sections. Parent/child sections can be called at any point within the process flow. Depending on how the parent and child sections are joined (one-to-one, one-to-many, or many-to-many), records are fetched first from the parent business view and then from the child business view for each corresponding parent record. When all parent records have processed, the system continues to the next section. If any database updates are performed in one of the first level-one sections, that change is reflected in the records fetched for the parent/child sections.
If the report contains a subsection join following a level-one section, then the parent/child section is processed independently of the first section.
22.2.3 Conditional Sections
Shown as the last section in the preceding graphic, the conditional section can be called from any of the previous level-one sections using the Do Custom Section system function. Conditional sections are called from a level-one section dependent on the criteria that you defined. For this reason, conditional sections are considered level-two sections. Memory allocation for conditional sections occurs at the beginning of a section. Therefore, you need to place conditional logic in the Initialize Section or End Section event to hide and show objects because memory is allocated and freed only once instead of each time a section is called.
Custom sections appear as level-one sections in the RDA workspace, but they are not processed unless explicitly called by the Do Custom Section system function.
22.2.4 Tabular Sections
Tabular sections output data to the report only when the system encounters a level break. The system does not initialize the Do Section event for each record in tabular sections; instead, it summarizes the records to the lowest level break level. The output to tabular sections is similar to the output to level break header sections.
22.3 Section Event Processing
When a report is processed, several events are encountered. The processing of attached logic might be dependent on processes that occur before and after a particular event.
When you submit a report for processing, the system processes the report header before the level-one section, and then the level-one section is initialized by the Initialize Section event. After the Initialize Section event, the system processes the Advance Section, Page Footer, Page Header, and so on. When the system finishes processing the first level-one section and all dependent sections associated with it, the system repeats the process for the next level-one section.
Each section type includes different events; therefore, the event flow for each section type is slightly different. The events for each section type are described in the Event Levels section of this chapter.
22.3.1 Group and Columnar Section Event Flow
The system processes group and columnar sections alike because they both write to the output after each record is read. This processing is unlike tabular section processing, which writes to the output only when a level break is encountered. The output is determined by the data selection and data sequencing defined in the section.
This diagram illustrates the typical event flow for group and columnar sections:
Figure 22-2 Event flow for group and columnar sections
Description of "Figure 22-2 Event flow for group and columnar sections"
22.3.2 Tabular Section Event Flow
Tabular sections are comprised of columns, rows, and cells. You can use calculations to define the information contained in each column, row, or cell. You can use column inclusion event rules to define the information to be contained in each column.
You can include a set of criteria, a business function, or a named event rule in column inclusion event rules. One advantage of tabular sections is that you do not have to define additional sections for level break logic or processing, as you do with group and columnar sections. However, totaling and Row Description columns in tabular sections are dependent on the level breaks that you define. Pay close attention when defining data sequencing and level breaks in tabular sections.
This diagram illustrates the typical event flow for tabular sections:
Figure 22-3 Event flow for tabular section
Description of "Figure 22-3 Event flow for tabular section"
Tabular sections summarize information and write to the output only when a level break is encountered. Level breaks are dependent on data sequencing and can be modified to make records as detailed or as general as the business need requires. The more fields that you define as level break fields, the more detailed the report. For example, you create a tabular section report to present open purchase orders. You sequence the data on Address Number, Document Number, and 2nd Item Number. You define all three fields as level break fields. The report displays the amount open for each 2nd Item Number for each document for each supplier. If you modify the data sequencing to include only Address Number and Document Number, and define only Document Number as a level break field, the report rolls up all the information and displays the total amount open for each document number. The result is a summary of the data included in the first report.
This diagram illustrates a tabular section level:
Additional features in tabular sections that affect processing include:
-
Drill Down
The Drill Down feature provides a view to the associated interactive application from the viewable output of a report. The interactive application displays the detail for the balances on the viewable output of the report.
-
Account Level of Detail
-
Automatic Totaling
The Automatic Totaling feature totals numeric values, regardless of the type, unless otherwise defined in the data dictionary. An example of a data item that does not total is Address Number. However, the system displays the description of some numeric values in the Row Description column, and might try to total these fields. You can suppress totals for a column from the column properties form.
If you have a report that uses multiple sections or a combination of group and columnar sections, consider using a tabular section. Tabular sections improve system performance because the system calls only one section instead of multiple sections.
22.3.3 Logic Attachment to Joined Sections
If you need to include logic on joined sections that should be processed every time the section is processed, attach the logic to the Refresh Section event. When joined sections are processed, the system initializes the Initialize Section event the first time the parent/child section is processed. The system then initializes the Refresh Section event for all subsequent times the parent/child section is processed. Therefore, if you attach logic to the Initialize Section event, the logic is processed only once. If you attach logic to the Refresh Section event, it is processed each time the section is processed.
22.3.4 Data Selection and Sequencing
If a report or batch process contains multiple sections and takes a long time to process, check the data selection for each section. The system processes all the records in a table unless you specify otherwise.
If you want a level-one section to adopt the data selection and data sequencing from another section, you can use the Use Data Sel/SeqFromASection system function. This system function uses the data selection and data sequencing that is defined in another section.
For example, in the Oracle's JD Edwards EnterpriseOne Print Pick Slips (R42520) application, you can select from hundreds of available columns in the Sales Order Detail File (F4211) table to use in the data selection. In the first section, which is hidden and sends data to the F4211 table, the report processes commitments first, which could add rows to the F4211 table. The next section in the report displays the modified and updated F4211 table showing the committed records. Possible solutions include:
-
Using a temporary file.
-
Changing the data selection on multiple sections.
-
Using the Use Data Sel/SeqFromASection system function to adopt the data selection and data sequencing from the previous level-one section.
The Use Data Sel/SeqFromASection system function enables a detail section to adopt the data sequencing or data selection specifications from:
-
Another section in the report.
-
A different report.
The target section can adopt the data selection criteria, the data sequencing information, or both from the source section. The selection or sequencing information from the source section replaces the information contained in the specifications of the target section.
To use the Use Data Sel/SeqFromASection system function, access Event Rules Design on the target section and access the Initialize Section event. The Initialize Section event is the only event that can invoke this system function. Expand the General folder to locate and select the Use Data Sel/SeqFromASection system function. Define the parameters to indicate the report, version, and section of the source data selection and data sequencing.
22.3.5 Custom Sections
Custom sections enable you to use event rules to control the information that prints on a report. Using custom sections, you can force a page break by creating a section with no objects and then activating Page Break After Print in the Section Properties. You can also use custom sections to print variable text and to present the same information but in different formats. An example would be a report that exists in two different modules but, depending on the user, calls a different section to present information specific to a particular module.
This diagram illustrates the process flow for custom sections called from event rules:
Figure 22-5 Process flow of a custom section called from event rules
Description of "Figure 22-5 Process flow of a custom section called from event rules"
When you run a report that includes a custom section, the batch engine calls and processes each section until it encounters the system function call to the custom section. The batch engine then processes the custom section. When the batch engine finishes processing the custom section, it continues processing the previous section.
You can call custom sections from any event except:
-
Initialize Section
-
Initialize Column
-
Report Level Events
-
Do Initialize Printer
-
Initialize Report
-
End Report
-
If you try to call a custom section from one of the exception events, the report writes a warning to the log, ignores the call to the custom section, and continues with the main section.
The custom section processes in the same manner as the type of section that it is (columnar, group, or tabular).
22.4 Level Break Processing
The system identifies a change in the data of a specific field by comparing the current record to the previous record. A level break occurs when the system identifies the change between the records for the fields that you define as level break fields.
You can use level breaks to organize the data of a large report into smaller, logical groups of data that are easier to review. Typically, the system displays a descriptive header before the associated data. For example, you can group address book records by search type. All records with the search type of E are grouped together with an appropriate heading. When the value in the search type field changes, a level break occurs and a new grouping begins.
Level breaks can be set up to initiate page breaks, totals, headers, and footers. Only business view fields can be defined as level break fields.
A single business view field can be attached to one level break header and one level break footer in a report template. If more than one level break header or level break footer is attached to a business view field, the batch engine processes only the first level break header or level break footer section and ignores the others.
This diagram illustrates level break logic processing:
Before a level break section is processed, the batch engine issues the Init Break Section event. This event stops processing for the current section and begins processing the level break footer section. After the level break footer section is processed, the batch engine processes the level break header if one is defined.
22.4.1 Level Break Section Events
When a report containing level break sections is processed, the system automatically calls the Init Lvl Brk Footer Section event or the Init Lvl Brk Header Section event. You can attach event rules to these events to control the flow of logic processed by the batch engine.
For example, if you want to create a report that summarizes information by company, you can create a level break footer to organize the data by company. You can define Company as a level break field and, when the company value changes, the batch engine will call the level break footer for the detail section.
You can also call business functions, define table input/outputs (table I/O), and include other logic in level break section events.
22.4.2 Init Lvl Brk Footer Section Event
A level break occurs when a new value for the level break field is encountered. Therefore, the new level break value is held in memory at the time that the level break occurs. When the batch system calls the Init Lvl Brk Footer Section event, the values for the previous level are accessed and either summarized or totaled. For example, if you have a level break footer defined to total revenue by company, the level break footer inserts the total following all the associated records that have been processed for a specific company. The Init Lvl Brk Footer Section event is attached to the level break footer section.
If you set up multiple level break footers for a report section, the batch system processes the footers from the lowest level to the highest level. For example, if you define two level break footers, one on business unit and one on company, the system processes the aggregates for business unit first and then the aggregates for the associated company.
When attaching logic to a level break footer, attach it to the End Lvl Brk Footer Section event rather than to the End Section event.
22.4.3 Init Lvl Brk Header Section Event
The Init Lvl Brk Header Section event is called after a level finishes processing and the system has encountered a new value for the level break field. It is also called after the Init Lvl Brk Footer Section event if you have a level break footer defined. The Init Lvl Brk Header Section event locates the header section associated with the previous level and processes the information in the level break header.
For example, if you define a level break header and a level break footer in a report, the system processes the level break footer before the level break header, as shown in the previous Level break logic processing diagram.
If you set up multiple level break headers for a report section, the batch system processes the headers from the highest level in the report to the lowest level in the report. For example, if you define two level break headers, one on business unit and one on company, the company level break header processes first, and then the business unit level break header processes.
22.4.4 End Lvl Brk Header and Footer Section Events
After the initialize level break events are processed, the system processes the End Lvl Brk Header Section and End Lvl Brk Footer Section events. These events end the level break process and return to the detail section. You can attach logic to the End Lvl Brk Section event to call a custom section. For example, you might want to print text, such as a disclaimer, after a level break footer. In this case, you can create a custom section that contains the information you want to print and attach the custom section logic to the End Lvl Brk Section event. When you process the report, the disclaimer appears following the level break footer section.
22.5 Batch Events
As a batch application processes, the runtime engine pauses at certain points—called events—to process logic. You can use events to insert custom logic for processing. The basic flow of events within a section is:
-
Initialize Section
-
Do Section
-
End Section
Some events are processed by the batch engine only if the appropriate section type exists. For example, Init Report Header and End Report Header are initialized only if the report includes a report header section. Likewise, Init Lvl Brk Footer and End Lvl Bk Footer are processed only if a level break footer exists.
22.5.1 Do Section Event
The Do Section event is the most commonly used event. It is used most often in columnar and group sections because the Do Section event occurs before any objects are processed.
The Do Section event is invoked after the system has assigned new values to objects in the report and immediately before the system processes objects within a section.
When the system processes the Do Section event in columnar sections, it processes the column headings first and then fetches the first record. For each object or column in the record, it processes the Init Object, Do Object, and End Object events. After processing the last object, the system calls the After Last Object Printed event and then fetches the next record and repeats the process. When all lines have been fetched from the database, the system processes the End Section event. This basic process is the same for group sections.
If an affected object is a child section, such as in a subsection join, the system invokes the Initialize Section event the first time that the child section is processed. For any subsequent times that the child section is processed, the engine invokes the Refresh Section event.
If an object does not fit on a page, the system invokes the Suspend Object event, which moves the object to the next page.
22.5.2 Report Level Events
This table describes the events that are available at the report level:
22.5.3 Section Level Events
This table describes the events that are available at the section level:
22.5.4 Page Header Section Level Events
This table describes the events that are available at the page header section level:
| Event | Description |
|---|---|
| Initialize Page Header | Occurs at the beginning of a report, after the report header section is processed and before the page header section processes for the first time. It also processes every time a page break occurs. Use this event to initialize values that cannot be set until after the report header logic executes. This event is similar to Init Section for a normal group, columnar, or tabular section, except that it is processed only for a page header section. |
| End Page Header | Occurs after the page header finishes processing. Use this event to do processing immediately after a page header. |
22.5.5 Page Footer Section Level Events
This table describes the events that are available at the page footer section level:
| Event | Description |
|---|---|
| Initialize Page Footer | Occurs at the beginning of the report, after the report header processes and before the page header section processes for the first time. Use this event to initialize values to be printed in the current page footer section. These assignments typically depend on information already processed on that page. |
| End Page Footer | Occurs after the page footer finishes processing. Use this event to do processing immediately after a page footer. |
22.5.6 Report Header Section Level Events
This table describes the events that are available at the report header section level:
| Event | Description |
|---|---|
| Initialize Report Header | Processes once at the beginning of the report. Use this event to initialize values at the beginning of a report. This event is similar to Init Section for a normal group, columnar, or tabular section, except that it processes only for a report header section. |
| End Report Header | Occurs after the report header processes. The system processes the page header for the report next. Use this event to do processing immediately after a report header and before a page header. |
22.5.7 Report Footer Section Level Events
This table describes the events that are available at the report footer section level:
| Event | Description |
|---|---|
| Initialize Report Footer | Occurs once at the end of a report, after everything else processes and before the report footer prints. Use this event to initialize values to print in the report footer. |
| End Report Footer | Occurs after the report footer processes. After processing completes, the report terminates. Use this event to do processing immediately after a report footer. |
22.5.8 Constant and Variable Events
This table describes the events that are available in constant and variable events:
| Event | Description |
|---|---|
| Do Column Heading | Occurs when the column is initialized. Use this event to populate the column heading based on event rules associated with a business function. |
| Do Variable and Do Constant | Occurs before the font and color are selected and before the value of the object is translated into a printable string of characters and output to the page. Use this event to do processing after an object has been processed. This is your last opportunity to manipulate the values or display attributes of objects before output. |
| End Variable and End Constant | Occurs immediately after an object is processed even if the object is invisible or suppressed. Use this event to do processing after an object is processed. |
| Initialize Variable and Initialize Constant | Occurs before each report object or variable is processed. Use this event to do processing before an object is processed. This event is useful for processing that affects the position of an object because the object's position on the page has not yet been determined. |
| Suspend Object (constant) | Occurs if an object requires multiple text strings or column headings and if only part of the object fits on a page. This event halts processing of the object until the next page has been started. Use this event to modify the value at the page break. Because the value of the object is already partially processed, this is not a good time to manipulate that value. |
| Column Inclusion | Valid only for tabular sections. Occurs after each record is fetched from the database. Use this event to perform calculations. Do not use the Column Inclusion event when you are performing calculations between columns (such as when calculating variance) or between variables within a column. |
| Cell Inclusion | Valid only for tabular sections. Occurs during Do Object after processing calculations for a cell. Use this event to manipulate cell data before displaying it. This event occurs before the Do Variable and Do Constant events. This event occurs during calculations. You can also attach criteria to determine whether the currently fetched data should be included in the cell calculation. |
22.6 System Functions Within Batch Events
System functions provide you with flexibility and control over how reports are processed. For example, you can use system functions to hide and show objects, hide and show sections, and generate messages.
This table describes the main categories of system functions available in batch applications:
Many system functions are shipped with JD Edwards EnterpriseOne. This table describes some of the commonly used system functions located in the general folder:
| System Function | Description |
|---|---|
| Set Selection Append Flag and
Set Sequence Append Flag |
Enables you to add, append, or overwrite data selection and data sequencing for a section. |
| Set User Selection and
Set User Sequence |
Enables you to define data selection and data sequencing for a section. |
| Stop Section Processing | Enables you to stop the processing of the current section. The system moves to the next section and begins processing that section. This system function is helpful for performance, especially when there is a large amount of event rule logic that remains to be performed. For example, if no more customers exist with a credit limit over a certain amount, the system stops processing that section and moves to the next section.
Stop Section Processing differs from Suppress Section Write. Suppress Section Write suppresses only the current record, which causes the engine to process the next record for the current section. |
| Hide Object | Enables you to hide objects in group and columnar sections using the Hide Object system function. The system prints a blank line even if the hidden object is the only object on the line because the system has no way of knowing whether the line contains other objects that need to be printed. To keep the system from printing a blank line, place the object in its own conditional section and suppress the printing of the conditional section using the Hide Object system function. |