Wednesday, September 18, 2019

Personalization in Fusion - SandBox


Personalization In Fusion – Part I




Introduction:

Acknowledge the potential of the customization options in the Fusion Cloud Platform. Explore the elaborate details. Learn the importance of customization and how one can utilize it to enjoy the benefits of the platform. Utilize the various sets of layers available for customization on a particular task, instance, or users. 

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 at the site layer affect all users.
2.     User layer: All personalizations are made at 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 top layer. With the default customization layers, the user layer is the top layer. An object may be customized more than once but in different layers. At run time, the top-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 as 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.

Example:

For example, the Sales application has a layer for a 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:
      i.         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 will 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) or you can create your own sandbox by Clicking “Manage Sand Box” option available as shown below.


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



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

iii.        Selection of Customization Layer
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.




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:
a.             Pulls the corresponding XML file from the repository
b.            Layers it on top of the standard Sales home page
c.             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.

Personalization:

All users of the application can use the Personalization menu items to personalize certain pages.
For example, you can:
a.             Move elements around on a page
b.            Hide elements
c.             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 will have 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 personalization’s, thus enabling the user to see the personalization changes along with the Sales Representative Changes.


Exiting SandBox:

Users can Click on SandBox name and then click on Exit Sandbox to exit from SandBox as shown in the below screen.





No comments:

Post a Comment