xmlaccess.sh



xmlaccess.sh


  1. ObjectIDs in XML export file
  2. Unique name
  3. -url parameter
  4. xmlaccess.sh inside shell scripts
  5. Can I run xmlaccess.sh through WebSEAL junction?
  6. Call xmlaccess.sh from ConfigEngine or WPSConfig?
  7. Can I use wildcard in uniquename search?
  8. Can you assign a uniquename to any resource?
  9. When the unique name wps.content.root of Content Root is changed, would it affect Portal?
  10. When I deploy applications using xmlaccess.sh in a cluster, do I need to run the command on every node?
  11. Can I use "delete" in the action on "portal"?
  12. How would I change the uniquename of a page using xmlaccess.sh
  13. When creating a content-node, can I specify the position in a hierarchy?
  14. What access rights are required to run xmlaccess.sh?
  15. What is "xmlaccess scripting user" and how is it used?
  16. When xmlaccess.sh runs out of memory, what can I do?
  17. Does xmlaccess.sh support transactions?
  18. When I use xmlaccess.sh to delete users or groups, would they be deleted from the user repository store?
  19. When generating full export using Export.xml, would be the result look like if "export-users" is set to true?
  20. Does the order of tags in the exported XML file change?
  21. How can I find the currently scheduled database cleanup task and other scheduled tasks?
  22. Can I run multiple xmlaccess.sh sessions simultaneously?
  23. Can I schedule a cleanup task twice every week?
  24. What are the differences between the full exports generated by Export.xml and ExportRelease.xml?
  25. Is there a relationship between xmlaccess.sh and Virtual Portals?
  26. Can I empty a virtual portal and then import an XML file generated from another virtual portal?
  27. What can I use ImportXML portlet for?
  28. What are the limitations of xmlaccess.sh?
  29. How is ReleaseBuilder related to xmlaccess.sh?
  30. Where can I find sample XML files?



ObjectIDs in XML export file

When a Portal artifact or resource is added to the database, either during the initial installation or later through development, a unique object identifier (ID) is then assigned to the resource. The object ID is generated by an internal algorithm and it is guaranteed to be unique for all portal installations. The main purpose of an object ID is to identify the object and provide an association when it is referenced elsewhere in the XML file generated by the export operation. When the artifact resides in the portal database, the object ID is fixed and will not change, until it is deleted. The normal way to obtain the objectID is to export the portal database content using xmlaccess.sh. There are exceptions that some object IDs are intentionally kept the same for different installations. "wps.content.root" for the base portal is one such example. Some artifacts do not have object IDs, because they are not to be referenced or their "singleton" nature. For example, "portal", global settings, service settings, and policy-nodes.

The object IDs are categorized. The category of an object ID is identified by the first 1 or 2 characters. Some commonly used ones are:

In Portal v7. a Z is added to the category identifier. For example, Z6 identifies a content node.

Since the object IDs are not meant to be manually handled by human, it is strongly recommended to create unique names for any artifacts to be referenced in own XML script. Portal will guarantee no two resources will have the same unique name.


Unique names

Unique names are set by administrators to identify Portal resources (pages, portlets, themes, skins, etc) by Portal administrators.

These names are alphanumerical strings, plus . (period), - (hyphen), and _ (underscore). Any other special characters are not recommended.

You can set unique names for a subset of categories using the Custom Unique Names portlet. To set unique names for other types of resources, use xmlaccess.sh.

When creating a page, if you try to assign a unique name to the page, but the unique name is already assigned to an existing resource (not necessarily a page), no errors would be generated, and the page will be created, but the unique name would not be shown for the page. This is true, even when the existing resource is inactive. Thus when you are having trouble assigning a unique name to a resource this way, chances are that the unique name has been used on another resource. To find out whether that is the case, you should obtain a full export using xmlaccess.sh and then search the unique name to see if it is already in use.

On the other hand, if you try to assign a unique name that has already been used to a new resource in Manage Custom Unique Names portlet, an error message would be returned.

If you tried to do similar assignment using xmlaccess.sh, the following will be shown in the result XML file,

<status element="[content-node Z6_4GFA8VO20OJ9F0IE5UOP6K3083 uniquename=sample.test.page.1]" result="failed">

