Configuring widgets to work with WebSphere Portal

If your team uses IBM® WebSphere® Portal, you can configure IBM Business Monitor widgets to work in the WebSphere Portal environment.

1. Create endpoint references on the WebSphere Portal application server. Product-specific endpoint reference entries must be created so that Business Space works properly in the WebSphere Portal environment. Endpoints must be defined on the WebSphere Portal server, but they are created remotely using the updateEndpointBindingsOnPortal command run on your product server.
   1. Start the WebSphere Portal server and your product server.
   2. Copy the service endpoint files from the Business Space component and your product to a temporary directory on your product machine, for example, c:/tmp/endpoints/.
      The service endpoint files are located on your product server in the following locations:

      • profile_root/BusinessSpace/node_name/server_name/mm.runtime.prof/endpoints/
      • install_root/BusinessSpace/registryData/product_name/endpoints

      Some endpoints files might exist in both locations. Copy only the service endpoint files for which you need to create entries. You don't need to copy a file that was previously processed using the updateEndpointBindingsOnPortal command. The following list includes IBM business process management examples of service endpoint files and widget endpoint files:

      • IBM Business Monitor: monitorEndpoints.xml and monitorWidget.xml
      • IBM Business Monitor with IBM Cognos Business Intelligence: cognosEndpoints.xml and cognosWidget.xml
      • wsumEndpoint.xml and wsumWidget.xml (for user membership)
   3. In a distributed environment, edit the service endpoint files to point to the correct URLs.
      Because endpoints are registered in the application server that hosts the WebSphere Portal server, it is required that all the endpoints point to the remote server with the Business Space component. The endpoints must include the fully qualified name or IP of the remote host, for example:

      <tns:Endpoint>
          <tns:id>{com.ibm.bspace}bspaceCommonWidgetRootId</tns:id>
          <tns:type>{com.ibm.bspace}bspaceCommonWidgetRootId</tns:type>
          <tns:version>1.0.0.0</tns:version>
          <tns:url>http://Business_Space_Host:port/BusinessSpace/</tns:url>
          <tns:description>Location of Business Space Common Widgets</tns:description>
        </tns:Endpoint>

      Configure the endpoints as needed by editing the service endpoint files. Each endpoint in the file is designated by a <tns:Endpoint> block. Identify the block that you want to change. Look for comments that identify where you make the edits, for example:

      <!-- When your REST service is remote from your Business Space server, update the following url
      value with the fully qualified URL to the service. For example https://host.domain.com:9443/rest/bpm/monitor/ -->
       <tns:url>/rest/bpm/monitor/</tns:url>

      Tip: If you do not intend to activate some endpoints, you can remove them from the file to prevent confusion.

      The location identified by an endpoint is specified in <tns:url>. This value is a path in a web module, specified as a full or relative HTTP URL. By default, the URL is relative. Change it to a full URL path, for example, https://virtualhost.com:virtualport/rest/bpm/htm or http://host1:9445/WBPublishingDRAFT/, where the protocol, host, and port identify how the product web module can be accessed.

      To locate the port number for the server, perform the following steps:

      • Log in to the administrative console.
      • Click Servers > Server Types > WebSphere application servers.
      • Click the server for which you want to find the port number, and then expand the Ports section.

      All applications use the same port as shown in either the wc_defaulthost (unsecured host) parameter or the wc_defaulthost_secure (secure host) parameter.
      Important: If you are using an HTTP server to access your web modules for load balancing, use the host name and port settings of the HTTP server.
   4. Open a wsadmin session on your product server. Run wsadmin.bat or wsadmin.sh in the profile_root/bin/ directory. The wsadmin session connects to the local product application server Java virtual machine.
   5. In the wsadmin session, run the updateEndpointBindingsOnPortal command. (In a network deployment environment, run it from the deployment manager.)
      • Jython example:

        AdminTask.updateEndpointBindingsOnPortal('[-nodeName Portal_node_name -serverName WebSphere_Portal -endpointBindingDirectoryName directory_containing_endpoints_files -host Portal_server_IP_or_host -port Portal_SOAP_port -user Portal_admin_ID -password Portal_admin_password]')

      • Jacl example:

        $AdminTask updateEndpointBindingsOnPortal {-nodeName Portal_node_name -serverName WebSphere_Portal -endpointBindingDirectoryName directory_containing_endpoints_files -host Portal_server_IP_or_host -port Portal_SOAP_port -user Portal_admin_ID -password Portal_admin_password}

      For Portal_SOAP_port specify the SOAP port name for the remote WebSphere Portal server; the default is 10025. In a clustered environment, specify the SOAP port name of the Deployment Manager; the default is 8879.

   6. Restart the WebSphere Portal server.
   7. From the WebSphere Portal administrative console, verify the endpoints by navigating to the resource environment provider named WP Mashup Endpoints. Click Resources > Resource Environment > Resource Environment Providers > provider_name > Custom Properties.
