Customization Lifecycle Management: MDS Labels and Sandboxes

Metadata Services

As a quick reminder, the majority of Fusion Application customizations are stored in the Metadata Services (MDS) repository, a database of XML deltas applied to the shipped pages and code at run-time. This process is illustrated in the diagram below, showing how a base page has user context-sensitive personalizations and customizations applied before display.

Figure 1 – MDS flow from base document to unique user pages

Almost all Fusion Applications technologies that support customization use MDS, however the Layers that support the context against which they are applied might vary. For example page customizations can be stored against Job Role only in CRM and against Organization and Country in HCM. In contrast some customizations apply only at the global site level layer, such as for BPEL customizations.

Managing Groups of Customizations

Sandboxes are the UI exposure of a feature inside MDS known as Labels, and is the main method of grouping customizations to they can be administered together. Obviously it is recommended to use sandboxes to test your customizations before promoting (Publishing) them into the live system. This helps avoid any conflicts and interference with other work in the instance. As shown in Figure 2 below, users can easily switch between the sandboxes, making another active for their session, plus they can review those recently published.

Figure 2 – The Manage Sandboxes page, available from the Administration menu in Fusion Applications, with options to set as active, to open and manage the content, and to publish.

In addition, in the Page Composer tool the “Label and Save” button gives the customization a similar identifier so it can be managed. As a general rule it is better to avoid this fine-grained labeling, and to use the Sandboxes.

Whilst centered around the use of run-time customization via Page Composer and Application Composer, the functionality offered by the Manage Sandboxes screen above is also available to System Administrators via a selection of WebLogic Scripting Tool (WLST) commands. An example of this is the createMetadataLabel command which essentially creates a label just as a Sandbox does. More details can be found in the WLST Command Reference Guide. These type of options should be used for those design-time customizations which do not support Sandboxes, such as for SOA. Actually JDeveloper (for ADFbc customizations) does support MDS Labels and the existing list of Sandboxes should appear for use as part of the customization MAR deployment process.

Related to this is a Release 7 feature call Customization Set Migration. This will offer customizations done in SaaS environments to be exported as a group from one instance and then imported into another instance. Initially this will focus on UI customizations, however the plan for this to eventually incorporate all customization types thereby useful for on-premise deployment administrators also.

Backing Out Customizations

So whilst we’ve looked at deploying and viewing customizations in a group as a Sandbox/Label, sometimes you might need to remove a customization, such as if it conflicts with changes in the system usage and business needs. Indeed proactively managing (including culling) customizations is critical to effective lifecycle management, as mentioned in our introductory LCM post.

Really only unpublished Sandboxes can be administered and removed. This might be the user exiting the sandbox, deleting its individual contents, or just removing the entire sandbox itself. Once published things get more complex relying on generic MDS capabilities. These are explained by the following two documents:

  • From the Fusion Applications Administration Guide there are some details on the different MDS label types, not just those from page composer.
  • From the Fusion Applications Extensibility Guide, section 2.3.3 mentions backing out customizations either using the WLST command promoteMetadataLabel or for specific pages by changing the current active/published Sandbox using the online Customization Manager.

Customization Collisions

Where more than one sandbox exists, should customizations be made to the same page (or object) in more than one it can cause issues. Generally speaking the last published sandbox will overwrite anything before it, and for Page Composer the changes are usually safe, albeit perhaps frustrating. Obviously good management centers on communication (and perhaps some rules) and this is a case-in-point.

However once you start putting in customizations to Business Objects using Application Composer (or design-time ADFbc and BPM/BPEL customizations) then dependencies can cause more likelihood of a problem in MDS.

Other Recommendations and References

  • A good tip is that after activating your sandbox, you should always re-login to Oracle Fusion Applications, as it clears the cache and helps avoid conflicts.
  • In a multi-developer environment it is recommended to use your own personal user (private) sandboxes for ongoing development, and then as those features are ready to be published they are put into a global (integration) sandbox which is then published to the mainline application run-time on an regular agreed schedule. The development lifecycle section of the Extensibility Guide goes into multiple and sharing sandboxes in detail.
  • If you have Oracle Composer customizations that include deployed flexfields, ensure that you migrate those flexfields to the target environment prior to migrating UI customizations. The Flexfield Sandbox is not the same as the MDS Sandbox, and is for testing only without the same online publishing feature.
  • As per the export/import blog post, keeping an offline export of customizations makes sense, as the import is a quick way to reset to a known foundation when required. In addition, once published it is not possible to export again, therefore if migration to another instance is needed this step is essential.
  • Ensure source and target environments (e.g.Test and Production) are at the same patch level before migrating customizations. Check with your administrator or use the global Help menu in Fusion Applications and see details under the About Applications link.
  • For more troubleshooting tips see My Oracle Support Note 1484889.1 which has attached a whitepaper on  using Sandboxes for CRM customization. This contains many good examples, some troubleshooting tips at the end, and many universal best practices.


Post a Comment:
  • HTML Syntax: NOT allowed

Follow us on twitter Fusion Applications Extensibility, Customizations and Integration forum Fusion Applications Dev Relations YouTube Channel
This blog offers news, tips and information for developers building extensions, customizations and integrations for Oracle Fusion Applications.


« July 2016