1Overview

This chapter contains the following:

Overview of Application Configuration and Extension

While your application provides robust functionality as delivered, you can make changes to it, if necessary.

You can:

  • Configure: Change a standard (existing) artifact. For example, you can add an attribute to an existing business object or change what's displayed on a standard page.

  • Extend: Create a new artifact, such as a new object.

Both configurations and extensions are preserved when the application is updated to a newer release.

The basic scenarios for configurations and extensions are:

  • Run time configurations and extensions

  • Personalization

What You Can Change

You can configure and extend many aspects of the application, for example the user interface, business intelligence, and data model.

The application is built using a common data model. So, when you make an application change in one area, that change is available to all objects in the application. For example, if you add an attribute to an object, you can easily add that attribute to the:

  • Web-based view page

  • Associated mobile page

  • Associated reports

Generally, you use the same tools and processes to configure all applications. For more information on configuring business intelligence, see the Creating and Editing Analytics and Reports guides relevant to your products.

Runtime Configurations and Extensions

Examples of Runtime Configurations and Extensions

You can make configurations and extensions at runtime using browser-based composers and other tools. All users or a subset of users can view and use these configurations and extensions. If your role has an administrative privilege, you can access most runtime configuration tools to modify the user interface (UI), create and modify objects, and so on. Some configuration tools, such as Application Composer, are available only for specific product families.

Modifying the UI

To modify the UI, use:

  • The User Interface Text tool to edit text that appears on multiple pages. For example, you can change the term, "buyer" to "customer" if that is your preferred term, and the change affects all pages where the term is displayed.

  • The Appearance work area to change the look and feel of the application pages.

  • The Announcements work area to create, edit, and delete announcements displayed on the home page.

  • Page Composer to configure application pages for other users. For example, you can:

    • Add fields

    • Add validation

    • Change default content

    • Rearrange regions

    • Add external content

    • Save queries

Tip: In Page Composer, you can make changes using the WYSIWYG view. However, in some cases, you can also use the Source view.

Configuring Navigation

Use the Structure work area to configure the Navigator and springboard. On the Navigator, select Configuration > Structure.

Adding User-Defined Attributes to Business Components Using Flexfields

Most business components, except those in Oracle Engagement Cloud products, support using flexfields to add attributes to objects. Use flexfields to create your own attributes without programming. A flexfield captures data that is related to a specific purpose, such as information about job positions or inventory items. Each attribute is a segment of a flexfield, and corresponds to a reserved column in the application database.

Modifying Reports and Analytics

Predefined analyses, dashboards, and reports help in meeting business intelligence requirements. You can modify them to fit specific business needs, for example, change the layout.

For more information, see the Creating and Administering Analytics and Reports guides relevant to your products.

Managing Help

Use the Manage Help Content page to:

  • Add and edit help files in the application Help

  • Determine which help files to show in specific help windows

You can open the Manage Help Content page from any help window, or from the help site.

Note: You must have the appropriate job roles to add and edit help.

Tools for Configurations and Extensions

You can configure and extend your application to suit your business needs.

Choose an appropriate tool based on the types of configurations and extensions to make, such as:

  • Page modifications

  • Branding modifications

  • Object modifications

  • Security modifications

  • Business intelligence modifications

  • Help content management

Note: The following tables present only the key tasks for application changes, not all tasks.

Page Modifications

This table shows some types of modifications that you can make to pages, and the corresponding tools to use. You can modify only certain pages in Page Composer.

Modification Task Tool

Add, move, delete, show, or hide components on a page

Page Composer

Change a page layout

Page Composer

Create a site-level search for all users

Page Composer

Change a page title

Structure

Modify dialog box content

Page Composer

Modify attributes for a flexfield on a page

Page Composer

Change properties for user interface (UI) components on a standard page

Page Composer

Configure the UI Shell template

Page Composer

Update a text string wherever it appears across all pages

User Interface Text

Change the look and feel of application pages

Appearance page

Change the announcements on the home page

Announcements page

Branding Modifications

This table shows some types of modifications that you can make to use your own branding logo, and the corresponding tools to use.

Modification Task Tool

Configure the UI Shell template

Page Composer

Change the logo and application name in the UI

