WebCenter Sites and WebCenter Content Integration

WebCenter Sites and WebCenter Content Integration

 

Overview

WebCenter Sites is a great tool for business users and marketers to easily manage their Web Experience. WebCenter Content allows consolidation of all enterprise documents and digital assets in a single repository. Its transformation engine easily creates different renditions of the documents and images. As enterprise standard, it is recommended that clients use WC Content as their enterprise repository for all documents, images, videos and digital assets, and they use WC Sites to manage Web Experiences for all sites.

WC Sites Content Connector tool automates the process of pulling the documents from WC Content into WC Sites. The documents and digital assets should be created, edited, work-flowed, and approved in WC Content. The approved documents and digital assets, along with their meta-data are pulled from WC Content as assets in WebCenter Sites. If the document and digital assets have different renditions, they can also be pulled into WebCenter Sites. WC Sites Content Integration is designed to synchronize content from WebCenter Content to WebCenter Sites – documents and digital assets, including images and videos – as native files, renditions, and HTML conversions. Renditions can be created by the core transformation engine or Digital Asset Manager, depending on the type of native file and which renditions are required. HTML conversions are generated by Dynamic Converter. File formats are unlimited.

When it runs for the first time, the WC Sites Content connector imports the latest released versions of native files, renditions, conversions, metadata, or combinations of them into WebCenter Sites. Connector rules and the mappings you specify decide which content it imports.

If the content items are then modified on WebCenter Content, the connector synchronizes them to WebCenter Sites in its next session. Updated content items are re-imported into WebCenter Sites, and deleted content items have their counterpart assets deleted from WebCenter Sites (unless dependencies on those assets were created since the last synchronization session). Import and synchronization can be triggered manually, or they can be scheduled to run on a timed basis.

Synchronization is always unidirectional, from WebCenter Content to WebCenter Sites. WC Sites Content Integration supports a many-to-one client-server model. Any number of WebCenter Sites clients can be connected to a single WebCenter Content instance.

 

Use Case

WC Sites Content Connector was designed for the use case where documents, images and digital assets are created, edited, managed and approved in WC Content, but they are rendered from WC Sites. The documents from WC Content are pulled over and assets are created in Sites.

However, there are many times when clients do not want to pull the documents from WC Content in to WC Sites. This may be due to following reasons:

  • Extra Storage If large quantities of documents need to be pulled from WC Content in to WC Sites, they are duplicated in WC Sites. Moreover, WC Sites has multiple environments, like Authoring/Editorial, QA, Delivery etc. This means the documents needs to be copied to two or three environments. Some clients do not want the extra storage required to duplicate the documents two or three times.
  • Publish Times Publishing documents adds to the publish time. If a client has tens of thousands or hundreds of thousands of documents, it needs to plan to initially pull all the documents from WC Content into WC Sites. Subsequently, depending on how many documents are to be published on a regular basis, they may need to plan for extra time accordingly.
  • Multiple Sources of Documents Recommended best practice is to make WC Content as the master source for all enterprise documents. The documents should be edited and maintained only in WC Content. But, if the documents are pulled from WC Content into WC Sites, it opens the possibility that someone will download the document from WC Sites, edit it and upload it back into WC Sites.

Thus there is a case where the client does not want to pull the document from WC Content into WC Sites, but only wants to pull the meta-data associated with the document. Using the meta data, the client should be able to make a link to the document, and link it to any page on the web site.

 

 

 

Setting-up WC Sites Content Connector for Meta-Data Only

WC Sites Content Connector document says that meta-data along with document and the required renditions will be pulled from WC Content. However, it is possible to pull only the meta-data and not the documents, as shown below. In the screens shown below, I am working with the AVISports site released with WC Sites.

 

STEP 1. Asset Definition

 

Create an asset definition, that does not have a blob attribute required to hold the document.

I have created a new AVIArticle Definition called wcDoc. You will notice that wcDoc definition does not have any blob attribute, required to hold a document.

 

SiteConnector1

 

 

Step 2: Configure WC Sites Connector for only Meta-Data

In the screen below, I have added a new rendition called WC MetaData, and removed the Primary & Web default renditions.

 

SiteConnector2

 

STEP 3: Setup Rules

Setup the rules for pulling the documents from WC Content. Give it a name, and define the rules and target.

 

Specify name for the given rule:

SiteContent3A

 

Specify rules for selecting Content Items from WC Content

SitesConnector3

 

Specify the target (Site name) in WC Site

SitesConnector4

 

STEP 4: Define Attributes

While defining the attributes, do not pull the document itself. You must include the URL for the document. The document URL is not a default attribute that can be pulled from in WC Content into WC Sites. However, WC Content Admin can easily expose this attribute so it can be pulled from Content into Sites. In the screen below, I am pulling xAbsoluteURL from WC Content and mapping it to docURL attribute in wcDoc assets on WC Sites.

 

Define attributes to be loaded:

SitesConnector5

 

That is all you need to do the setup. Next time when Connector is run, it will pull the meta-data for the document, including its URL, but will not pull the physical document into WC Sites.

 

Here is the asset inspection screen on WC Sites, showing the meta-data and the URL for the document pulled form WC Content.

