WebCenter Content - Instance Architecture

A common question is,  “Can I have a single WebCenter Content instance to serve my enterprise?”

First, an instance is defined as an installation of WebCenter Content (WCC) with a unique URL location, database, and file system.  All of these attributes are defined during the installation process.   Instances cannot share a database or a file system.[1]  A clustered install does not count as separate instances because they share the same URL, the same database, and the same file system.

This post also uses the term “application”.  The term application is used to define a WCC implementation scope that is targeted to a specific user community, line of business, or set of capabilities.  A WCC instance may support multiple “applications”.  For example an instance may be configured with the appropriate metadata, security, components, etc. to support an HR policies and procedure “application”.  It may also be configured to support a marketing collateral application.

So, the answer to the question posed above is “perhaps”, but there are many things to consider when deciding if you should use one single instance or deploy multiple instances.  For enterprises of any significant size or complexity the answer will almost always be that multiple instances are effective and recommended.

This blog post covers specific topics to consider when making the choice about how many instances should be deployed, and why.  This blog post also discusses the hardware infrastructure best practices associated with multiple instance architectures.

1.       Multiple Instance Considerations 

This section enumerates the most common topics of discussion when determining an instance-architecture.  These are presented without value qualification in that any of these may or may not be important to your organization.

1.1      Architectural Considerations

1.1.1          Internal, DMZ, External

Some applications require access by external parties.  This is most common for web content management related projects, but is not limited to those.  This architecture will require a DMZ presence of some sort, which may be a reverse proxy – or it may mean having a UCM instance within the DMZ.  This can be a significant architectural difference from applications that are intended to be entirely internal – such as HR or legal documents.  In addition, external applications may require the use of HTTPS, while internal applications do not.

1.1.2          Capacity Requirements

Some applications are extremely heavy users of resources, including CPU, I/O, database, and network.  Applications that fall into this category are often of an archiving nature, but not always.  For example, an application may be developed that captures a constant stream of “documents” coming from a mainframe print spool.  We often describe such an application as being “high volume”.  There are a number of other reasons an application may be “high volume”, including a significantly large consumer population, a significant publishing process, or a significant ingestion rate.  Such applications will frequently be put on dedicated infrastructure so that they can be tuned and configured completely independently from other WCC instances and applications.

1.1.3          Contribution and Consumption

It is a best practice in web content management deployments to use two instances – one for contribution and one for consumption.  This is a best practice for several reasons. 

First, it separates the resource usage (CPU, I/O, Network, etc.) of the contributors from the consumers.  The authoring and editing of content, workflow and approval processes, document conversion, and other processing is isolated from the consumption environment – which is likely to be tuned for optimal performance for consumers.

Second, it provides a separation of security models.  The internal contribution instance will often have a finer grained security model (definition of who can edit what) than is required in consumption.  In fact, it is often the case in consumption environments that everything is converted to public and read-only (although certainly not always).

Third, it allows for a separation of security integrations.  The internal contribution instance will likely be integrated with a corporate directory such as LDAP or Active Directory.  The external consumption instance may not be (again, another level of security) or may be integrated with a separate LDAP that contains external consumers.

Fourth, it allows the disabling of contribution activity on the consumption server so that it is generally more secure.

Fifth, it can provide a level of failover support in the event of a considerable “disaster” since the entire site is operational on the contribution server as well.

1.1.4          Service Level Agreements

Different applications will likely have different overall value to the business or organization.  That is to say, some applications may be deemed mission critical, while others are not.  Mission critical applications will often require redundant components throughout the architecture as well as tier-1 storage.  The infrastructure for such applications can be costly and may not be necessary for all applications.  Other instances may be departmental or have lower service level agreements in terms of recovery times.  Such applications can be deployed on instances with fewer redundant components and lower tier storage to save cost.

1.1.5          Geography

Many businesses are geographically disbursed, and are sometimes comprised of multiple data centers.  It is usually the case that applications are best deployed “near” the user community to achieve the best performance.  This also means that usually application support and administration is “local”.

