WebCenter Sites Asset Modelling Tips

At some stage you may find yourself needing to design and implement an Asset Model in WebCenter Sites. This post will give you some basics to get you started.

There are two models for designing content types in WCS – the Basic Asset Model and the Flex Asset Model.

Basic Assets have been around since the first version of the product, but Flex Assets were introduced later as part of the Catalog Centre module which appeared with version 3 (I think, it was a long time ago). They were initially designed to implement product catalogs for e-commerce sites, but are now used to model just about everything.

These asset models determine how Content Server interacts with your content, down to a very basic level, such as how the content is stored in the database, and what tags are used to obtain data and render it.

In this post I’m going to give you information about these models and how to decide which of them to use in various scenarios.

Flex Family Approach

Flex assets and families give you a lot of cool functionality as well as scope to change things up when you’d like to.

You can create an organizational taxonomy of data with successive levels, and these taxonomies can be presented to the user via Tree Tabs.

Children inherit traits (attribute values) from their parents and grandparents. Attributes can be added/removed at any time without having to destroy the tables (see below…).

Additionally, Flex families introduced support for Multi-valued attributes, the ability to use Attribute Editors to style the input forms in any way you want (WYSIWYG editors, calendars, colour wheels, you name it) and the concept of Flex Filters which allow you to do post processing on your Attributes before saving them to the database (think image resizers or xml parsing).

However, all this functionality comes at a price.

Each family will contain more than 50 database tables, and any implementation is likely to have multiple families. Of course to retrieve the data you now have to do joins across a large number of those tables, so it has a performance impact.

There’s also a decision to make about how many tables to implement to actually store content assets. If you have only one content (_C) table per family, you can quickly find the table that stores the attribute values (called Mungo tables for reasons best known only to Engineering) becoming very large, requiring database partitioning and other tuning tactics.

When designing your Flex Family, keep in mind the following:

• Determine when to make an attribute single- or multi-valued
• Children can overwrite the value inherited from their parent(s), however the overwritten value is not deleted from the database
• How many values are inherited from parent to child, and likelihood of parents to be modified on a frequent basis.
• This is important and becomes a huge performance consideration because the parent values are actually stored against the child assets. So, if you have a parent with 10,000 children or grandchildren, and you modify the parent Attribute values, all those descendants will need to be updated in the database, which can be slow and resource intensive.
• You’ll generally need to use the “assetset:” JSP tags to access any Flex Assets

Using the Basic Asset Approach

Basic assets have a couple of advantages and a few drawbacks.

On the plus side they’re fast because each asset type is held in a single table, with each new instance being a single new row in the table, so you don’t have all the joins in queries you see when using flex assets.

On the other hand, there’s no idea of hierarchy, there’s no inheritance, and if you need to modify them by adding or removing a column, you’re out of luck – you have to export the data, destroy the asset type, recreate it with the new fields and reimport the data. So you want to make sure you get it right the first time.

With that in mind, Basic assets are good for data whose structure is unlikely to change and needs to be accessed quickly. The WCS Community product uses Basic Assets for its comment and review assets, and they’re also useful for reference data which is unlikely to change structure e.g. external product data and suppliers, or simple things like calendar data or colours.

When designing your Basic Assets, keep in mind the following:

• No hierarchy
• No inheritance
• One primary storage table per asset type
• Attributes correspond to columns
• Each new instance is a new row in the table
• Schema is fixed
• You’ll need to use the “asset:” JSP tags to access Basic Asset

In Summary

Both Asset Models come with their own benefits and drawbacks. While most implementations now use Flex Families for the majority of their Asset Modelling due to their ease of use and functionality, it’s always worth keeping Basic Assets in mind for specific tasks.