Customization Primer

This chapter covers the following topics:

• Customization Overview
• Configuration
• Personalization
• Extensibility
• Interoperability

Customization Overview

The Oracle E-Business Suite has a layered architecture, where each layer encapsulates the maximum reusable set of features without creating dependencies on higher layers. Such architecture enhances reusability of functionality and makes possible global customizations. The task of customizing an Oracle application can fall into one of a few categories:

• Configuration: using pre-built features to fine-tune the application to match the business and deployment practices of a particular customer. Configuration examples:

  • Setup of a chart of accounts.

  • Setup of business groups or organizations.

  • Setup of logging and auditing profiles.

• Personalization: declaratively tailoring the user interface (UI) look-and-feel, layout or visibility of page content to suite a business need or a user preference. Personalization examples:

  • Tailor the color scheme of the UI.

  • Tailor the order in which table columns are displayed.

  • Tailor a query result.

• Extensibility: extending the functionality of an application, beyond what can be done through personalization. Extensibility examples:

  • Add new functional flows.

  • Extend or override existing functional flows.

  • Extend or override existing business logic.

• Interoperability: interfacing the Oracle E-Business Suite with third party applications and service providers. Interoperability examples:

  • Interface with a single sign on server.

  • Interface with a credit rating service.

  • Interface with a legacy application.

These customization categories aren't always clear cut. Certainly, in some cases, customization tasks can even span a couple of categories. This book is designed to give a high level perspective of the various customization categories, and discusses only those categories that OA Framework facilitates. References to other resources are provided, where other customization categories are discussed in more detail.

Configuration

Configurations exist almost in every layer and every application. Broadly, configurations can be classified into three classes, as follows:

Deployment Topology Configurations

Deployment topology configurations map closely to the hardware topography of a deployment and are mostly done through technology stack configuration parameters. Examples:

• Setting up the number of Java Virtual Machines (VM) to run on each application-tier server.

• Setting up the number of database connections.

• Setting up the JServ parameters.

Configurations under this category are documented in greater detail in each technology stack layer's respective administration manuals, which include the following:

• Oracle E-Business Suite Setup Guide

• Oracle E-Business Suite Maintenance Guide

• Oracle E-Business Suite Installation Guide: Using Rapid Install

• Oracle E-Business Suite Upgrade Guide

Global Functionality Configurations

Global functionality configurations cut across application families and are mostly done through shared technologies such as AOL (Application Object Library), TCA (Trading Community Architecture), Tasks, Notes, and so on. Examples:

• Setting up the multi-org hierarchy.

• Setting up the various party business relationships.

• Setting up various Profiles and Responsibilities.

Configurations under this category are documented in greater detail in the respective layer's implementation and administration manuals, which include the following:

• Oracle E-Business Suite Multiple Organizations Implementation Guide

• Oracle E-Business Suite Flexfields Guide

• Oracle E-Business Suite Setup Guide

• Oracle E-Business Suite Maintenance Guide

• Oracle E-Business Suite Security Guide

• Oracle Workflow Administrator's Guide

Application or Functional Area Configurations

Configurations associated with a particular functional area (such as accounting) or application. Examples:

• Setting up General Ledger chart of accounts.

• Setting up employee benefit packages.

• Setting up an online catalog.

Configurations under this category are documented in a greater detail in a respective application's implementation manual, grouped under:

• ERP product manuals

• CRM product manuals

Personalization

OA Framework was designed with durable personalization capabilities. Durability of OA Framework personalization is largely attributed to the declarative architecture and the object-oriented approach underlying the implementation. Declarative UI component definitions are stored in the form of meta-data in a database repository. Personalizations are translated into offsets from the base meta-data definition and stored separately. At runtime, the applicable personalizations meta-data is uploaded from the repository and layered over the base meta-data definition to produce the net effect. Product upgrades and patches affect only the base meta-data definition, so customer personalizations continue to function properly as applicable.

