Create and modify resources
With xmlaccess, in addition to copy and restore functinality, we can also install new resources into the portal.
We can start with an XML export and partially modify it to to accomplish our task, or we can modify one of the example files bundled with WebSphere Portal.
The examples use the ID generating mode and do not specify literal object IDs. Therefore, we can run them on any portal installation, as they do not depend on hardcoded object ID values. As noted earlier, using literal object IDs makes sense only if you really want to create two instances of the same resource, and if we have a controlled environment where we can guarantee that all object IDs the resources depend on have exactly the required values. As object IDs are difficult to use for identifying the resources, the examples assign unique names to most top-level resources. This way we can reference them later, and the resources are not duplicated if we run the scripts twice.
The example file DeployPortlet.xml deploys a portlet and creates a test page to display the portlet. Some of the attributes in the XML must match the corresponding settings that were defined in the portlet.xml deployment descriptor in the portlet WAR file. This is necessary so the XML processing can properly identify the contents of the WAR file. When to deploy a different portlet, we must not only specify a different WAR file but also adapt those attributes. Also, the configuration specified for the portlet is less than what we see in an XML export result for the portlet. For example, the localized titles are not included in the XML script. This is because those settings are specified in the portlet.xml deployment descriptor; we do not have to override them with xmlaccess.sh.
As Windows limits the maximum path length to 260 characters, the name of the WAR file must be 25 characters or less. Deploying a WAR file with a name that is more than 25 characters results in an error.
The CreatePage.xml sample shows the following extra possibilities:
- It assumes the portlet is already installed. Therefore, it uses only a locate action for the web module, not an update action.
- It sets a specific skin for displaying the portlet on the page.
- It shows how we can specify localized titles in properties files rather than include them in the XML script: the titles and descriptions for the page are now loaded from two properties files for two different languages.
Both examples use a simple page layout with just one row and one column. To generate more complex page layouts, use the administration portlets to create them. We can export the result to generate a template for the XML scripts.
When we create new resources, we might want to define specific access control settings for them, for example to make them visible to all portal users. The UpdateAccesscontrol.xml example shows the syntax for specifying different access control settings. This sample updates existing resources, but use the same syntax to define access control settings for new resources while we are creating them in an XML script. This sample also shows how we can specify access control user roles on virtual resources. This allows us to give a user access to all resources of a specific type that exist in the portal.
The CreateURL.xml sample defines a URL mapping for the sample page created with the DeployPortlet.xml example mentioned earlier. After creating the URL mapping, we can access the page directly by entering that URL in the browser.
The DeployTheme.xml example shows how use XML scripts to install new themes and skins into our portal. The XML scripts create these resources only in the portal database, so they can be used in the portal. In addition, we must write the JSPs that run the actual visualization and copy them to the resource directory specified in the XML before using the theme in the portal.
The ModifyPortlet.xml example changes settings of a portlet instance shown on a page. Such settings are normally set in the edit mode of the portlet. It depends on the code of the portlet which settings are stored and how they are used.
The CreateUser.xml example imports a new user into the portal. It also creates a group containing only that one user.
To add a language to the portal, use the CreateLanguage.xml example.
To prepare for running this XML script, we must insert resource bundles and, where applicable, JSPs for the new language. For details about how to do this, refer to the topic about how to support new languages in the WebSphere Portal information center.
The UpdateVault.xml example demonstrates how to create new resources in the portal credential vault with an XML script.
The ClonePortlet.xml example shows how use xmlaccess.sh to add new portlets with different settings to existing applications.
The Transaction.xml example demonstrates the effect of using different transaction levels for the execution of an XML import.
The MovePage.xml example shows you how to move a page to another node.
The actual move of the page is done by the last two lines in the sample file.
Parent Use the XML configuration command line clientRelated tasks:
Support a new language