cancel
Showing results for 
Search instead for 
Did you mean: 

URL iView vs WSRP

Former Member
0 Kudos

Hi all,

I was wondering what the advantage of proxy-to portlet WSRP iViews versus URL iViews would be.

In other words, suppose we've got a portlet running on a non-SAP producer. Why would we want to WSRP it instead of creating a URL iView referencing it?

Thank you in advance.

Marco

Accepted Solutions (0)

Answers (1)

Answers (1)

Former Member
0 Kudos

WSRP allows sharing of portlets (iViews) between SAP and

non-SAP portals

Runtime execution of portlets remains on the WSRP producer

<b>Consuming WSRP Content</b>

Any WSRP producer can offer portlets to an SAP NetWeaver

consumer

The SAP consumer can integrate remote portlets into local

content as standard iViews

<b>Producing WSRP Content</b>

Customers and partners are able to develop Java-based iViews

and make them available for WSRP consumption

The WSRP standard provides support for integration on a generic

portlet level only

For more info refer this...

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/e014d4a3-3d08-2a10-1091-8419ff8a...

Former Member
0 Kudos

Well,

I already went through the http://help.sap.com website and the presentation you referred me to, but that doesn't answer my question.

What I'd like to understand is the difference between a URL iView and a proxy-to-portlet one.

Many thanks.

Marco

Former Member
0 Kudos

Hi Marco,

The difference is the following:

URL iView either redirects your browser to the target address (portal looses the scope - browser interacts directly with the target) or acts as a propagator to the browser request by opening an HTTP request (connection) from the portal to the target for the incoming request from the browser. Now, in case the target server creates additional URLs, those URLs will be invoked directly from the browser to the URLs targets (again, portal looses scope) -> this is why it must be isolated in a window frame.

WSRP is a web service protocol that is responsible for allowing the portal user to consume (in your case - consume) and produce content. the WSRP service on the consumer acts as a full propagator to all the user requests from the browser to the destination (producer). The consumer (WSRP service) never looses scope and takes care of embedding the responses into the consumer page (therefore no URL isolation - FRAME - is required) and no DOMAIN / FIREWALL limitations apply to this interaction once the consumer-producer relationship is established.

How I helped,

Avi.