WebSphere Portal Server - xmlaccess : export a place

Author

xmlaccess : export a place

kdefty

2004-01-19, 2:54 pm

I know this issue has been posed by others before but I don't believe it really got any attention or answered.

Is it possible, using xmlaccess for WPS 4.2.1, to export a place in one shot? That is to say, is there an equivalent xml input to that required to export the whole portal for a place?

The goal here is to export a complete place ( including all references to skins, themes, detailed page layout and container permissions, etc., etc. ) from say a QA system and import into a production system for create/update.

I know we can do this by exporting the complete portal and extracting the pieces we need to compile a new input file that will create the place. However, this is very tedious and there must to be way to build an input xml file that will export the place w
ithout having to know in advance everything that is required to reassemble the place in question.

Have tried several forms of xml input but best I can do is produce xml output that is not detailed enough to describe the place ... again, assumes various components pre-exist and no real detail regarding container layout and permissions, etc.

Any insight gratefully appreciated.

Thanks & Cheers, ... Keith.

imsakar

2004-01-19, 2:54 pm

This not possible as far as what I had info from IBM (top level) support. You have to have references to your root element. XML Access is good for new installs but is lame when it comes to granular administration and control.
Also, I second your opinion about how hazy it is to work and hunting down the references in the XML file

XMLAccess one thing that definitely needs improvement in portal - because there is absolutely on way in real world that administrators going to accept the GUI way of administration/deployment.

Darrell Rials

2004-01-19, 2:55 pm

I think IBM support is being lazy about this. I have had some success in
exporting a place and its pages from one machine, and then importing this
place and its pages to another machine. It is somewhat of an error prone
process, but it does work if you are careful.

A few things to keep in mind about this:
(1) prior to importing a page, you have to have added all of the portlets
that will belong to the new page to the target portal server. All of the
portlets that will be added to the page have to be referenced in the XML
file prior to the page definition XML.
(2) In WPS 4.2, there is a toplevel, "pseudo" page group called
"Root.Composition". It is somewhat tricky to locate this object using an
xmlaccess <composition> tag. I found that I had to exactly specify the
"owner" attribute or xmlaccess could not unambiguously locate the object.
Below the "Root.Composition" <composition> tag, there is a toplevel
<component> tag called "Home" (on the WPS 4.2 portal servers that I am
working on, at least). All of the administrator-defined places appear as
<component>'s contained within the "Home" component.
(3) You must define the pages in the input XML file before you can reference
them in the place definitions.
(4) You must use action="create" in the <composition> tag that defines the
place.

I have some working samples that I can send you by request. They are rather
lengthy, though, so I won't include them here. (If you want to see them,
email me at "drials at sbiandcompany dot com". You'll have to fix the
reply-to email address in the news header; I use a "fake" email address in
the header to prevent spam.)

By the way, I agree that xmlaccess leaves much to be desired. However, it
will work for this particular thing if you are willing to spend the time
experimenting with it.

Also, why is IBM's documentation so wrong on the format of the xmlaccess
input file? (For example, their documentation talks about a <pagegroup> tag;
there is no such thing.)

Cheers,
Darrell

"imsakar" <sakar_kawle@troweprice.com> wrote in message
news:764206647.1053637064851.JavaMail.wasadmin@swg3ws006...

quote:

> This not possible as far as what I had info from IBM (top level) support.

You have to have references to your root element. XML Access is good for new
installs but is lame when it comes to granular administration and control.

quote:

> Also, I second your opinion about how hazy it is to work and hunting down

the references in the XML file

quote:

>
> XMLAccess one thing that definitely needs improvement in portal - because

there is absolutely on way in real world that administrators going to accept
the GUI way of administration/deployment.