1 / 13

XMLaccess for WebSphere Portal

XMLaccess for WebSphere Portal. Sherwood Yao, Senior Developer. Agenda. Background, what can XMLaccess do (and cannot) Basic concept of portal configuration Usage of Xmlaccess: steps, types and operations Best practices of using XMLaccess Virtual Portal considerations.

juanevans
Download Presentation

XMLaccess for WebSphere Portal

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. XMLaccess for WebSphere Portal Sherwood Yao, Senior Developer

  2. Agenda • Background, what can XMLaccess do (and cannot) • Basic concept of portal configuration • Usage of Xmlaccess: steps, types and operations • Best practices of using XMLaccess • Virtual Portal considerations

  3. Why we need xmlaccess • WebSphere Portal (WP) stores most configuration and user data in database tables • But you cannot modify databases directly using SQL. • XMLaccess is the tool for the end user to interface with the backend data. • You can transfer a entire portal configuration or just a subset of a portal

  4. So What xmlaccess can do? • Xmlaccess can transfer • Whatever is stored in XML configuration database (wpsdb), such as • Pages, portlets, and the relations built on top it • Theme and Skins • Users and groups • Except the following (pay attention to this) • WP configuration modified on WAS • E.g. your portal datasource, portal mail provider etc • Actual file transferring • (war file, theme skins)

  5. Basic concepts of config data • ObjectID: machine generated ID • Portal ObjectID attribute is a globally unique ID stored in a portal database to allow the portal uniquely identify a portal resource. • Guaranteed to be unique when resource newly generated • Can be the same if use xmlaccess to move resources • Once created, the ObjectID cannot be modified. • UniqueName: human version ID • UniqueName is a human-readable ID that serves the same purpose as identifying portal resources. • UniqueName must be unique in a portal database. • UniqueName can be set via Portal admin portlet • UniqueName can be changed after it is created.

  6. Example of OID and Uniquename <?xml version="1.0" encoding="UTF-8"?> <request ….> <portal action="locate"> <content-node action="locate" objectid="_6_0830654DUD0K11PB_35" uniquename="wps.My Portal"/> <content-node action="locate" objectid="_6_0G0ALN1D5C0Q1TQ7_LT"/> • here you see two pages (<content-node>) have objectid and/or uniquenames • Objectid was created when resource was created. It is always there. • Uniquename is optional. • Out of the box, many portal resources already have uniquenames • You must define uniquename for the resources you want to move

  7. export import XML XMLaccess demystified • It is THE cmd UI to export and import portal config data. • XMLaccess is client and server • Server portion (servlet) runs on Portal server JVM to listen to client request • Client portion is a command line tool takes input xml and generate output xml.

  8. Two steps of operation • Export • Executed on source server • Input is a list of resources to be exported • Output is the actual configuration of the resources in portal • You need to create (or steal) the input XML file • Import • Executed on target server • Input is the exported XML • Output is the result/status of execution

  9. Portal object types and hierarchy • Portlet WAR: <web-app>, Porltet APP: <portlet-app> and Porltet <portlet> • <web-app action="locate" uniquename="warUniqueName"> <portlet-app action="locate" uniquename="appUniqueName"> <portlet action="export" uniquename="portletUniqueName"/> • </portlet-app> • </web-app> • Pages: <content-node> • <content-node action="locate" objectid="_6_0830654DUD0K11PB_35" uniquename="wps.My Portal"/> • <content-node action="update" content-parentref="_6_0830654DUD0K11PB_35" • Theme and Skins: <theme> and <skin> • <theme action="export" uniquename="themeUniqueName"/> • <skin action="export" uniquename="skinUniqueName"/> • Url-mapping: <url-mapping-context> • <url-mapping-context action="export" uniquename="urlUniqueName">

  10. Virtual Portal considerations • Each virtual portal has its own URL pattern • E.g. http://host/wps/portal/vp1/something_else • You must connect to the corresponding xmlaccess servlet URL, http://host/wps/config/vp1 • Multiple Virtual Portals share resources • Porltets, themes and skins • You don’t need to transfer these shared resources using xmlaccess

  11. Best practices: remember this • Use examples provided as starting point • Make sure the resources are moved without breaking the dependency • If you transfer portlet, you must move the portlet war file first • If pageA contains portletA, you must move portletA first, or your pageA transfer will fail. • Portal resources operation are recursive. Embeded resources will be moved always together! • When you move a war, all its portlets/portlet apps get moved • When you move a URL mapping context, all its subcontext will be moved

  12. Best practices (continued) • No implicit delete on its children, • For example, pageA contains children pageB on src, same pageA contains only pageB and pageC on target, when you transfer pageA from src to tgt, pageC will not be removed. • Theme and Skins are special • Migration to a portal cluster requires you rebuild wps.ear and deploy wps.ear in a cluster before you run xmlaccess • Use ANT or other scripting language to automate things • Make sure you move everything that need to be moved

  13. Questions

More Related