Generating Reports 2.

5 - Maximizing Generation with Minimum Layout Modifications

Paul Dirksen ARIS Corporation Abstract
Although commonly under utilized, the Oracle Reports generator is a powerful tool for generating high levels of Oracle Reports 2.5 code. The Oracle Reports generator allows, with some minor layout modifications, developers with little or no Reports 2.5 experience to develop all levels of complexity and styles of reports. By eliminating the need for custom Reports 2.5 development, developing and maintaining production reports can be supported by substantially smaller staffs.... hence reaping the benefits of near 100% generation from Designer/2000. generation tricks will help generate 100% of nonstandard Oracle layout reports.

Starting the Generation Process

KNOW THY DATA..... As is with all reports development, regardless of reporting tool, you must know your data. Developing reports with Designer/2000 (D2K) is no different. When generating reports with D2K, the only additional wrinkle is understanding the BASE/LOOKUP table relationships of the data requirements of the report. An illustration of determining such a relationship is provided in Figure 1, where the EMP table is BASE with a lookup table usage of EMP_TYPE. FIGURE 1

Introduction
ALL REPORTS CAN BE GENERATED!!! Yes, you read that correctly, all reports can be generated if designed and developed correctly.... including a majority of those nasty matrix reports. Any experienced Oracle Reports developer would agree that the layout editor of Oracle Corporations Report development tool has not exactly been the most pleasant of interfaces to work with. In order to avoid this nasty beast, reports developers have evolved as a species, becoming more influential in the design of reports. The result of this practice yielding reports which require little or no layout modifications. Once designed, the trick to minimizing the amount of exposure to the layout editor is in building a better mouse trap. Reports developers have learned that the more precise the reports data model is, the less aggravation will be encountered customizing the layout. The same process applies when generating reports from Designer/2000. The key is first being influential in the design process of reports. If successful, this practice can result in near 100% finished Oracle Reports 2.5 products upon generated. Even for those absolutely, positively, got to have it in a customized layout reports, a number of strategies can be deployed to MAXIMIZE generation while MINIMIZING layout post generation modifications. Just keep in mind that no amount of
EMP_TYPE EMP _T Y_CD EMP _T Y_NAME EMP _T Y_DESC EMP EMP _NO NAME EMP _T Y_CD

Once the data relationships are understood, it is important to focus on how users will interact with the report and the expectations of how the data is to be displayed. Key items to look for include: Special, non-standard column formatting. Usage of decode statements. Type(s) of parameter(s) used (bind and/or lexical) Operator(s) used to evaluate report parameter(s).

All of the above listed items play a significant role in the ability of the Reports generator to consistently generate near finished Oracle Reports 2.5 products. To that end, I strongly recommend that prior to beginning the development of an Oracle Reports 2.5 module to walk through this five step pre-generation analysis. 1. 2. Identify the location of the data requested of the report on the physical model of the database. Understand the primary/foreign key relationships as they will translate into BASE and LOOKUP table relationships in the module definition.

Copyright@ARIS October 1996 - All Rights Reserved

3. 4.

5.

Understand the correlation of the reports break groups and the BASE/LOOKUP table usages. Identify requirements for concatenated fields, decode statements or special, non-standard column formatting. Understand the types of parameters to be used, bind and/or lexical, and the operators used to evaluate the parameters.

purpose of the constraint and a reminder about the CREATE and VALIDATE IN property settings.

Enabling Flexible Parent-Child Reporting

If you are not an experience Oracle Reports or D2K Reports developer, youre probably wondering why you would ever have to create these views in the first place. The answer to that question involves understanding repeating frames in Oracle Reports and how D2K generates them. Repeating frames control ALL selected data displayed within a report. Repeating frames control break groups, column ordering, print frequency and print direction of all data returned by the reports query(s). When generating reports from D2K, for each detailed module table usage (DTU) defined as a BASE table, a repeating frame is created in the layout editor referencing that BASE table usage as its source. With this in mind, if you have reporting requirements that call for: breaks on columns from a child table in a parentchild relationship above the frequency of the parent. display of parent-child data at the same frequency.

The results of this analysis will be used to deploy various combinations of report specific views, item groups, reporting libraries, specific module level preferences, and perhaps customized, report specific templates. All of these items assist reports developers in consistently achieving near 100% report generation.

