WebSphere

Enabling Business Space widgets for multiple endpoints

For multiple instances of service endpoints, for example if you have partitioning of work on two clusters, and you want to have widgets showing data from each cluster, you must enable the additional widgets manually for each additional cluster. You must edit two files: the endpoints file, which registers endpoints with Business Space, and the widget metadata file, which contains definitions of widgets.

Before you begin

Topic scope: This topic applies to the following products:
  • WebSphere® Business Modeler Publishing Server
  • WebSphere Business Monitor
  • WebSphere Process Server
  • WebSphere Business Services Fabric
Before you complete this task, you must have completed the following tasks:
  • Installed the product.
  • Configured a profile, and configured Business Space on that profile.
  • Configured the database tables (if you are using a remote database or deployment environment).
  • Configured all endpoints for your widgets.

About this task

In a deployment environment, you can have partitioning of work. For example, you can have two clusters, one that processes accounting data and one that processes insurance data. However, a service endpoint serves only one cluster. To access both partitions of work from Business Space, you must register two separate widgets, one for each partition of work, so you can access them both from Business Space. For example, you could have an Account Human Task List widget and an Insurance Task List widget in the catalog (both with the same actual human task list code).

If you want to configure multiple instances of the same REST service endpoint, you must manually edit the endpoints file and the widgets metadata file.

Service endpoint registration files are bundled with each product and are added during the installation of the product. The following products have widgets that require manual configuration. You must edit one or more of the following endpoint files, based on the products you have installed, and the widgets you are using with Business Space:
  • WebSphere Business Modeler Publishing Server: pubserverEndpoints.xml
  • WebSphere Business Monitor: monitorEndpoints.xml
  • WebSphere Business Monitor with Alphablox: monitorABXEndpoints.xml
  • WebSphere Process Server, if enabling multiple instances of Managing Tasks and Workflows widgets: bpcEndpoints.xml
  • WebSphere Business Services Fabric: fabricEndpoints.xml
  • This information applies to feature pack. To use what is described, you must have installed the optional feature pack WebSphere Process Server and Enterprise Service Bus V6.2 Feature Pack (for administration widgets): administrationEndpoints.xml
Widget metadata files contain the definition of widgets for your product. You must edit one or more of the following widget files, based on the products you have installed, and the widgets you are using with Business Space:
  • WebSphere Business Modeler Publishing Server: pubserverWidgets.xml
  • WebSphere Business Monitor: monitorWidgets.xml
  • WebSphere Process Server: wpsWidgets.xml
  • WebSphere Business Services Fabric: fabricWidgets.xml
  • This information applies to feature pack. To use what is described, you must have installed the optional feature pack WebSphere Process Server and Enterprise Service Bus V6.2 Feature Pack (for administration widgets): polymorphicWidget.xml, scaWidget.xml, and smGraphWidget.xml.

Both the endpoint registration files and the widget metadata files are located in the registryData directory for Business Space in the directory you created for your profile.

The directory install_root/BusinessSpace/registryData/ contains endpoint and widget definition template files for your product. You can copy the definition files that you need to use as a template and add your changes. The files in your profile directory, profile_root/profiles/profile_name/BusinessSpace/registryData/, on all the nodes for the cluster where the Business Space server is running, contain the endpoint and widget metadata definitions that are currently registered with the Business Space server.

If you are creating an additional instance of a widget, complete the following steps.

