ALUI Administration Tool for Environment Refresh: String Replacing for URLS

Any company that owns a portal infrastructure such as ALUI will usually also plan for extra portal environments for troubleshooting and test purposes. Any portlet developments, portal customizations, or administrative changes will be implemented and tested in those environments. This is very good practice indeed. But you will quickly notice something happening: Your production portal is no longer in sync with your other staging / QA / Test environments. Although not necessarily a huge deal in the immediate future, that could become a problem when your test environment is really too different from the production one: Imagine the test team trying to execute a test plan in Staging environment, but half the production communities are simply not present in the test environment...etc...etc...etc...

I am sure you figured where I am going: Sooner or later, a clean refresh of your tests environments will be needed. Such a refresh is best done by a full database copy from production to your test environment (ALUI built-in export / import functionality is not suited for a large amount of objects, and thus is totally inappropriate and not recommended in the present case)   

Besides restoring all the appropriate repositories (documents, published content, search indexes etc...), a major problem remains: All the various service' urls specified in the various ALUI objects (Remote servers, web services, KD cards, server urls, etc...) are no longer accurate in the refreshed test environments (of course: those urls are the production ones). Thus  your test environment is far from working yet.

2 possibilities from here (1 good and 1 less good):

• You use host files in your test environments. These hosts files will direct the same production urls to the appropriate test servers (not good in my point of view because it is dangerous: if the hosts files is removed, there is a huge risk of having your test environment accessing production - thus not good :) )
• You use environment-specific DNS entries for each services. (Much better because no risk of inter-environment communication)

First, it is much better practice to call each service through DNS name rather than directly to through the server name. And secondly, it makes it much easier when it comes to environment refresh.

Why? Because all the DNS entries follow a global "intelligent" pattern (i.e. PUBLISHER.COMPANY.COM / PUBLISHER-TEST.COMPANY.COM / PUBLISHER-DEV.COMPANY.COM / etc...), it is much easier to create a tool (or a DB query for those DB gurus out there) that will allow for automatic replace of these DNS names.

That's where I wanted to lead you:

I created a tool that allow just that: for all the portal objects that contain URLs, the tool can replace a specific pattern with another one that you define. Although I could have created a set of DB queries that could do the job (I actually started to do that when I had to do my first environment refresh), I realized that a utility written in JAVA (most portable language) and using ALUI server API would guaranty portability, extensibility and reusability. The main advantage is that it is completely independent from backend technologies, and can work with any ALUI portal (.NET or JAVA), as well as any database (MS SQL or Oracle). It has been tested with JRE 1.4 and used by me on all G6 portal versions (until 6.1 MP1 included)

DISCLAIMER: ALTHOUGH I PERSONNALY USE THIS TOOL, THERE IS NO GUARANTY; SO USE THIS TOOL AT YOUR OWN RISK blah blah blah AND USE IT ONLY IF YOU ARE PROFFICIENT ENOUGH WITH ALUI PORTAL TECHNOLOGIES.

2 smart moves if you are not the easily scared type of person: First, make a DB backup of the test environment you are going to refresh, and second, test it in your local environment first, and see with your own eyes that it works perfectly well :)

For the moment, this migration utility only updates the main portal objects that contain urls:
    -Remote servers
    -Web Services
    -Portal Settings

When I have time, I'll improve the utility and include publisher content items (especially urls embedded in them) in the list of migration objects.

Shell scripts (.bat and .sh) are created in order to facilitate and secure the usage of this utility. The user must provide several key information for the program to run:
    -Application name (by default: portal)
    -Administration username (must be an ALUI local database user)
    -Username password
    -Pattern to look for (any valid regular expression)
    -Replacement String
    -Optional: Debug mode? (if true, details of the parsed objects is output to screen)

The executable JAR along the appropriate launch scripts (bat for windows, sh for unix/linux) must be copied into the <PT_HOME>/bin folder in order to access the required libraries (otherwise the shell script -especially the java classpath- can be changed appropriately)