1.2      Functional Considerations

1.2.1          Incompatibilities

Each instance of WCC has its own set of components that are deployed and its own set of system-wide configuration settings.  Sometimes these components and/or configuration settings are not compatible with different applications.  For example, it is possible to configure an instance of WCC to use what is referred to as “Fast Check-In”[2].  This streamlines the check-in process to bypass some of the normal processing in exchange for speed.  This includes bypassing the check for workflow, bypassing the check for notifications, etc.  This behavior is likely not desirable in an application that is used for general document management.

These types of incompatibilities may include such things as document conversion definitions; rendition set definitions, components, security integrations, retention policies, customizations, and many others.

1.2.2          Application “Personalities”

While less concrete than other considerations discussed, this will often have a bearing.  Instances are sometimes established around the application capabilities they intend to support.  For example, a number of applications that tied to scanning, fax, and other types of similar ingestion, that require workflow routing, are often a good candidate for combining on an instance.

However, disparate applications such as records management vs. web content management may not share much in common.  This will be evident in the architecture, the components required, the metadata, the security, and many other facets of the instance.

1.3      Metadata Considerations

1.3.1          Metadata Differences

While it is a good idea (and strongly recommended) to have a corporate-level governance structure around taxonomy and classification (metadata) it often a very bad idea to implement the entire corporate metadata model in any WCC instance[3].   In fact, it is a best practice to implement a given application with a targeted and pragmatic set of metadata to streamline the application, resources used, and the user interface.

To this end, two different applications may have very different metadata models – even through they both fit into the corporate taxonomy structure.  Applications that do not share a reasonable amount of metadata may be adding unnecessary resource usage, maintenance, and complexity to an instance.

1.3.2          Metadata Complexity 

Some applications have complex and even custom metadata behavior that is necessary to support the requirements for the application.  Often this may create complexities or incompatibilities with other applications on the same instance.

1.3.3       Metadata Size

The number of metadata fields, whether from Oracle provided components or custom, can have an impact on an instance. There is a hard limit to the number of metadata fields that can be defined.  This limit is set by the record size limitation of the underlying database.  While this is fairly significant, if reached it is a hard limit.  Breaking into multiple instances may be required as this limit is neared or reached.

1.4      Security Considerations

1.4.1       Security Model

Much like the metadata model, different applications are likely to have unique security model requirements.  Also like metadata, it is strongly recommended that a governance structure around managing security models is established.  Continuing the thought, it is also like metadata in that if two applications have significantly different security models there may be limited value in combining them on an instance.

1.4.2       Security Integrations and Provisioning

Applications may also be unique in their source of user provisioning.  Some applications may use a corporate directory, others may use a directory designed for external users, some my combine these, some may use the internal content server provisioning.   All of these are valid – but the deployment on a specific instance may create an incompatibility with other applications.

Likewise, some applications may deploy custom security integrations – either at the filter level (SSO integrations for example) or at the provider level.  Again, the security customizations done for a specific business requirement (an application or set of applications) may not be applicable to other applications.

1.4.3       Complexity

Another consideration is the complexity or methods of security deployed on an instance.  For example, the base security model may be extended with additional capabilities such as ACLs (Collaboration for example), Supplemental Markings (RM), Classified Security (RM), and custom security processing.  The “NeedToKnow” component, for example, changes the security processing within UCM.  Again, these types of security configurations may not be compatible with all applications you wish to deploy.

1.4.4       Performance

The security model, and any custom or product extensions to the security model, can have a direct impact on performance.  For example, Oracle generally recommends that an instance have 50 or fewer security groups defined.  The reason for this is because the content server takes a user’s roles and converts that to a “security clause” that gets appended to searches.  While the content server generally does a nice job of optimizing the search, if the security model is sufficiently large or complex it can slow the search response times.  Certainly database tuning, indexes, partitions, and other methods can be used to tune and improve search performance, it is still a good idea to plan on having as lean a security model as possible.

1.4.5       HIPPA, Auditing, and Other Regulations