Procedure
  1. This information applies to feature pack. To use what is described, you must have installed the optional feature pack For the WebSphere Process Server V6.2 Feature Pack Administration widgets: Configure SCA REST services on your additional application deployment targets. You deploy the SCARestServices.ear on the additional application servers or clusters that you created.
    1. Install the new application from install_root/installableApps/SCARestServices.ear.
    2. When deploying, update the application name and context root name to a unique value. For example, add a suffix to the application name, such as _nodename_servername or _clustername. Take note of the context root name that you use, so that you can use the same value when adding the new SCA Service endpoint in step 3.b.
  2. In order to have multiple instances of a widget, you must install the applications that provide widgets with a unique application name and context root for each widget instance.
    1. Deploy the appropriate widget application on the Business Space deployment target (the same server or cluster on which the BusinessSpaceManager application is running) for each widget instance. Depending on the product and the version that you are using, deploy one or more of the following Enterprise Archive (EAR) files:
      • BSpaceWidgets.ear (for the V6.2 version of your product)
      • This information applies to feature pack. To use what is described, you must have installed the optional feature pack BSpaceITWidgets.ear (for the WebSphere Process Server V6.2 Feature Pack and WebSphere Enterprise Service Bus V6.2 Feature Pack Administration widgets)
      • This information applies to feature pack. To use what is described, you must have installed the optional feature pack HumanTaskManagementWidgets.ear (for the WebSphere Process Server V6.2 Feature Pack)
      • This information applies to feature pack. To use what is described, you must have installed the optional feature pack WorkOrganizerWidgets.ear (for the WebSphere Process Server V6.2 Feature Pack)
    2. When deploying, update the application name and the web module context root names to a unique value. For example, add a suffix to the application name, such as _nodename_servername or _clustername. Take note of the context root names that you use.
  3. Edit the new REST service endpoints for the additional application deployment targets (the server or cluster where the REST services application is deployed). Modify the endpoints file to add additional endpoints.
    1. Locate the endpoints file or the endpoints template file to add new endpoints. If you are working with the template file, copy the endpoints template file. Remove all the endpoints that you do not intend to change.
    2. Edit the endpoints file and add an additional service endpoint starting with <tns:Endpoint>, with a unique ID (<tns:id>) and the URL for the new endpoint (<tns:url>), but with the same version, and optionally all the locales as the original endpoint. The type (<tns:type>) must have the same value as the ID (<tns:id>). You can change the name and description, for example, Insurance Task List.
    3. Save your changes.
  4. Edit the widget endpoints for each widget instance. Depending on the widgets you use, the widget endpoints may be located in either the widget endpoint file or the widget metadata file.
    1. Edit the endpoints file or the metadata file. Add an additional widget endpoint starting with <tns:Endpoint> and with a unique ID (<tns:id>). The type (<tns:type>) must have the same value as the ID (<tns:id>). The URL for the new endpoint (<tns:url>) should be the same as the context root you deployed in step 2, but with a end directory / at the end, for example, <tns:url>BSpaceWidgetsWPS2/</tns:url>. The widget endpoint you add should contain the same version and can optionally contain all the locales as the original endpoint. You can change the name and description.
  5. Edit the widget metadata file, or definition file, to use the new widget endpoints and REST service endpoints.
    1. Locate the widget metadata file or the widget template metadata file to add new widget definitions. If you are working with the template file, copy the widget metadata file. Remove all widget definitions that you do not intend to change, and add your additional widgets in the new file.
    2. The new widget metadata should have its own unique id (<tns:id>). You can keep all the other definitions, and optionally, the local sections if you need them. Change the default and locale-specific name, description, and tooltip to make the new widget available as a distinct widget in Business Space that outlines the nature of the widget. For example, you could name your widget My team's insurance task list in <tns:name>.
    3. Update the <tns:widgetEndpointId> so that it matches the type (<tns:type>) for the widget endpoint that you added in step 4.
    4. Make sure that the endpoint reference (<tns:refId>) matches the type (<tns:type>) for the service endpoint that you added in step 3.b. in the endpoints file.
    5. Save your changes.
  6. Register the REST service endpoints, the widget endpoints, and the widget metadata.
    1. Create following directory: profile_root/profiles/profile_name/BusinessSpace/registryData/, and copy both the endpoints file and the widget metadata file to that directory.
    2. Place the endpoint file and the widget metadata file in the same directory on every node in the cluster where Business Space is deployed. For easier administration, use the same node, if possible. However, the files can be placed on multiple nodes.
  7. Start all the recently installed applications.

Example

The following service endpoint can be copied and modified in bpcEndpoints.xml:
<tns:Endpoint>
	<tns:id>{com.ibm.bpm}HTM</tns:id>
    <tns:type>{com.ibm.bpm}HTM</tns:type>
    <tns:version>6.2.0.0</tns:version>
	<tns:url>rest/bpm/htm</tns:url>
    <tns:name>Location of backing services for HTM widgets</tns:name>
	<tns:description>Location of backing services for HTM widgets
	</tns:description>
</tns:Endpoint>
The following widget endpoint can be copied and modified in wpsWidgets.xml:
<tns:Endpoint>
	<tns:id>{com.ibm.bspace.htm}bspaceTeamTaskListWidgetRootId2</tns:id>
    <tns:type>{com.ibm.bspace.htm}bspaceTeamTaskListWidgetRootId2</tns:type>
    <tns:version>1.0.0.0</tns:version>
    <tns:url>BSpaceWidgetsWPS2/</tns:url>
    <tns:name>Location of widget resources for 2nd HTM widgets</tns:name>
    <tns:description>Location of widget resources for 2nd HTM widgets
</tns:description>
</tns:Endpoint>
Consider the following information when modifying the endpoints:
  • <tns:id>: The ID can be any string but must be unique for all registered endpoints. Ensure that this ID is unique when you are adding additional endpoints.
  • <tns:type>: The type must have the same value as <tns:id>.
  • <tns:url>: For the service endpoint, if the URL is relative, then it is assumed that the REST service endpoint is co-located with the Business Space server. Update this field with an absolute URL if your endpoint is on a remote system. Make sure that you have https as the transfer protocol if your REST service endpoint is secured. For the widget endpoint, make sure the URL is same as the context root you deployed, but with an end directory (/), for example, <tns:url>BSpaceWidgetsWPS2/</tns:url>.
  • <tns:name>: Type a meaningful name to your endpoint that helps identify your endpoint.
  • <tns:description>: Type a meaningful description that further details the nature of the data set that this endpoint is working on. It could either be based on the cluster that is working on the data set or the nature of the data set, for example, insurance claim human tasks or accounting data human tasks.