SitesConnector6

 

Rendering the document from WC Content

If the document is not pulled from WC Content, but only the meta-data along with its URL is pulled, the document from WC Content can be rendered in the following ways:

1)      Use the URL One can make a link to the document using the URL from WC Content. Using this link the document can directly be rendered from WC Content.
2)      Use a proxy However in many cases, WC Content may be behind a fire-wall and not easily accessible from internet. In such cases one can setup a proxy outside of the firewall that will connect to WC Content and render the document.
3)      Secure Document Servlet Documents in WC Content are secure, and may have access rules regarding who can see the documents. In such cases, it is best to write a simple document servlet to render the document. The links from WC Sites should be to this document servlet. The document servlet should pass the username and authentication information about the user to WC Content, read the document from WC Content using the GET_FILE service APIs, and render it on the site. It is not advisable to directly render this document from WC Sites template, as that will have performance implication on WC Sites. It is best to do it from a separate servlet.
 

 

 

 

Comments

  1. Marco Moraes says:

    Great and clear article!

    The only thing that was not clear for me is how can the xAbsoluteURL metadata field be automatically populated with the WebLayout URL for the document…

    Can you please provide any insight on how to do that?

    Thanks!

    Marco.

    • Vivek Singh says:

      Marco,

      I am not a WebCenter Content architect, so I consulted a WebCenter Content architect for this. Below, I am giving the reply I received from him.If this does not answer your question, please contact a WebCenter Content architect.

      “The best place to do this would be in a WebCenter Content Java Filter hook that is fired after the WebLayout URL has been calculated through FileStoreProvider logic that is part of computing the WebLayOut path for a given content item and before indexing of the document is initiated. Which is the best Java Filter hook to implement can vary based on different things like.

      · Underlying Index Engine being used on WebCenter Content (ex: Database.Metadata, DataBase.FullText, Oracle Text Search) if hooking into to a filter that is fired during indexing

      · Whether FastCheckin is being used. FastCheckin bypasses indexing so wiring into an indexing filter hook will not get fired if FastCheckin is being used

      · Whether the xAbsoluteUrl metadata field was configured to be searchable. If it is not then having the data populated into the xAbsoluteURL metadata field before indexing would be less of a factor

      A couple of extra points of consideration here. Typically I would not see that the xAbsouteURL metadata field would need to be configured as searchable but the need for this to be searchable could vary by environment and implementation based on requirements and use cases. Any java Filter Hook that is implemented to handle the auto population of the xAbsoluteURL metadata field is going to be after the custom metadata for the content item being checked in has been inserted/persisted into the DocMeta table so an update to the row in the DocMeta table for the content item being checked in would be required in the process. Just raising this last point in case it comes up. Most people would likely be inclined to think that this type of thing could be done in a derived rule of a profile rule (global or otherwise) but derived profile rules are processed before FileStoreProvider logic is processed so the final WebLayout path to a content item has not been established during the processing of a derived rule in a document profile.”

  2. Thanks Vivek, appreciate the write-up. Could you also elaborate on the handling of web page content in a Webcenter Sites and WebCenter Content integration in two areas:
    1) Your article implies that web page content would be managed in Sites, though it would leverage WCC for digital assets. Can you also speak to the WCC “multi-site publishing” as a capability and where this implementation pattern would be desirable?
    2) Content organization structure — I imagine many would want to implement similar structures across WCS and WCC for authoring and publication governance. What are the best practices for harmonizing these structures across the platforms for internal workflows, and website navigation and search?

    Thanks,

    Mike Conant

    • Vivek Singh says:

      Michael,

      For point 1- Multi-Site publishing:

      I am not a WebCenter Content Architect, so I was not able to answer your queries directly. I consulted a WebCenter Content Architect, and am giving the response I received from him. If this does not answer your queries, please consult your WebCenter Content architect.

      “the concept of “multi-site publishing” in WebCenter content is more applicable to when WebCenter Content is being used for the WebContent Management delivery platform with Site Studio, and less applicable in this context of WebCenter Content being used as the enterprise content repository for Sites which is the Web Content publishing and delivery platform. If a given site is a multi-lingual site then you would want a custom metadata field in WebCenter Content that indicated the language dialect of the document and publish and map that locale/language based metadata field to Sites over the Connector and incorporate that into the publishing and distribution logic used in Sites for delivery.”

      For point 2 – Content Organization Structure: To a large extent the answer will depend on what do you need to achieve authoring and publication governance.

      In the model where WCC is being used for the Enterprise Content repository and Sites is being used as the delivery and publishing platform there may not be a need to have this harmonized as process for management of content are dis-joined from a workflow and search perspective (e.g. each has its own workflow and search functions) and the website navigation is entirely owned by WebCenter Sites as it is the rendering and delivery platform.

      If you need a direct mapping between the structures in WebCenter Content and hierarchy in WebCenetr Sites, it may not be possible in every case. In some cases, it may be possible to use WebCenter Sites Flex Assets to make a hierarchy similar to WebCenter Content’s structure. But this can be dangerous. As a best practice, you should make WebCenter Sites hierarchy keeping in mind its best practices and depict the relation ships of the parent & child assets.

Add Your Comment