How to Update Metadata of documents through DB at UCM(webcenter Content) ?

let’s imagine the following scenario

you have different employee profile for different Document types of each employee such sanctions,vacations, services,certificate ,.. etc

and every UCM profile has 2 metadata “civil number of employee” , and ” employee name” and title which have specific signature as follow

“type of Documnet of ********** ” where the position of * is the civil number example “Vacations of 1235495689” vacations “document title” and the number represent the civil number

and the entry user forget to enter the civil number of employee and those documents are more than 700 document

sure you will not request from user to back to all those document and updates their metadata it’s time consuming and headache

we need to make workaround to get from title the civil number and update the missed civil number

to overcome via DB this problem we should have background about the UCM DB diagram specially the tables of Documents

the metadata of document spread through more than table as following

DOCUMENTS    contain basic data of document “metadata of slandered chick-in”

DOCUMENTHISTORY  contain history of document and life cycle from new to released

DOCMETA    contain metadata of document the customized one

REVISIONS  contain different versions of document

all those tables contain the DID column primary key at DOCUMENTS   table and represented as foreign key at remaining tables

we need to modify metadata so it will be available on  DOCMETA   table but at our case we will get the new value from another metadata -basic one- the DDOCTitle  metadata which represent the  document title

so we need to set the civil number to equal sub string from the document title “get the last 10 characters from title column”

where  r.did=dm.did

the previous SQL statement get all document with civil number null “have not civil number” and get also the civil number as substring from title field which belong to another table revision

we can get them by different method which will be ready for update statement as following

select  dm.XCIVILRECORDNUMBER ,(select  substr(R.DDOCTITLE,-10,10) from REVISIONS r  where r.did=dm.did) as newcivil

now let’s run our update statement as following
set dm.XCIVILRECORDNUMBER =(select  substr(R.DDOCTITLE,-10,10) from REVISIONS r  where r.did=dm.did and r.ddoctype !=’Document’)

the result will appear as following screenshot

18-08-2013 06-33-55 م



how to modifiy kernel parameters at redhat

at installation of webcenter content some checks failed like parameters of  kernel

Checking for hardnofiles=4096; hardnofiles=1024.    Failed <<<<
Checking for softnofiles=4096; softnofiles=1024.    Failed <<<<


cd /etc/security

vi limits.conf

add the following lines before the end of file and save and restart the system


change kernal paramters





What is the necessity of oracle record management(URM)?

URM is another amazing product from Oracle Shipped with oracle UCM product that are formally called Oracle webcenter Content now , at this post i am trying to focus on business needs and what is the necessity for URM

Oracle records management

The best way to understand the business need to the record management in general is to compare it to back-up software any back-up software that an IT department uses. The Back-up software is used to ensure the company can recover its data after a disaster “restore the missing information after disaster”

In contrast  records management software is used to ensure that content which must be kept for specific periods of time is indeed kept for that length of time.  It ensures that correct content is used throughout the organization and perhaps most importantly. It is responsible for ensuring that content is moved, approved for disposition by the correct people and eventually disposed of at the appropriate time.  This ultimately helps the company recover in the event of a legal disaster.

On the surface, keeping everything forever seems like the easy and right scenario for those needs, but there are several significant issues with that approach:

Lowering the cost of storage 

Saving everything forever can create significant storage cost.  It takes money to pay for both physical and electronic storage.  It takes money to pay for handling and management of the content items too.  Each time a box of old invoices is moved, more money and time are invested to maintain its existence.  Every square foot of storage space is purchased or leased, taxed and sometimes heated and cooled.  Likewise, every byte of data is stored, backed up and maintained on a hard drive somewhere.  Overall, there’s a larger than expected “hidden” cost associated with storing every piece of content the company owns regardless of whether the item is printed and stored in a file cabinet or whether it is stored electronically on a network.  As the number of content items increase, the cost of carrying those items increases.  keeping everything forever guarantees that a company’s cost of content will increase perpetually so there is a need for reducing content “disposition”.

Lowering the cost of discovery