Whats so hot about Views?

Probably the single most important aspect of generating reports is the usage of views. Using views reports developers have additional flexibility over straight table development to: 1. Generate reports where a column from a child table breaks at a frequency at or above the same frequency of columns from a parent table in a parent-child table relationship. Generate columns with Report specific formats using decodes, concatenations and to_x functions. Define dummy primary/foreign key constraints to join the view to other tables or views.

2. 3.

you will NOT be able to generate the layout from D2K without creating a report specific view. To illustrate this point, examine the data model in Figure 2. FIGURE 2
EMP_TYPE EMP _T Y_ CD EMP _T Y_ NAME EMP _T Y_ DESC EMP EM P _NO NAM E EM P _T Y_CD

Although percentages of code generation increase dramatically when using report specific views, they do need to be used responsibly. Specifically, care needs to be taken to insure: 1. The view is truly NECESSARY to SIGNIFICANTLY increase generation, since the view is an additional item to be created and maintained in the database. A particular views functionality is not duplicated in the creation of a new view. All view select statements are tuned. All view primary/foreign key constraints CREATE property are set to FALSE. All view primary/foreign key constraints VALIDATE IN property are set to SERVER to avoid unwanted code generation if the view is used in Form generation. All view primary/foreign key constraints key components contain documentation stating the

EMP_DEPT EM P _NO DEP T _NO P RIM _DEP T _ FLG

2. 3. 4. 5.

DEPT_TYPE DEP T _ T Y_CD DEP T _ NAME DEP T _ T Y_DESC

DEPT DEP T _NO NAM E DEP T _T Y_ CD

6.

Copyright@ARIS October 1996 - All Rights Reserved

You have been tasked with reporting all employees for your company showing the primary department in which they are assigned with break groups of employee type and department type. A prototype of the report is supplied below.
Employee Departmental Assignments Report Employee Type: Full Time Department Type: Science Employee Name Alice Anderson Bob Bear Carl Cliff Department Name Biology Biology Geology

tables (EMP and EMP_DEPT). No explicit break groups were specified. As you can see, the results of our MDD did not quite yield the desired layout format. In fact, numerous post-generation modification are required in Reports 2.5 to complete the report including: Consolidating the reports 2 queries into one (unless the preference DOJOIN was set to Y or NULL). Creating a break group on DEPT_TYPE below EMP_TYPE and above the body of the report. Defaulting a new layout for the report. FIGURE 4

Employee T ype: CG$EMP_T YPE Employee Name CG$EMP Department CG$DEPT Dept T ype CG$DEPT _T YPE

When developing the report to meet the specified requirements the Module Data Diagram (MDD) would look something similar to Figure 3 (only display columns are shown). FIGURE 3
EMP (BASE) EMP_NAME

By implementing these customization, we would achieve a complete product. However, we would not have created a manageable D2K reporting module. Since the layout of the report is recreated on each generation, unless the preference CRELAY is set to N, all future support and upgrades to this report will require the same customizations undertaken in the initial development. Alternatively, lets approach the same report using a report specific view. The goal of implementing the report using a view being substantially increased generation, which will enable this module to be wholly developed and supported from D2K. Define the view in D2K with the end result DDL generation yielding something similar to this:

EMP_TY_CO DE (LO O KUP) EMP_T Y_NAME

EMP_DEPT (BASE) NO DISPLAY COLUMNS

DEPT (LO O KUP) DEPT _NAME

DEPT_TYPE (LO O KUP) DEPT _T Y_NAME

The MDD referenced in Figure 3 would generate the Reports 2.5 output displayed in Figure 4. Notice that our MDD resulted in the creation of two repeating frames identified by the triangle in the upper left hand corner of the frames. The creation of these frames is directly correlated to the 2 DTUs in the MDD defined as BASE

Copyright@ARIS October 1996 - All Rights Reserved

CREATE OR REPLACE VIEW EMP_RPT_VIEW AS SELECT ety.emp_ty_name EMP_TY_NAME , dty.dept_ty_name DEPT_TY_NAME , emp.name EMP_NAME , dept.name DEPT_NAME FROM dept_type dty , dept dept , emp_dept ed , emp_type ety , emp emp WHERE dty.dept_cd = dept.dept_cd and dept.dept_no = ed.dept_no and ed.emp_no = emp.emp_no and ed.prim_dept_no = Y and ety.emp_ty_cd = emp.emp_ty_cd

