WebSphere Portal 7. Remote portlet update through Xmlaccess.

In the previous post we setup the xmlaccess for running on Windows.
Now I'll show how to update the existing portlet through the xmlaccess on the remote host.




One way to do update the portlet:
1) copy the war to the place, where portal can access it (on the host machine or the http server)
2) execute xmlaccess script to update the portlet.

The most difficult  part is to find out what to place into xml file.

First, you have to execute the following xml:
<request
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0.xsd"
    type="export">
        <portal action="locate">
        <web-app uid="UID_OF_YOUR_WEB_APP" action="export"/>
    </portal>
</request>

After executing this script you will get the material like the following:
<request build="wp7002_132_01"  type="update" version="7.0.0.2" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="PortalConfig_7.0.0_2.xsd" create-oids="true">
    <portal action="locate">
 <!-- uid must match uid attribute of portlet-app in portlet.xml plus postfix .webmod -->
        <web-app action="update" active="true" domain="rel" removable="true" uid=value" uniquename="your given uniquename value">
            <url>file://localhost/PATH_TO_WAR_FILE</url>
 <!-- uid must match uid attribute of concrete-portlet-app in portlet.xml -->
            <portlet-app action="update" active="true" name="portlet.war" uid="portlet.war">
 <!-- name must match content of portlet-name subtag  of concrete-portlet in portlet.xml -->
                <portlet action="update" active="true" name="name" objectid="any value">       
                </portlet>
            </portlet-app>
        </web-app>
    </portal>
    <status element="all" result="ok"/>
</request>

1. For the <web-app> tag in the deployment XML file, the "uid" attribute should match the "id" attribute given in the <portlet-app> tag in portlet.xml, appended with ".webmod", i.e. "id+.webmod"; Otherwise, if "id" is absent, use the WAR file name with suffix ".webmod".

2. Similarly, the "uid" attribute for the <portlet-app> tag of the deployment XML file should match the "id" attribute of <portlet-app> tag in portlet.xml, or WAR file name, if "id" attribute is absent.

3. Since the WAR file name can be different from the original when updating the portlet application, it's recommended to always set "id" for all portlet applications to avoid confusion.

4. When initially deploying applications with the objectID creation mode, i.e., setting create-oids="true", you can use symbolic names to set objectIDs for reference in the same XML file. It is not recommended to keep the objectID creation mode for subsequent updates. It is recommended to use a unique name, or the "uid" attribute as mentioned in step 1.

As object IDs are not used to identify existing resources in ID generating mode, it is good practice to define unique names for all resources that are created in such scripts. That way, if the script is executed twice, the second execution can find and update the resource by its unique name, instead of creating two identical resources.

Please note the    <url>file://localhost/PATH_TO_WAR_FILE</url>. This tag contains the location of the portlet, where the portal can find your portlet and install it.

Xml configuration reference can be found here. Also note that you WebSphere Portal contains xml samples in xml-samples folder.