Best Practices from Oracle Development's A‑Team

Portal And Content - Content Integration - Best Practices


Lately we have seen an increase in projects that have failed to either get user friendly content integration or non satisfactory performance. Our intention is to mitigate any knowledge gap that our previous post might have left you with, therefore this post will repeat some recommendation or reference back to old useful post. Moreover this post will help you understand ground up how to design, architect and implement business enabled, responsive and performing portals with complex requirements on business centric information publishing.


Main Article

Design the Information Model

The key to successful portal deployments is Information modeling. Since this is a key task to understand the use case that you are designing for, the following is a set of question that should be asked of yourself or the customer:

Question: Who will own the content, IT or Business?
Answer: Business
Question: Who will publish the content, IT or Business?
Answer: Business
Question: Will there be multiple publishers?
Answer: Yes
Question: Are the publishers computer scientist?
Answer: No
Question: How often do the information changes, daily, weekly, monthly?
Answer: Daily, weekly

If the answers to the questions matches at least 2, then  ATEAM strongly recommends that you design your content with following principles:

  • Divide your pages into logical sections, where each section is marked with its purpose
  • Assign capabilities to each section, does it contain text, images, formatting and/or is it static and is populated through other contextual information
  • Select editor/design element type
    • WYSIWYG - Rich Text
    • Plain Text - non-format text
    • Image - Image object
    • Static List - static list of formatted information
    • Dynamic Data List - assembled information from multiple data files through CMIS query

The result of such design map could look like following below examples:


Based on the outcome of the required elements in the design column 3, you can now design a data model in WebCenter Content (Site Studio), by creating a Region Definition structure matching your design requirements.

For more information on how to create a Region definition see following post:
Region Definition Post - note see instruction 7 for details.

Each region definition can now be used to instantiate data files, a data file will hold the actual data for each element in the region definition. Another way you can see this is to compare the region definition as an extension to the metadata model in WebCenter Content for each data file item.

Design content templates

With a solid dependable information model we can now proceed to template creation and page design, in this phase focuses on how to place the content sections from the region definition on the page via a Content Presenter template. Remember by creating content presenter templates you will leverage the latest and most integrated technology WebCenter has to offer.  This phase is much easier since the you already have the information model and design wire-frames to base the logic on, however there is still few considerations to pay attention to:

  • Base the template on ADF and make only necessary exceptions to markup when required
  • Leverage ADF design components for Tabs, Accordions and other similar components, this way the design in the content published areas will comply with other design areas based on custom ADF task flows
  • There is no performance impact when using meta data or region definition based data

All data access regardless of type, metadata or xml data it can be accessed via the Content Presenter - Node. See below for applied examples on how to access data

  • Access metadata property from Document - #{node.propertyMap['myProp'].value}

myProp in this example can be for instance (dDocName, dDocTitle, xComments or any other available metadata)

  • Access element data from data file xml - #{node.propertyMap['[Region Definition Name]:[Element name]'].asTextHtml}

Region Definition Name is the expect region definition that the current data file is instantiating Element name is the element value you like to grab from the data file

I recommend you read following useful post on content template topic:

For more information on templates:

Internationalization Considerations

When integrating content assets via content presenter you by now probably understand that the content item/data file is wired to the page, what is also pretty common at this stage is that the content item/data file only support one language since its not practical or business friendly to mix that into a complex structure. Therefore you will be left with a very common dilemma that you will have to either build a complete new portal for each locale, which is not an good option! However with little bit of information modeling and clear naming convention this can be addressed.

Basically you can simply make sure that all content item/data file are named with a predictable naming convention like Content1_EN for the English rendition and Content1_ES for the Spanish rendition. This way through simple none complex customizations you will be able to dynamically switch the actual content item/data file just before rendering. By following proposed approach above you not only enable a simple mechanism for internationalized content you also preserve the functionality in the content presenter to support business accessible run-time publishing of information on existing and new pages.

I recommend you read following useful post on Internationalization topics: Internationalize with Content Presenter

Integrate with Review & Approval processes

Today the Review and approval functionality and configuration is based out of WebCenter Content - Criteria Workflows. Criteria Workflows uses the metadata of the checked in document to evaluate if the document is under any review/approval process. So for instance if a Criteria Workflow is configured to force any documents with Version = 2 or higher and Content Type is Instructions, any matching content item version on check in will now enter the workflow before getting released for general access.
Few things to consider when configuring Criteria Workflows:

  • Make sure to not trigger on version one for Content Items that are Data Files - if you trigger on version 1 you will not only approve an empty document you will also have a content presenter pointing to a none existing document - since the document will only be available after successful completion of the workflow
  • Approval workflows sometimes requires more complex criteria, the recommendation if that is the case is that the meta data triggering such criteria is automatically populated, this can be achieved through many approaches including Content Profiles

Criteria workflows are configured and managed in WebCenter Content Administration Applets where you can configure one or more workflows.  When you configured Criteria workflows the Content Presenter will support the editors with the approval process directly inline in the Contribution mode of the portal. In addition to the approve/reject and details of the task, the content presenter natively support the user to view the current and future version of the change he/she is approving.
See below for example:


Architectural recommendation

  • To support review and approval processes - minimize the amount of data files per page
  • Each CMIS query can consume significant time depending on the complexity of the query - minimize the amount of CMIS queries per page
  • Use Content Presenter Templates based on ADF - this way you minimize the design considerations and optimize the usage of caching
  • Implement the page in as few Data files as possible - simplifies publishing process, increases performance and simplifies release process
  • Named data file (node) or list of named nodes when integrating to pages increases performance vs. querying for data
  • Named data file (node) or list of named nodes when integrating to pages enables business centric page creation and publishing and reduces the need for IT department interaction


Just because one architectural decision solves a business problem, this does not mean that it is the right one.  When designing portals all architecture has to be in harmony and not impacting each other. For instance, the most technical complex solution is not always the best since it will most likely defeat the business accessibility, performance or both. Therefore the best approach is to first design for simplicity that even a non-technical user can operate. Consider the performance impact and finally look at the technology challenges.  Workaround these challenges first with out-of-the-box features.  Then design and develop functions to complement their short comings.

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Recent Content