created 3 repeating frames. One repeating frame was created for each of the break levels and one for the remainder of the display columns that did not have the BREAK property explicitly set. Although this example is quite simplistic it highlighted a very common problem encounter by D2K reports developers, display of child data at or above the frequency of parent data.

Implementing Formats

Non-Standard

Column

Another instance in which the usage of views can dramatically increase the amount of generation is special, non-standard column formatting such as the concatenation of fields or non-Oracle standard column formats. To illustrate this point, lets revisit our previous data model and add a couple of new tables, DEPT_LOC and LOC as shown in Figure 7. FIGURE 7

The resulting MDD based on this view would be dramatically more simple as shown in Figure 5. FIGURE 5
EMP_RPT_VIEW (BASE ) EMP_TY_NAME DEPT_TY_NAME EMP_NAME DEPT_NAME

The difference here is that break groups need to be explicitly set to create the desired layout. Set the BREAK property on the EMP_TY_NAME field to 1 and DEPT_TY_NAME to 2. Figure 6 reflects the generated output from MDD. FIGURE 6
Employee T ype: CG$EMP_T YPE Dept Type: CG$DEPT_T YPE

Employee Name CG$EMP

Department CG$DEPT

Notice that explicitly setting breaks on EMP_TY_NAME and DEPT_TY_NAME actually

Copyright@ARIS October 1996 - All Rights Reserved

EMP_TYPE EMP _T Y_CD EMP _T Y_NAME EMP _T Y_DESC

EMP EMP_NO NAME EMP_T Y_CD

Employee Departmental Assignments Report Employee Type: Full Time Department Type: Science Employee Name Alice Anderson Bob Bear Carl Cliff Dept Name Biology Biology Geology Legal Location 10.0N 5.0E 10 9.5N 2.0W 25 10.0N 4.5E 13

EMP_DEPT EMP_NO DEP T _NO P RIM_DEP T _FLG

DEPT_TYPE DEP T _T Y_CD DEP T _NAME DEP T _T Y_DESC

DEPT DEP T _NO NAME DEP T _T Y_CD

When using report specific views, this is a non-issue. The special formatting needed to fulfill the column requirement can be built into the views select statement. This will enable all existing and future application usages which select from the view to benefit from this standardized implementation. Here, the EMP_RPT_VIEW which we previously created to support this report, will need the location column added to the select statement.

LO C LOC_NO T W N_W HOLE_NO T W N_FRACT _NO T W N_DIR_FLG RNG_W HOLE_NO RNG_FRACT _NO RNG_DIR_FLG SECT _NO

DEPT_LO C DEP T _NO LOC_NO P RIM_LOC_FLG

Now lets add an additional column to our report called legal location. Legal location is defined as the combination of the township, range and section, including direction flags, to indicate the precise location of our department. The revised prototype of the layout is supplied on the next page. Differing from our first example, we can actually generate the columns of the report at the correct frequency. The difficulty here is in laying out the legal location field without excessive layout customization as the legal location DCU actually consists of 7 of the 8 columns in the LOC table.

CREATE OR REPLACE VIEW EMP_RPT_VIEW AS SELECT ety.emp_ty_name EMP_TY_NAME , dty.dept_ty_name DEPT_TY_NAME , emp.name EMP_NAME , dept.name DEPT_NAME , loc.twn_whole_no||.||loc.twn_fract_no|| || loc.twn_dir_flg||loc.rng.whole_no||.||loc.rng_fract_no|| loc.rng_dir_flg|| ||loc.sect_no LOCATION FROM , loc loc , dept_loc dloc , dept_type dty , dept dept , emp_dept ed , emp_type ety , emp emp WHERE loc.loc_no = dloc.loc_no and dloc.dept_no = dept.dept_no and dty.dept_cd = dept.dept_cd and dept.dept_no = ed.dept_no and ed.emp_no = emp.emp_no and ed.prim_dept_no = Y and ety.emp_ty_cd = emp.emp_ty_cd

Copyright@ARIS October 1996 - All Rights Reserved

Once added to the view, we would then proceed to add the LOCATION field as a DCU to our MDD for this report as shown in Figure 8. FIGURE 8
EMP_RPT_VIEW (BASE ) EMP_TY_NAME DEPT_TY_NAME EMP_NAME DEPT_NAME LOCATION

