Deploy websphere portal Portlets as Web Modules using jenkins

Question

I have one build server (win) with Jenkins 2.0 as a Build and Deploy Tool. and a Cluster of 2 WAS Servers (win) of WebSphere Portal 8.5.5.2

i build my EAR and WAR files successfully with ANT script. and use the jenkins "websphere deployment" plugin to deploy the EARs and WARs to my websphere portal 8.5.5.2.

The WAR files are web module portlets. if i choose to deploy a web module manually i can either use XMLACCESS script or via the Administration -> Web Modules GUI.

if i use jenkins to deploy the WARs it converts them to EAR files and deploy them to the portal, and it doesn't show as a web modules in the Administration Console.

i noticed that when installing the WARs for example "webapp.war" from the Administration Web Modules GUI it adds the Display name as PA_webapp and the context root as /wps/webapp but when installing via either the /ibm/console interface or via jenkins plugin the display name would stay webapp and the context root also webapp (it doesnt add the PA_ prefix or the /wps/ ...)

how can i deploy the portlets web modules correctly using tools other than XMLACCESS and Administration GUI?

Answer 1

You must initially install the portlets using the administration GUI for WAS Portal (Since this requires XML Access to register the portlet(s)). After this initial deployment, you can use the WebSphere Deployment Plugin to automatically generate and deploy portlets to WAS Portal. You must make sure you match the path (i.e. /wps/) & the Application name (i.e. PA_app_name) in the WDP configuration. You can use the latest WDP 1.4.2 beta plugin to publish updates (You must have the plugin use updates only and not installations from scratch). After your portlets are automatically updated, you can simply refresh the web page to see the updates changes.

The WDP should automatically generate and EAR for the portlet if you specify a WAR for deployment.

-WDP Architect/Developer

Answer 2

I had the same issue more or less, although I do not use Jenkins, and I did use XMLAccess to solve it.

There are basically three approaches for automated deployment of portlet applications:

1. Package your portlet WARs in EAR files and deploy them through the deployment manager/WAS. This is what is called 'predeploying' and this is what Jenkins does. After you put the EARs in you have to finalize deployment using XMLAccess, so that portal knows that the EAR contains web applications that contain portlets. If you have deployed and registered once through XMLAccess, you can continue to deploy updates of the application by deploying new EAR files.
2. Use WAR files and deploy them through portal, similar to the way you would do that through the GUI; and then Portal will use the deployment manager/WAS to deploy it. It will then generate the application name in WAS (PA_YourModule). For this you need to upload the WAR files to the server.
3. Generate a PAA file. This contains both the WAR file and the XMLAccess file. You need to fire up the ConfigEngine for this one.

In all cases you need an XMLAccess script to register the application in portal, and these scripts will slightly differ in the approaches. In the first approach your XMLAccess script will reference the WAR inside the EAR file, and the web-app tag will have the attribute predeployed="true":

<?xml version="1.0" encoding="UTF-8"?>
<request type="update" version="8.0.0.1" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
        xsi:noNamespaceSchemaLocation="PortalConfig_8.0.0.xsd">
    <portal action="locate">
        <web-app action="update" active="true" domain="rel" predeployed="true" 
        removable="true" uid="{id from portlet.xml}">
    <url>file://localhost/$predeployed_root$/MyEARfile.ear/MyPortlets.war</url>
  </portal>
</request>

In the second approach your XMLAccess script will look like this, and you have to put the war file in the directory yourself:

<?xml version="1.0" encoding="UTF-8"?>
<request type="update" version="8.0.0.1"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:noNamespaceSchemaLocation="PortalConfig_8.0.0.xsd">
    <portal action="locate">
        <web-app action="update" active="true" domain="rel" uid="{id from portlet.xml}">
            <url>file:////opt/WebSphere85/PortalServer/installableApps/MyPortlets.war</url>
        </web-app>
    </portal>
</request>

You can export all kinds of XMLAccess scripts using the examples that can be found in \PortalServer\doc\xml-samples.

I went for the second approach, because I still wanted to manually update portlet applications through the portal GUI and a lot of the stuff was already deployed that way. So what I did was set up XMLAccess on the build server. I copied the JARs described here over to the build server and I created an XMLAccess Ant macro (note that the IBM docs show incorrect JARs) to run the XMLAccess scripts:

<path id="XMLAccess.libraryclasspath">
  <pathelement location="${WPS_80_DIR}/base/wp.xml.client/bin/wp.xml.client.jar"/>
  <pathelement location="${WPS_80_DIR}/base/wp.base/shared/app/wp.base.jar"/>
  <pathelement location="${WPS_80_DIR}/base/wp.engine.impl/shared/app/wp.engine.impl.jar"/>
  <pathelement location="${WPS_80_DIR}/base/wp.utilities.streams/shared/app/wp.utilities.streams.jar"/>
  <pathelement location="${WAS_80_DIR}/lib/j2ee.jar"/>
  <pathelement location="${WAS_80_DIR}/lib/bootstrap.jar"/>
  <pathelement location="${WAS_80_DIR}/java/jre/lib/ext/ibmjceprovider.jar"/>
  <pathelement location="${WAS_80_DIR}/plugins/com.ibm.ws.runtime.jar"/>
  <pathelement location="${WAS_80_DIR}/plugins/com.ibm.ws.emf.jar"/>
  <pathelement location="${WAS_80_DIR}/plugins/org.eclipse.emf.ecore.jar"/>
  <pathelement location="${WAS_80_DIR}/plugins/org.eclipse.emf.common.jar"/>
</path>

<macrodef name="xmlaccess">
  <attribute name="script"/>
  <sequential>
    <java  dir="${module}" classname="com.ibm.wps.xmlaccess.XmlAccess" logError="true">
      <classpath refid="XMLAccess.libraryclasspath" />
        <arg value="-user"/>
        <arg value="wpsadmin"/>
        <arg value="-url"/>
        <arg value="http://portalhost:10040/wps/config"/>
        <arg value="-password"/>
        <arg value="passw0rd"/>
        <arg value="-in"/>
        <arg value="@{script}"/>
    </java>
  </sequential>
</macrodef>

Then I copy the generated WAR file to one of the portal nodes using a SCP task. It doesn't matter which node, as long as it got its connectivity settings to the deployment manager right. I would recommend using a SSH key file here, and of course the local user needs to be given write access to that installableApps directory on the server.

<scp file="mywars/portlet.war" 
        todir="deploymentuser@portalhost:/opt/WebSphere85/PortalServer/installableApps" 
    keyfile="${deployment.scp.key}" 
    passphrase="${deployment.scp.passphrase}" trust="true" />

For each application I have a XMLAccess xml file that I use for deployment (or if it is missing, I have a Ant XSLT task to generate one on the fly using the portlet.xml portlet descriptor). You can set the unique names for the portlets in the XMLAccess script, making them easier to reference in pages you may want to deploy through XMLAccess as well, and also that you can set the preferences and deploy multiple instances of the same portlet (instead of having to do that in the portlet descriptor). You could also use the xml access task to publish pages and other stuff, for example for setting up your test environment to a state for running automated integration tests.

The xml task is just this:

<xmlaccess script="deploy-portlets.xml" />

Then portal will do the rest by putting it in the deployment manger. I also run these Ant scripts from RAD and make quick updates on our development server.