In some cases instances may be segregated to be compliant with regulations.  For example, in some industries external audits of systems are confined to the systems containing relevant data.  If a system contains considerably more data than the target of the audit, the “other” data can be subject to discovery.

1.5      Organizational Considerations

1.5.1       Ownership

Occasionally it is the case that different business units, departments, or lines of business operate independently.  This sometimes also means that individual lines of business have autonomy on managing IT infrastructure and applications.  In cases like this it is common for WCC instances and applications to be deployed “close” to the owning organization.

1.5.2       Administrators & Maintenance

Application administrators and server/network maintenance may be divided within the business based on the line of business, it may be geographically, or some other mechanism that maps better to a multi-instance architecture.

2.       What are the Advantages to Multiple Instances? 

While this is likely not an exhaustive list, here are some of the commonly considered advantages.

• Better performance
  
  Instances, when they are properly planned and designed to contain “like” or “similar” applications, will have a security model and a metadata model that is leaner.  Likewise, each instance will be operating on smaller data sets (number of content items and database sizes).  Both of these points taken together means applications that generally perform better.

• Better Resource Utilization
  
  Instances that are operating efficiently and performing well will by definition be using resources well.  However, the total utilization of the hardware, storage, and other components is also a consideration.  By deploying multiple instances on shared infrastructure (see the Best Practice section below) it is possible to also better utilize the underlying infrastructure.  Since presumably each independent instance is operating efficiently, the net result is a higher throughput of service requests overall (for everything running on the shared infrastructure) and good utilization of the infrastructure overall.
  
  The negative way to look at this is instances that have overly complex security or metadata models and/or large data sets.  These instances will have lower throughput as the service calls, particularly searches, may require more time and resources.  The end result is slower response times with lower overall infrastructure utilization[4]. 

• Easier Management
  
  This topic is specifically in regard to the metadata model, security model, and rules / profiles.  By having divided the applications into smaller and less complex instances, the maintenance time required is reduced and the interactivity (impact of changes) to the environment is reduced. 

• Better User Experience
  
  As more and more applications are combined into an instance, it generally becomes necessary to make the user interface more and more generic to encompass all of the applications.  With similar applications grouped per instance, it is possible to better tailor or customize the user interface to better serve the consumers.

3.       What are the Disadvantages to Multiple Instances?

Below are some of the common objections and disadvantages to multiple instances.  It often these disadvantages that are weighed against the considerations and advantages to determine a final instance architecture.

• Maintenance and Administration
  
  One of the common objections to multiple instances is the necessity to administer and maintain each instance separately.  This is a fair consideration.   It is true that each instance will need to be individually administered.  There are methods that can be used to mitigate the impact of this (such as Master / Proxy configurations), but in the end managing each instance has a cost associated. 
  
  In fact, after reading the considerations for instances you may be wondering why not have one instance per application, and the “cost” for distributed administration is a consideration. 

• Search
  
  Another common objection to multiple instances is that now users must search within individual instances to find things and thus don’t truly have an “enterprise view” of all the content.  First, it is true that each instance maintains its own search index, such that searches within a particular instance execute against the content stored in that instance.
  
  However, there are 3 important things to note. 
  
  First, it is often the case that applications and instances are split in such a way that it doesn’t really make business sense for most users to be searching across multiple repositories.  Experience has shown us, having done hundreds of implementations, that this requirement will usually either be deleted or can be significantly reduced to some target users or groups.
  
  Second, assuming it is necessary to search across multiple instances in some cases, this can be done by connecting the desired instances using WCC’s “Enterprise Search” capability.  This provides the ability to execute a single search across multiple WCC instances.
  
  Third, it may be that searching across multiple WCC instances is not even enough.  Perhaps the real requirement is to be able to search “anywhere” in the enterprise – including WCC instances, shared drives, SharePoint, web sites, etc.  For use cases like this an enterprise search tool, such as Oracle Secure Enterprise Search, should be used in addition to WCC.