<message id="EJPXA0187E">com.ibm.wps.command.xml.XmlCommandException: EJPXA0187E: The resource content-node already exists. [content-node Z6_4GFA8VO20OJ9F0IE5UOP6K3083 uniquename=sample.test.page.1]</message>

</status>

You cannot delete a unique name if you have not deleted the corresponding resource, but you can change the unique name of the resource, and then use the original unique name for something else. Be careful when you change unique name of a resource if you have used it as a way of updating resources between two different systems. If you change the unique name of, say, a page, you basically cut off the association between the two systems.

As a best practice, we recommend a convention of creating unique names to be adopted in own company or organization, such that they are identifiable for different types of resources. Please do not use names that could be confused with the out-of-the-box Portal resources.

Unique names are very useful for release updates, especially for systems that do not share the same objectIDs, and can be the reference of changes when Release Builder is used.


-url parameter

If the -url parameter is omitted, the URL will be default to http://localhost/wps/config, whichi s generally not a correct URL, and generates errors such as:


xmlaccess.sh inside shell scripts

Yes. There are a couple of precautions:


Can I run xmlaccess.sh through WebSEAL junction?

The answer is no. The reason is that xmlaccess.sh is a command line tool. It can't fulfill WebSEAL's basic authentication challenge, thus the admin user cannot be authenticated by WebSEAL. Since xmlaccess.sh is an administrative function in nature, it should not be an exposure. If there is a concern about sending the password through the open wire, it is recommended to use SSL over HTTP when running xmlaccess.sh.


Call xmlaccess.sh from ConfigEngine or WPSConfig?

The answer is yes. Using the following XML script file, you should be able to run xmlaccess.sh to export releases 

<?xml version="1.0" encoding="UTF-8"?>

<target name="full-export-release">
     <xmlaccess
         user="${PortalAdminIdShort}"
         password="${PortalAdminPwd}"
         srcfile="${WpsInstallLocation}/doc/xml-samples/ExportRelease.xml"
     destfile="${WpsInstallLocation}/bin/fullreleasexport.xml"/>
</target>

.where we assume PortalAdminIdShort and PortalAdminPwd are configured in wkplc.properties (or wpconfig.properties in version 6.0). Alternatively, they can be provided on command line as well.

Save these into an XML file and move the file into directory...

Then you should be able to run the following...

Similarly, you can have other xmlaccess.sh commands in the same XML file with different input and output files.


Can I use wildcard in uniquename search?

When exporting all pages, you may wonder whether you can use something like

The answer is no. For the normal export of Portal resources, the only attribute that takes wild card is "objectid". Thus, to export all content-nodes, using the same example above, the tag should be like

In some special cases, like exporting all policies, you can use the following

.to export all different types of policies.


Can you assign a uniquename to any resource?

Most of Portal resources can be assigned a unique name, such that you can reference them by their unique names, when you use administration tools to manage them. The resources that can be assigned a unique name by using Portal Administration portlet, Custom Unique Names portlet, are...

Many other resources can be assigned unique names through xmlaccess.sh, such as...

Some attributes do not allow a unique name by nature, such as policy node, access control items, application roles, markups, locale data, etc.


When the unique name “wps.content.root” of Content Root is changed, would it affect Portal?

When you change the unique name "wps.content.root" of Content Root, the portal may not be accessible any more. This is because that the Portal rendering content model depends on the correct reference of this uniquename. So it is not supported to change the unique name of the Content Root. If you or someone accidentally changed it, however, you can use xmlaccess.sh to change it back, because xmlaccess.sh does not depend on the content model.


When I deploy applications using xmlaccess.sh in a cluster, do I need to run the command on every node?

The answer is No. You only need to run the xmlaccess.sh command on one node, preferably the primary node, followed by a full synchronization, and then run "activate-portlets" to activate the portlets deployed.


Can I use "delete" in the action on "portal"?

Is it safe to use xmlaccess.sh with Portal? Is it possible for one to accidentally delete the entire Portal using "delete" on "portal"?
For example, can I run the following script to delete "portal"? 