2. Configure the Ajax proxy on the WebSphere Portal server. To allow remote URLs to access your product server from the WebSphere Portal server, you must configure the Ajax proxy.
   1. Update your existing proxy-config.xml file with the proxy policy example code snippet shown in Required entries for the proxy-config.xml file to configure widgets to work with WebSphere Portal.
   2. Run the checkin-wp-proxy-config script.

      In a clustered environment, run the script on the primary node.

      ConfigEngine.[bat|sh] checkin-wp-proxy-config -DProxyConfigFileName=dir_path/temporary_proxy_file.name -DWasPassword=application_server_password -DWasUserid=application_server_user_ID -DPortalAdminId=WebSphere_Portal_administrator_ID -DPortalAdminPwd=WebSphere_Portal_administrator_password where dir_path/temporary_proxy_file.name is the complete path of your modified wp.proxy.config.xml file.

      For more information about the proxy configuration, see the WebSphere Portal documentation at http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Global_proxy_configuration_wp7.

   3. From the administrative console, restart the application named AJAX Proxy Configuration.
3. Register the IBM Business Monitor widgets on WebSphere Portal.

   IBM Business Monitor widgets are registered as iWidgets with WebSphere Portal by a bulk import using the WebSphere Portal-specific widget catalog file with your product. The catalog XML file is available at the root of the product web archive (WAR) file. Each product has a different context root.

   There are two types of widgets: common widgets and product-specific widgets.

   The context root for the common widgets is /BusinessSpace, and the catalog file is catalog_commonWidgets_portal.xml. For example, specify the URL to the catalog XML file for the common widgets as http://localhost:9080/BusinessSpace/catalog_commonWidgets_portal.xml.

   The following URLs are examples for business process management products:

   • IBM Business Monitor: http://Business_Space_hosting_Monitor:port/BusinessDashboard/catalog.xml
   • IBM Business Monitor with IBM Cognos Business Intelligence: http://Business_Space_hosting_Monitor:port/CognosWidgets/catalog.xml
   1. Run the following command from wp_profile\ConfigEngine to register iWidgets using your product catalog XML file :

      ConfigEngine.[bat|sh] register-iwidget-definition -DIWidgetCatalog=URL_to_catalog_XML_file -DWasPassword=password -DWasUserid=ID -DPortalAdminId=ID -DPortalAdminPwd=password -DRegistrationAspects=catalogTitlesOverule,considerWidgetParam,considerUniqueName

      Example for IBM Business Monitor:

      ConfigEngine.bat register-iwidget-definition -DIWidgetCatalog=http://localhost:9080/BusinessDashboard/catalog.xml -DWasPassword=admin -DWasUserid=admin -DPortalAdminId=admin -DPortalAdminPwd=admin -DRegistrationAspects=catalogTitlesOverule,considerWidgetParam,considerUniqueName

   2. To verify that the command ran correctly, look for Return Value:0. For more information about optional commands, see the WebSphere Portal documentation at http://www-10.lotus.com/ldd/portalwiki.nsf/dx/Task_registeriwidgetdefinition_wp7.