Personalization Levels

The built-in personalization UI facilitates a variety of personalization features at a number of different levels within the following user groups:

Oracle's In-House E-Business Suite Developer

• Seeded Function Level - like the Function Level available to Administrators (see the following section), but personalizations made at this level can only be changed or deleted by Oracle.

• Seeded User Level - like the User Level available to End Users (see the following section), but personalizations made at this level can only be changed or deleted by Oracle. (Also referred to as "Oracle-seeded user-level" personalizations.)

• Other seeded levels - Oracle E-Business Suite Developers can create and ship personalizations at any of the Administrator personalization levels discussed in the following section, but these are not protected against change and deletion by Administrators at the customer site.

For additional information, refer to Chapter 4: Implementing Specific UI Features: Personalizable Pages in the OA Framework Developer's Guide.

Oracle E-Business Suite Administrator

• Function Level - the customer administrator can define functions and use them as context for granular level personalizations. For example, you can create a function-level personalization to "hide the salary field, if the user is updating an employee record, but not when the user is creating a new employee".

• Industry Level - the customer administrator can use the delivered set of predefined industry categories to define personalizations according to vertical market distinctions.

  Seeded personalizations may be provided at this level, but customer administrators can also create their own admin-level Industry personalizations.

• Localization Level - the customer administrator can use locales as context for personalizations such as "showing a different address field label based on country settings".

• Site Level - the customer administrator can introduce global personalizations that affect all users with access to the given application component, such as "setting the number of rows shown in a table".

• Organization Level - the customer administrator can introduce personalizations that affect all users belonging to a particular organization or business unit with access to the application component. Example: "sort notifications by age for one organization and by urgency for another".

• Responsibility Level - the customer administrator can introduce personalizations that affect all users of a particular responsibility with access to the application component. Example: "show a trend graph for the sales manager responsibility".

• Seeded User Level - like the User Level available to End Users (see below), but personalizations made at this level are visible to all users and can only be changed or deleted by the customer administrator. (Also referred to as "admin-seeded user-level" personalizations.)

• Refer to Personalizing Your Pages and Portlets for additional information.

Oracle E-Business Suite User

• Application Users can resize or reorder columns of tables as well as save personalized searches of a query results region and retrieve them at a later time. User level personalizations aren't seen by other users.

• Refer to Personalizing Your Pages and Portlets for additional information.

Available Personalizations

The following administrator and end user personalizations are available:

Administrator Personalizations

• Change number of rows displayed in a table.

• Change product branding (image).

• Change region header icon.

• Hide or show regions and items.

• Change layout order of regions and items within the boundaries of the parent region.

• Include or exclude descriptive flexfield segments.

• Define up to three sorting levels for tabulated data.

• Filter (restrict querying of) tabular data.

• Change item labels and region headers.

• Change required state of non-mandatory items.

• Update allowed state for updateable items.

• Enable totals for table columns, when applicable.

• Alter the item cascading style sheet (CSS) - to personalize the look and feel of an item.

• Set a default value for an item.

• Define tips (in line instructions and usage help) for associated items.

• Add new items to an existing region. Typically, as part of an extensibility project, where new items are limited to specific styles.

• All administrator personalizations are visible to the end user.

• System Personalizations - in addition to the above, the following are some cross application personalizations facilitated by both OA Framework and Application Object Library:

  • Branding

  • Style sheets

  • Images

  • Responsibilities

  • Menus

  • Messages

  • Lookup Codes

  • Pre-packaged Flexfields

  • Customizing Look and Feel

End User Personalizations

Unlike Administrators, Users can create and save several personalized searches that can be retrieved conveniently at a later time. That said, end-user personalized saved searches are limited in scope to Query regions with search results tables. For these regions, end-users can personalize any of the following features:

• Change the number of rows displayed in a table.

• Hide or show regions and items (results table columns are a popular example).

• Change the layout order of regions and items within the boundaries of the parent region (order of results table columns are a popular example).

