About xmlaccess.sh

xmlaccess.sh provides a batch processing interface for portal configuration updates, allowing us to export an entire portal configuration or parts of a configuration, for example specific pages, to an XML file. We can then re-create the exported configuration from such a file on another portal.

How do I access xmlaccess.sh?

We access xmlaccess.sh using a command line tool. This command line client is a small separate program that connects to the server using an HTTP connection or a secure HTTPS connection with SSL. It is therefore possible to configure the portal remotely.

Tasks we can perform with the XML configuration interface

These are typical tasks for which we use the XML configuration interface:

• Copy parts of a configuration, such as specific pages, from one portal to another. This usage scenario includes the case where you try out a new portal configuration on a test portal for evaluation, and then transfer it to a production portal in a separate step using the portal configuration interface.

• Install additional resources on a portal.

• Perform recurring administration tasks in an automated and reproducible manner.

Use of xmlaccess.sh for backing up or restoring complete portal configurations is restricted by the following limitations:

1. A complete XML export of a portal configuration is not sufficient to re-create the portal. We also need the WAR files for the portlets and possibly additional file resources, such as theme files if they are not part of the standard portal installation.

2. xmlaccess.sh is not designed to deal efficiently with large volumes of data. For a backup and restore solution on a production server, we should rely on low-level database and file system backups.

Access and security considerations

To use xmlaccess.sh requires the manager role on the virtual resource XML_ACCESS, and the security administrator role on the virtual resource PORTAL. This makes us a super administrator of the portal, who can perform any action. We can view, update, and delete all resources in the portal.

When we use an HTTP connection, the user and password are sent to the server unencrypted. Connect to xmlaccess.sh from inside a protected intranet where we can be sure the HTTP connection is not compromised. In all other networks configure SSL and use a secure HTTPS connection to connect to the XML configuration interface.

Overall structure of the XML input and output

There are two main types of requests that can be sent to the XML configuration interface:

Export requests

Triggers the export of complete or partial portal configurations into XML. Does not modify the configuration of the portal. It results in a response file.

Update requests

Modifies the configuration of the portal according to the values found in the XML script.

Export-orphaned-data requests

Export the complete portal configuration into XML, including orphaned data. It results in a response file.

Requests to and responses from the XML configuration interface use the same XML format. An export request generates an XML response containing all the configuration data required to re-create the exported configuration part. We can export a portal configuration, save the XML output file and, without modification, send it to another portal to re-create the same configuration there.

The XML schema is in a jar file found under ...

PORTAL_HOME/base/wp.xml/shared/app/

Unpack the JAR file and we will find the wp.xml file with the XML schema under...

com/ibm/wps/command/xml/PortalConfig_8.5.0.xsd

An XML request contains the following:

• A mandatory portal section

  Describes the parts of the portal configuration that should be exported or updated

• An optional status section

  In an XML response it indicates the success or failure of the requested operation. During the import of configuration data the XML processing ignores this section of the XML input file.

Representation of a portal configuration in XML

The XML hierarchy found under the portal section in the XML request file represents the structure of a portal as an XML tree. This tree contains resources in the portal, such as portlets or pages, and their configuration data. The XML hierarchy of all supported portal resources is shown in the following table:

XML element	Description
portal	Main element of every XML request
global-settings	Global portal settings
services-settings	Global portal settings for portal services
language	Languages defined in portal
task	Tasks used to schedule programs
action	Actions used to create action sets
action-set	Action sets used to create roles. Also known as Role Types.
virtual-resource	Virtual resources that have associated access control settings
resource-type	Resource types used to create custom resources.
protected-resource	A resource instance protected by Portal Access Control (PAC).
user	Users defined in the portal user management system
group	Groups defined in the portal user management system
markup	Markups that can be supported by portal pages
client	Client devices (browsers) the portal knows about
device-class	Device class information
skin	Visual appearance settings that can be applied to user interface elements
theme	General visual settings that can be applied to the user interface
wsrp-producer	Producer of web services as defined in the consumer portal
wsdl-url	The URL to the Producer's WSDL document
porttype	The URL to the service description, markup, registration, or portlet management of the Producer
web-app	Web modules containing portlets
url	The WAR file containing the web application
context-root	The context root assigned to the web application of the portlet application in the predeployed EAR file (reference: application.xml)
display-name	The name assigned to the application in the predeployed EAR file (reference: application.xml)
servlet	Servlets defined in the web module
portlet-app	Portlet applications defined in the web module
portlet	Portlets defined in the portlet application
federation-server	The federation server definition. This server is used to retrieve content nodes.
content-node	Elements of the portal content tree (pages or labels)
supported-markup	The markups supported by this content node
allowed-portlet	The portlets allowed on this page
component	Layout components of pages
component	Subcomponents in the structure of the page
portletinstance	Occurrences of a portlet on a page with customized settings
cross-page-wire	Property broker wiring between two portlet instances. The wire tag has been deprecated with WebSphere Portal v7, as it supports property broker wiring between two portlets on the same page only. Use the cross-page-wire tag as it supports property broker wiring between portlets on the same page and on different pages.
credential-segment	Segments for storing credentials in the credential vault
credential-slot	Slots in a credential segment that hold a credential
url-mapping-context	User defined URLs that map to pages in the portal
user-resource	Allow exporting and deletion of a specific user resources.
policy-node	Policies defined in the portal
application-role	A named set of authorization roles that can be assigned to users or groups.
wsrp-customized-portletinstance	A customized occurrence of a portlet provided by WSRP on a Producer portal
custom-resource	A custom resource that can be tagged or rated by users
category-instance	A category assigned to a custom resource
tag	A tag applied to a resource by a user
rating	A rating applied to a resource by a user
filter-instance	A filter for preprocessing data before the data is finally stored.

Depending on the content of an XML request, these resources can be created, modified, deleted or exported. An XML request can contain any number of such resource definitions. It can therefore create hundreds of new resources in one step or modify only a single configuration setting of one existing resource.

Parent xmlaccess.sh

Related concepts:

Portal administration tools

Related tasks:

Set up SSL
Delete orphaned data