'WSRP Application Sharing' Mode 

Description

Web-Services for Remote Portlets (WSRP) is a portal standard that defines a set of interfaces which enable the integration of portlets hosted or rendered on remote portal servers from different vendors. SAP NetWeaver supports WSRP 1.0.

Using this content usage mode, you can share heterogeneous content and applications between NetWeaver and non-SAP portals over WSRP. The following combinations are supported:

·        NetWeaver consumer and non-SAP producer: a NetWeaver portal consumes and integrates WSRP-compliant content from a non-SAP vendor.

·        Non-SAP consumer and NetWeaver producer: a NetWeaver portal exposes its WSRP-compliant content to a non-SAP portal vendor.

A SAP NetWeaver Portal can serve both as a WSRP producer and WSRP consumer at the same time.

You can use this content usage mode to share content between a NetWeaver producer portal and a NetWeaver consumer portal; however there are no benefits over using the remote role assignment or remote delta link copy modes. For NetWeaver-to-NetWeaver portal content interoperability, you should use remote role assignment or remote delta link instead.

This documentation set does not provide information on how to operate a non-SAP portal. Use documentation supplied by the portal vendor.

 

Advantages and Disadvantages

Advantages

Disadvantages

●      Facilitates heterogeneous interoperability of content and applications across independent portal vendors: ●      Increases user productivity by enabling a seamless and consolidated user experience—company-wide applications are accessed through a single portal interface. ●      Runtime execution of portlet-based iViews remains on the non-SAP producer portal, thus reducing the load on the NetWeaver portal. ●      Increases return-on-investment (ROI) by utilizing applications residing on distributed servers. ●      Users can personalize properties of iViews and portlets at runtime.

●      Content must be WSRP-compliant. ●      WSRP standard provides support for integration on a portlet/iView level only. Whole business packages, roles, worksets, and portal pages are not supported. ●      Some restrictions apply to the type of content that is supported by WSRP. Details for NetWeaver content are provided later in this topic. ●      Source iViews/portlets on the producer portal are required at all times for the runtime execution of corresponding iViews/portlets on the consumer portal.

Basic Administration Workflow on a NetWeaver Producer Portal

The following workflow describes the steps performed by administrators on a NetWeaver producer portal in order to expose content to a non-SAP consumer portal over WSRP:

...

       1.      The system administrator defines the root PCD folder for WSRP-based content requests. This allows you to specify which part of your Portal Catalog you want to be accessible over WSRP to non-SAP consumers.

       2.      The user administrator creates a dedicated registration user and password for each non-SAP consumer. This allows you to assign specific content to consumers through the use of portal permissions. It also allows you to assign a unique password for each consumer.

       3.      The system administrator or content administrator assigns access permissions to the content that you want to expose.

       4.      You supply your portal URL and consumer logon information (user and password) to each consumer (this could be done before assigning permissions to content, but is not recommended).

See also: Workflow: WSRP Application Sharing

Basic Administration Workflow on a NetWeaver Consumer Portal

The following workflow refers to a NetWeaver consumer portal consuming content from a non-SAP producer portal:

...

       1.      The system administrator sets up a connection to the non-SAP producer portal and registers itself.

       2.      The content administrator connects to the non-SAP producer portal and browses its shared portlets.

Before a consumer can use this mode, the portal administrators on the non-SAP producer portal must first configure their environments accordingly so they can accept remote WSRP connections and expose content.

       3.      The content administrator selects relevant portlets.

       4.      The content administrator generates local proxy-to-portlet iViews in the Portal Catalog of the NetWeaver consumer portal.

A proxy-to-portlet iView on the consumer portlet functions as a local NetWeaver proxy application that references its corresponding portlet residing on another portal (a producer portal).

       5.      The content administrator integrates the proxy-to-portlet iViews with other local content, such as pages and roles, and assigns it to users.

See also: Workflow: WSRP Application Sharing

Technical Aspects

Pay attention to the following technical aspects when working with the WSRP application sharing mode:

●      At runtime, NetWeaver-derived portlets on a non-SAP consumer execute their corresponding iView on the remote NetWeaver producer, which in turn execute their portal component. Thus, the source iViews on a NetWeaver producer are always needed for non-SAP consumers in order to function.

●      The producer specifies which properties in the source iView or portlet can be personalized by business users executing the remote content from the consumer. Note that at runtime, the application properties of the source iView/portlet are separated from the non-application properties of the proxy-to-portlet iView (see Personalizing Content).

●      WSRP application sharing supports WSRP-compliant iViews/portlets only. SAP application iViews and Web Dynpro iViews are not supported, as well as many SAPbusiness packages. For more information, see the SAP note referenced in Limitations.

For guidelines on developing WSRP-compliant Java applications, see Developing WSRP-Compliant Applications.

●      SAPNetWeaver iViews based on .NETapplications can also be exposed by a NetWeaver producer portal to other third-party WSRP-compliant platforms.

For more information about SAP Portal Development Kit (PDK) for Microsoft .NET and for guidelines for creating WSRP-compliant .NET applications, go to www.sdn.sap.com/irj/sdn/dotnet on the SAP Developer Network, and then access the Development Center link.

●      Application-oriented services are not supported:

○       Client-side eventing

○       Object-Based Navigation (OBN)

○       WorkProtect Mode for securing user data

●      If the non-SAP producer exposes its portlets with the corresponding WSRP classes (CSS classes, such as portlet-font), the portlets render at runtime in the look and feel of the NetWeaver Portal theme.

●      Personalization data made by end users on the consumer is stored on the producer portal.

 

The following figures illustrate the design time and runtime aspects of WSRP application sharing between NetWeaver and non-SAP portals:

 

Figure: WSRP application sharing of portlets between a non-SAP producer and a NetWeaver consumer. At design time, the content administrator on the NetWeaver consumer chooses an exposed WSRP portlet from the producer and generates a local proxy-to-portlet iView. The content administrator on the consumer then assigns the local iView (iView A) as a delta link to a local role (Role A). When users assigned to Role A log on to the consumer portal at runtime, the execution of iView A' in Role A passes through iView A, which executes the portlet on the producer portal. HTML markup is returned to the NetWeaver consumer portal.

 

Figure: WSRP application sharing of portlets between a NetWeaver producer and a non-SAP consumer. At design time, the content administrator on the non-SAP consumer chooses an iView exposed from the NetWeaver producer and generates a local consumer portlet. The content administrator on the non-SAP consumer then assigns the portlet to its users. At runtime, the consumer portlet executes the WSRP-compliant iView and the portal component on the NetWeaver producer. HTML markup is returned to the non-SAP consumer portal.