• Access by other instances
  
  A key capability of WCC is the notion of content reuse.  This is the ability to use a piece of content (perhaps in various renditions) across a number of consumption channels.  A concern with multiple instances is often that content that needs to be reused in another instance.  This may require replication of the content or “remote access” to the content.  Again, this is an important consideration.  While WCC provides tools to make this easier (replication, metadata mapping, retention, web services, etc.) any content reuse scenarios across instances will require careful planning.

---

[1] Instances can share the same database SID (database instance) but require unique schemas.  Likewise, they can share the same storage solution but must have a unique file system allocation within the storage solution.

[2] Note that recent versions of the software include this ability as a separate service, not an instance configuration variable.

[3] Increased maintenance with no business value add, increased database usage and complexity, increased complexity of rules and profiles, increased frustration and complexity for users, etc.

[4] The utilization of the database may be very high as it is processing through the larger and more complex data sets.  The rest of the infrastructure may be underutilized.

4. Best Practice Instance Architecture 

To this point we’ve discussed many of the considerations for determining appropriate instance architectures.  While the term “best practice” is not really applicable[1], there is an “appropriate practice” for your organization based on your requirements, infrastructure, organization, and the other considerations.

However, there are patterns to successful enterprise deployments of WCC that we can certainly draw knowledge from.  Some of the patterns have been hinted at.

Avoid the extremes of having either one instance for your enterprise or having 1 instance per application.  Neither of these approaches will likely produce optimal results for your organization in the long run.  The “best” instance architecture is going to be in the middle, where applications share instances when it makes the most sense.

Another pattern is the deployment of multiple instances on the same hardware.  It is entirely possible to install and run multiple WCC instances on the same server (or servers for clustered environments).  These multiple instances can share a single web logic environment[2] or each can have their own.  The former is more common.  There are several advantages to deploying instances in this “stack them on the same server(s)” approach (depicted in the diagram below).

First, this approach can be used to get good utilization out of the servers.  Instances can be added to the infrastructure and traffic balanced via the load balancers to tune the overall environment.  This is like a server consolidation method that allows for getting better value out of your hardware.

Second, this approach takes advantage of the way that Oracle licenses the software.  Because the licensing is by CPU, there are no restrictions on the number of instances you can run on server(s) once the CPUs have been licensed.

Third, this approach (if multiple servers are used) allows for flexibility in leveraging the capacity of the servers.  In other words, a smaller traffic instance with no HA requirements may run on one of the servers, while larger traffic instances can be spread across all the servers.  If the instances are installed such they span all the servers in the cluster, it is possible to do this load balancing dynamically using load balancer configurations.

Fourth, this allows system-monitoring tools to also be consolidated in the sense that they can monitor the servers in the cluster rather than a wider distribution of servers.

Finally, this allows for affective scaling.  If additional capacity is needed it can be added by adding either additional server(s) (horizontal scaling) or by adding addition CPU / Memory capacity to the existing servers (vertical scaling).  The existing applications can take advantage of the new capacity, as can additional instances.

5. Conclusion

Careful planning, with all the considerations in mind, is the best approach to deploying an enterprise content management instance infrastructure that will work for your organization.

Oracle has many customers that have done successful enterprise deployments that resemble the best practices described herein, and to them we are grateful.

---

[1] The term “best practice” assumes some common starting point that all implementations will fall under.  This is simply not the case, and it is necessary to take into account all of the considerations listed in this document – as well as others that may be unique to your organization.

[2] Each instance must have a unique web root

Diagnosing and Reporting a Product Bug

When upgrading a customized UCM instance from a pre-10g release to 11g, we encountered a subtle but critical bug in OTS (Oracle Text Search), where the result of an incremental index update sometimes differed from that of a full collection index rebuild.

In this case, the client instance had a number of custom metadata fields, including Major Revision and Minor Revision. While Major Revision was a required field, a Minor Revision value was optional. A custom component allowed a user to explicitly search for documents with a blank Minor Revision. Here is where the fun started.

