3 The WebCenter Sites Development Process

In WebCenter Sites, you design two sites: a content management site(s) that the content contributors use to add and update information, and an online site that is delivered to visitors' browsers from your delivery system. Content contributors publish the online site from the management system to the delivery system.

So you are responsible for the user experience of two sets of end users:

  • The site visitors who use your delivery system.

  • The content providers who use the management system.

When creating these two closely connected yet separate sites, the development team performs a series of planning, development, and testing steps. This chapter describes the development process in one possible sequence of events and in very general terms. Your own workflow will vary based on your work environment and business needs.

Topics:

Step 1: Set Up the Team

People with a variety of skillsets collaborate to assemble a site in WebCenter Sites. Some people design the site, some code various elements, some manage content, and so on.

  • Solution architects (site designers)

  • XML and JSP developers

  • Java application developers

  • Database administrators

  • System network administrators

  • Marketers and advertising staff

  • Product managers (if you are developing a commerce site)

  • Content providers

You need people such as DBAs, system administrators, and content providers on your development team in addition to the people (like you) who do the actual coding for several reasons:

  • You need to design a data model in addition to creating a page design, which means that you need early input from the DBAs who will be supporting the databases on each system.

  • Code and data need to move around on multiple separate systems, several of which are probably clustered, which means you need early input from system and network administrators.

  • Implementing a WebCenter Sites system is dependant on the work habits of your content providers being accurately reflected in the design of the management system. You need early input from those who will use the management system.

Step 2: Create Functional and Design Specifications

An online site delivered from an Oracle WebCenter Sites content management system is a holistic construct in which everything interacts, intersects, and works with everything else. So, you need to create a functional specification and a design specification (to design your online site on paper).

You should accomplish some pieces of this task before you begin coding anything (although you might do some proof-of-concept coding while working on the design specification).

Functional Requirements

Before you can begin a design specification, product management and marketing must provide the functional requirements for the online site.

Page Design

After you obtain the functional requirements from your marketing folks, a good place to start is to map out all the types of pages that you want to present on the online site. For example, home page, section page, columnist page, search page, article page, and so on. To design a commerce site you will need other kinds of pages: registration page, product category pages, product description page, article page, FAQ page, invoice page, and so on.

Determine the graphical, navigational, and functional features for each page and the site overall: navigation bars, buy buttons and shopping carts, tell me more buttons, search functions, logo placement, animated graphics, and so on.

If you are using Oracle WebCenter Sites: Engage, decide where the merchandising messages (recommendations) are to be placed on the pages and on which pages they'll be placed. For example, each product category page may include a New Products section in the upper-right corner of the page.

Map out the entire structure of the site and create mock-ups.

Caching Strategy

One of the major elements in your design is caching: page caching and resultset caching. No online site can reach performance goals without you planning, testing, and implementing a caching strategy. While designing the pages that you want to present on your online site, you must consider how and when page caching can and should be implemented for each piece on each page. While designing your queries, you must map out all the tables in the database and determine how the resultset caching settings should be set for each table.

Security Strategy (Access Control)

You must determine what kinds of access control you want to enforce early in the design process so that you design your pages correctly. For example, requiring your visitors to identify themselves before they are allowed to access any part of your online site. The requirement to check visitors' identities before allowing them access to a page affects how you would cache the components of that page. You could design a container page, which is never cached. This page verifies the identity of the visitor and then assembles the page from cached pagelets only if the verification is successful.

Separate Format from Content (Elements from Assets)

Following the basic proposition of separating content from format, take a look at each piece of each proposed page in your site and determine whether that piece should be represented as data or as logic.

A good design is one in which data is designed to be represented as an asset and is not embedded into element code. Examine every component of design or content, and then determine what your assets are. You make that determination by deciding which category a component belongs to: data or logic/code.

Simply speaking, do not code something into an element (embed it in logic) if it is really data. Data should be in a separate asset.

Here's another way to look at it:

  • Assets that represent content are the responsibility of content providers.

  • Logic, anything coded into any element, is the responsibility of the developers.

Determine the Asset Types (Content)

Documents, articles, products, and images are easily identified as assets. However, design components such as headers and footers could also be assets:

  • When the content in a header or footer is embedded in the code of an element, you or another developer has to change the text in it when anything in it changes (a phone number, a logo, and so on).

  • When the content in a header or footer is in an asset, the code in your elements must be able to obtain the identity of the asset. Its content becomes the responsibility of a content provider.

Other page components that can be assets include the following:

  • Animation and other media

  • Quote of the day

  • Company or stock profiles

  • Knowledgebase questions and answers

From your point of view, someone else is responsible for a component's content which is represented in an asset. You are only responsible for when and where it displays on your online sites and what it looks like when it displays there.

Decide How to Handle Images and Other Blobs

You have two general options when deciding how to manage the images and other blobs that you want to use in your online site:

  • Treat them as assets: Store them in the WebCenter Sites database and have the BlobServer servlet serve them.

  • Treat them as static files: Put them in a file structure on your web server and let the web server serve them.

Either method is a valid option. You can create links to image files stored on the web server with the WebCenter Sites tags. There may be performance benefits when you allow your web server to deliver your images. However, if you keep your images and blobs separate from the WebCenter Sites database:

  • You must implement a separate file management process. The publishing methods that move image assets from your management system to your delivery system cannot move content that is not in the WebCenter Sites database. You must manage this process on your own.

  • None of the native WebCenter Sites security mechanisms will apply. That is, you cannot use ACLs to limit access to blobs that are not managed by WebCenter Sites.

Map Out the Functional Design and Format (Elements)

