Additional Blogs by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
jana_richter
Active Participant
0 Kudos

In the previous blogs of this series we have seen what the goal of FPN is overall and how you can set up the environment. You can find the link to those 2 blogs at the end of this one. Within this blog here, I would like to go deeper into the topic “How can I share content between my portals?”

As said in the previous blogs already, the federated portal network is all about linking from one portal to the content of another portal and thus creating a relation between them. SAP currently offers 3 options on how you can share content between the portals:

  • Remote Role Assignment (RRA)
  • Remote Delta Links (RDL)
  • Web Services for Remote Portlets content sharing (WSRP content sharing)

RRA and RDL can only be used for sharing content between SAP NetWeaver Portals and I am focusing on these two sharing modes in this article. WSRP can be used when federating portals from different vendors and we will cover this more in detail in a later edition of this blog series.

Before going into the details of the content sharing modes and their meaning, let me illustrate the standard content creation tasks within a portal:

  1. In some cases, like Web Dynpro Java applications, you can deploy those applications to the Application Server of the portal.
  2. You create an iView that will enable the access to an application, report, information …
  3. You build a page that contains iViews and this page defines layout and arrangement of them.
  4. You can create a workset that defines clusters of related tasks (pages + iViews and maybe some additional navigation structures).
  5. Worksets are bundled into a role which defines a person’s responsibilities and authorizations in the organization.
  6. Roles are assigned to portal users or groups.

Now, in the following paragraphs I will cover some more details on the individual content usage modes and their relation to a “classical content creation process”.

Remote Role Assignment (RRA)

As the name already indicates, we can share roles from one portal with another. On the producer portal you are going through the whole content creation process and define a role for your organization. Then in the consumer portal this role can be assigned to users through the standard user administration tools. Thus you have the majority of portal content administration steps performed on the producer portal and use the consumer portal only for providing those roles to users (see figure 1). The only option for modifying those roles slightly on the consumer portal is role merging. This means that you could define IDs that merge the navigation structure and content from different roles into one content offering for end users (more documentation on role merging is available on SAP Help: http://help.sap.com/saphelp_nw70/helpdata/en/53/89503ede925441e10000000a114084/frameset.htm)

 
Figure 1 - Remote Role Assignment: Portal Content architecture

So how does Remote Role Assignment work then? You can use the standard functionality in the portal in “User Administration „³ Identity Management”. There, since SAP NetWeaver 7.0 SPS 09 you can find a modified UI offering drop down boxes for data sources. If you have defined a producer system and alias successfully before, you can find this in the field data sources. For example you could search for all roles that you have permissions for on a specific producer portal. You can assign this role to local users on your consumer portal (see Figure 2)

 
Figure 2 - Remote Role Assignment Screenshot

One remark at the side: Behind the scenes when assigning a remote role to a user on the consumer portal those roles are assigned to the same user on the producer portal too. This is done in order to really show during runtime only content that the user has permissions for on the producer portal.


Remote Delta Links (RDL)

Remote Delta Links are following the paradigm of usual delta links, but enable using them cross-portal. With a delta link, you basically create a child of an object (e.g. iView) and can modify its properties. All non-modified properties are going to be inherited directly from the original object, thus changes on the original are reflected in the delta-linked object. All changed properties contain “broken delta-links”, thus they won’t change if the original changes. You can create remote delta links for iViews, pages, worksets and roles. This gives you the possibility to adjust the content to the needs on the consumer portal and integrate them into the local content offering (see figure 3).

 
Figure 3 - Remote Delta Links: Portal Content architecture

How does RDL creation work? If you go into the portal content directory (pcd) of your consumer portal, you could see the entry “NetWeaver Content Producers”. In there you can find the aliases of the producers that were created (see figure 4). Clicking on them will show the portal content that you are allowed to see. You can right-click on this portal content and paste it as local content into the pcd of the consumer. On the consumer you will then see a small symbol with a globe, indicating that this object is inherited from a remote location.

 
Figure 4 - Remote Delta Link Screenshot 

Remote Role Assignment vs. Remote Delta Links

After I have explained those 2 modes: Now, when should you use which one? Is Remote Role Assignment or Remote Delta Links more beneficial for you? Of course there’s no simple answer to that and it always depends on what you want to do. But here are some general guidelines and recommendations.

First of all, you should make yourself clear, in which portal you would like your content administrators to work. There might be 2 major options: Case 1 -  If you establish a federated portal network, because different departments within your company would like to work on their individual portals and share this content, then content creation activities are desirable on a producer portal. Case 2 - If you are setting up a federation due to technical reasons, like different SPS or releases should be available for the portal or you would like to distribute load, then you still would like to have the majority of content admin activities in one central place – the consumer portal. With Remote Role Assignment you can perform the full content creation process on the producer side and on the consumer you only assign those roles to users – thus this might help more in the case 1. With remote delta links you can manage the portal content, like building up navigations structure, adjust permissions to objects … on the consumer – thus it might be more desirable in case 2.

Required modifications on the consumer are an important consideration as well: If you would like to adjust content on the consumer, then Remote Delta Links provide more flexibility then Remote Role Assignment. Mergingremote roles is a valid option too, but you will come to its boundaries quite fast.

Performance might influence your decision too: If you are using remote roles you should be aware that during the initial log on of a user to consumer portal those roles will be fetched if they aren’t in the cache anymore. Thus the connection between consumer and producer will influence the logon time to the consumer portal. Remote delta linked objects will only be fetched when they are accessed by the enduser (of course only if they are not integrated into the top-level-navigation).

Moreover, the user stores connected to the portals might influence your decision too. At the moment there is an open restriction existing for remote roles: In case you are connecting different user stores to your producer and consumer portal, then you cannot assign remote roles to groups. An example for this would be a consumer portal connected to a corporate LDAP user store and the producer portal to an ABAP CUA (central user administration). Reason for this limitation is that FPN cannot make sure that the groups are identical on both user stores - even if the ID seems to be identical it’s not sure whether the contained users are consistent. This would impose a security risk otherwise. Thus remote roles can then only be assigned to individual users. In case you will face this constellation, it might be more advisable to create remote delta links of roles, paste these roles into your local pcd and then assign them to groups on the consumer portal.

There might be some more factors influencing your decision the content usage mode, but as of now these are the major ones that I encountered so far. Hope this helps when you are facing the situation that you would like to choose the right content usage mode for your scenarios.


So far for the content sharing modes Remote Role Assignment and Remote Delta Links. In the next edition of this blog series I will give you some more insights on WSRP.

 

Overview Blog Series FPN:

An Introduction to Federated Portal Network (FPN)
FPN Part II - Configuring a Federated Portal Network
FPN Part III: Sharing Content between SAP NetWeaver Portals in an FPN - this blog

9 Comments