Show TOC

Running the UWL in the Consumer PortalLocate this document in the navigation structure

Use

To use the universal worklist (UWL) in a federated portal network landscape we highly recommend running the UWL directly in the consumer portal. In this case the maintenance is much easier.

The following figure shows the connections between the consumer portal and the producer portal and also the back-end systems, for example customer relationship management (CRM) if the UWL runs in the consumer portal:

Procedure

You have to configure the UWL to do the following:

  • Connect directly to the Business Workflow and alert systems to get work items and alerts

  • Launch applications in corresponding producers and back-end systems.

1. Transport XML configurations

Transport the XML configurations manually from all producers to the consumer.

More information: UWL Content Configuration

Note

Clear the cache after the XML configuration upload.

If producers run different versions of the same application, merging XML configurations from different versions can cause item type and view name conflicts.

2. Copy iViews and Portal Pages as Remote Delta Links

Copy all iViews and portal pages that have to be launched as a remote delta link from all producers to the consumer.

If producers run different versions of the same application, the iViews or portal pages to be launched can have the same IDs in several producers. In this case, the remote delta link of the conflicting iViews and portal pages has to be resolved manually. Only one of the source objects in the producer can be copied by the remote delta link to the consumer into the same location and ID of the source object in the producer. All other objects must be copied as remote delta links into a different location in the consumer, which causes a change in their original ID.

More information: Consuming Content as Remote Delta Links

Since item types are configured to launch iViews or portal pages, the iViews and portal pages are configured against an iView ID or a portal page ID. This requires a manual change in the configuration XML file. This also implies that if an item type is configured in the back end its configuration has to be overwritten by a configuration XML file.

Example:

Producer 1 has an item type configured to launch an iView ID1:

<Action name="launchIView" handler="IViewLauncher">
  <Properties>
   <Property name="iview" value="ROLES://portal_content/com.sap.pct/every_user/general/iViews/myDemoIView"/>
  </Properties>
 </Action>
            

Producer 2 has an item type configured to launch the same iView ID1:

<Action name="launchIView" handler="IViewLauncher">
  <Properties>
   <Property name="iview" value="ROLES://portal_content/com.sap.pct/every_user/general/iViews/myDemoIView"/>
  </Properties>
 </Action>
            

The iView ID from producer 1 is linked by a remote delta link to iView ID1 at the consumer. iView ID1 from producer 2 is linked by a remote delta link to iView ID2 at the consumer. You have to change the configuration XML file from producer 2 before you upload it in the consumer portal:

<Action name="launchIView" handler="IViewLauncher">
  <Properties>
   <Property name="iview" value="ROLES://portal_content/com.sap.pct/every_user/general/iViews/myDemoIView1"/>
  </Properties>
 </Action>

            

3. Transport System Definitions and Their Aliases

Transport the system definitions and their aliases manually from the producers to the consumer.

If producers run different versions of the same application, the same system alias name can point to different back-end systems. The system alias names in the consumer portal are allowed to be defined differently. This implies that the XML configurations from producers do not have to contain any references to system aliases defined in producer portals.