We live in a litigious society.  Most companies of any size will at some point find themselves the target of legal action.  As part of the legal action the company will be required to produce documents for the discovery process. Imagine a single discovery request that will reviews 75 million pages of text during the previous three-year period, during the process of e-discovery, company must follow several steps, including

v  Collect

  • Collect content for discovery
  • Log and copy content

v  Prepare

  • Restore backups and data extraction, de duplicate
  • Organize documents by concept, keyword, batch, or other Methodology

v  Review

  • Have lawyers read through content to determine what is relevant to the case

v  Produce

  • Output data to a usable format such as PDF
  • Gather content for transmission to court and opposition

Those steps cost the company efforts, money, and time. so there is a need for “e-discovery mechanism”

Keeping content “keep everything forever”

In fact many companies simply “keep everything forever.” companies don’t have a tool to insure compliance across the organization, keeping everything forever quickly becomes the easiest and most often implemented The challenges of categorizing the content, finding it when needed and disposing of it at the right time simply require too much effort so there is a need for “retention policy”.

Delivering consistent “get the right document”

There may be different versions of the same document.  Imagine a manufacturing company and there may be assembly or installation instructions for a product. Perhaps an incorrect installation will fail to meet a specific government regulation.  In these cases it is critical that only the most recent installation instructions are used. 

Single and Federated Search

“Federation” is a term used to describe the process of providing a single point of contact/entry for searching multiple disparate data sources across applications and repositories throughout the enterprise

Expanding number of software systems holding important content so there is need for “single and federated search”.


What is the Oracle Universal Records Management(URM)?

Oracle Universal Records Management (URM)

1-enables you to apply records management policies and practices on content in remote repositories such as file systems, content management systems, and email archives.

2-enables you to apply records management practices to non-records content.

3-offers a scalable and flexible records and retention management system to consistently apply records and retention policies to all types of content, regardless of where the content resides.

4- provide a central policy engine that serves as the single source for all record schedules and retention policies, and can apply records management processes to non-records as well

5-allowing your organization to set retention policies on everyday business content.

The system leverages adapters to enforce the policies and schedules in each repository across an organization. The adapters facilitate federated search and discovery, litigation and audit holds, and content disposition and destruction from a central console. With this approach, managed content does not need to be moved to a central location for management—it can be managed “in place.”


  • Centralizes records and retention administration
  • Manages external applications and physical records using a distributed architecture
  • Provides “in-place” management of content
  • Manages file plans, policies, and business rules from a central console
  • Centralizes holds, dispositions, and discoveries
  • Maintains a catalog of all content
  • Provides audit trails and certificates of destruction

summary :

URM  is an enterprise-wide 5015.2  certified electronic and physical records management system. that  provides a single application that can be used to create and administer the information life cycle for both physical and electronic information,  and allows organizations to apply retention policies as well as legal discovery and holds to relevant content across the enterprise, from e-mail attachments and content stored in file servers to physical records in a warehouse. It also has a framework for extension to other repositories via adapters.

note :

the terms content and record are synonymous and are used interchangeably.

oracle autovue – UCM integration configurtion files

/home/oracle/Oracle/Middleware/user_projects/domains/PBAD_domain/ucm/cs/config/config.cfg                     –>SocketHostAddressSecurityFilter=||                    –>IntradocServerPort=4444 /home/oracle/Oracle/Middleware/user_projects/domains/user_domain/ucm/cs/custom/AutoVue/autovue_environment.cfg                    –>VueLinkHostName=                    –>VueLinkPort4HTTP=16200                    –>VueLinkContext=vueLink

/home/oracle/Oracle/Middleware/user_projects/domains/PBAD_domain/ucm/cs/custom/AutoVue/AutoVue.hda          classpath=$COMPONENT_DIR/classes;$WebLayoutDir/jsp/autovue/jvue.jar;$WebLayout Dir/jsp/autovue/jvue.jar;$IntradocDir/weblayout/jsp/autovue/jvue.jar;



deployed vueLink.war                     –>WEB-INF/web.xml (deployment descriptor for vueLink)

