Posts Tagged ‘Managed Pages’
Vanity URL Administration for IBM WebSphere Portal and Web Content Manager
Business users of IBM WebSphere Portal version 8.5 can offer customers better digital experiences by using Vanity URLs. Managing this new feature should not introduce any new headaches for administrators but a few tips and a little prior planning will go a long way toward ensuring a smooth implementation.
URLs are important; short, readable URLs empower potential customers and users to locate meaningful resources quickly. In contrast, typical portal URLs are cumbersome. Vanity URLs, new to IBM WebSphere Portal 8.5 offer features with greater possibilities than portal URL Mappings without incurring direct administrative effort.
Requirements and Base Knowledge
In order to work with VanityURLs the portal platform must have Managed Pages support enabled. This is the default (and recommended) configuration of a new IBM WebSphere 8.5 installation. If the portal was migrated from an earlier version, support for Managed Pages must be enabled. A ConfigEngine task, enable-managed-pages must be executed in order to proceed. In addition to enabling support for Managed Pages, sites that are migrate will also require manual enablement of Vanity URLs. This ConfigEngine task, enable-vanityurl-support, creates a new custom property in the WP Configuration Service resource environment provider and sets the property named vanityurl.support.enabled to “true”. Information regarding this task may be found in the Knowledge Center at: http://www-01.ibm.com/support/knowledgecenter/#!/SSHRKX_8.5.0/mp/wcm/van_url_cfgtsk_enable_vus.dita
Information and additional details for the enablement of Managed Pages task can be found in the IBM Knowledge Center at: http://www-01.ibm.com/support/knowledgecenter/#!/SSHRKX_8.5.0/mp/migrate/mig_t_enable_mngpages.dita
In addition to platform readiness, administrators seeking to manage Vanity URLs will need to be familiar with the WebSphere Application Server Integrated Solutions Console (ISC), the ISC trace string settings interface, Web Content Manager Syndication, Site Authoring Toolbar, portal Release configuration database, the JCR (Java Content Repository) database, HTTP server rewrite rules, Friendly URL paths, and URL Mappings.
Creating Vanity URLs
Business users employ the Site Authoring Toolbar to create and manage portal pages, set content preferences, and to create or modify Vanity URLs. A nice PDF describing the design objectives and features of the toolbar is available at IBM’s web site. When creating or modifying a Vanity URL the toolbar is loaded in the current page context. This means that the state of the page, including selected content, default content, locale, and authentication stipulations are available at the time the definition of a Vanity URL is being set or modified.
A Vanity URL is stored as a property of the Managed Page site area artifact created in the Portal Site WCM library. In addition to specifying (1) a name, users may specify a (2) locale and (3) indicate a choice for web content associated with a Web Content Viewer portlet. It is worth noting, as indicate in this following screen shot, that a page may have multiple Vanity URLs such that each may have unique locale and content settings. In addition, users can indicate whether a request to the Vanity URL will force authentication.
Three aspects of Vanity URL creation.
When a Vanity URL is created a reference, for performance purposes, is also created in the portal Release configuration database. The URL syntax, which can be previewed in the page properties editor of the toolbar, is http://host/wps/vanityurl/<customurl>.
Enhancing Vanity URLs
A simple url, such as host://wps/vanityurl/Specials is probably adequate for many needs but most business users will wish to simply even this URL. Many will prefer a syntax such as http://host/Specials. This is one of several enhancements that are supported. This shortened syntax will require administrative effort consisting of modifications to the configuration of the external http server.
If, for example, you are using the IBM HTTP Server an administrator will modify the web server’s configuration file. This file, httpd.conf, can be modified to enable rewrite rules. Then, once the rewrite engine is enabled, the administrator will provide a rule to parse any incoming “single path” requests and redirect the request to the vanity url servlet. The IBM Knowledge Center provides detailed instructions on the process here.
The rewrite module, once enabled, will need at least one rule. The following rule redirects “all single path requests to the vanity URL servlet. The P flag at the end of the line tells the rewrite engine to use a proxy request. This flag is required for the IBM WebSphere® Application Server plug-in to handle the request without an additional redirect.”
RewriteRule ^/([^/]+)$ /wps/vanityurl/$1 [P]
Other rules will be required to support projects, static files, and the Web Application Bridge. Please refer to the link referenced above for the necessary details.
Not only might users wish to enhance their Vanity URLs by shortening them for customers they may also wish to preview them in the same manner. To do so, execute the ConfigEngine task “enable-vanityurl-httpserver-preview”. Later, if you wish to return to the default full vanity url syntax you can execute the “disable-vanityurl-httpserver-preview” task. Complete documentation for this process is found here in the Knowledge Center.
A final enhancement administrators should consider is provision of a custom URI for handling missing vanity urls. By default, when a customer requests a resource for which a vanity url no longer exists or was never defined, a 404 error is returned. Administrators may, alternatively define a value for an additional custom property of the WP Configuration Service resource environment provider. To do this a ConfigEngine task is needed that includes the object identifier of the URI to which errors will be redirected:
./ConfigEngine.sh set-vanityurl-error-uri -DPortalAdminPwd=password -DWasPassword=password -DErrorURI=cm:oid:ibm.portal.Home
Vanity URLs, Life Cycle, and Release Management
One area in which administrators coming to versions 8 or 8.5 are likely to struggle is release management. This is because Managed Pages has a significant impact on how artifacts are managed. The advent of Managed Pages raises the role of WCM syndication to a new level making it a significant player in the task of achieving a consistent state between staging and production.
Because Vanity URLs are primarily members of site area properties in the Portal Site library with corresponding pages and labels in the portal configuration Release database it is easy to forget or overlook the necessity to syndicate the web content libraries in order to propagate Vanity URLs. This may be exacerbated when the decision to populate the target system during the first release by using a clone of the JCR. (Cloning is a popular strategy used to avoid lengthy data transfers associated with large web content libraries.) This approach mandates execution of another ConfigEngine task, “sync-vanityurl-data”. This synchronizes the configuration database with the JCR so that the Vanity URL references are set in the release database. Full instructions are available in the Knowledge Center here.
Troubleshooting
Even under the best of circumstances trouble may arise. Typical errors are those associated with missing or non existent Vanity URLs. When this happens the vanity url servlet will return a 404 error.
To more completely understand the problem you may need to apply a diagnostic trace. Use the value “com.ibm.wps.portlet.vanityurl.*=all” and provide the trace log to IBM for assistance. Information about this string and related errors is available here.
One other item, though not explicitly related to troubleshooting, is the relationship of vanity urls to search and indexing. Administrators should be aware that vanity urls are not included in seed lists. To ensure successful index ranking, be certain to define friendly urls for all pages whether or not vanity urls are used.
Conclusion
IBM WebSphere Portal version 8.5 offers customers better digital experiences through Vanity URLs. With the tips and practices described in this article, administrators are better equipped to ensure a smooth implementation.
Managed Pages – First Look at a New WebSphere Portal 8 Feature
The task of managing portal pages and web content is evolving and in the next release of WebSphere Portal the integration between web content management and portal page management will grow even tighter. Recently I installed WebSphere Portal 8 Beta 3 and dove into my first examination. In the following paragraphs I talk about what I saw and learned during my sortie into this new realm.
To install WebSphere Portal 8 Beta 3 follow the procedure I described for Beta 2. The updated download links are here and from there you can link to the installation guide I provided here.
After logging into the portal I landed on the Getting Started page. I decided to take a quick look at the properties and layout of the page using a conventional approach. I navigated to the Administration pages and loaded the Manage Pages portlet. At the top of the page is a new feature. This pane, which I have dubbed the project pane, represents the state of the page as a member of a project. Projects are not new to Web Content Management but they are, so far as I know, new to page management. According to the product Wiki, “When working in a project, any changes you make to a page affect only your view of the page.
Figure 1
After the project is approved and published, the changes are then available to all users.” Welcome to version control for portal pages! The second panel is a conventional display of page properties. There is one variation to the interface as it pertains to the layout template of the page but otherwise there are no other surprises here. (Figure 1)
Returning to the Manage Pages portlet I next selected the Edit Layout portlet. Again a “project pane” and the layout pane appear. By the way, you can collapse the “project pane” to recover more useable space for managing properties or layout. In the layout pane there were not surprises here at all. However, I was a bit disappointed. I realize that this is (1) a beta and (2) the release teams efforts need to be spent on other chores but (3) it would be really nice if the content on the Getting Started Page was web content delivered through the Web Content Viewer portlet and not the “handy dandy” Information Portlet. What next?
Figure 2
I decided the best way to get a feel for how managed pages might be experienced would be to create a new project and edit a new page. Returning to the Home tab and the Getting Started Page I placed the page into the Edit Mode. Again, the product Wiki states, “There are several ways to enter edit mode: You can click Edit Mode directly in the user interface. A default project is created, with the project name being based on the page name and the date. You can change the project name later. The first thing to note is that the functionality for creating a page related project will be very familiar to users who have created pages with the Page Builder theme interface. (Figure 2).
Working from the Getting Started page I clicked the Edit Mode button. Right away a vital distinction needs to be made between making changes to a published site and making changes to a project that is not yet published. When stated this way the consequences may seem self evident. However, to a user unfamiliar with the interface they might surmise that the changes they make are not immediately visible. If they believe this, they are wrong. In this case I elected to create a new project. The properties of the project are self explanatory and for this exercise I elected to select Manual for the Publish option.
I created a new project named Demo Project. Figure 3 provides a before and after comparison of the interface as I moved through the steps to create a new project. You can select view or edit for a project from the project menu. Choosing the View on the Published site and a particular project allows you to see how one compares to another. Only the published site can be seen by the user community.
Figure 3
Now that we have an unpublished project I added a page, Demo Page. If you want to follow my experiment, make sure you have an unpublished project and place it in the edit mode as illustrated in the “after” illustration shown in Figure 3 above. Then, select the More button and choose sibling or child page. I chose sibling to simply illustrating the concept. Figure 4 demonstrates this.
Figure 4
Page creation in the context of a project such as the one illustrated in this topic places management of the portal page artifact into a Web Content Management (WCM) library. This means that “Publishing of projects can be scheduled in the same manner as other traditional WCM components. Additionally, this means that managed pages, as a form of managed content, can be syndicated from an authoring environment to a rendering environment. To my mind this is a huge leap forward in portal site development because it is very plausible that revisions to a site would not only incorporate changes to the content that authors might submit but also pages and related artifacts for presenting content. Syndication does not include propagation of portlets or other web archive (JSP for example) resources.
Before creating the page you can change to another template type. Additional page templates can be defined. Page templates are not a new feature but it
Figure 5
will be interesting to see how these are leveraged in the future as more portal and WCM administrators take advantage of the managed pages feature. See Figure 5 for an example.
Once a page and other artifacts are added to a project you will typically refine their properties. Now that we have a page it will be useful to finalize one more aspect of how managed pages work. Keep in mind that the interface seen by our administrator references the published site as well as the projects that are in progress. In our example we have a Demo Project. By alternately clicking the View link for either the project or the published site we can quickly visualize the distinction. Figure 6 illustrates this and in Figure 7 and 8 we show how members of a project are published and, in turn, how the published site is altered.
Figure 6
As mentioned, here are screen shots to illustrate HOW an artifact is published.
Figure 7
NOTE: It may take several minutes for publish to complete. Be patient!
Figure 8
Taking Notez - Island Pond Consulting 