Generating portlets for heritage human services exposed as dashboards (deprecated)

If you exposed a heritage human service as a dashboard for a group of process participants, and you want to use the dashboard in IBM® WebSphere® Portal, generate a portlet. Then the portal server administrator can deploy the JSR 286 portlet to the portal server runtime environment.

1. For heritage human services that are exposed as dashboards for a group of process participants, click Create a Portlet from the Dashboard on the overview page in the desktop Process Designer to open the Export Dashboard wizard.
2. When setting the parameters for the portlet, consider how the portal server administrator and the process participants use the deployed portlet:
   • Enter a name and a description that describe what the portlet does.
   • If you created an XML file for globalization of the name and description of the portlet, select Globalization and browse to the file.
   • Select the snapshot that represents the version of the dashboard that you want to be generated as a portlet for process participants to use at run time. If you select an older snapshot, changes after the snapshot was taken are not represented in the generated portlet.
3. Optional: Define inbound events for the dashboard portlet.

   At run time, other portlets interact with the dashboard portlet by sending events to it. When the dashboard portlet receives an event from another portlet, it fires a boundary event, moving the dashboard to another coach.

   • For each inbound event that you want this dashboard portlet to respond to, change the event name field to something meaningful to your dashboard. The namespace default value makes the event unique and prevents unintended interactions between portlets.
   • Specify a payload variable if you expect the inbound event to contain data that you want to use to update the dashboard data. If the coach uses a payload variable, select the payload variable that the dashboard portlet receives from other portlets at run time. You can choose from variables that are part of the heritage human service. As previously mentioned, ensure that the payload variable is included on each coach that is part of the heritage human service.
   • Select a coach and a boundary event that represents the user interface element that you want the dashboard portlet to interact with when it receives the event. The boundary event in a heritage human service diagram is labeled as End State Binding. If you selected a payload variable, make sure to select a coach that has the same variable.
   • Define multiple interface elements by clicking the plus sign and designating another coach and boundary event.
   • When the dashboard portlet receives the event, it interacts with only the interface element on the currently displayed coach.
4. Optional: Define outbound events for the dashboard portlet.

   At run time, the dashboard portlet sends events to other portlets.

   • Select a boundary event to designate user interface elements that cause the dashboard portlet to send the event.
   • If you specify a payload variable, the dashboard portlet includes data in the sent event for other portlets to use. As previously mentioned, ensure that the payload variable is included on each coach that is part of the heritage human service.
5. After you finish exporting the dashboard as a portlet, install the .war file on your IBM BPM server and tell the portal server administrator to point to the endpoint for the Web Services for Remote Portlets (WSRP) 2.0 protocol and import the .war file.

   The IBM BPM server comes with a WSRP 2.0 provider already installed, which allows consumption of portlets generated from WebSphere Portal. The URL for accessing the WSPR 2.0 provider web service on an installed IBM BPM server is: http://{BPM_host_name}:{BPM_port}/producer/wsdl/wsrp_service.wsdl. For information on using WebSphere Portal with a WSRP provider, see Using WSRP services on the IBM WebSphere Portal wiki.

   If you are not using WSRP, give the .war file to the portal server administrator to deploy.

   Discuss the following points with the portal server administrator:

   • The administrator should install dashboard portlets on the same cluster as Process Portal.
   • Notify the administrator that the IBMBPM keyword is added to the generated dashboard portlet. The keyword makes it easier for administrators to find and manage the dashboard portlets.
   • Make sure that the administrator knows that portlet preferences can be edited in WebSphere Portal using the edit page for the portlet. The administrator can edit the following information for the dashboard portlet that is generated: host name, port number, width, and height.
   • Give the administrator information about the following IBM BPM portlet preferences that can be edited in the dashboard portlet. All other IBM BPM portlet preferences should not be changed.
     • bpmHost (default: localhost) - The host name or IP address for the server
     • bpmPort (default: 9080) - The port number for the server
     • bpmUseSSL (default: false) - The indication that https should be used instead of http
     • bpmWidth - The width (in pixels) to be used for the portlet iframe that displays the dashboard
     • bpmHeight (default: 400) - The height (in pixels) to be used for the portlet iframe that displays the dashboard
     • bpmUseDojo (default: true) - A boolean value to indicate if Dojo should be used when available for client-side events. If the value is true, the portlet tests if Dojo is loaded and uses the Dojo publish-subscribe methods to send and receive events. If the value is false, the portlet uses server side-events as specified in JSR286.
     Tip: The WSRP Producer for WebSphere Application Server is a stateless producer and does not manage any portlet preferences on the server. If you are using the WSRP Producer, you must update the portlet.xml file that is contained in the exported .war file with any portlet preference changes before the administrator installs the .war file.
   • Tell the administrator the following requirements for using single-sign-on (SSO) and Secure Sockets Layer (SSL) protocol in WebSphere Portal with the dashboard portlets from IBM BPM.
     • To prevent the Process Portal login panel from appearing in the dashboard portlet, administrators should enable and configure single-sign-on for the WebSphere Portal and IBM BPM servers. See Single sign-on for authentication in the IBM Knowledge Center for WebSphere Application Server.
     • To avoid browser messages about secure connects for process participants who connect to WebSphere Portal and use the dashboard portlets, administrators should replace personal, self-signed certificates with those provided by a trusted external certificate authority (CA). See Creating a certificate authority request in the IBM Knowledge Center for WebSphere Application Server.
     • If using personal certificates for testing or in a pre-production environment, the administrator can import the certificates from each system into the browser before testing.
     • In a production environment, administrators should avoid using self-signed certificates.
     • If using HTTPS to connect to WebSphere Portal, the administrator should also use HTTPS in the dashboard portlets. If a part of a page is loaded using HTTPS, and other parts are loaded using HTTP, process participants who connect to WebSphere Portal and use the dashboard portlets might receive a warning that some content on the page is not secure.
   • The portal server administrator should determine whether to use client-side events or server-side events. Both client-side events and server-side events use the boundary events that are modeled as part of the heritage human service definition. The difference between client-side events and server-side events is the channel for communication.

     When using client-side events, the portlets created with Process Designer use the Dojo Toolkit to send messages between portlets that are on the same page in the portal server. Using client-side events is faster, because it does not require events to be sent to the server for processing and does not require page reloads when an event is sent or received. If client-side events are used, the Dojo Toolkit must be loaded as part of the theme for the portal page, and the generated dashboard portlets send events using only the Dojo Toolkit. The generated dashboard portlets receive server-side events from other portlets on the page that are not using client-side events.

     Server-side events do not require the Dojo Toolkit to be loaded and are the standard event mechanism defined in the JSR286 specification. Server-side events take longer to process because the events must be sent to the server for processing and the page must be reloaded to display the results. Server-side events can be used across portal server pages with the correct portal configuration and wiring.

   • If the administrator decides to use client-side events, the Dojo Toolkit must be loaded as part of the theme for the portal page. See the WebSphere Portal V8 documentation Changing the theme default profile or the WebSphere Portal V7.0.0.2 documentation, which requires two steps: Installing a new theme and enabling the full profile to use Dojo by default as described in Theme enablement.