Discussions
Categories
Groups
Community Home
Categories
INTERNAL ENABLEMENT
POPULAR
PUBLIC CLOUD
PRIVATE CLOUD
Quick Links
MY LINKS
HELPFUL TIPS
Back to website
Home
Web CMS (TeamSite)
Content Freshness options
faz_at_freddie
We're looking into implementing a Content Freshness system and I was wondering if anyone out there has incorporated such a system? Basically, static content that is managed within Teamsite, including shell files, SSIs, images, "Office" docs, etc., would need to be periodically reviewed for "freshness" or relevance of the content. Every content item must be associated or tagged with metadata (or similar) that species how long the item can stay on the website before it needs to be revalidated.
I would also like the system to offer advance notification of pending "staleness", where for example, on the first day of the month I would be alerted to content that would become stale next month, etc. Content must also be able to be revalidated based on continuing relevance.
These are some of the things we're looking to do. 6.5 seems to offer some functionality via the reporting module, but I'm not sure how robust the module will be or whether it's designed for what I'm looking for OOTB.
Thanks!
Find more posts tagged with
Comments
iwovGraduate
There has been numerous posts about this. What you are refering as content freshness is essentially the same as being referred by others as content expiration. If you search the posts and the KBs you will find many references.
You seem to be thinking along the lines of a typical solution for this kind of requirement - using metadata/extended attributes. Unfotunately there is nothing OOTB that would alert you of upcoming expiration/alertness. But its relatively simple to write a script that would do that.
iwovGraduate
I am not sure how much of this you can get by OOTB 6.5 reporting as I have not worked with it extensively. Maybe somebody else will chime in for that.
faz_at_freddie
Thanks for the heads up on the topic. I did a search for "content freshness" and didn't come up with anything, so it's good to know that "content expiration" has been discussed before. I'll research this, but if anyone has some input on how this may work in 6.5, that would be great.
iwovGraduate
I remember there is a PDF document floating somewhere on content expiration. You might want to look at it as well.
smenon
With TeamSite 6.5 you have a couple of options - using Search or using Reporting.. If you have captured content expiry as metadata on the assets, then you can index the EA and run a search against that EA value to get a list of expiring content. With TeamSite 6.5 SP1 due to be released in two weeks, you can write a CSSDK application that can run the search for you using the new CSSDK Search APIs.
Alternatively, you can choose to use ReportCenter to report on that EA. There is a sample OOTB report that ships with ReportCenter that provides a list of assets that haven't been modified since an input date. You can use that report as an example and potentially create a more sophisticated report to capture the EA data. Once you have uploaded that report to Crystal Enterprise, you use the scheduling features in Crystal Enterprise to run a scheduled report (every day or at whatever frequency you would like) and have the report emailed to you. I just want to point out that scheduled reporting with different output options is part of standard Crystal Enterprise functionality and is not exposed as an option from the TeamSite UI. You can get more information about these features from the Crystal documentation.
--Sunil Menon
Product Manager
Interwoven, Inc.
iwovGraduate
Wonderful !
This is exactly what I am trying to do. I have already configured capturing expiration date ext attr, and Search on that ext attr. I am able to search from the UI on the dates - which is great.
Now what I need is to run the same query (search of all content whose exp date ext attr is before a given date) using a CLT from my script. Is there any example of a similar query ?
Any suggestions/hints/RTFMs appreciated !
(The CLT guide has one example which is for full text search. What I am looking for is to search for a particular ext attr)
iwovGraduate
Ok, so now we have API in CSSDK for Search and some examples of search queries as a KB article/document. All good.
From the CS for TS RN 2.5.0 SP1 -
"The package com.interwoven.search is now both publicly exposed and available as a web service across SOAP/HTTP, providing API support for full text and metadata search for already indexed documents within the TeamSite repository."
The CS for TS Cookbook 2.5 says that -
"Not all functionality that exists in the ContentCenter user interfaces, such as their search and reporting capabilities, are exposed programmatically as APIs in ContentServices for TeamSite."
I assume that the SP1 release notes overrides whats stated in the 2.5 cookbook ? What I want to know is how much of Search functionality is exposed via CSSDK ? Is it everything that the UI provides or are there things that you can do in the UI but not via API ?
How about the CLTs ? Do CLTs provide all the functionality that you can do via the UI and/or using CSSDK APIs ?
Migrateduser
The Search webcast outlined what capabilites are available in the CS SDK. No index capabilities are part of the SDK. There are CLTs, but no API.
hth,
lissa
foxman
We use TeamSite 6.5 and we just run a script that checks the expiry EA and also checks that the Content Last Edited by person is still a valid TeamSite member.
We then send 4 emails. One that notifies of content expiry in a week, 4 days, tomorrow and expired. They sort of get stronger the closer it gets.
The last edited person gets a personal list and all masters get a master list...if the person doesnt exist in TEamSite anymore, the master gets those too for reassignment of ownership.
We provide a link to staging for preview, which is a bummer as you cant edit them, but there is no better option that we can think of.
Out of interest, we also use teh 6.5 Search for basic link checking. In the workflow after a deletion we use the search to show all of the affected files for editing. We have found that if it affect a lot of pages, users MAY just change their mind about what they are trying to do. So far, its the best idea we could come up with without expensive link checking solutions.