Core Content Only

Some of you may have used or even still have an excel spreadsheet which can be used to update metadata. This spreadsheet was originally provided by the former content server creator, Stellent. I am actually unaware of the name or names of the original author or authors and as such have not credited them here. Leave your name to take credit!  Some people love it.  Some people hate it.  Either way, it has been useful to me. 
The original style sheet allowed users to specify additional custom columns named after their custom metadata. It offered two buttons. The first was “submit query’ which invoked the user defined query string located to the left of the button. The second button “update’ would cycle through each of the result records from the query and update the metadata based on the values in the spreadsheet. 
I have updated the spreadsheet in two ways. I have added a login button which simply causes a prompt for user credentials. The importance of this button is the reduction in steps needed to update secured content. With the original spreadsheet the user first had to search on public content only and invoke an update which then prompted for credentials after which the user could conduct another search which would then have the credentials to access secured content. With the login button we can now skip this cycle. The second change is a new worksheet which contains configuration variables for the searches. Currently there are three configuration variables including ResultCount, SortField and SortOrder. 

Additionally I often get asked how one can use this spreadsheet to update metadata only check-in’s. The trick is an additional column named createPrimaryMetaFile. This column should be set to TRUE if that record represents a metadata only check in. 
 
 
 
This file and all updates to it are presented here as-is with no support implied or otherwise. As always, use at your own risk.

References: 
Download the Remote Metadata Updater

Brian "Bex" Huff and Andy MacMillan delivered a session called "A Pragmatic Strategy for Oracle ECM" which pushed some of the integration and cooperative concepts that have been pervasive among the keynotes and sessions today. They describe their approach to content management as more realistic than the message presented by many vendors as "Hey, we will do it all". Their approach is also more tolerant of your existing content repositories and your investment in those elements.

They describe a situation where a client has several existing content repositories. Some of these can be consolidated into your new strategic content management repository. Some of them cannot. This can be due to technical issues or the fact that you have spent a lot of money on those repositories and/or users are entrenched in using that repository already. These previously existing repositories that perhaps service tremendous load or importance but are not capable or selected as the strategic repository are termed tactical repositories.

The session then moved on to discuss federated software solutions to help control and integrate your existing, tactical repositories with the feature set of your new strategic enterprise wide solution. Examples of these federated software applications included Secure Enterprise Search and Information Rights Management.

Additionally, these two guys are writing a book together, potentially entitled "Transform Infoglut: A Pragmatic Strategy for Oracle Enterprise Content Management" and it will hopefully be delivered sometime around January 2009.

I attended Brian "Bex" Huff's session entitled "Enterprise 2.0: What it is and How You'll Fail". At first attendance was a little sparse, but by 20 minutes in we got more than 15 people in the room. One of the biggest themes of the message was about focus. Focus on Culture versus Technology. This is one of those points that is so foundational to the concept at hand that once you hear you say to yourself, "Well sure, that's obvious", but you would not normally come up with it on your own.

We also heard an echo from the old Stellent days when he reminded us of the importance of "Getting the right information at the right time to the right people in the right format and context". This reminded me of the big launch of Profiles with 7.5.x Stellent Content Server. It was true/relevant/important then and it still is today.

There were a lot of concepts presented in the presentation and of them all the concept of Social Capital was my favorite. This was somewhat new to me. The concept was not new, but being able to linguistically wrap a name around the subject was a neat discovery. The concept of Social Capital is described on Wikipedia. Basically it can be thought of as referring to the value of the connection between employees and potentially even vendors. People like to work with their friends and so projects get done quicker or more thoroughly.

In the end, I wonder how much push back corporate America will engage in when liability of all this Enterprise 2.0 culture and technology come to bear. While companies may accept it at first, I am concerned about a backlash that comes from committing so much of what would have been hallway conversations, water cooler talk, quick phone calls, etc., into a written, searchable, liable format.

All in all, great talk. It is certainly though provoking.

As a result of one of the more recent core updates for oracle content server the actual update screen has several new pieces of data available to help you with the install.  I am not exactly sure when these pieces started showing up in the component update screen but they are very handy.

There is a marker for current status along with the bundled version marker and installed version marker which help you compare your installed version with the new version inside the core update.  This will help you make the decision as to whether or not you should place a checkmark in the checkbox thereby installing the component coming in from the core update.

My thanks to whomever got this in place.

There are several ways to execute iDocScript from Java, but in this quick example we will use a PageMerger object.  There are several ways to get ahold of a PageMerger object.  If you are executing in a context where a service object is readily available you may be able to get a PageMerger object reference with code like this:


PageMerger pm = m_service.m_pageMerger;


If that doesn’t work for you I would try something like:


PageMerger pm = PageMerger(databinder, executioncontext);
 

Now that you have your merger object you can execute all kinds of iDocScript code, an example of which might be:


pm.evaluateScript("<$lc(\"wwMyString\")$>");