• Define up to three sorting levels for tabulated data.

• Filter (restrict query) tabular data.

• Change item labels and region headers.

• Enable totals for table columns, when applicable.

• Reorder and/or resize table columns.

Extensibility

OA Framework was designed with durable extensibility capabilities. Durability of OA Framework extensibility is largely attributed to the declarative architecture and the object-oriented approach underlying the implementation. The JDeveloper wizards and built-in personalization UI make it easier to extend the Oracle E-Business Suite. In addition, Oracle customers can take advantage of the extensibility offered by Flexfields (Oracle E-Business Suite Flexfields Guide) and Oracle Workflow (Oracle Workflow Administrator's Guide).

OA Framework extensibility is geared to enable customers to add new functionality and override or extend existing business logic beyond what can be accomplished via personalization. This includes the following extensibility scenarios:

• Adding new pages or complete flows.

• Adding a new attribute (i.e. field) to a prepackaged page.

• Extending attribute defaulting logic.

• Extending validation logic.

To understand how extensibility works, one must understand how OA Framework applications are built. Please refer to the following sections in the OA Framework Developer's Guide:

• Chapter 2: OA Framework Essentials: Anatomy of an OA Framework Page

• Chapter 3: Building an OA Framework Application: Implementing the Model

• Chapter 3: Building an OA Framework Application: Implementing the View

Extensibility is often observed in the UI, but implementation is mostly centered on the underlying business objects. The following diagram depicts the BC4J objects involved when extending an OA Framework application.

BC4J Objects in Extending an OA Framework Application

The first row of the diagram represents an exhaustive list of all possible objects a developer might create when creating an entity object. The first box illustrates that when creating an entity object, two files are generated: the meta-data definition XML file and the actual implementation Java class file. Entity Objects handle attribute level and record level validations. These validations often need to use other View Objects, called Validation View Objects (VVO). Validation View Objects are grouped under a Validation Application Module (VAM). Like Entity Objects, creating a VVO and a VAM generates a meta-data definition XML file and an implementation java class file for each object.

Finally, the Entity Object sometimes relies on a helping class to offer, among other services, a validation service optimized for usage by other Entity Objects. This helper class is called the Entity Expert and is linked to the Entity Object through an Entity Object property.

Note: The diagram illustrates a case in which all objects are extended, which is not always the case. In most of the situations, you may be satisfied with extending just a portion of these objects.

Caution: Never edit the base definition of an object or make a copy of a base object. Always extend the relevant object and use BC4J substitutions to reference the extended object.

For example, you may be satisfied with extending the Entity Expert to override a validation method such as isSupplierValid. In such a case, it is not wise to reference the extended Entity Expert (MyEntityExpert) directly from the base Entity Object (EntityEO.XML), as such an approach does not survive upgrades.

A durable approach requires extending the base Entity Object (using the JDeveloper Wizards) and updating the entity expert property on the extended Entity Object to point to the extended Entity Expert.

Interoperability

Implementing the Oracle E-Business Suite for established customers sometimes involves interfacing with legacy applications or third party services. Interoperability scenarios can be classified into three levels:

• Deployment Wide - these involve cross application services that can be interfaced transparently from the application. Example: integration with a single-signon server.

• Application Specific - these involve special interoperability features that the application is directly aware of. Example: integration between Oracle iPayment and credit card processors. These are documented in the respective application implementation manuals.

• Function Specific - these involve industry standards for publishing a variety of interfaces used to interoperate with third party applications and services. Such industry standards include Web Services, Enterprise Java Beans, MIME, and so on.

In addition to the above, the Oracle E-Business Suite technology stack is consolidating around the OA Framework technology stack. In the interim, some CRM applications are not migrated from the JTT technology stack. Instead, OA Framework has created interoperability solutions that allow for these technology stacks to coexist and facilitate a smooth user experience upon transition between technology stacks.