All content that had been migrated from the old instance to the 11g instance could be successfully be retrieved by the component, regardless of its Major Revision and/or Minor Revision values (or lack of value). All newly added content could be retrieved using the custom component…unless the Minor Revision was blank, and the search criteria being passed to the custom component explicitly looked for a blank Minor Revision. In that one case, no search results were returned.

For example, here were the results for a search of Document Number SO-G-108. Note that there are 15 items returned, 9 of which have blank minor revisions:

When we added the condition that the minor revision value must be blank, we got:

Yes, only 7 of the 9. From the Release Dates, we could see that the 2 that were missing had been checked in on April 24, i.e. after the content migration and a full search index rebuild. Just for reference, here’s how I defined that search:

I should add that when I was running the test show above, for the one with the 15-item result set, I also ran it with &IsSoap=1 appended to the URL, and the xppMinorRev values looked identical for all 9 with blank values there, i.e. there was no visible difference in the metadata values for the 7 that came back in the more specific search versus the 2 that did not.

In order to further help pinpoint the issue, we performed another collection index rebuild, and lo and behold, the search now returned all 9 documents with the blank minor revision. We then immediately checked in another document fitting the criteria, and repeated the steps above. Sure enough, the “new” document showed up when only the Document Number was specified, but was not in the search results when the blank Minor Revision was added to the criteria. So, it was time to open a bug report with Oracle, with clear instructions on how to reproduce the errant behavior. Clearly, incremental indexing that occurs upon check-in was suspect here. The bug was opened, and Oracle replied: 

The short version of this long email is:  Bob is right, this is a bug. I’ll open one.  

Searching on nulls is fixed in ps5 for DATABASE.METADATA and DATABASE.FULLTEXT. However, I haven’t checked OracleTextSearch yet, so this is good test.

I created two text fields to test what Bob described. This query is converted to the following format before getting run on the database:

Universal format: xTextField <matches> `SO-G-108` <AND> xMinorRevision <matches> ``

Converted native query: ' ((SO#0023G#0023108) WITHIN xTextField)   and   ((idcnull) WITHIN xMinorRevision) '

Notice that the empty string `` is converted to idcnull for that actual database search.

When I look in the idctext2 table, I can see that empty xMinorRevision fields have ‘idcnull’ as their value.  So far everything makes sense.

select dDocName, xMinorRevision from idctext2 where xTextField LIKE 'SO-G-108';

DDOCNAME                       XMINORREVISION                

------------------------------ ------------------------------

PFLIES-LNX.US.001405           A                             

PFLIES-LNX.US.001406           A                             

PFLIES-LNX.US.001403           idcnull                       

PFLIES-LNX.US.001404           B       

When I run the query described above I get one hit, which is what I expect.

xTextField <matches> `SO-G-108` <AND> xMinorRevision <matches> ``

I can manually run this query on the database using the instructions in the note:

Troubleshooting OracleTextSearch in UCM 10g and 11g: How To Convert UCM Searches into SQL Queries (Doc ID 1333414.1)

This query is exactly the same as what UCM runs. It returns the expected document.

SELECT dDocName FROM idctext2 WHERE CONTAINS(dDocName, '((SO#G#108) WITHIN xTextField)   and   ((idcnull) WITHIN xMinorRevision) ')>0;

DDOCNAME                       XMINORREVISION                

------------------------------ ------------------------------

PFLIES-LNX.US.001403           idcnull 

Now, I go to optimize the field xMinorRevision and run a fast rebuild.  The fast rebuild does what it always does, and that’s update the otsmeta column, adding: 

<sdxMinorRevision>IDCNULL</sdxMinorRevision>.

If a minor revision exists, then it’s set to

<sdxMinorRevision>B</sdxMinorRevision>.  

The “sd” prefix means that the field is an SDATA section. 

However, and here’s where Bob is right about the problem, new checkins have idcnull set in the xMinorRevision field. But in the otsmeta column, the sdata section lacks IDCNULL. So yeah, looks like a bug. I’ll open one…

New checkins after the fast rebuild have this in otsmeta:

<sdxMinorRevision></sdxMinorRevision>