D2K Arguments and Reports 2.5 Parameters

Another source of generation fun is generating D2K arguments which create Reports 2.5 parameters. On the surface it appears as though D2K generates little more than simplistic bind parameters with equally simple operators. However, in reality, the reports generator supports the generation of both bind and lexical parameters with more complex operators such decodes, in, or, and many more. It is important to remember when generating parameters, that parameters are the only means by which a user can limit the results of a report to usable information. Bind and Lexical parameters are merely methods to facilitate this process.

Notice the simplicity in D2K of adding a new field to the report once the complexity of the special formatting was added to the view. Upon generation this MDD would create the layout shown in Figure 9. FIGURE 9
Employee Type: CG$EMP_T YPE Dept Type: CG$DEPT _TYPE

Bind Parameters Defined

Bind parameters are used to substitute one value at runtime for evaluation and are identified by a preceding :. An example of a bind parameter in a select statement is provided below, where :P_EMP is the bind parameter reference.
SELECT emp_name , dept_name emp emp , emp_dept edept , dept dept and emp.name = :P_EMP and emp.emp_no = edept.emp_no and edept.dept_no = dept.dept_no

Employee CG$EMP

Department CG$DEPT

Location CG$LOC

FROM

WHERE

Usage of Item Groups

To achieve additional clarity in report layouts, reports developers can use item groups to logically group data together surrounded by a border, such as a rectangle, and optionally identified by a title. The effectiveness of item groups varies on a report by report basis, but is exceptionally useful for: Logically grouping reporting columns when the reports layout requires enumerated columns which widely dispersed across the page.
1. SET VALUE QUERY WHERE CLAUSE

This parameter would be replaced by either a user defined value or a default value at runtime. An overview of this process is provided in Figure 10. FIGURE 10
USER INTERFACE

Keep in mind that item groups only work for detailed column usages (DCU) which are tied to the same BASE DTU. This also includes DCUs from LOOKUP DTUs that are linked to the BASE DTU.

Copyright@ARIS October 1996 - All Rights Reserved

Generating a bind parameter is really quite simple. Simply create an Argument, define it and assign it to the DCU to which it applies. The generator will create the where clause statement that reflects the association. If your requirements call for an operator not provided by D2K, do NOT assign the argument to the DCU as described above. Rather, on the DTU which contains the desired DCU, explicitly add the evaluation statement to the WHERE/VALIDATION CONDITION text property field. An example of such an addition might be:
WHERE emp.name = decode(:p_emp,DAVE,DAVID,:p_emp)

All of these components create the process by which the lexical parameters value is replaced at runtime. An overview of the process is provided in Figure 11. FIGURE 11
USER INTERFACE 1. INTERPRET QUERY AFTER FORM TRIGGER 4. SET VALUE WHERE CLAUSE

Note: The WHERE key word is optional. If you supply the WHERE key word the reports generator will use it. If it is not supplied, the reports generator will supply it when creating the queries where clause.

2. CALL 3. RETURN LIBRARY FUNCTION

Lexical Parameter Defined

Lexical parameters are used to substitute multiple values at runtime and are identified by a preceding &. Lexicals can consist of as little a one line where clause to an entire select statement. An example of a lexical parameter usage in a select statement is below where &L_EMP is the lexical parameter reference.
SELECT FROM emp_name , dept_name emp emp , emp_dept edept , dept dept &L_EMP and emp.emp_no = edept.emp_no and edept.dept_no = dept.dept_no

To illustrate lexicals in action, refer once again to our simplistic lexical example provided below:
SELECT FROM emp_name , dept_name emp emp , emp_dept edept , dept dept &L_EMP and emp.emp_no = edept.emp_no and edept.dept_no = dept.dept_no

WHERE

WHERE

In contrast to generating bind parameters, lexical parameters are a little more complex. Generation of lexical parameters involves: Usage of both lexical and bind parameters. A custom report library. Adding one line of post generation code per lexical parameter used in Reports 2.5. Associating the lexical parameter to where clause of the appropriate query.

