Why ADFbc Customizations are restricted to GLOBAL layer
By Vik Kumar on Apr 19, 2013
Fusion Extensibility Guide Section 10.2.2 Customizing the Artifacts mentions “All customizations for ADF business components must be done in the Global layer. View layer customizations can be made in any other layer except User”. You may wonder why such a restriction is necessary for ADFbc? To understand that we need to understand the life cycle of ADFbc first.
ADFbc Life Cycle
ADF Business components like View Objects are created using the wizards in the JDeveloper. The end result is a .xml file which stores the definition of the view object in the form of metadata. This metadata definition is then used by Definition Object classes of ADF like ViewDefImpl.java to create an instance at run time. Similarly, other ADFbc components have their definition objects instantiated in a similar manner at run time. Each of these definition objects is a complex structure holding the reference to other business objects like a view definition to entity definition, to view links to application module definitions etc. As an example ViewDefImpl has its members like private EntityReference mEOInfoRefs; which is an array of entity object references based on which the view object definition is created (at design time). This hierarchy defines the relationship between ADF objects in a similar manner from entity objects to entity association definition references and from application module definition reference to the view object definition references forming a complex graph.
At the application start-up, the metadata definitions for business objects are read from ADF libraries and then instantiated into java classes. This is done with the help of base definition objects (like ViewDefImpl.java) when java classes were not generated at the design time. If java classes were generated at design time like a <Name>VODefImpl.java then this subclass is used to populate the metadata definition at the run time instead. For the scalability, ADFbc considers that packaged definition objects will be shared by all the users across the application. The complexity of definition graph makes it difficult to reload a particular definition in the graph. This is because of the reason that it will be require to propagate the changes to all the associated objects referring the definition being reloaded.
Customization Aspect for ADFbc
Due to the sharing of the metadata definition references across the entire tenant it is not possible to reload the entire ADFbc at each customization layer and are hence loaded just once and continues to exist. Customizations are stored in the form of xml into the MDS repository and are fetched and merged to the higher level document based on the layer at which application is accessed. For Global Layer, the base document generated at design time in JDeveloper is used as a source to merge with the global layer customizations. As Global layer is the highest layer in the customization hierarchy and applies to entire application so this level of customization is merged at the time of loading the business components at the start up. So, this is the reason that customization for ADFbc could be supported only at this layer with no ability to reload. In JDeveloper the context menu option “Customize” is thus disabled for ADFbc objects if any other layer is selected except GLOBAL.
ADF UI layer on the other hand has self contained metadata objects and hence it is possible to reload at any layer without any overhead of dependencies. For example, if you customize a jsff or a jspx file in the UI layer then they do not have dependency on any associated definition implementation and can be reloaded any number of times being a jspx or jsff file. Unlike ADFbc objects there is no definition implementation for UI artifacts which need to be reinitialized.