Introduction

In this article we will try to unravel what is meant by Customization layer in context of Fusion Cloud Application and also try to understand how does customization layers ensure that the correct customizations or personalizations are available at run time to appropriate users.

There are built-in customization layers in your application to make customizations that affect only certain instances or users of an application. Before we create customizations, we should select the layer in which we want to customize. Most of the customization tools provide a dialog box for selecting the layer for your customizations.

Built-In Customization Layers

The customization layers available to an application depend on its application family. However, all applications have the following customization layers:

1. Site layer: Customizations made in the site layer affect all users.

2. User layer: All personalizations are made in the user layer. Users don't have to explicitly select this layer as it's automatically applied while personalizing the application.

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. With the default customization layers, the user layer is the tip layer. An object may be customized more than once, but in different layers. At run time, the tip-layer customizations take precedence. For example, say you customize in the site layer. You use Page Composer to add a region on a page. A user personalizes the same page to hide the region. In such a case, the user-layer customization takes precedence for that user at run time.

Storage of Customizations and Layer Information

Customizations 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 (MDS) repository. The XML file acts like a list of instructions that determines how the artifact looks or behaves in the application, based on the customization layer. The customization engine in MDS manages this process.

When you apply an application patch or upgrade, it updates the base artifacts, but it doesn't touch the customizations 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 need to redo your customizations.

Worked Example

For example, the Sales application has a layer for job role. When you customize an artifact, you can choose to make that customization available only to users with a specific role, for example, a sales representative.

We would not be making any changes to the pages but rather try to understand the effect customization layer has on a specific application page from a conceptual point of view.

Let’s say for this example we want to remove the Quick Create panel from the Sales home page, and customize this page only for users with the Sales Representative role.

The perquisites for this are as follows:

1. Availability of an Active Sandbox

We would need to activate a sandbox (shown below).

Login to Application with appropriate credentials (HCM_IMPL in this case)

Click on ‘Customize Pages’ link 

A popup message box would appear stating that a Sandbox must be activated to perform customizations

Next, we need to click on the ‘Activate Sandbox’ button, choose one of the available sandboxes (which would appear on a new popup window and choose the ‘Active’ button)

The sandbox will be activated (horizontal strip would appear on top of the screen with the name of the sandbox mentioned)

2. Appropriate Job Role

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

3. Selection of Customization Layer

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

5. Note: HCM_IMPL does not has the Sales Administrator Job Role attached with the user and hence not displayed.

So these three are the perquisites for this example.

The customization engine in MDS then stores the XML file in an MDS repository.

When someone signs in and requests an artifact, the customization engine in MDS checks the repository for XML files matching the artifact and the given context. On matching, the customization 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 customization engine in MDS:

1. Pulls the corresponding XML file from the repository

2. Layers it on top of the standard Sales home page

3. Removes the panel

Without the role of Sales Representative signs in, the customization 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.

Diagrammatic Representation

Personalization

All users of the application can use the Personalization menu items to personalize certain pages.

For example, you can:

1. Move elements around on a page

2. Hide elements

3. Add available elements to a page

While you personalize a page, the customization engine in MDS 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 customization engine in MDS:

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

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

When other sales representative login they don’t see the user 1 personalization changes (as shown below)

Ashish Harbhajanka

Add comment