Resolving 404 errors accessing WCM content through POC Servlet

The other day, I got a tweet from my buddy, Dave Hay, who blogs on A Portal to a Portal. He was looking for a post I had in my former blog before a lot of that content was lost. I looked on the Internet Archive Wayback Machine, which allows you to look at the Web as it was in the past and I found the content so I’m reposting it. Dave has since added more information to this subject, so be sure to check out his post also: “More on 404 errors accessing WCM content through the POC Servlet (/wps/mypoc/…)

Here’s the original post from December, 2011:

Recently, we had a problem where WCM URLs in OmniFind search results (generated by the Portal seedlist mechanism) were giving 404 errors when clicked. These are URLs that contain /wps/mypoc in the URL. This page documents a solution that worked for us.

/poc and /mypoc are mapped to the POC Servlet which is part of the URI resolution framework. The purpose of the URI resolution framework is to resolve a WCM resource (that is, a piece of content or POC) to a portal view. You can learn a lot about the URI resolution framework in this excellent article: Leveraging WebSphere Portal V6 programming model: Part 5. Accessing portal content with custom URLs.

But let me get to the point quickly. As you may know, you can create a portal page with the WCM Web Content Viewer (JSR286) on it and map the portal page to a site or web content folder in WCM. After creating and saving a portal page, you can find this mapping control in the advanced section when you edit the page properties. After mapping the portal page to a web content folder in WCM, any piece of content within that area should then get resolved to the mapped portal page and consequently render in the JSR286 viewer that is on it.

But recently, we had an issue where that wasn’t going too well for us; the default URL generated by the seedlist mechanism just wasn’t working – we got 404 response. We could not get the POC Servlet to resolve properly to a portal page. We were able to resolve the issue by rewriting the URL using a RegEx filter mechanism available to OmniFind. We found that links would always resolve properly as long as the base URL was as follows (with the content identifier appended):

https://www.ourportal.com/wps/mypoc/?urile=wcm%3apath%3a%2f

That is just an encoded form of the following:

https://www.ourportal.com/wps/mypoc/?urile=wcm:path:/

Append the content identifier to the end of that (typically the wcm library, site area path, and content ID). For example:

Content%2fSiteArea1%2fSiteArea1-1%2f7cdad580493e87dd89e7891b4dda79ec

Together, the resolvable URL should looks something like this:

https://www.ourportal.com/wps/mypoc/?urile=wcm%3apath%3a%2fContent%2fSiteArea1%2fSiteArea1-1%2f7cdad580493e87dd89e7891b4dda79ec

And that worked for us. It resolved to a portal view. You could tell because the URL in the browser then switched to one of those crazy portal URLs with all the state information encoded in it… and the expected piece of content was rendered in the JSR286 Web Content Viewer.

If you’re interested in learning more about how to rewrite search result URLs in OmniFind using the RegEx filter, see the following tech-note: How to use “Configuring a regular expression URL filter for search results” feature in Enterprise search portlet deployed on WebSphere Portal version 6