Web Url Mapped Folders Exposed
By Kyle Hatlestad on Feb 15, 2010
I was recently made aware of a feature in the Folders (folders_g) component called Web Url Mapped Folders. I guess it's been available in the updates for a year or so. In a nutshell, it lets you map Contribution Folders to a relative URL path of your choice. So instead of needing a UCM service based URL like http://server/idc/idcplg?IdcService=GET_FILE&dID=67&dDocName=WC-000030 or a webdav based url like http://server/idc/idcplg/webdav/Contribution Folders/Documents/info.doc, you can have a URL like http://server/documents/info.doc.
It's using the mechanism offered in the standard WebUrlMap functionality. I covered that a bit in this previous post to help offer friendlier and shorter links for common functions. But this particular implementation with Folders offers a couple of very powerful advantages...which I'll cover in a bit.
So to enable the mapping, log in as an administrator and go to Administration -> Folder Configuration -> Web Url Mapped Folders.
Then you just Browse your virtual folders and enter a Url mapping for it.
Your next step is to enable this relative path in the web server. For IIS, our UCM filter automatically filters all URLs for a potential prefix, so no additional work needs to be done for that. But for Apache, iPlanet, or Oracle HTTP server, you'll need to add this location and apply the IdcSecurity parameter to it. You can look to the one specified for the primary UCM relative location as a reference. Depending on your environment's configuration, you can take a shortcut and simply apply the IdcSecurity to the '/' location. Then every relative path will be recognized by UCM.
IdcUserDB idc "/opt/oracle/ucm/data/users/userdb.txt"
Allow from all
You must then restart the web server to enable the change. This is very similar to how Site Studio sites are configured as well. But one thing that is different about the Folders Url mapping is you must restart content server before it is recognized from within UCM.
Now when you search or browse to an item that exists within that folder (or sub-folder), the link will go to that mapped URL. And if you go to its content information page, at the bottom you will see the Mapped Folder Web Location in addition to the standard web and native locations.
The path location is now part of the data binder information coming back to the page. If you add the '&IsJava=1' to the page, you'll see MappedFolderDocUrl=http://wc/Documents/info.doc as part of the local data. So if you call the DOC_INFO service programmatically, you'll have access to the path. And as part of search results, the value 'mappedFolderURL' is part of the SearchResults result set.
So that's fundamentally how it works. But what is it good for?
For one use case, it can be very helpful to provide a friendly and effective URL for search engine optimization. For instance, in your Site Studio website you may provide a dynamic list of documents for download. In the past, you could have provided the GET_FILE service URL (not friendly or good for SEO) or the weblayout directory (not good for SEO). In the most recent Site Studio 10gR4 patch (covered recently in the ECM Alerts blog), a new feature was added to allow linking to a native document while keeping the web site path intact. So that helps if the structure of the site is good for SEO. But what if you have the same document offered on different parts of the site? Or you need a distinct path separate from the web site path. Now you can store those documents in Contribution Folders and reference them by your mapped URL.
So in your Site Studio dynamic list, the code to display the document link might look like:
And your links can end up looking like http://company/products/widgets/part1234/specifications/part1234_specs.pdf.
The other use case is for managing items that have relative paths to each other. A great example would be a static HTML website. Because the paths are maintained and resolved using this approach, the code in the HTML that links the items should not need changing.
This used to be possible by using the Local Folders feature of Folders, but that could be problematic due to items left behind after moving content and migrating to other instances.
Here we can see the content as it's been dragged and dropped into our WebDAV folder.
After you have your folders and content submitted, you can configure your mapping.
Then after restarting UCM and clicking on the mapped web folder location for index.html, the site should be displayed.
There are some caveats to be aware of. This URL points to the native version of the file and not the web viewable. So even if the file went through a conversion, it will point to the original format.
Also, items that are in workflow or set for a future release date will still be accessible through this link. This may or may not be bad depending on your use-case. Even if the Folders configuration variable 'CollectionReleasedOnly' is set to true which will hide the file through the folder interface unless it's released, the mapped web folder location link will still resolve to the file.