<?xml version="1.0" encoding="UTF-8"?>
<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.0.xsd" type="update"  domain="rel">
    <portal action="delete" />
</request>

The answer is No. You will see similar error messages as follows, when you run xmlaccess.sh with the script above as input, 

    <status element="unknown" result="failed">
        <message id="EJPXA0049E">com.ibm.wps.command.xml.XmlFormatException: EJPXA0049E: Input syntax error in 
line 4 column 28: the XML input does not conform to the XML schema PortalConfig_7.0.0.xsd. unknown</message>
        <message>org.xml.sax.SAXParseException: cvc-enumeration-valid: Value 'delete' is not facet-valid with respect to 
enumeration '[locate, export]'. It must be a value from the enumeration.</message>
    </status>

Apparently, "portal" should not take action "delete" and this is guaranteed by the xmlaccess.sh schemas.


How would I change the uniquename of a page using xmlaccess.sh

Remember, objectIDs represent the uniqueness of an object in the Portal database. Therefore, we may reference the objectID of a resource with an "update" action to update the unique name.

For example, using a script like the following...

.you can set an existing page with that object ID to the new uniquename.

On the other hand, you cannot use uniquename to set objectID to a different value.


When creating a content-node, can I specify the position in a hierarchy?

The answer is yes. Portal pages are arranged as a tree hierarchy with Content Root as the top. Each node, called content node, in the tree can be a page, a label, or a URL (internal or external). The position of a content node under a parent node in the hierarchy can be ranked by its ordinal, an integer. The smaller the ordinal, the higher the rank. The display and rendering of the content tree in Portal is according to the page ordinals.

When you add a node, you can specify its ordinal which can take the following values




What access rights are required to run xmlaccess.sh?

We normally run xmlaccess.sh using the Portal administrative user or a user in the administrative group. To assign any other users to run xmlaccess.sh, they need
Security Administrator@Portal + Editor@XML Access
where Portal and XML Access are two virtual resources.
This assumes that there are no role blocks set for inheritance in Portal resource hierarchy. If you have configured any inheritance role block, it is advised to give proper access to the user or group who runs xmlaccess.sh.

What problem could it cause if the user's access rights are not correct? When a user does not have the proper rights to run xmlaccess.sh, you would find the following in the output, 

<failure>
com.ibm.wps.command.xml.XmlCommandServlet$AuthenticationException: EJPXA0011E: 
Authentication for user wpsadmin failed.
</failure>

To assign the proper access rights to users or groups, you can Resource Permissions portlet, or User and Group Permissions portlet. Alternatively, you can also use xmlaccess.sh to assign permissions.


What is "xmlaccess scripting user" and how is it used?

When the portal is installed, an internal user called "xmlaccess scripting user" is added to the Portal database. This user is mapped to the user who runs the xmlaccess.sh command after that user is authenticated and access control is checked.

In the trace log, you should see the entries like the following,

authority: Name: xmlaccess scripting user, OID:[ExtIDImpl '9eAeOBROMGDC3BP6NP14JRO4NK1EKBQSMJ14LRSA6P1' [xmlaccess scripting user / USER, Domain: [Domain: rel]]]

Without such "authority", the xmlaccess.sh would fail.

Due to its importance, please do not remove or modify this user from Portal database.


When xmlaccess.sh runs out of memory, what can I do?

Sometimes, when importing an XML file with a lot of updates, you may see OutOfMemoryError. You may see this problem again if you rerun the same command. This error can occur on either the client or server side, but more often on the server.

If the problem occurs on the client side - The first suggestion is to not run xmlaccess.sh on the same Portal server. As stated in question “Does xmlaccess.sh have to be run directly on the Portal host?”, xmlaccess.sh need not to be run on the server itself. When you run it on a remote client, it would off load the job from the running Portal server.

The second suggestion is to increase the client JVM by doing the following,
- open xmlaccess.bat or xmlaccess.sh under PortalServer/bin, depending on the platform;
- search for the JAVA line, you should see something like the following, 

%JAVA% -classpath %WPS_HOME%/base/wp.xml.client/bin/wp.xml.client.jar;%WPS_HOME%/base/wp.base/shared/app
/wp.base.jar;%WAS_HOME%/lib/j2ee.jar;%cpath% com.ibm.wps.xmlaccess.XmlAccess %*


