Sample XML configuration files

Sample XML configuration files

Sample files are provided for reference to help illustrate how to use XML configuration for different portal configuration purposes. Before you use them, read the other topics about xmlaccess.sh carefully. Many of the samples need to be modified with valid page or user name before they can be used.

Sample file location

Sample XML configuration files are found in...
$PORTAL_HOME/doc/xml-samples

Sample file list

This list is not complete.

Export.xml

ExportRelease.xml

ExportPage.xml

ExportPageResult.xml

CreatePage.xml To not set page title for portal locales, set for default system locale of the portal.
CreateCsaPage.xml

CreateLegacyPage.xml

CreatePageFromZip.xml

CreatePageFromTemplate.xml

DeployPortlet.xml

ClonePortlet.xml

ModifyPortlet.xml

ExportPortletAndPage.xml

ExportSubTree.xml

UpdateAccesscontrol.xml

UpdateVault.xml

CopyPage.xml

CreateURL.xml

CreateUser.xml

CreateLanguage.xml: Add a new language for the portal.
To define a new language for the portal, set the title for the new language in all locales that are supported for the portal in the XML file. If you do not want to set the title for all portal supported locales, you need set the title at least for the default system locale of the portal.
DeployTheme.xml

ExportAllPortlets.xml

Transaction.xml

MovePage.xml The actual move of the page is done by the last two lines.
ActivatePortlet.xml Change the states of portlets, portlet applications, or Web applications between active and inactive by setting the attribute active of the appropriate tag to true (for active) or false (for inactive). The sample activates the respective resources.
Task.xml Create a scheduler task for cleaning up portal resources...
com.ibm.portal.datastore.task.ResourceCleanup

Run with default settings to immediately perform cleanup.
RegisterPreDeployedEAR.xml Install a predeployed portlet. You might have to change this sample for requirements.
For the deploy_target_directory in the url tag specify the directory to which you deployed the EAR file on the WAS. The default target directory is AppServer, but when deploying portlets for the portal it is a good option to specify PortalServer as the target directory.
This XML sample script works only for portlets that are written to comply with the IBM Portlet API. For portlets written according to the Standard Portlet API you have to adapt the sample. In this case consider the following hints:

With the web-app tag Standard API portlets do not have a uid attribute. Use the id attribute of the portlet-app tag in the file portlet.xml instead. Append webmod to the end of the id attribute to make up the uid.

With the portlet-app tag Standard API portlets do not have a uid attribute. Use the id attribute of the portlet-app tag in the file portlet.xml instead.

With the portlet-app tag Standard API portlets do not have a name attribute. Remove the tag for Standard API portlets.

An EAR can hold more than one WAR file. To configure the pre-deployed portlet resources into portal you need to reference each Web Application resource separately in the XML configuration script. Provide a dedicated <web-app> statement with the corresponding data in the XML script for every WAR file that contains a portlet application in that EAR file.
CleanupUsers.xml Identify users and groups in the portal database who have been removed from the user registry, but not from the portal database.
Set both cleanup-users and export-users to true
Creates a file that:

Lists removed users and groups and marks them for deletion
Lists users who have been muted, for example after too many wrong password attempts.

Before re-importing the file, remove users and groups that you want to keep in the portal database. During XML import all users and groups that remain listed in the file will be removed from the portal database.
After deleting these entries via the modified XML script, all customizations are lost for the deleted users and groups.
ExportIncludingOrphanedData.xml Perform an export that includes all orphaned data. You do this to prepare for deleting the orphaned data. Note that this sample uses the request type export-orphaned-data.

Parent
xmlaccess.sh
About xmlaccess.sh
Manage portal resources with policies

Related tasks

Deploy J2EE resources with portlet application WAR files
Export a Producer definition by using xmlaccess.sh
Create a Producer definition and consuming a WSRP service by a single XML script
Changes to xmlaccess.sh for this version of portal
XML configuration reference
XML samples for creating Producer definitions
Automated tasks for composite applications

Work with xmlaccess.sh

+
Search Tips | Advanced Search

Export.xml
ExportRelease.xml
ExportPage.xml
ExportPageResult.xml
CreatePage.xml	To not set page title for portal locales, set for default system locale of the portal.
CreateCsaPage.xml
CreateLegacyPage.xml
CreatePageFromZip.xml
CreatePageFromTemplate.xml
DeployPortlet.xml
ClonePortlet.xml
ModifyPortlet.xml
ExportPortletAndPage.xml
ExportSubTree.xml
UpdateAccesscontrol.xml
UpdateVault.xml
CopyPage.xml
CreateURL.xml
CreateUser.xml
CreateLanguage.xml:	Add a new language for the portal. To define a new language for the portal, set the title for the new language in all locales that are supported for the portal in the XML file. If you do not want to set the title for all portal supported locales, you need set the title at least for the default system locale of the portal.
DeployTheme.xml
ExportAllPortlets.xml
Transaction.xml
MovePage.xml	The actual move of the page is done by the last two lines.
ActivatePortlet.xml	Change the states of portlets, portlet applications, or Web applications between active and inactive by setting the attribute active of the appropriate tag to true (for active) or false (for inactive). The sample activates the respective resources.
Task.xml	Create a scheduler task for cleaning up portal resources... com.ibm.portal.datastore.task.ResourceCleanup Run with default settings to immediately perform cleanup.
RegisterPreDeployedEAR.xml	Install a predeployed portlet. You might have to change this sample for requirements. For the deploy_target_directory in the url tag specify the directory to which you deployed the EAR file on the WAS. The default target directory is AppServer, but when deploying portlets for the portal it is a good option to specify PortalServer as the target directory. This XML sample script works only for portlets that are written to comply with the IBM Portlet API. For portlets written according to the Standard Portlet API you have to adapt the sample. In this case consider the following hints: With the web-app tag Standard API portlets do not have a uid attribute. Use the id attribute of the portlet-app tag in the file portlet.xml instead. Append webmod to the end of the id attribute to make up the uid. With the portlet-app tag Standard API portlets do not have a uid attribute. Use the id attribute of the portlet-app tag in the file portlet.xml instead. With the portlet-app tag Standard API portlets do not have a name attribute. Remove the tag for Standard API portlets. An EAR can hold more than one WAR file. To configure the pre-deployed portlet resources into portal you need to reference each Web Application resource separately in the XML configuration script. Provide a dedicated <web-app> statement with the corresponding data in the XML script for every WAR file that contains a portlet application in that EAR file.
CleanupUsers.xml	Identify users and groups in the portal database who have been removed from the user registry, but not from the portal database. Set both cleanup-users and export-users to true Creates a file that: Lists removed users and groups and marks them for deletion Lists users who have been muted, for example after too many wrong password attempts. Before re-importing the file, remove users and groups that you want to keep in the portal database. During XML import all users and groups that remain listed in the file will be removed from the portal database. After deleting these entries via the modified XML script, all customizations are lost for the deleted users and groups.
ExportIncludingOrphanedData.xml	Perform an export that includes all orphaned data. You do this to prepare for deleting the orphaned data. Note that this sample uses the request type export-orphaned-data.