After a short introduction on the general idea of FPN in the previous blog, we are now going to dive really into some detailed aspects of portal federation. Within this blog, we will cover the main configuration steps.
Before starting how to configure FPN, let me say that it is a lot more time consuming and complex to evaluate the organizational aspects and plan the portal architecture in comparison to the configuration steps themselves. You should really make yourself clear how your federated landscape will look like and what you want to achieve with it. You should be aware that governance and organizational processes within your company will be crucial for setting up a federation and maintaining it appropriately. Thus there are some questions you should ask yourself in advance like for example: Which portals should be accessed by end users? In which portals will administrators like content administrators perform their tasks? Who oversees the federated portal network overall and maintains and tests the landscape regularly? And how can I ensure that these guidelines will then be carried out?
After you have answered those questions for yourself, let me briefly state some of the basic boundaries of FPN. These are mainly:
All portals should reside in the same subdomain of the network
The portals should be connected to the same user store preferably (alternatively they could be connected to different user stores, but the user stores contain identical user-id)
The portals have to use the same transport protocol (all are addressed via http or all via https)
There is no “barrier” established between the portals such as firewalls, reverse proxies or load balancers.
We will cover some considerations and required setup steps if some of these requirements cannot be fulfilled in upcoming blogs or articles. Within this blog here we will stay within those limits and cover the steps required in a basic setup.
I would like to point out here two important settings that might lead to a couple of errors if they are not set correctly: Proxy and P4 Port settings. Those settings are relevant for both consumer and producer. The protocols used by the FPN tools are http (for Remote Role Assignment) and RMI P4 (for Remote Delta Links). First of all, you should configure the proxy settings in the portal accordingly, so that traffic leaving your company domain is controlled appropriately and that all content is displayed correctly. For that purpose you should configure the portal configuration service “com.sap.portal.ivs.httpservice - proxy” according to your network settings. The P4 Port is then especially crucial for Remote Delta Link communciation. In standard we expect that the P4 Port is similar to the HTTP Port, but ends with “4” instead of “0” (e.g. http = 50000 - P4 = 50004). It might be the case that you have modified the P4 port of your portal or your landscape requires to connect to a different address, e.g. because there is a load balancer in between the portals. Then you should configure the appropriate FPN service to ensure that P4 communication is working correctly. For that purpose you should fill in the according value into the portal service “com.sap.portal.fpn.persistance - ProducerInformationService”. This step is not necessary if you haven’t modified the standard settings. By the way: you can find the information on the P4 port of your engine on the Web Application Server itself in the area “System Information”.
"
After those basic settings, we can now establish connections between individual consumer and producer portals. For this purpose two basic steps are required as illustrated in the graph above.
First you should set up a trust relationship by exchanging portal certificates and defining the Java Systems as trusted systems. Between two SAP NetWeaver 7.0 (2004s) portals you perform those steps:
1. In the portal under "system administration - keystore administration" (see screenshot 1) you can export your keystore tickets and import those of the other portal.
2. In Visual Administrator in the area "Security Provider - ticket" (see screenshot 2) you enter the details of the system you want to trust.
Those steps have to be performed on both consumer and producer. After you have done that the portals will trust each other and single sign-on from one portal to the other is possible.
"
Screenshot 1 – keystore administration in portal system administration
Now you can define a producer system within a consumer portal. This can be created in the portal under “System Administration - Federated Portal” (see screenshot 3). You should provide the details for the producer system and then register to the producer.
Screenshot 3 – create producer system in consumer portal
You can define on the producer portal a registration password, which will then be required during the registration phase on the consumer side. Moreover, after registration you will see in the producer portal all the consumers that have registered to it and can block access if required. Similar applies for the consumer portal: You can see a list of all producer systems that were created and you can block access to individual producer portals if required.
After you have established both trust and the producer system, you can then in a next step share content between different portals. The methods that are available and some considerations in this context will be covered in the next edition of this blog series.
" 
" 
RECENT COMMENT