This select statement is actually a simplified version of the report we created in the view sections above. The requirements of this report are to show the employees and the departments in which they are assigned. In this case, the users may optionally select up to five employees on which to base the report. If no employees are specified the report is to return all employees. Obviously the only difficulty in generating this report is generating the lexical logic to fulfill the employee name selection criteria. Following our model in Figure 11, we will need: 1. 2. The capability to allow users to optionally enter 5 employee names. The logic to interpret the emp_name fields.

Copyright@ARIS October 1996 - All Rights Reserved

3. 4.

A call to the reporting library. To set the value of the lexical parameter.

For sake of this example, assume that we have a Forms 4.5 application which contains a customized reports calling form which serves as our user interface. As it pertains to our example, the form will assemble a comma delimited text string of the entries for the employee parameter and pass it to the report. If nothing is input, the Form will pass NONE in the string. To facilitate this reporting process 3 bind parameters and 1 lexical parameter will need to defined in D2K as arguments. Specifications of the parameters are provided below:
Short Name P_EMP P_COL P_OUT L_EMP Datatype + Length VARCHAR2(20) VARCHAR2(20) VARCHAR2(100) VARCHAR2(100) Argument NULL NULL NULL NULL

FUNCTION TM$LIST (p_emp in varchar2, p_column in varchar2) RETURN VARCHAR2 IS p_out varchar2(100); BEGIN -- Handles NULL values for a parameter if or then p_emp is null p_emp = NONE p_out := '1=1';

-- Handles multiple values for given parameter elsif then instr(p_emp, ',')>0 p_out := p_col||' in('''||REPLACE(p_emp,',',''',''')||''')';

-- Handles one value for given parameter else p_out := p_col||' = '''||p_emp||''''; end if; RETURN(l_list); END;

Once defined, the lexical parameter needs to be assigned to the WHERE/VALIDATION CONDITION property text field of the BASE DTU as shown below:
WHERE &L_EMP

The simple post-generation modification needed to call this function is a one line call added to the after parameter form trigger in Reports 2.5 as shown below. Notice that the library name is omitted from the call, only the function name is required.
function AfterPForm return boolean is begin :l_crew_list := TM$LIST(:p_emp,emp.name); return (TRUE); end;

The logic to determine the value of this statement will be contained within a Oracle Reports 2.5 library function similar to the one supplied on the next page. A major advantage of using library functions to set lexical values is that the same function can be used by multiple lexical parameters. Each lexical to be set simply needs an additional call to the library function. Once the function is complete, attach the custom library to the Reports 2.5 template used for generation. By attaching the library to the template, all report modules which are generated referencing this template will inherit the library as an Attached Library. This enables multiple reports to leverage the logic in this function.

Using lexicals, reports developers can dramatically increase the flexibility and often times the performance of reports. As this example has shown, generating lexicals from D2K is not only possible, it is quite practical.

Other Alternatives
Reports 2.5 preferences and customized templates are other alternatives by which reports developers can dramatically increase generation. In addition, preferences and templates go a long way toward insuring consistency in the development of reports as well as the

Copyright@ARIS October 1996 - All Rights Reserved

look and feel of the end product. Due to the sheer volume of subject matter which should be covered when addressing these two topics, I will not define them in great detail. However, I STRONGLY encourage customizing the standard stock reports template minimally including: Runtime parameters as display fields to the report heading. Reformatting of the heading to leverage both headers and footers. Display of the Company/Division or Department Name.

In addition, application level parameters should be defined to insure consistency across the application. Simply put, proactive work in defining application preferences and custom templates can SIGNIFICANTLY reduce the amount of work needed to standardize generated products.

Closing Thoughts
Designer/2000 is more than just a tool for application analysis, it is a powerful tool for code generation. Over the lifecycle of a project, the time spent researching methods to increase generation quite often result in significant time and cost savings. Achieving consistent reports generation results that approach 100% code generation is possible. It merely requires a certain level of creativity and ingenuity on the part of each developer to reach this goal. All reports can be generated, you simply must be resourceful enough to do it.

Author
Paul Dirksen is a Senior Consultant with ARIS Corporation specializing in CASE generated, client/server application development. Functioning in technical lead and project managerial roles, Paul has successfully implemented CASE generated applications for several Fortune 1000 companies as well as public sector organization using Oracle CASE 5.0/5.1 and Designer/2000. Paul can be reached at [email protected].

Copyright@ARIS October 1996 - All Rights Reserved