Occasionally, you might have the need to perform what is known as a metadata only check-in. To perform this action you will need a configuration variable known as AllowPrimaryMetaFile. This variable allows users to check in metadata only records. Similarly there is another configuration variable you may want to keep in mind known as AllowAlternateMetaFile. These settings will create check boxes next to the primary and alternate file inputs. This might look like:

These variables should be set to true in the config.cfg file. They can also be set through the admin server in the general configuration. These changes will require a content server restart.

Why would one want to use a metadata only check-in? Often these serve as the records to track things like places or people. Perhaps they can even represent reusable hyperlinks. These data records are then used with tools such as Site Studio in which a designer can create pages and craft the data records into some type of meaningful display.

References
AllowPrimaryMetaFile
AllowAlternateMetaFile
createPrimaryMetaFile
createAlternateMetaFile

It is early in the project and you create a nifty Java application to access content server.  It executes a few services and generally accomplishes some black wizardry that people OH and AH over.  Everything is going well.  You are just about to board the corporate jet for that all expense paid developer retreat in Hawaii when they call you back with a problem.

Customer xyz decided they wanted to use the active directory integration everywhere in the content server and now Nify App does not work.  WHAT COULD IT BE?  After some truly Sherlock-like investigation work you find out they have switched the Default Authentication mechanism from Basic to NTLM.  You quickly dial, "HOLD the plane, I can fix this and still make it!"

Within a minute you have your code open and spot the problem, yes, yes, of course, you will need to set a request property.  Your fingers fly across the keys pouring out something akin to these pearls of wisdom:

URL url = new URL(URL);HttpURLConnection urlConn = (HttpURLConnection)url.openConnection();urlConn.setRequestProperty ("Cookie", "IntradocAuth=basic"); 

You casually remark on the way out the door to your stunned co-worker that this enhancement will allow your code to continue connecting with Idc Security, thereby working just fine.

Reality:  While the context of this story may be a bit far-fetched the code is not.  Thanks Matt Pelham for this tidbit.

In the oracle forums today a question came up about how to add custom actions to the menus in the actions drop downs for the Content Information page (sometimes called the Doc Info page).  I wanted to dive into this a little more because in 10gR3 the way the developers crafted the menus is much more extensible.  It is very nice.  Somebody should get a raise.

Look at the dynamic html include named docinfo_menus_setup in the std_page.htm file.  The menus are crafted as a result set, which makes adding to the menus very easy.  Also, at the end of the code they perform an include on something named custom_docinfo_menus_setup and this is key.  Let's look at how we might override this include to add some of our own custom actions:

<@dynamichtml custom_docinfo_menus_setup@>
  <$include super.custom_docinfo_menus_setup$>
  <$exec rsAppendNewRow("PageMenusData")$>
  <$PageMenusData.nodeId = "JAVASCRIPT_ALERT"$>
  <$PageMenusData.parentId = "CONTENT_ACTIONS"$>
  <$PageMenusData.label = "JavaScript Alert"$>
  <$PageMenusData.type = "item"$>
  <$PageMenusData.href = "javascript: alert('JavaScript Alert!'); void 0;"$>
  <$PageMenusData.loadOrder = 150$>
  <$exec rsAppendNewRow("PageMenusData")$>
  <$PageMenusData.nodeId = "CORE_CONTENT_ONLY"$>
  <$PageMenusData.parentId = "CONTENT_ACTIONS"$>
  <$PageMenusData.label = "Visit www.corecontentonly.com"$>
  <$PageMenusData.type = "item"$>
  <$PageMenusData.href = "http://www.corecontentonly.com"$>
  <$PageMenusData.loadOrder = 170$>
<@end@>

This will add two menu actions to the doc info page content actions menu.  One of which will simply pop up a JavaScript alert and the other one will take you to this blog.  That sounds pretty straight forward, but what are all these properties?  Let's learn a bit more about two of them, parentId and loadOrder.

The collection of menus on the page are known as PageMenusData.  Technically there are three menus within this.  The bar going across the page (HEADER_MENU) is the first menu, and the second two menus (CONTENT_ACTIONS & EMAIL) hang off of that bar.  Here's a little picture for reference:

As you look through the docinfo_menus_setup include you see these menu names or id's in action and you can start to piece together how the menu structure is crafted.  Our custom actions have been "joined" to the CONTENT_ACTIONS menu by setting that menu id as the parent id for our menu nodes. 

Load order is also one of the more interesting points.  Supplying specifically planned load orders allows you to control where in the menu your node is displayed.  And SOMEBODY at Oracle/Stellent was paying attention because the load order for the default set of actions items generally increments by units of ten.  This means they left some space in there for us to get our custom actions in between out of the box actions if we find the need.

Here is an example component you can download and adjust to play around with this functionality.

03SEP08_v1_DocInfoCustomActions.zip