- adding parameters "-Xms128m -Xmx512m" would give the initial size 128MB and maximum 256MB. You can adjust these parameters to suit client. Make sure client machine has that much real memory. If not, try to stop other applications.

If the OutOfMemoryError occurs on the server side, you may want to avoid running xmlaccess.sh when the server is busy, such as at high peak hours during the day. If that doesn't resolve the problem, try to increase the JVM heapsize on WebSphere_Portal server. Also try to make multiple small updates in multiple XML files, rather than making a lot of updates in a single big XML file.


Does xmlaccess.sh support transactions?

When you use XML scripts to create, update or delete resources, the changes in the portal database are grouped into transactions. All changes that are part of one transaction are either executed completely or not at all.

The XML configuration has two different levels of grouping database updates into transactions. The grouping is defined by the transaction-level attribute of the main request element, which can have the following values:

resource Every top-level resource in the XML script is processed in one separate transaction. For example, this can be a content node with its complete layout. If an error occurs, all resources up to the one where the error was encountered have been fully processed; the resource where the error was encountered is not created, or, if it already existed, it is left unchanged. Default.transaction level.

    <request type="update" transaction-level="resource"></request>
request The entire XML script is executed in one transaction. If an error occurs, all database changes caused by the script are made undone, and the original state is restored. Note that using this level of transactionality might cause large and long-running database transactions if used in large XML scripts. As a result, you might encounter database errors caused by exceeding database limits on transaction duration or transaction log size, depending on the configuration of database.

    <request type="update" transaction-level="request"></request>

IBM recommends having multiple small XML updates when using xmlaccess.sh, especially when the network or database conditions are not very stabilized, or Portal and database may be in different firewall zones.

For large updates, especially in a clustered environment...

  1. Increase read and write timeout values to 180

  2. Increase timeout to 3000 under...

In the request tag, to adjust whether to refresh some internal caches, set...

The default value for both is false. The second parameter depends on the first. If the first is set to true, then the second would be ignored.

In some special conditions, you can set a couple of configuration properties in WP ConfigService to avoid a race condition:


When I use xmlaccess.sh to delete users or groups, would they be deleted from the user repository store?

The answer is yes. They are not only removed from portal databases, but also removed from the corresponding user repository configured for the Portal. All data associated with these users and groups stored in Portal database are also removed by database constraints.


When generating full export using Export.xml, what would be the result look like if "export-users" is set to true?

In the sample Export.xml, export-users is usually set to false. If it is set to true, the export will contains users and groups as <user..> and <group...> tags. The resulted XML file is equivalent to the full export using Export.xml plus the export using ExportAllUsers.xml. If there are invalid users/groups in the Portal DB, the export will fail. Thus it is not recommended to enable this parameter, when the focus is not on users and groups, but rather the other portal artifacts.


Does the order of tags in the exported XML file change?

The general orders of top-level tags in the XML file are the same, under "portal". For example, in an export generated (on a version 7 system) using "Export.xml", they are shown as follows: 

    portal
    global-settings
    services-settings
    language
    action
    virtual-resource
    resource-type
    markup
    client
    event-handler
            protected-resource
    skin
    theme
    web-app
    content- node
    credential-sement
    url-mapping
            wsrp-producer
            task
    user-resource (v7)
    policy-node
    application-role
    wsrp-customized-portletinstance (v7)
    custom-resource (v7)
    rating (v7)
    tag (v7)
    filter-instance (v7)

However, xmlaccess.sh cannot guarantee that the orders with the same type of artifacts are kept the same when running multiple times. The order of the sub tags can also change.


How can I find the currently scheduled database cleanup task and other scheduled tasks?

Use the following XML, you can export the currently scheduled tasks: 

<?xml version="1.0" encoding="UTF-8"?>

<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"  type="export">

    <portal action="locate">
        <task action="export" name="com.ibm.portal.datastore.task.ResourceCleanup"/>
        <task action="export" name="com.ibm.portal.ai.task.AITask_Purger"/>
        <task action="export" name="com.ibm.portal.ai.task.AITask_PolicyHandler"/>
    </portal>