Appearance page

Change report layouts

Layout editor in the BI application or external applications such as Microsoft Word

Object Modifications

This table shows some types of modifications that you can make to objects, and the corresponding tools to use.

Modification Task Tool

Add an attribute to a business object using flexfields (not Oracle Engagement Cloud)

Setup and Maintenance work area

Add a business object page to the Navigator menu

Setup and Maintenance work area

Security Modifications

This table shows a security modification that you can make to objects, and the corresponding tool to use.

Modification Task Tool

Add data security to a custom object

Setup and Maintenance work area

Business Intelligence Modifications

This table shows some types of modifications that you can make to business intelligence (BI) analytics and reports, and the corresponding tools to use. For more information, see the Creating and Administering Analytics and Reports guides relevant to your products.

Modification Task Tool

Create report layout

Layout editor in the BI application or external applications such as Microsoft Word

Change report layouts

Layout editor in the BI application or external applications such as Microsoft Word

Create a report

The BI application

Modify analyses

Reports and Analytics work area or the BI application

Configure dashboards

The BI application

Help Content Management

This table shows some types of changes that you can make to help, and the corresponding tools to use.

Modification Task Tool

Modify text that is displayed when the user hovers over a button, link, icon, or tab title

Page Composer

Manage help files and determine the help links to show on help windows

Help windows or Applications Help

Simultaneously replace multiple occurrences of a word or phrase that appear in the embedded help

User Interface Text

Some product families have additional tools available for application changes, for example, Application Composer and Business Process Composer.

Personalization

Personalization refers to the changes that every user of the application can make to certain artifacts in the user interface (UI) at run time.

Note: Personalization changes remain for a user each time the user signs in to the application.

Personalization includes:

  • Changes based on how you use the UI, such as changing the width of a column in a table

  • Changes that you select to save, such as search parameters

  • Changes you make to the springboard and infolets

Context Layers

Overview of Context Layers

Use the built-in context layers in your application to make changes that affect only certain instances or users of an application. Before making application changes, select the layer in which you want to make changes. Most of the configuration tools provide a dialog box for selecting the layer for your changes. If the dialog box to select a layer doesn't appear before you make application changes, then by default your changes are made to the Site layer.

Available Layers

The context layers available to an application depend on its application family. However, all applications have the Site layer and User layer. Application changes made in the Site layer affect all users. Personalizations such as setting column size for a table or editing infolet titles are in the user layer.

Layer Hierarchy

The layers are applied in a hierarchy, and the highest layer in that hierarchy in the current context is considered the tip layer. An object may be modified more than once, but in different layers. At runtime, changes in layers closer to the tip layer take precedence. For example, say you make application changes in the Site layer. You use Page Composer to add a region on a page. Then you use a layer for a specific job role to hide the region. In such a case, the job role specific changes take precedence for a user of that job role at runtime.

Storage of Configurations and Layer Information

Configurations aren't saved to the base standard artifact. Instead, they're saved in Extensible Markup Language (XML) files for each layer. These files are stored in an Oracle Metadata Services repository. The XML file acts like a list of instructions that determines how the artifact looks or acts in the application, based on the context layer. The configuration engine in Oracle Metadata Services manages this process.

When you apply an application patch or upgrade, it updates the base artifacts, but it doesn't touch the configurations stored in XML files. The base artifact is replaced. Hence, when you run the application after the patch or upgrade, the XML files are layered on top of the new version. You don't have to redo your application changes.

Examples of Working with Context Layers

The following scenarios illustrate working with context layers to ensure that the correct configurations or personalizations are available at run time to appropriate users. For example, job role is a layer. When you modify an artifact, you can choose to make that application change available only to users with a specific role, for example, a sales representative.

Configuring Pages for Users with Specific Roles

You want to remove the Quick Create panel from the Sales home page, and configure this page only for users with the Sales Representative role.

Following are the prerequisites:

  • Activate a sandbox.

  • When you modify a page for a specific job role, that role must be assigned to you for you to test the application changes in the sandbox. Your security administrator can either assign the role to you directly, or make the role self requestable for you to add it from the resource directory.

  • Select the layer in which you want to make your application changes. In this case, select the role layer with the value, Sales Representative. While modifying pages, when you remove the panel from the page, an XML file is generated. This file contains instructions to remove the panel for the role layer, and only when the value is Sales Representative.