When they should have this:

<sdxMinorRevision>IDCNULL</sdxMinorRevision>

Oracle subsequently supplied a patch to the client, which resolved the problem.

The intent of this article is twofold:

1. For any reader who has experienced similar behavior – this is indeed a bug, and Oracle does have a patch to address it. I am unsure if it has been included in any official patch release.
2. If you suspect a bug in a product, be persistent and methodical in diagnosing and reporting the problem. If the behavior surfaces in a customization (as it did here), your first priority must be to successfully demonstrate the bad behavior WITHOUT the involvement of the customization in the mix. Finally, report the bug in as much detail as possible, and provide detailed instructions on how to reproduce the bad behavior. This will go a long way in getting the problem addressed.

Debugging Pages in Content Server 11g

More often than not, new developers working with Content Server are baffled as to “how” to find a given resource include to edit, or exactly what data sets are available on a given page.

There are some very useful flags that can be used to reveal a “behind the scenes” look at what is actually happening on a given page. 

This post deals exclusively with the 11g release.  There are other flags available that work in previous releases of the software, but most of them have been rolled up into a new flag (IsPageDebug), which will be covered later in this post.

• IsJava

This variable can be set as either a flag on a page or as a parameter to a service call.  When set to “1”, it instructs the Content Sever to return the data in the databinder using the Content Server’s hda format as shown (using the service PING_SERVER for an example).  

http://myinstance/idcplg?IdcService=PING_SERVER&IsJava=1

Contrary to the official documentation, IsJava returns both “local” data, plus any result sets that are generated as a by-product of the INITIAL request.  

• IsSoap

This variable can be set as either a flag on a page or as a parameter to a service call.  When set to “1”, it instructs the Content Sever to return the data in the databinder using a SOAP format as shown (using the service PING_SERVER for an example).

http://myinstance/idcplg?IdcService=PING_SERVER&IsSoap=1

Contrary to the official documentation, IsSoap returns both “local” data, plus any result sets that are generated as a by-product of the INITIAL request.

• trace

This Idoc function enables logging a debug or trace message to the debug trace output. A message can also be output to the console or to the system logs.

This function can used when creating dynamichtml includes in components, or as statements in profiles and workflows in the various applets.  

The use of tracing messages, particularly in workflows, is a powerful way to debug problems where the standard debug isn’t clear.

The trace function takes two mandatory parameters and one optional parameter.

Option	Obligation	Notes
The message itself	Mandatory	The options are Your special text string, or a string variable that has been accumulated.  It can also be set to “#all” to output the entire contents of the databinder as it exists when the <$trace$> statement is called. It can also be set to “#local” to output just the data in the local data section of the databinder as it exists when the <$trace$> statement is called.
The location where the message will be relayed.	Mandatory (the documentation says “optional” but the trace isn’t output or visible anywhere if this option isn’t set.)	The options are “#console” - displays to a console or the system audit trace. “#log” - logs a message in the HTML log files. The name of a variable (such as “StatusMessage”). In that case, the message is appended to the current value.
Tracing section	Optional	This option is only valid when “#console” is selected as the second parameter.  To log a message strictly as a profile debugging tool, for example, this parameter would be set to “docprofile”.  A list of valid OOTB values can be found on the System Audit page, under the “Tracing Sections” portion of the page. Using a section helps to tidy up the output, and makes reading the tracing messages much easier.

Examples of a trace statement:

The following example logs the string message to the system console, which is always logged:
                           <$trace("message", "#console")$>

The following example logs the string message to the system console in the pagecreation tracing section.
                           <$trace("message", "#console", "pagecreation")$>

The following example logs the string message to the HTML Content Server log file.
                           <$trace("message", "#log")$>

The following example dumps all local variables and their values to the system console.
                           <$trace("#local", "#console")$>

The following example dumps all local variables, result sets, and environment variables to the system console.
                           <$trace("#all", "#console")$>