</request>

Notice that you have to specify the name of each task specifically. I.e., you cannot export all the tasks using something like 

     <task action="export" objectid="*"/>

or 

     <task action="export" name="*"/>

You can find out why from the result of the export which will be something like the following, 

<?xml version="1.0" encoding="UTF-8"?>
<!-- IBM WebSphere Portal/7.0 build wpnext_528_01 exported on Mon Nov 29 19:23:53 EST 2010 from machine_name -->
<!-- 1 [task name=com.ibm.portal.datastore.task.ResourceCleanup] -->
<!-- 2 [task name=com.ibm.portal.ai.task.AITask_Purger] -->
<!-- 3 [task name=com.ibm.portal.ai.task.AITask_PolicyHandler] -->

<request build="wpnext_528_01" 
         type="update" 
         version="7.0.0.0" 
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
         xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd">

    <portal action="locate">
        <task action="update" 
              name="com.ibm.portal.datastore.task.ResourceCleanup">
            <dayOfWeek>6</dayOfWeek>
            <startTime>20:00</startTime>
        </task>
        <task action="update" 
              name="com.ibm.portal.ai.task.AITask_Purger">
            <dayOfWeek>7</dayOfWeek>
            <startTime>00:00</startTime>
        </task>
        <task action="update" 
              name="com.ibm.portal.ai.task.AITask_PolicyHandler">
            <startTime>22:30</startTime>
        </task>
    </portal>
    <status element="all" result="ok"/>
</request>


From the export, we can see there are no objectIDs for the task. In addition, wildcard cannot be used on "name" attribute.


Can I run multiple xmlaccess.sh sessions simultaneously?

The answer is no. Sometimes, when you run xmlaccess.sh, you might see the following error, 

<failure>
com.ibm.wps.command.CommandFailedException: EJPXA0166E: The XML Configuration Interface is currently 
busy with another request. Please try again later.
</failure>

This means you have another xmlaccess.sh process running. xmlaccess.sh tool prevents multiple sessions to be run at the same time.

This can also be the case of the following situation: When you have an xmlaccess.sh command hangs or is stuck in a thread, you tried to kill it by interrupting it on the client side, such as Control+C, or "kill ", the JAVA thread on the server side is still stuck and may not be terminated. Issuing another xmlaccess.sh command will generate the same error. This kind of situations sometimes may only be resolved by restarting the server.


Can I schedule a cleanup task twice every week?

For performance reasons, it is recommended that the cleanup of WebSphere Portal database to be delayed to a time when traffic on the web site is light, because the database cleanup is normally CPU extensive and continuously running cleanup can degrade the system performance on the production system. WebSphere Portal has a delayed database cleanup scheme which takes advantage of WebShere Scheduler Service.

All portal installations would have the default configuration for "scheduler.cleanup.enabled" set to true, and the time for the delayed clean up is 8 PM Saturday.

Because of this delay, the portal resources deleted are usually not purged from the database immediately. This could cause some problems. For example, after you delete a page, you could not create a new page with the same title; or after you just deleted a virtual portal, you are not able to create a new virtual portal with the same context.

The database cleanup task cannot be run more than once a day as a scheduled task in Portal database. In the scheduled task table, there can only exist at most one entry per task.

If you have two entries in the XML file, then the last would be the winner. For example, if you have 

    
<task action="create"  
      name="com.ibm.portal.datastore.task.ResourceCleanup">

    <dayOfWeek>5</dayOfWeek>
    <startTime>7:00</startTime>

</task>

<task action="create"  
      name="com.ibm.portal.datastore.task.ResourceCleanup">

    <dayOfWeek>4</dayOfWeek>
    <startTime>0:00</startTime>

</task>

.the database would be cleaned up at 12 AM on Thursday.

To trigger the cleanup immediately, you can run xmlaccess.sh Task.xml You can schedule the clean up using the scheduler task once daily, or once weekly, or once monthly. You can set up a scheduled Operating System job or cron job to run xmlaccess.sh at the day and time you choose.


What are the differences between the full exports generated by Export.xml and ExportRelease.xml?

