Export and transfer parts of a portal configuration

To export partial configurations, specify the XML hierarchy down to the specific portal resource to export. For the portal resource element itself, specify an export action; for its parents, specify a locate action. The sample XML request file ExportPage.xml provided with the portal exports a page with the unique name...

ibm.portal.ssa.SamplePage

This exported page does not exist in a newly installed portal. We can create it by running the DeployPortlet.xml sample file, which is covered in the next section.

Use the Custom Unique Names administration portlet to look up object IDs and unique names of portal resources. Some resources also support lookup by other attributes.

Running the ExportPage.xml example request file results in an XML file similar to ExportPageResult.xml. Use this file to update the page to the exported state, if it still exists in the portal. We can also use this file to re-create the page, in case you delete it later. The file includes not only the page itself, but also other configuration elements referred to by the page, for example the portlet placed on the page. These other elements have a locate action. The export does not include their full configuration data, but enough information to look them up in the portal, assuming they exist. The configuration of the page makes references to the objectid attributes of other resources, for example in the portletref attribute of the portletinstance elements. All those references are described by object IDs. If the object IDs are correct, the referenced resources can be looked up in the portal even if they were not included in the export. Locating resources before they are referenced is only necessary if we do not know their actual object IDs so that we must find the resources by some other identifying attribute. See the XML reference documentation. That way, for example a portlet can be identified by its name and by the uid attributes of its parents, and the referencing still works, even if the object ID is not available for looking up the portlet.

Exporting resource configurations normally creates update actions for all exported elements. This means that if the portal resource exists on the importing system, the settings are modified, and if it does not yet exist, it is created. This in turn means that if you reimport the page into the portal exported it from, nothing changes.

We can import the XML file into another portal to create a copy of the page, this importation requires the referenced resources (such as the portlet and the content parents) also exist on the target portal and can be found by an identifying attribute. In that case, the page and all contained resources take their object IDs with them so they have the same object IDs on the source and target system - the resources retain their identity. We can avoid that using the ID generating mode. See the XML reference documentation. When we use the ID generating mode, the object IDs in the input are not taken literally, but during the import process the resources obtain new object IDs when they are created on the target system. We apply ID generating mode by adding the following attribute to the main request tag:

<request . . . create-oids="true" . . . >

We can create a duplicate of the page in the portal from where we exported it using the ID generating mode and changing the unique name of the page in the XML script. This way, the page, and its changed name, cannot be found for updating by either its object ID or its unique name, therefore a new page with the same settings is created. Change the page title so we can distinguish between the two pages. The CopyPage.xml sample shows how this script would look.

When we are exporting resources to XML scripts, it is possible and often useful to export several resources using one request. The ExportPortletAndPage.xml example extends the ExportPage.xml example by including also the portlet contained on the page. The resulting XML file contains the complete configuration data of the portlet and the page. The ExportSubTree.xml example shows how we export subtrees of the portal content hierarchy. It exports part of the predefined administration page hierarchy created during the portal installation.

Use wildcard characters:

When we export portal resources, we can specify the asterisk (*) as a wildcard character for tag attributes. Be aware of the following limitations:

1. The asterisk wildcard character is supported for attributes of top-level tags only, that is, subtags of the portal tag.

2. Specify the asterisk wild character for the object ID attribute of tags as follows: objectid='*', except for policy-node tags, where we can specify it for the path attribute.

3. Specify only the asterisk alone: "*".

   The asterisk does not work in combination with partial strings that precede or follow it. For example, we cannot specify "abc*" or "*xyz".

4. If we specify the asterisk as a wildcard character, all other attributes of that tag are ignored, except for the following tags, where the listed attributes are interpreted as filters:
   • The tag content-node, attribute create-type
   • The tag tag, attribute locale.

The ExportAllPortlets.xml example shows the use of the asterisk character (*) as a wildcard to export all resources of a given type. This example exports all the web modules that were installed in the portal and their contained portlets.

Parent Transfer portal configuration data using xmlaccess.sh

Related reference:

XML configuration reference
Sample XML configuration files