Importing XML Schema file for xmlAccess scripts
If you are new to WebSphere Portal, and setting up a test/staging /production environment, then you should closely familiarize yourself with the XmlAccess interface. This is the command line scripting interface. Yes, you are probably thinking “command line?? why got out of the green screen stone age years ago!”. Well that’s fine and dandy, but think about this, once you have a test system up and running, how are you going to get it out of there and into your staging environment? Run through the GUI again? What happens, when you need to continually be adding new features, testing them, and pushing them into staging for integration testing? Yes, clicking through a GUI seems a bit overwhelming. That is why we still have command line interfaces.
With the XmlAccess interface you can export a page, a theme, skins, personalization rules, etc. Then you can import them into the target server with the exported results. It also lends it self to an automated test and build process. If you want to know more about this, either leave a comment or shoot me a line.
Those of you already familiar with XmlAccess, but would really like the bring in some context sensitive (control-space) functionality you get with other XML files, you can import the portal xml schema into your Rational Application Developer. The schema file is located under the
This makes it much easier to build out an XmlAccess file, as RAD will read the XSD and present options for legal values in the editor.
Who really wants to remember the exact format of the schema anyway?
xmlaccess is important, but painful. it does not “replace” or “synchronize” when you target a portal on a different tier. rather it just “updates” whith whatever it has. So if you intended to delete a page in Development then do xmlaccess to Production, it will not delete the page from production.
We have resorted to deleting everything from the target portal before running the xmlaccess import to ensure everything is in sync. Prior to v6 of portal that had the bad side affect of deleting all user customizations.
The good news is that IBM is working to improve the whole deployment/lifecycle of portal applications.
Pete K