Export.xml exports data from the release, customization, and community database domains; ExportRelease.xml exports data from the release database domain only

If you closely examine the two files, you would see the differences are that in ExportRelease.xml, it specifies domain "rel" (for release). When a domain is specified, "export-users" is automatically set to false.

The export generated by Export.xml is a super set of the one generated by ExportRelease.xml. Data from customization and community domains will be included. Policy nodes will be generated. Because of these additional data, sometimes, the export action using Export.xml fails, but it would succeed if ExportRelease.xml is used. In those occasions, you may want to find out why. Some common reasons are orphaned data. For example, after users are deleted from the LDAP, the customization data remains in Portal Database.

One procedure we recommend is so-called "CleanupUsers'. Running xmlaccess.sh against CleanupUsers.xml (in PortalServer/doc/xml-samples) to generate a list of invalid users and groups. If you run xmlaccess.sh again with this output XML file as input, those invalid user and group entries would be deleted from Portal database, taking along with the resources owned by them.


Is there a relationship between xmlaccess.sh and Virtual Portals?

When a Virtual Portal is created using the Manage Virtual Portals portlet, the new Virtual Portal's content is created when the file InitVirtualPortal,xml is imported to the Portal by the portlet.

Depending the installation of the Portal family products and installation options, there may be several different initialization XML script files under...

You can choose which one to be used to populate the virtual portals when you use Manage Virtual Portals portlet. To change the init script, simply configure the portlet through Manage Portlets, and change the name of the file in parameter SCRIPT_INIT_VP.

Note that if any of the out-of-the-box applications are deleted or deactivated, you should not directly use these out-of-the-box virtual portal initialization XML scripts. Doing so, the creation of the virtual portals will likely fail due to the missing applications. You can customize these scripts by deleting or commenting out of those applications.

You can also create own template initialization XML files, such that virtual portals created with these templates would contain own custom applications.

If a Virtual Portal is created using the configuration task "create-virtual-portal" the new Virtual Portal's content should be established by importing an export of a Virtual Portal from another Portal environment using xmlaccess.sh.

You can replace the default VP initialization XML files with own. Sometimes, you may want to create own VP template and use it to create multiple Vps. If you have deleted out of box applications from the base portal, the default initialization XML files should not be used, or they must be customized to delete the referenced applications from the files.


Delete and recreate resources with uniquenames

If an existing resource with, for example, a page with a certain uniquename is deleted and recreated with the same uniquename, the import step may result in a DuplicateKeyException. This occurs because upon deletion, the page is marked as deleted in the database but, in fact, it is still there; it's just not visible. To avoid the issue, first stage the delete, run the cleanup task, recreate the page, and then stage that creation again.


Staging based on partial exports

Use ReleaseBuilder on partial exports is usually not supported. When a partial export is done using...

.you probably have some items (web-apps, servlets, portlet-apps, and portlets) with an action="locate", which ReleaseBuilder does not recognize. It is implied that an input file for ReleaseBuilder contains only items with action="update"

When a portlet is changed on a page, the partial release export looks something like the code shown in listings 1 and 2.

Old release... 

<web-app action="locate" uid="webapp1">
    <portlet-app action="locate uid="webapp1.1">
      <portlet action="locate" name="My Portlet" objectid="_5_xx">
    <portlet-app>
<web-app>
<content-node action="update">
:
       <portletinstance action="update" portletref="_5_xx"/>
:
<content-node>

New release 

<web-app action="locate" uid="webapp2""
    <portlet-app action="locate uid="webapp2.1">
      <portlet action="locate" name="A Portlet" objectid="_5_yy">
    <portlet-app>
<web-app>
<content-node action="update">
:
	  <portletinstance action="update" portletref="_5_yy"/>
:
<content-node>

This may make ReleaseBuilder think that web-app webapp1 was removed, causing it to generate a delete operation for that web-app.

So, yes, you can use partial exports but, at the very least, carefully review the resulting output (difference) file before using it because content may be deleted accidentally.


Empty a virtual portal and then import an XML file generated from another virtual portal?

Since the resources in a virtual portal are mostly links to those in the base portal, there does not exist a procedure to empty a virtual portal like what the ConfigEngine task "empty-virtual" does to the base portal. As a matter of fact, you should not delete the resources that are not scoped to the virtual portal only, because they may be used and shared by base and other virtual portals.