Analyze all of the functionality that you plan to incorporate into your online site. Parts of a commerce site will no doubt behave more like an application. Outline what code or logic is required for your visitor registration pages, visitor data collection pages, shopping carts, personalization, and so on.

Remember that your WebCenter Sites system provides you with coding options: Java, XML, and JSP. As you look at each of the functions you want to provide, determine which is the best coding solution for that function.

Data Design

Once you know which pieces of your site should be represented as assets, you can map out what your asset types should be. Each new asset type will use one or more database tables (depending on whether it is a basic or flex asset type).

Asset Types

No matter which asset model you are using, basic or flex, consider the following when you design your asset types:

  • Asset type design affects both of the user groups that you are designing for (visitors to the online site and the content providers who enter the data).

  • Which types of assets have to be linked or related to other assets of other types to successfully implement your page design? Be sure to implement these relationships in the asset type.

  • Be sure that your asset types store only the data that you really plan to use so that content providers do not waste time maintaining data that no one uses.

Auxiliary Tables That Support Your Asset Types

The data design that you want to implement for your system extends beyond the database tables that hold your assets. Depending on the kinds of information that you want to provide, you might have to create auxiliary tables that support your asset types. For example, in a site that has asset types with a Mimetype drop-down list, a user must select a value from this list. You could create a lookup table named MimeType and pull these values from this table. Depending on your needs, you might have to create similar tables for your system.

Your DBAs should be involved in your discussions about the asset types and auxiliary tables that you plan to create so they can understand from the start the kind of database tuning issues that might arise on the management and delivery systems.

Visitor Data

If you are using Engage, determine what kinds of visitor data will be gathered. These data types are represented by the Engage visitor data assets that you use to create segments for personalizing your site based on the identity of the visitor. For example, demographics, purchase history, or clickstream information.

After your WebCenter Sites system goes live and starts collecting visitor data, the tables that store that data grow very quickly. This is another area that you have to consult your DBAs about.

Step 3: Set Management System Requirements

Don't yet begin coding. Think about how the management system should be organized. Keep in mind that the design depends on the content management site.

A content management site is an object that you use as an organizational construct for an actual online site and as an access control tool. When you create Template assets, WebCenter Sites creates an entry in the SiteCatalog table. The naming convention for the page entries includes the name of the content management site that you are creating the Template for. This means that you must be consistent with site names throughout your entire content management system (development system, management system, and delivery system), and you must know the names of the sites that you are using before you begin coding.

Although your primary concern is the name of each site, the system administrators and business managers must also determine the following:

  • How many users and ACLs (access control lists) do you need? (Remember that you may have to create ACLs to assign to the visitors of the online site, as well.)

  • How many site roles you do you need?

  • Which asset types need a workflow process?

  • Which asset types should use revision tracking?

  • Who should have access to which asset types on which sites?

Use both this guide and Administering Oracle WebCenter Sites to help you make these decisions.

Step 4: Implement the Data Design

You’ve created the design specification, and you understand how the management system is organized. So, it’s time for you to implement the data design.

On the development system, you complete tasks such as these:

This step and Step 5: Build the Online Site are iterative and will most likely overlap a great deal. While you create asset types so that you can create assets before you create templates for them, it is likely that you will uncover areas that need refinement in your data design only after you have coded a template and tested the code.

Step 5: Build the Online Site

As soon as you've created your design specification, you can begin coding elements that do not display assets. And, to start coding templates and building the online site all you need is the sample assets of one type.

In this step, you complete tasks such as these:

See Website Development with Tag Technologies.

Step 6: Set Up the Management System

After your online site becomes functional on the development system, it’s ready to move to the management system.

The developers complete the following task:

  • Publish the content management site and all its components to the management system. See Working with RealTime Publishing in Administering Oracle WebCenter Sites.

The system administrators then complete the following kinds of tasks:

For information about setting up the management system, see Administering Oracle WebCenter Sites.

Import Content as Assets

It is likely that you have content in some non-asset format that you want to use. To import this content into the WebCenter Sites database as assets, use the XMLPost utility. See About Importing Assets Using the XMLPost Utility.

Import Catalog Data and Flex Asset Data

For the flex asset model, you can import a large amount of pre-existing data with the BulkLoader utility. See Importing Flex Assets with the BulkLoader Utility. For systematic updates, however, you use the XMLPost utility. See Using the XMLPost Utility.

Instruct the Editorial Team About Site Design

Before the editorial team can successfully maintain the online site, they must understand your design. For example, how frequently are collections supposed to be rebuilt?

If you are using the basic asset model, content providers have to know the following:

  • Which categories and sources they should assign to their assets in order for their assets to be located by the appropriate queries and collections.

  • Which templates they should assign to which assets.

  • Which association fields must be filled out in order for the links on the site pages to function correctly.

It is a good idea to program as much of this information as possible into the start menu shortcuts that you and the system administrators create for each asset type.

If you are using the flex asset model, content providers have to know the following:

  • The general hierarchy or taxonomy in place for the flex assets.

  • Some information about what information a flex asset inherits.

  • Which templates they should assign to which assets.

Step 7: Set Up the Delivery System

You're ready to publish all assets on the management system to the delivery system as soon as you've set up the delivery system. Since the delivery system hosts the public-facing site, you don’t have to publish Start menus, workflows, revision tracking, and so on which you configured on the management system for content contributors and marketers.

On your delivery system, you need to also accomplish these tasks:

For information about setting up the delivery system, see the section on publishing in Administering Oracle WebCenter Sites.

Step 8: Publish to the Delivery System

Your content is published to the delivery system. Open your site to the public only after an intensive testing (both performance and load).

See Working with RealTime Publishing in Administering Oracle WebCenter Sites.