I zipped this tool (scripts and jar) for your convenience and uploaded it (pturlreplace-1.0.zip) to my google code project (http://code.google.com/p/alui-toolbox/).

Let me know what you think of it after you tested it. If you think it is useful, I'll update this post with new version of the tool as I come up with it. Enjoy!

Technorati Tags: ALUI Portal,Portal Maintenance,Technical Tips,Tools

ALUI Portlet Monitoring Tool

Most ALUI Portal environments will usually contain a large number of portlets, either "out-of-the-box" or custom portlets. These portlets, which range from simple bookmark links to sophisticated applications that interact with third party products such as Siebel or SAP, are indeed the major components that serve the high value functionality of your ALUI portal. Thus, it is vital that these portlets are monitored properly, so that a problem can be detected as soon as possible (preferably before your customer calls you to report the error that you had no idea was occurring...) and of course corrected asap.

Developed by Project Performance Corporation (www.ppc.com), Portlet Monitor® is a utility designed to track the operational status of all portlets registered in any communities or mypages of your ALUI Portal environment. Although Rakesh Gupta from PPC is the creator of this product, I personally redesigned and upgraded it for version 6.X of ALUI, and thus know the internals of it inside out.

You can contact me (fsanglier-at-ppc-dot-com) if you need additional information and pricing.

What is it?

Portlet monitor is a stand alone application (developed in .NET) that uses the Port

al Server API to read the portal data, especially the community and portlet objects. It can be installed on any server that have the following components: Portal, Automation, or API Service (to be able to use the server API). Using windows automated tasks (or even ALUI automation server) portlet monitor can be configured to run at any pre-specified time.

How does it work?

In plain English, Portlet Monitor connect as a portal user (by initiating a portal session) and iterate through all communities, mypages and finally portlets (the ones that are actually used on the community or "My" pages) that this user has access to. For each of the portlet found, Portlet monitor will "fake" a gateway call to the remote server hosting the portlet, passing all the required portal preferences and other ALUI-specific settings to the remote portlet application.

Error Found?

Various types of error can be caught by portlet monitor:

• Various HTTP Errors (500 / 401 / etc...) returned by the remote portlet application/web server.
• Portlet Timeout errors
• Network errors (remote portlet server has some network problems)
• Portal exceptions (portal settings or portlet preferences missing, problem with gateway component or any other portal internal component, etc...)
• Specific error text pattern found in the portlet (if the above errors are not found, an error can be triggered if a specific text patterns is found in a specific portlet)

Results?

The result of each run is locally saved in an XML file that contains the following:

• The portlet ID
• The community / mypage of the analyzed portlet
• Processing Time
• If "Broken", the last date/time the portlet was found "Working"
• If "Broken", the cause of the error (exception trace or error code)

After each run, an email containing the above XML report is automatically sent to the specified email list. (usually portal administrator and specific portlet developer(s))

It is also possible to eventually serve the XML report directly in the portal through a portlet (with a XSLT applied of course)

Performance?

Portlet monitor can be installed on any windows server that contains either the portal, automation or API service component (It is important to note that the portal component service does not need to be running) Thus, to minimize the performance impact of portlet monitor successive runs, it is recommended to install it on a server that is not part of the live portal cluster.

Why using this Tool versus Enterprise Monitoring Tools?

While most enterprise monitoring tools (i.e. NETIQ) work from the component service (or process) point of view, Portlet Monitor works from the portal point of view. What does it mean exactly?

Basically, enterprise monitoring tools are able to to monitor windows services, and eventually restart them if something wrong is happening. They are also able to monitor component log files and search for any text pattern that are relevant to an error, and if found, perform a specific action. (like restart the service) They are also able to perform a lot of other various operations...

But what they are not able to do in a portal context like ALUI (versus Portlet Monitor) are:

• Detect the errors before the end-user finds it (by running the portlet monitor scans at scheduled intervals) - compared to finding the errors in the log files when the end-user actually triggered the error himself...
• Detect point of failure(s) between the portal and the portlet remote server
• Detect portal application or database defects (i.e. gateway problem) that could induce the portlet in error (from portal point of view), even if the remote application is just working fine.
• Detect misconfiguration of the portlet that could induce the portlet in error (from portal point of view), even if the remote application is just working fine.
• Detect any infrastructure or software errors that would induce a timeout of the portlet.
• Detect any portlet errors even if the monitoring agent is not running (sometimes the monitoring agent can have defect too...)
• Detect any portlet errors even if the portlet application service is in a "Frozen" state (meaning the service is still up, the log are not showing any error, and thus the monitoring system is not reporting anything wrong, but the application is actually not responsive anymore)

It is important to note that portlet monitor is just a monitoring and notifying tool: It does not perform any action (like restarting services etc...) other than notifying the right people.

Last Words

If you don't have a monitoring infrastructure in place, this tool will offer you monitor effectively the most important and valuable components of your portal (portlets).

If you have already a monitoring infrastructure in place, this tool is not meant to replace it, but rather to be a valuable addition that completes your monitoring infrastructure already in place.

Technorati Tags: Aqualogic User Interaction,ALUI Portal,Tools