UCM Black Hole Check In
By Kyle Hatlestad on Aug 18, 2009
One situation where we used this with Content Server when we were under Stellent was on our stellent.com website. Our website was built using Content Server (aka UCM) as the foundation and one of the options we offered on the site was for the submission of resumes. Prospective employees could upload an electronic version of their resume into the site which would kick off a process to review that resume by HR. But as soon as they submitted that document, they would no longer be able to view or download it. Thus we needed a way to provide that unusual security use-case.
Different options were discussed such as a custom component to override security. Then a much more simple (and elegant, I think) solution was brought up that wouldn't require any customizations. The approach was termed the "black hole check in".
Basically, the black hole check in uses the Archiver to remap the Security Group and/or Account on the document as soon as it's checked in. Archiver has three major purposes.
- Archive/export content with metadata out of the Content Server.
- Replicate content from one instance to another.
- Remap metadata value.
By combining it's ability to replicate and remap values, you can create an automated way of changing security. What you do is set up replication, but instead of pointing to another instance, the same instance is both the exporter and importer.
Then you set up your Export Query to catch the content you want to remap on the way in. On the Import Maps, you set up your Value Maps to change your security to your new secure settings.
Be sure to set your Export Query in a way to avoid an endless loop that would still catch the content after it was remapped. So it's best to include the security as part of the query.
Now when content gets checked in, it's security gets remapped and voila! - it's not accessible by the author anymore.
Another scenario that doesn't have quite the same requirements, but which this approach is helpful, is for security or other system metadata field to change during workflow.
There is a handy Idoc Script function you can use in workflow events which will let you update metadata.
This works well with custom metadata, but does not work with system metadata. So if you wanted to change the Security Group for instance, it would not work.
So what you can set up is an Archive similar to what is outlined above. When the item is released in workflow, it will hit the Archiver process and remap whatever system fields you need.