Beruflich Dokumente
Kultur Dokumente
Learning Points
OLTP design issues OLTP design philosophy An OLTP design methodology
BO4EBS
BO4EBS provides customized reporting solutions for Oracle E-Business Suite to clients The reporting solution includes universes, reports, tables, PL/SQL code whatever is necessary to meet the clients reporting needs All done for a fixed price
3 Types Of Classes
Main classes these are typically documents such as invoices, receipts and purchase orders Set up classes these are typically lists of how things are set up such as customers, suppliers and buyers General purpose classes these are classes that arent tied to a table such as objects for unions and WebI configuration
Class Naming
Each main and set up class should have an acronym, usually two or three letters which is at the end of every object and subclass with that class The names of main and set up classes should be in UPPER CASE and the name of all subclasses should be in mixed case Example main/set up class names PURCHASE ORDERS PO, CASH RECEIPTS CR, SUPPLIERS SUP Example subclass names Supplier PO, Cash Receipt Details CR, Supplier Sites SUP
Derived Tables
Derived tables should be given names that start with DT_ Only aliases of derived tables will be used for objects, conditions and joins Derived tables are laid out in a column at the bottom left of the universe The derived tables within the column are in alphabetical order.
Base Tables
Only aliases of base tables should be used for objects, conditions and joins Base tables should be laid out at the bottom of the universe Base tables should be in columns to the right of the derived tables For Oracle E-Business Suite, similar tables start with the same prefix (e.g. AP_, MTL_, PO_) Tables whose names start with the same prefix should be placed in the same column The columns should be laid out in alphabetical order of the prefix The tables within the column should be in alphabetical order.
2009 SAP BusinessObjects User Conference
Contexts
Each main/set up class should have its own context The name of the context should be the name of the class, except in mixed case and without the class acronym. Sometimes, there will be multiple contexts for a class, such as if there is a summary-level and detail-level context to provide better performance when only summary level information is needed. In that case, each context should be the name of the class in mixed case without the acronym and with the word "Summary" or "Detail" at the end.
Table Acronyms
The following rules are very specific to Oracle E-Business Suite The acronym should be the first letter of each word in the table name, except no "A" should be used if the table name ends in "_ALL". For example, the acronym for MTL_SYSTEM_ITEMS_B should be "msib If two tables used together have the same acronym, one table should use a small word instead of a letter. For example xeventtt should be used for XLA_EVENT_TYPES_TL if xett has already be used for XLA_ENTITY_TYPES_TL
Self-Joins
If there is a restriction that should be in the SQL for a query that applies to only one table, then that restriction should be added as a self-join to that table By doing this, the LOV for an object made from that table will be restricted to how it is used in the query.
Self-Join Example
An example of a self-join would be the restrictions on the FND_LOOKUP_VALUES table The po_fob_flv alias uses the FND_LOOKUP_VALUES table for the lookup value for the FOB_LOOKUP_CODE on the PO_HEADERS_ALL table The po_fob_flv alias has two self-joins: po_fob_flv.LOOKUP_TYPE='FOB' and po_fob_flv.VIEW_APPLICATION_ID=201 By creating the restrictions as self-join on the po_fob_flv alias, the LOV for an object from that table is restricted to only FOB lookups.
Examples Of Self-Joins
Object Naming
Names of all objects should be in mixed case Names should end with the acronym of the top-level class that contains them Names should be unique within the universe (exception: see List Of Values slide) An example object name is Currency Code GL
Coding Order
For a subject area, the set up classes should be built first For the main class, the set up classes should be reused For example, a universe for purchasing should have the set up classes created first buyers, locations, payment terms, suppliers When the PURCHASE ORDER PO class is created, aliases of the aliases for the set up classes should be created and the set up classes should be copied and pasted as subclasses of the PURCHASE ORDER PO class
Copying Main Classes Main classes should be copied to be subclasses in other main classes For example, the AP INVOICES API class should be copied and made into a AP Invoices PO class. Ditto for a Purchase Order API class These structure eliminates the double outer-join problem
Aggregate Awareness
Aggregate awareness is very useful for OLTP universes The main use is to make objects reusable when getting more details. For example, you could have a Journal Entry subclass of a General Ledger class that pulls journal entry information. That way, the user doesnt have to build a completely new query if he/she wants to see the journal entries behind a general ledger balance
List Of Values
Slow running list of values is a major blow to usability Many times, the default SQL for a list of values will result in the running of full table scan of large tables Therefore, liberally create custom lists of values
Contact Information
Phone: 214-924-6015 Email: dennis.disney@bo4ebs.com Feel free to email me questions and I will do my best to answer them I contribute regularly to BOB (www.forumtopics.com/busobj)
Questions
Ask away My background is Oracle E-Business Suite, but I will do my best to apply what I have learned to your OLTP
Thank you for participating Please remember to complete and return your evaluation form following this session.
SESSION CODE: 1009