Originally published at developer.com
Before Service Pack 5 (SP5), the most dreaded day of some portal projects was the push to production. If you have a fairly decent deployment plan, getting the portal EAR into production was a snap. What profited the pizza industry with the late-night dinner orders was moving all of the settings that are stored in the database from Staging to Production. Entitlement roles, groups, and the association of entitlements to portlets had to be re-created by hand. Because these deployments often take place after hours, the person with the pleasure of creating them will almost always make some mistake that takes hours to trace down. The mistakes aren’t because it is terribly difficult, but because even if you get to come in late for these deployments, you still probably woke up at your usual hour and are starting to fade a bit. That, and few deployment documents are perfect. The propagation tool is here to rescue you.
The propagation tool is built into SP5 and SP6, and is available as a patch upgrade to SP4 (note: there are other patches included in this download, so this may entail risk depending on what APIs you are using). For earlier versions, you need to contact your BEA representative.
There is an official manual for the propagation tool on the BEA site, which I recommend if you want every nuance. What I will cover here is a typical, simple, straight-forward approach that will save you some time. I also deviate a bit here for the sake of doing the process faster, knowing that time is often a factor when you get to your deployment phase. As with any process, I highly recommend doing a dry-run in a test environment first (mostly because I own no stock in pizza companies). The steps described here are for SP5. They should be the same for SP6. If you wish to attempt this on an earlier version, I suggest going to the link mentioned earlier.
First, you need to put the tool where you can use it. Copy propagation.war from <WEBLOGIC_HOME>weblogic81portallib to the root of your Staging domain (or Integration, if you are moving to Staging). To make sure you put it in the right place, make sure that adminPortal.war is already in the same path you are copying to.
Start your server through Workshop, then go to <DOMAIN_ROOT>META-INF and open application.xml in your favorite XML editor. After the last <module> entry, add the following:
<module>
<web>
<web-uri>propagation.war</web-uri>
<context-root>propagation</context-root>
</web>
</module>
When you save the file, Workshop should detect the update and automatically deploy it to the server for you. If for some reason it doesn’t, you will need to stop your server, open config.xml, and manually add the following to the end of your <Application> node:
<WebAppComponent Targets="genericPortalServer" URI="propagation.war"/>
Once your server has started up again, check your installation by going to http://<SERVER>:<PORT>/propagation (example: http://localhost:7001/propagation). You should see the following screen:
From the screen the next step should be obvious: Click Export an Inventory. The application will walk you through the steps with fairly clear instructions (you’re welcome to read them all, based on your paranoia level or the fragility of your application). The steps are as follows, with only minor comments where necessary:
- Enter the user name and password for the uber admin account
- Click Continue
- Click Export XML
- Click Export Locally and save to someplace convenient (unless you are propagating to an domain on the same machine with read-write privileges)
Export complete! That was easy, wasn’t it? Now you need to import it. Again, I’m going to pare things down for the simple, straight-forward process here. If your application is really, really complicated, fragile, or you just have a lot of time on your hands, you can read the full documentation at http://e-docs.bea.com/wlp/docs81/sp5/prodOps/propTool.html#1025334.
First, you need to install the propagation application on the target server. Copy the same war file to the same place in your new domain. Then deploy your portal EAR to the new domain. So long as you create the EAR after installing the propagation application on the original server, you shouldn’t have to do anything else. If for some reason it doesn’t work for you, follow the same installation instructions given above for the original server.
The import process is also very simple, and has step-by-step prompts. With lots and lots and lots of warnings. Again, we’re going to cover the short path here. And, again, read the docs at the link given earlier if you have concerns. For me, the longest part was reading the warning labels.
With the EAR and the propagation application deployed on the target server, open the propagation application the same way as before, only with your new URL (http://mynewhost:7001/propagation), and do the following:
- Click Import an Inventory
- Log in
- Click the Specify the file radio button
- Enter the full path to the zip file you created in the export process, including the file name, i.e., I:DeveloperDotComPropagating BEA Portalsinventory.zip
- Click Continue (if you see The input file was not found. The application tree was loaded instead., check your path)
- Click Continue
- Click Preview Changes
- Click the checkbox, then click Continue
- Click Deployment Complete
- Click Continue
- Click Continue
- Scroll to the bottom and Click Continue
- On the Review Manual Changes page, there will probably be a list. This is why I recommend a dry run, because you may not need to do anything with this list, so click Continue the first time and out and note during your testing if anything needs to be dealt with. Note that users are not exported, and this is addressed later in this article.
- Click Continue
- Click Commit the Inventory
The next screen has you export what you have just imported. Again, for the dry run, I wouldn’t bother. For the real deal, though, it is a good best practice.
You can now go to your new portal URL and review how well things turned out for you. You will need to add your users to do much real testing. If you have an authentication method that relies on an external application, you will need to test and possibly reconfigure it for your new domain. If you use the internal LDAP, you should create your users before testing.
While not considered a best practice by BEA, it is a common practice to have the same users in Staging as Production, so I feel obligated to list the steps here to propagate these as well.
In your original domain, go to the Weblogic Server Console and navigate to your security realm and click on the Migration tab and then the Export tab.
I prefer to enter a path ending with LDAP to make it easy to find. Click export, then check the path you entered to make sure you have the five expected files.
If necessary, copy the folder you exported to to somewhere where your new deployment can access it.
Now go to the Import tab in your new domain and enter the location to import from.
Despite the dire warning in the propagation screen, you should have most of your assets up and running, except some as noted in the Manual screen.
Now, go have dinner at home rather than the pizza.
© Scott S. Nelson