<init-param> <param-name>JVueServer</param-name> <param-value></param-value> </init-param> − <init-param> <param-name>Verbose</param-name> <param-value>0</param-value> </init-param> − <init-param> <param-name>DebugLevel</param-name> <param-value>0</param-value> </init-param> − <init-param> <param-name>EnableSSL</param-name> <param-value>false</param-value> </init-param>


<property name=”port”>4444</property> <property name=”host”></property>

confguring auto vue servlet on weblogic

If the AutoVue server will be accessed by clients outside a firewall, direct access non-standard ports (i.e. non-HTTP) are often blocked. To enable clients to access servers that are protected by firewalls, a servlet is provided to tunnel requests through the HTTP or HTTPS protocol. When tunneling is required, the AutoVue client encodes requests from the HTTP/HTTPS protocol and attempts to invoke the servlet on the specified server. The servlet decodes the parameters included in the request and forwards the request to the AutoVue server using a socket connection. The servlet also replies to the client machine using the same HTTP/HTTPS protocol.

Two changes are needed to configure the server.

A) Install the file vueservlet.jar into the Application server or Servlet engine. Follow the instructions provided with the Application server or Servlet engine.

Tunneling through J2EE-enabled Application Servers This section provides instructions for creating and deploying VueServlet for J2EE application servers. Creating a WAR File for VueServlet Complete the following instructions to create a WAR file for VueServlet. 1 Create a directory. Example: C:\csiwar 2 In the folder C:\csiwar, create a sub-directory WEB-INF. 3 In WEB-INF, create a directory lib: C:\csiwar\WEB-INF\lib 4 Copy vueservlet.jar to C:\csiwar\WEB-INF\lib. 5 Create a deployment descriptor. The deployment descriptor should be stored as a file named web.xml in the WEB-INF directory. • The following is the mandatory header for the web.xml document. It defines the document as an XML file and relates the file syntax to the DOCTYPE resource specified.

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web
Application 2.2//EN" "">

• Use the following code to specify the deployment descriptor needed to deploy the VueServlet.


The <servlet-name> parameter is how the Servlet is known within the XML file.

The <servlet-class> parameter is the fully qualified Java programming language class name of the Servlet. The <url-pattern> parameter is how the Servlet is referenced from a Universal Resource Indicator (URI).

Update hostname with the name of AutoVue server machine.

Note The parameter structure must follow the order in the DTD definition. For example, all <servlet>s must be defined before any <servlet-mapping>s can be specified. • Update hostname in web.xml with the name of AutoVue server machine.

6. To create the WAR file, use the “jar” utility from the JavaTM Development Kit distribution. If you are in the root directory you created for the WAR contents (C:\csiwar), use the following command: jar cvf VueServlet.war WEB-INF Now you can deploy VueServlet.war using any J2EE compliant application server or Web container.

7 After the VueServlet is deployed, to access the content, type the following into your web browser:


The <context> parameter can be set in the deployment phase or set automatically by the application server. Some application servers allow you to specify the context name, but generally the WAR file name is used as the context.

Steps to Deploy the WAR File 1 Launch the administrative console of your application server. 2 Select Install a new Web application. 3 Browse and select VueServlet.war. 4 Specify VueServlet for the context name. 5 Deploy VueServlet.war.

B) Update the Web pages that embed the AutoVue client to include the full URL of the Servlet (something like http://servername/servlet/VueServlet) as the JVUESERVER parameter.

The VueServlet supports two parameters: the JVueServer parameter and the Verbose parameter. The JVueServer parameter needs to be set to the hostname:port value used when starting the AutoVue server. By default, localhost:5099 is used and will work if you installed the AutoVue server on the same machine as the Web server.

You can specify more than one hostname:port separated by semi-colons ( ; ) for fail-over. In other words, if one machine is down the servlet will try the next machine. The Verbose parameter enables verbose output. Both parameters are optional. If JVueServer is not specified, it defaults to localhost:5099. The servlet assumes that AutoVue server is running on the same machine as the Web server and communicates through port 5099. If Verbose not specified, it defaults to False.