Fast becoming the Swiss army knife of WebLogic Portal 9.2, I will discuss some non-standard uses for the WebLogic Portal Propagation Tool. In addition to a myriad of application provisioning use cases, the Propagation Tool can provide solutions to problems in areas such as Change Reporting as well as Backup and Recovery of WebLogic Portal applications.
NOTE: this blog entry was originally posted January 16th, 2007 on my previous blogging system (dev2dev.bea.com).
What is the Propagation Tool?
The Propagation Tool's primary purpose in life is to provision WebLogic Portal environments with configuration data. The provisioning can be done for a new WLP environment, or as a promotion of updates on top of an existing environment. A propagation is typically immediately preceded by the promotion of a new EAR file, which contains updates to the code artifacts of the application.
To support this primary mission, the Propagation Tool in WLP 9.2 supports these features:
- Exports database and LDAP configuration artifacts as XML files, all packaged into a single zip file (called an inventory file)
- Advanced reconciliation UI allows an operator to visually choose exactly how to reconcile the two environments
- Promotes the new configuration using the inventory file that came from the visual tool
- All operations can also be done using Ant tasks, as an alternative to the visual tool
For more information on the many features of the Propagation Tool in 9.2, please visit the official documentation. The docs take you through the primary use case of the Propagation Tool - moving WLP applications from one environment to another.
This blog entry covers some alternate use cases for the Propagation Tool. The toolset that we built is very flexible and can cover more than just promotion use cases. I will cover 2 use cases in this blog that uses the Propagation Tool on a single environment. Before I cover the use cases, I will talk about a best practice that is relevant to this discussion.
Best Practice: Historical Inventories
These use cases require that you create and retain a series of historical inventories for the environment. This is a good idea for so many reasons that we recommend that inventories be retained in source code control (if size allows) or a backed up disk drive (for huge inventories). The idea is to periodically take a snapshot of the environment and store that inventory. Think of your inventory as a peer to your code assets - the same care you put into maintaining historical versions of your code should be applied to inventories.
Note: inventory snapshots do not replace the need to do database and file system backups.
Use Case 1: Change Reporting
Do you ever wonder how much configuration work has been done in an environment over a period of time? The Propagation Tool can help answer that question. It provides a logical view of exactly what has changed in an environment, as an alternative to dredging through audit logs.
For example, imagine that you have taken a baseline inventory on December 1st. On December 15th, you want to see what Admin changes have been made to your WLP enviroment. To do this, export a new inventory and compare it the baseline inventory with the Propagation Tool Eclipse User Interface. The user interface will show you the net differences in a logical, visual format.
Use Case 2: Backup and Recovery
The pain of all operations people is to have to recover an application to a previous state. While traditional backup and recovery procedures are still relevant for WLP environments, the Propagation Tool can provide additional options that will help you get home in time for dinner. Database backups and file system backups can provide point in time recovery options, but may be too big a hammer for certain cases. The Propagation Tool is a more precise instrument, but it does not handle all configuration data , so it does have limits in a recovery role. I will show some cases where the Propagation Tool is the right tool for the job.
For example, imagine that your Portal Administrator deletes a page on a desktop in production accidentally, and the problem is not discovered for 3 hours. After flogging him with a bundle of network cables, what is your next step? A point-in-time database restore is probably not an appealing option, as it will take a lot of your time, will require application downtime, and will result in data loss of updates made after the mistake. Instead, consider a targeted propagation that fixes the problem at the logical level. Using a historical inventory, the Propagation Tool can be used to restore that specific desktop in the production environment. This can be done while users are interacting with the application, so it is a quick and easy approach. It is also precise - it will not disturb any configuration artifacts outside of the scope of the propagation.
Here is a table that suggests a toolset to use for different failure scenarios. In cases where only WLP artifacts in the application need to be restored, the Propagation Tool is generally the best option. The table shows a sample set of use cases, but in fact the Propagation Tool can handle many more types of data in a similar fashion. Also, it should be noted that any problem that is fixable using the Propagation Tool is also fixable by manually affecting changes through the Portal Admin Tool.
* For Portal Framework use cases, be aware that the Propagation Tool cannot restore end user customizations if the artifact was deleted, if any exist for that asset. For example, if a user made customizations to the deleted page, the Propagation Tool cannot restore that. If user customizations are important to recover, another tool called XIP could be used together with Propagation.
Additional Resources
- Propagation official documentation
- Propagation Tool Field Guide - best practices, known issues
- developer.com article - a look at the 8.1 SP5 web app based Propagation Tool (an ancestor to the 9.2 tool)
No comments:
Post a Comment