Information for Each Content Item

Content managed by Oracle Content Server is primarily tracked by four tables: Revisions, Documents, DocMeta, and RevClasses. These tables track the content's metadata, state, and actions as well as information that is associated with each file.

Revisions

This table tracks core information of each revision of the content.

• One row per revision.
• Different revisions with same content share the same content ID and RevClass ID.
• System metadata for each revision:
  
  • Metadata for revisions: content ID, title, author, checkin date, and so on
  • Metadata for categorization and security: type, security group, doc account
• State information for various actions:
  
  • Indexing
  • Workflow
  • Document Conversion
• Numeric IDs and text labels to help track and retrieve a revision:
  
  • A unique dID per revision (the primary key in the table).
  • A unique dRevClassID per content.
  • A revision ID to mark the revision number for each revision.

Documents

This table tracks information for files that are associated with each content revision.

• One row per revision.
• Multiple rows per revision, one row for each of these files:
  
  • Primary
  • Alternate
  • WebViewable
• File information: original name, location, language, size, and so on

DocMeta

This table contains extended metadata fields.

• One row per revision.
• One column per metadata field.
• Definition for each field stored in the DocMetaDefinition table.

RevClasses

This table tracks information for each content revision.

• One row per content item.
• Row locked for content modification.
• A unique dDocName and RevClassId.
• Current indexed revision.
• Tracks date and user:
  
  • Creation date and creator
  • Last modified date and user
  • Owner

Webcenter Content User Table

Today when I logged in my Content Server, I was abashed by an error, stated below:

Unable to load the user information. Possible database connection failure encountered. Error message: (!csDbUnableToCreateResultSet,Quser(SELECT * FROM Users WHERE LOWER(dName) = LOWER('weblogic'))!$Closed Connection). java.sql.SQLRecoverableException: Closed Connection.

This error enlightened me with the User table which stores all the Content servers user details. This table is associated with 'User' Admin Applet in Content Server. It shows all data but password. Password is stored as Asterisk sign.

The cause of above error may be- DB is shutdown or the listener is not up and running. 

I checked my db and it was up so I bounced the server. The error went away. :)

SOLVED: Google chrome issue with Oracle WebCenter Content- Unresponsive, Kill pages, Hangs, Loading...

Google Chrome is very clever, fast and responsive browser. It has customer rich extensions and themes. It also provides vast developer investigation tool. All these features makes it excellent browser. 

Google Chrome has shown incredible performance but there is one pathetic issue which made many users sad. It is unresponsiveness of browser page in many situations, it ask for 'Wait' or 'Kill'. Many blogs and suggestions talk about it but there is not common fix for it. 

We faced this issue while working on SSXA application with Oracle WebCenter - Content as content server. Whenever we were launching contribution mode, we were facing the issue. On the other side, IE and Firefox were working fine. 

We worked hard and tried many fixes but nothing was working. One of our developer pointed out its style sheet which is causing the issue. We analyzed our css thoroughly but didn't get anything. Actually complete css was not working but if we divide the complete css in blocks then each block was working fine separately. It was bad time indeed. 

Later a week we identified the relative path that we have used for css was causing the issue. We replaced the relative path with absolute path. So we concluded that Google Chrome browser spend much time in parsing while we have relative urls.

For Quick reading for developer:
Please replace relative urls by absolute urls. 

dID Vs dDocName or Content ID

Below is the small concept although a very important one. Many beginners are confused with two important metadata fields. Here is the brief description. 

dDocName or Content ID is the unique identifier for a content revision set. 

dID is the unique identifier of each individual content revision within a set.

Being able to identify a content revision set is very useful, as it shows and tracks (makes auditable) the changes of content items over time.

Being able to identify each individual revision with dID is also very useful, so we can work with specific content revisions. This is one of the great advantages of the Content Server over other systems, which only store the changes between revisions. Full revision sets as well as individual revisions are managed objects and each one can be accessed by its own unique URL.

Cache Problem in WebCenter- Content (UCM) and SSXA

I was thinking to restart the series of blogs on Webcenter – Content (prior UCM, Stellent) from long. I will start with the basic problem that we face in content server i.e. Cache.  

The case study belongs to a Site studio External Application (SSXA) Project.

My team member was working on one assignment where she had to update some taxonomy values via Content Server. She had made all the changes but she didn’t get new values in application although new values were reflecting in DocMeta table. So she bounced the Content Server then she got the new values. She was happy!!

Here comes the situation, we can’t bounce the production server daily or weekly for this purpose. So we need to have some mechanism which can reflect our changes without bouncing Server. Here are some options:

1.    1. Content Server Cache:

This feature is very important. There might be a case when you see new data in table or view but it doesn’t reflect in Content Server forms like in dropdowns, list of values etc. In such cases, you try publishing schema explicitly. This populates new data changes in Content Server forms.

  

2. Site Studio External Application Cache:

When we work on Site Studio External Application (SSXA) then such problems come frequently. This problem is associated with above case, so you need to be sure that changed values are coming in Content Server first then you can proceed for Site Studio External Application. We can use Clear Entire Cache option for Site Studio External Applications. 

3. Site Studio External Application Cache via browser:

There is one more trick that you can apply if above both options didn’t work. Sometimes we send a request to Content Server to clear the cache and it responses with new values. We use refresh_cache parameter in this situation. You need to write complete application path and append ?refresh_cache=true at the end. This will load your page with some delay but it works well.

Example: http://gkquestions_application_rocks.us.com/index.html?refresh_cache=true