d2k report layout

Copyright@ARIS October 1996 - All Rights Reserved

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. 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 Corporation’s 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

generation tricks will help generate 100% of non-standard 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

EMP

EMP_NONAMEEMP_T Y_CD

EMP_TYPE

EMP_T Y_CDEMP_T Y_NAMEEMP_T Y_DESC

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. Identify the location of the data requested of the

report on the physical model of the database. 2. Understand the primary/foreign key relationships as

they will translate into BASE and LOOKUP table relationships in the module definition.


3. Understand the correlation of the reports’ break groups and the BASE/LOOKUP table usages.

4. Identify requirements for concatenated fields, decode statements or special, non-standard column formatting.

5. Understand the types of parameters to be used, bind and/or lexical, and the operators used to evaluate the parameters.

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. What’s 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.

2. Generate columns with Report specific formats using decodes, concatenations and to_x functions.

3. Define “dummy” primary/foreign key constraints to join the view to other tables or views.

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.

2. A particular views functionality is not duplicated in the creation of a new view.

3. All view select statements are tuned. 4. All view primary/foreign key constraints CREATE

property are set to FALSE. 5. 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.

6. All view primary/foreign key constraints key components contain documentation stating the

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, you’re 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 it’s source. With this in mind, if you have reporting requirements that call for: breaks on columns from a child table in a parent-

child relationship above the frequency of the parent. display of parent-child data at the same frequency. 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

EMP _NONAMEEMP _T Y_CD

DEPT

DEPT _NONAMEDEPT _T Y_CD

EMP_DEPT

EMP _NODEPT _NOPRIM_DEP T _FLG

EMP_TYPE

EMP _T Y_CDEMP _T Y_NAMEEMP _T Y_DESC

DEPT_TYPE

DEP T _T Y_CDDEP T _NAMEDEP T _T Y_DESC


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 Department Name Alice Anderson Biology Bob Bear Biology Carl Cliff Geology 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

EMP_TY_CODE(LOOKUP)EMP_TY_NAME

EMP_DEPT (BASE)NO DISPLAYCOLUMNS

DEPT (LO OKUP)DEPT_NAME

DEPT_TYPE (LOOKUP)DEPT_TY_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

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 Type: CG$EMP_TYPE

Employee Name Department Dept Type

CG$EMP CG$DEPT CG$DEPT_TYPE

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, let’s 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:


CREATE OR REPLACE VIEW EMP_RPT_VIEWASSELECT

ety.emp_ty_nameEMP_TY_NAME, dty.dept_ty_nameDEPT_TY_NAME, emp.name EMP_NAME, dept.name DEPT_NAME

FROMdept_type dty, dept dept, emp_dept ed, emp_type ety, emp emp

WHEREdty.dept_cd = dept.dept_cdand dept.dept_no = ed.dept_noand ed.emp_no = emp.emp_noand ed.prim_dept_no = ‘Y’and ety.emp_ty_cd = emp.emp_ty_cd

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_NAMEDEPT_TY_NAMEEMP_NAMEDEPT_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 Department

CG$EMP CG$DEPT

Notice that explicitly setting breaks on EMP_TY_NAME and DEPT_TY_NAME actually

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 Non-Standard Column Formats 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, let’s revisit our previous data model and add a couple of new tables, DEPT_LOC and LOC as shown in Figure 7.

FIGURE 7


EMP

EMP_NONAMEEMP_T Y_CD

DEPT

DEP T _NONAMEDEP T _T Y_CD

EMP_DEPT

EMP_NODEP T _NOP RIM_DEP T _FLG

EMP_TYPE

EMP _T Y_CDEMP _T Y_NAMEEMP _T Y_DESC

DEPT_TYPE

DEP T _T Y_CDDEP T _NAMEDEP T _T Y_DESC

EMP_DEPT

EMP_NODEP T _NOP RIM_DEP T _FLG

DEPT_LO C

DEP T _NOLOC_NOP RIM_LOC_FLG

LO C

LOC_NOT W N_W HOLE_NOT W N_FRACT _NOT W N_DIR_FLGRNG_WHOLE_NORNG_FRACT _NORNG_DIR_FLGSECT _NO

Now let’s 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.

Employee Departmental Assignments Report

Employee Type: Full Time

Department Type: Science

Employee Name Dept Name Legal LocationAlice Anderson Biology 10.0N 5.0E 10Bob Bear Biology 9.5N 2.0W 25Carl Cliff Geology 10.0N 4.5E 13

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.

CREATE OR REPLACE VIEW EMP_RPT_VIEW ASSELECT 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 LOCATIONFROM

, loc loc, dept_loc dloc, dept_type dty, dept dept, emp_dept ed, emp_type ety, emp emp

WHEREloc.loc_no = dloc.loc_noand dloc.dept_no = dept.dept_noand dty.dept_cd = dept.dept_cdand dept.dept_no = ed.dept_noand ed.emp_no = emp.emp_noand ed.prim_dept_no = ‘Y’and ety.emp_ty_cd = emp.emp_ty_cd


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_NAMEDEPT_TY_NAMEEMP_NAMEDEPT_NAMELOCATION

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

Employee Department Location

CG$EMP CG$DEPT CG$LOC

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

report’s layout requires enumerated columns which widely dispersed across the page.

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.

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. 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

FROM emp emp , emp_dept edept , dept dept

WHERE and emp.name = :P_EMP and emp.emp_no = edept.emp_no and edept.dept_no = dept.dept_no

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

QUERY

1. SET VALUE

USER INTERFACE

WHERECLAUSE


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: WHEREemp.name = decode(:p_emp,’DAVE’,’DAVID’,:p_emp)

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. 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.



WHERE &L_EMP and emp.emp_no = edept.emp_no and edept.dept_no = dept.dept_no

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.

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

1. INTERPRET

4. SET VALUE

2. CALL 3. RETURN

AFTER FORM TRIGGER

LIBRARY

FUNCTION

USERINTERFACE

QUERY

WHERECLAUSE

To illustrate lexicals in action, refer once again to our simplistic lexical example provided below:



WHERE &L_EMP and emp.emp_no = edept.emp_no and edept.dept_no = dept.dept_no

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. The capability to allow users to optionally enter 5

employee names. 2. The logic to interpret the emp_name fields.


3. A call to the reporting library. 4. 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 Datatype + Length Argument

P_EMP VARCHAR2(20) NULLP_COL VARCHAR2(20) NULLP_OUT VARCHAR2(100) NULLL_EMP VARCHAR2(100) NULL

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 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.

FUNCTION TM$LIST(p_emp in varchar2, p_column in varchar2)RETURN VARCHAR2 ISp_out varchar2(100);

BEGIN

-- Handles NULL values for a parameter

if p_emp is null or p_emp = ‘NONE’ then p_out := '1=1';

-- Handles multiple values for given parameter

elsif instr(p_emp, ',')>0 then 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;

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 isbegin

:l_crew_list := TM$LIST(:p_emp,’emp.name’); return (TRUE);end;

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


“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].

d2k report layout

Documents