The following example dumps all data to the variable “MyTraceDump”, which can then be displayed on the page. This is useful for HCSP developers who may not have the appropriate access rights to view the console or the logs.
                              <$trace("#all", "MyTraceDump")$>
            <$MyTraceDump$>
As an example of using <$trace$> in an applet scenario, here is a profile rule with a trace statement, and the resulting output in the system audit trace in the “docprofile” section.

• IsPageDebug

I am utterly shocked that this flag is not in the official 11g documentation!!  IsPageDebug in my opinion is the most powerful debugging tool available for a developer in 11g.  It exposes the same functionality as IsJava and ScriptDebugTrace in earlier versions, but adds the most powerful part - the full contents of the final page binder, and some javascript tracing as well.  

With IsJava and IsSoap, it was noted above that only the INITIAL binder is exposed.  However, many pages have either special functions or <$executeService$> calls during the course of the page rendering that add data to the binder.  This data is not available on the initial request, but IsPageDebug gets all of that data and makes it available at the click of a button.

Note that this parameter must be used with a page that has a template associated with it.  It won’t work with PING_SERVER, for example, but would work wonderfully with a checkin page or a search page.

http://myinstance/idcplg?IdcService=CHECKIN_NEW_FORM&IsPageDebug=1
Near the bottom right corner of the page, a small gray button is displayed.

Clicking the button expands a tray as depicted.

These buttons have mostly very useful data associated with them.

1. idocscript trace -This option performs like <$ScriptDebugTrace=1$> performed in versions 10g and earlier.  It displays a list of every include statement evaluated to render a page, along with the file/filesystem path where that include statement is actually located.  Indentations in the code show the number of times the include statement has been overridden, which is really helpful when debugging issues with includes that contain “super” references.

request binder - This option shows the data available at the time of the page request.

response binder – This option is similar to IsJava, where the initial data binder for the service response is shown.  Clicking on a header like “Local Data” shows/hides the information associated with the section.

final page binder – this option exposes all of the result sets and local variables available AFTER the page has completed rendering.  This is way useful when trying to figure out “how” a data value was computed for display, since additional data can be loaded as part of the page build process.  It also shows any local data variables that may have been altered during page generation. Clicking on a header like “Local Data” shows/hides the information associated with the section.

javascript log – this option shows the javascript trace calculated on the page using the idc JavaScript trace functions.  This is not a substitute for a normal JavaScript debugger, and I haven’t found a really good use for the functionality – yet.

Hopefully this bit of information is useful to help find answers when you need to know “where” something is coming from.

Declaring Records in 11g Like 10g and Earlier

With the 11g release of WebCenter Records (formerly Universal Records Management),
the definition of a “record” is now much blurrier than in previous versions of the
software.


While the new flexibility is nice, sometimes there is a desire to make sure that an item
really can’t get changed when it gets to a certain point – like when the “Is Record” box
in 10g and earlier was explicitly checked. Without that declaration, an item could still
be edited or otherwise manipulated.


A use case for “locking” such an item usually occurs when a policy or a contract is
being created. The document goes through several iterations of revision, and finally,
the last revision should be declared a “record”.


In 11g, the “Is Record” isn’t exposed on a checkin or update page. However, you can
still get the same functional result with a bit of configuration.

1. In config.cfg, enable the following setting (RmaEnableFixedClone=true), and restart the managed server
2. Once the system is restarted, go to the retention category where the document resides.
3. “Browse”the category and find the item to be declared a record
4. Under the “Actions” menu, select “Content Actions --> Create Fixed Clone”.

1. The following dialog appears.
2. Complete the options in the dialog. You will have to select the correct category where the cloned item will reside. Browse to the correct category, and then select “OK”. You will be returned to the document info page for the original item.
3. Go to the retention category where the cloned item was placed. The following entry should appear. Depending on the system configuration, an icon may appear as shown.
4. Clicking the info icon, and viewing the document information page shows the item as non-editable, non-deletable, and non-revisable. (If the entire metadata set for the item was displayed, the value for xIsRecord is now set to “1”).

Note that this technique only works with electronic content. Items managed by Physical Content Management are not affected by cloning.