Note: The original page file remains untouched.

The configuration engine in Oracle Metadata Services then stores the XML file in the Oracle Metadata Services repository. When someone signs in and requests an artifact, the configuration engine in the metadata service checks the repository for XML files matching the artifact and the given context. On matching, the configuration engine layers the instructions on top of the base artifact.

In this example, whenever someone:

  • With the role of Sales Representative (the context) requests the Sales home page (the artifact), before the page is rendered, the configuration engine in Oracle Metadata Services:

    • Pulls the corresponding XML file from the repository

    • Layers it on top of the standard Sales home page

    • Removes the panel

  • Without the role of Sales Representative signs in, the configuration engine doesn't layer the XML file on top of the standard Sales home page. So, the Quick Create panel is displayed on the page.

This figure shows how the XML file with configurations is applied to the base document and is displayed only for a sales representative.

Application of XML files at run time to determine
visible application changes

Personalization

Users can personalize their home pages and infolets. For example, you can:

  • Personalize your home page content that you use to navigate in the application. Based on your requirements, you can show or hide the groups and page entries that appear on the home page.

  • Edit infolet titles and views, move them around, and show or hide specific infolets on an infolet page.

While you personalize a page, the configuration engine in Oracle Metadata Services creates an XML file specific to a user (in this case, you), for the User layer. For example, say User 1 (with the role of Sales Representative) personalizes the Sales home page. An XML file, noting the changes that the user made, is stored in the repository. When User 1 signs in, the configuration engine in the metadata services:

  • Pulls the XML file with the sales representative configurations from the repository, and layers the file on top of the standard Sales home page

  • Pulls the XML file with the User 1 personalizations, thus enabling the user to see the personalization changes along with the Sales Representative changes.

When other sales representatives sign in, they don't see the User 1 personalization changes, as shown in this figure.

Application of XML files at run time to determine
visible personalizations

Example of Using Context Layers in Application Changes

While making application changes, when you use the dialog box to select the context layer, you can also include lower layers to view the application changes from those layers.

The following scenarios explain what happens based on your selected layers. For these examples, the available layers are Site, Country, and Job Role.

What You See While Making Application Changes

Suppose you choose to:

  • Edit the Job Role layer and select Sales Representative as the value for that layer

  • Include the Country layer and select France as the value

Note: The Site layer is automatically included because it applies to everyone.

While modifying pages in Page Composer, you see changes that apply to sales representatives in France, based on:

  • What was defined for each layer

  • Which is the highest layer with application changes for a specific artifact

What Your Application Changes Apply to

No matter what you see while making application changes, your changes apply only to the selected layer for your changes, that is, Job Role. For example, say a field is hidden in the Site layer, but displayed in the Country layer for France. No changes exist for the field in the Job Role layer for sales representative. Since Country is higher than Site, you see the field displayed while modifying pages in Page Composer. However, if you choose to hide the field as part of your changes, then that change applies to the Job Role layer for sales representatives. Users with other job roles in France may still see the field. However, Job Role is higher than Country. So, no sales representatives in any country can see the field, unless a layer higher than Job Role applies to any of these users and has the field displayed.

Business Process Models

The application is based on business process models that map out business flows. When you configure and extend your application, for example to add new pages, you can use these models to help you plan. For diagrams of business process models, see Oracle Fusion Business Process Models (1542019.1) on My Oracle Support at https://support.oracle.com.

Business Process Modeling Levels

The business flows are presented in a five-level hierarchy: industry (L0), business process area (L1), business process (L2), activity (L3), and tasks (L4).

  • The hierarchy goes from a high-level, conceptual view to a low-level, application-specific view.

  • L1 through L3 are business-driven and don't depend on any specific implementation in the application.

  • L4 aligns with specific features and functionality in the application.

Business Process Models In the Application

The application is organized around these hierarchy levels and flows, which puts focus on the activities and tasks that you must perform. Several aspects of the application are influenced by, if not directly based on, the business process modeling levels. For example, the navigation, user interface, and parts of security are influenced by the business process modeling levels.