The following widget definition can be modified in wpsWidgets.xml:
<tns:Widget>
    <tns:id>{com.ibm.bspace.widget}teamTaskList</tns:id>
    <tns:version>1.0.0.0</tns:version>
    <tns:name>My Team's Tasks</tns:name>
    <tns:type>{com.ibm.bspace}iWidget</tns:type>
    <tns:description>This widget displays tasks that have been assigned to 
people within your team.</tns:description>
    <tns:tooltip>My Team's Tasks</tns:tooltip>
    <tns:categoryId>{com.ibm.bspace}tasks</tns:categoryId>
    <tns:widgetEndpointId>
		{com.ibm.bspace.htm}bspaceTeamTaskListWidgetRootId2
		</tns:widgetEndpointId>
    <tns:url>iWidget/widgets/ttlist/TeamTaskList_iWidget.xml
		</tns:url>
		<tns:helpUrl>bspace_help/widget_help/help.jsp?page=myteamstasks.html
		</tns:helpUrl>
    <tns:iconUrl>com/ibm/bspace/widgets/ttlist/themes/images/
		icon_teamtasks.gif</tns:iconUrl>
    <tns:previewUrl>com/ibm/bspace/widgets/ttlist/themes/images/
		prev_teamtasks.gif</tns:previewUrl>
    <tns:previewThumbnailUrl>com/ibm/bspace/widgets/ttlist/themes/
		images/thumb_teamtasks.gif</tns:previewThumbnailUrl>
    <tns:owner>International Business Machines Corp.</tns:owner>
    <tns:email>TBD</tns:email>
    <tns:serviceEndpointRef required="true">
      <tns:name>serviceUrlRoot</tns:name>
      <tns:refId>{com.ibm.bpm}HTMinsurance</tns:refId>
      <tns:refVersion>6.1.2.0</tns:refVersion>
    </tns:serviceEndpointRef>
    <tns:serviceEndpointRef required="false">
      <tns:name>userImageServiceUrlRoot</tns:name>
      <tns:refId>{com.ibm.bspace.htm}bspaceUserImageServiceRootId
			</tns:refId>
      <tns:refVersion>1.0.0.0</tns:refVersion>
    </tns:serviceEndpointRef>    
    <tns:serviceEndpointRef required="true">
      <tns:name>monitorServiceRoot</tns:name>
      <tns:refId>{com.ibm.wbimonitor}monitorServiceRootId</tns:refId>
      <tns:refVersion>1.0.0.0</tns:refVersion>
    </tns:serviceEndpointRef>
    <tns:serviceEndpointRef required="true">
      <tns:name>vmmServiceUrlRoot</tns:name>
            <tns:refId>{com.ibm.bpm}VirtualMemberManager</tns:refId>
<tns:refVersion>6.2.0.0</tns:refVersion>
    </tns:serviceEndpointRef>      
  </tns:Widget>	
Consider the following information when modifying the widget definition to create multiple widgets with the same base functionality and behavior:
  • <tns:id>: The ID can be any string and must uniquely identify the widget definition. For each new widget definition that you add, make sure that this ID is unique.
  • <tns:name>: The default name should help the business users choose the right widget. Type a meaningful name.
  • <tns:description>: The default description should help the business users understand the nature of the data and the functionality of the widget that they are selecting.
  • <tns:tooltip>: This default tooltip further enhances the ability for the business users to select the right widget; when they move a cursor over it, hover help appears.
  • <tns:localeInfo>: Remove the <tns:localeInfo> that you do not need. For the <tns:localeInfo> that you keep in the widget definition, update the name, description and tooltip that are used.
  • <tns:widgetEndpointId>: The widget endpoint ID must match the type field in the widget endpoint definition section. Make sure that the <tns:widgetEndpointId> is the same as the <tns:type>.
  • <tns:refId>: The service endpoint reference identifier must match the type field in the service endpoint definition section. Make sure that the <tns:refId> is the same as the <tns:type>.

What to do next

Set up security for Business Space.


task Task topic

Terms of use | Feedback


Timestamp icon Last updated: 22 June 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic/com.ibm.websphere.wbpm.bspace.config.620.doc/doc/tcfg_bsp_multiple_endpoints.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
This information center is powered by Eclipse technology (http://www.eclipse.org).