The correct procedure should be the following:

  1. Prepare the XML file for the virtual portal import, i.e. generate full export from the virtual portal;

  2. Delete the virtual portal you plan to empty;

  3. Run xmlaccess against Task.xml to clean up the database;

  4. Set values in wkplc.properties for virtual portal title, context, realm, hostname (if any), and NLS file;

  5. Create a new virtual portal...

    ConfigEngine.sh create-virtual-portal

  6. Import the XML file generated in the first step into the newly created virtual portal.



What can I use ImportXML portlet for?

The ImportXML portlet is intended for simple import/update jobs. It can only be used in the current portal or virtual portal the user is logged into, since you cannot specify a different URL. It cannot be used to export any resources, because one cannot specify the output file. Notice that if the import XML file contains update actions on some resources, the user who is logged in must have proper access on the target resources. The access control rules are applicable to the portlet, just like the command line xmlaccess.sh.


What are the limitations of xmlaccess.sh?

xmlaccess.sh is a high level database utility, used to read, create, update, and delete resources in Portal database. Through PUMA and VMM, it can also add and delete users/groups in user repositories. Although it is a powerful tool for Portal administration, it also has some limitations.



How is ReleaseBuilder related to xmlaccess.sh?
ReleaseBuilder and xmlaccess.sh are directly related. While ReleaseBuilder itself does not depend on xmlaccess.sh to function, an XML file generated by the ReleaseBuilder (a "release") must be imported to the target Portal using xmlaccess.sh.

ReleaseBuilder is designed to take as input 2 XML files exported from the SAME Portal host to determine or calculate the changes made between the times the first and the subsequent export were generated. This process is referred to as "building a release."

If Release_1.xml and Release_2.xml are the XML export files from a source Portal processed by Release Builder such that the output file is Revison_1.xml, then Revision_1.xml is meant to be imported to the target Portal as the xmlaccess.sh input file. I.e., 

releasebuilder.sh -inOld Release_1.xml -inNew Release_2.xml -out Revision_1.xml

and 

xmlaccess -in Release_1.xml -out <output_file.xml> -url <URL_of_target_Portal/wps/config> 
-user <Portal_admin> -password <Portal_admin_pwd>

This xmlaccess.sh command ensures that the changes in Revision_1.xml are applied to the target Portal server.

Notes:




Where can I find sample XML files?

Most of xmlaccess.sh sample files are located in directory /doc/xml-samples. It is recommended to keep these files as they are. If you need to customize these files to test different scenarios, make copies and rename them, or copy them to a different location.

Sometimes, you may not find the exact sample XML file for what you are trying to accomplish. We recommend you take a full export of the Portal content, using either Export.xml or ExportRelease.xml, depending on the tags you want to review. Then extract the top level component and adjust to needs. For example, if you want to export all URL mappings, but there is not a sample file, you can create one, like the following (save it as ExportAllURLMappingContexts.xml), 

<request xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:noNamespaceSchemaLocation="PortalConfig_1.4.xsd"
    type="export">
    
    <!-- This XML script exports all URL mapping contexts. -->
    <portal action="locate">
        <url-mapping-context objectid="*" action="export"></url-mapping-context>
    </portal>

</request>

Sometimes, you have to try and test some cases before you can get it right.

Note that in every XML script, action must be start from a top level element under "portal". For example, you cannot make a change directly to a "portlet", rather the change must be done starting at "web-app".


References


WebSphere Portal version 7 InfoCenter - Working with XML configuration interface
http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Working_with_the_XML_configuration_interface_wp7

WebSphere Portal version 6.1 InfoCenter - Working with XML
http://publib.boulder.ibm.com/infocenter/wpdoc/v6r1/index.jsp?topic=/com.ibm.wp.ent.doc_v6101/admin/adxmltsk.html

IBM WebSphere Portal v6.0 staging scenarios using ReleaseBuilder
http://www.ibm.com/developerworks/websphere/library/techarticles/0712_kubik/0712_kubik.html


+

Search Tips   |   Advanced Search