Q) What is an external-facing portal?
Ans: An external-facing portal is an implementation of the SAP NetWeaver Portal as a public Web site.
An external-facing portal is open to the internet, providing content to anonymous users, internal employees and business partners and enabling users to self-register in order to access additional content and to personalize the portal.
An external-facing portal uses features of the portal that provide Web-like behavior (for example, use of the browser navigation buttons) and reduce the amount of resources required to view portal pages.
Although not always appropriate for certain resource-rich applications, the external-facing portal can boost ROI by using the same platform for the company's internet and intranet implementations.
Q) What version of NetWeaver do I need to implement an external-facing portal?
A: SAP NetWeaver ’04 SPS 14 or higher, or SAP NetWeaver 2004s SPS 6 or higher.
Q) Where can I find the limitations of implementing an external-facing portal using SAP NetWeaver Portal?
A: SAP Note 877188 and SAP Note 853509.
Q) Why shouldn’t I use the external-facing portal for internal implementations?
A: It is recommended not to use this solution for internal use because some functionality that is commonly used for internal implementations is not supported.
Specifically, session management and WorkProtect mode are not supported as they require the use of the client framework JavaScript. Therefore, some standard SAP content – such as Web Dynpro, SAP business packages and KM (especially collaboration) – that uses these features are also not supported.
In addition, to get the full benefit of the performance improvements in an external-facing portal, the content must be “light” and supported by the light framework page. Content in internal implementations generally does not meet these requirements. For more information on recommended content for an external-facing portal, see the Content section.
Q) Should I use the provided light framework page for my external-facing portal implementations?
A: Your external-facing portal should use the light framework page, but we recommend that you customize or replace the out-of-the-box navigation iViews within the light framework page. You can easily do this with the Navigation and Framework tag libraries.
Q) What content is recommended for an external-facing portal?
A: Content within an external-facing portal must be supported by the light framework page. And in order to get the full performance benefits of an external-facing portal, content should also be “light”.
Q) What content is not supported by the light framework page?
A: The following types of content are not supported:
• Web Dynpro
• SAP business packages
• Collaboration rooms (see below for more information on Knowledge Management)
These applications and business packages make use of the session termination and WorkProtect mode features of the portal, which are not supported in the light framework page.
Q) What content is considered “light”?
A: Content that does not use a lot of resources is considered “light”.
The following are guidelines for creating “light” content:
• Use static content as much as possible.
• Avoid HTMLB.
• Avoid client-side eventing (specify in the portalapp.xml an EPCFLevel value of 0 for no eventing).
• Use the navigation tag library for navigation links.
• Use page layouts with custom iView trays. The default iView tray uses HTMLB.
• Do not create Related Links for iViews and pages, as the Related Links iView is considered "heavy" content.
• Make sure that any dynamic navigation iView for your content is also light.
• Avoid the out-of-the box Knowledge Management iViews.
• Avoid using EPCM.doNavigate Links; use ?NavigationTarget= links instead, to avoid loading the EPCM framework.
Q) What content is considered “heavy” and not as suitable for an external-facing portal?
A: The following types of content are considered “heavy”:
• HTMLB
• Knowledge Management iViews
Q) Can I still use HTMLB and client-side eventing in an external-facing portal?
A: Yes, however, the portal will not enjoy the performance benefits from the light framework page. The performance impact from HTMLB is much more significant than from client-side eventing.
Q) Can I still use Knowledge Management (KM) in an external-facing portal?
A: Yes, but with the following restrictions:
• KM iViews are considered “heavy” content.
Although you can run KM iViews in the light framework page of an external-facing portal, a portal running these iViews does not enjoy the performance benefits of the light framework page.
• Browser functionality (that is, the use of the browser’s navigational buttons, such as Back, Forward and Add to Favorites) is not supported within KM iViews.
• KM content may not be indexed by search engines.
• KM content cannot be accessed via the quick links implementation.
Q) Are collaboration rooms supported in an external-facing portal?
A: No.
Q) Can I run .NET iViews in an external-facing portal?
A: Yes, but some HTMLB and other JavaScript files will be loaded automatically, making such iViews not as light.
Q) How is navigation different in an external-facing portal?
A: In an external-facing portal, the light framework page displays portal pages in a single frame.
When a user clicks on a navigation link, the following occurs:
• The browser retrieves new content for the entire browser window.
With the standard framework, new content is generally retrieved for the desktop inner page only.
• The URL for the current page is displayed in the browser address field.
With the standard framework page, the URL for the portal’s home page is generally displayed.
Q) How is the light framework page assigned to users?
A: Administrators create desktop rules to assign desktops to different users.
A desktop is a combination of a framework page and a theme. Desktops can be assigned based on such parameters as the user name, the user groups to which the user belongs, the portal alias in the URL, or the bandwidth of the user's connection.
Q) Is it possible to switch between the light and standard framework page while a user is logged in (for example, in order to display static content in the light framework page and KM or Web Dynpro content in the standard framework page)?
A: No.
As display rules are used to provide a user with the relevant desktop when logging on, the user receives a framework page that cannot change until the user logs off. If the user then logs on again, the user could receive a different framework page if a different user name or URL is used.
However, it is possible to provide a light desktop containing the light framework page to all anonymous users and, then, provide the standard framework page when the user logs in.
Q) Will the pages in my external-facing portal be indexed by internet search engines?
A: Yes. Since navigation links in an external-facing portal include a complete URL that uniquely identifies a specific navigation node, search engines will be able to index portal pages.
However, KM content contained within KM iViews is not indexed.
For further information on how to make your portal searchable, refer to the search engines Web master guides.
Q) Can I use styles that are set in the Theme Editor with my light navigation iViews?
A: The default light navigation iViews that come with the portal contain styles that can be customized using the Theme Editor. These styles are listed in the Theme Editor under Light Top-Level Navigation and Light Detailed Navigation.
You can create your own light navigation iViews by copying the default light navigation iViews and making modifications, while keeping the styles already defined in these iViews.In your light navigation iViews, you cannot use styles set in other areas of Theme Editor, nor can you create your own styles and link them to the Theme Editor.
Q) Can I use the Navigation, Framework and Layout tag libraries to create navigation iViews and custom layouts for the standard framework page?
A: Yes.
Q) How is user management configured in an external-facing portal?
A: User management is configured just as in a standard portal implementation, except that anonymous users are given access to content.
In an external-facing portal, administrators must do the following:
• Enable anonymous users by opening the portal to the internet and configuring the portal to accept anonymous users. Anonymous users can access the portal with the
by default, anonymous users are given access to the portal.
• Map anonymous users to a specific user defined in the portal Guest is the default anonymous user, and this user is part of the Everyone, Anonymous Users and Guests groups.
• Assign content to this user, or to the Anonymous Users group.
• Map registered users to groups.
By default, self-registered users are assigned to the Everyone group. You can configure the system to assign registered users to one or more specific groups.
• Assign content to the groups to which self-registered are assigned.
Q) How is performance improved in an external-facing portal?
A: An external-facing portal makes use of the light framework page, which displays portal content in a single frame. This framework page includes navigation iViews that do not use HTMLB or client-side eventing, eliminating the need to download relatively large resource files.
The following portal features were developed to improve the performance of an external-facing portal but can be used in any portal implementation:
• Navigation Cache: The portal can cache navigation hierarchies and nodes. For a user with the same navigation hierarchy as a previous user, the portal can retrieve the hierarchy from the cache instead of creating it again. This saves time and improves performance.
• Short (hashed) URLs: In navigation links, navigation nodes are specified by short GUIDs instead of the entire navigation path, which can be very long.
• Resource-Sensitive Page Builder: The page builder only downloads the JavaScript that is required by the current page or iView.
Q) I have implemented an external-facing portal, but my performance is not much better than when I used the standard framework page. How come?
A: The performance gains in an external-facing portal are due to reducing the resources required by the framework page and navigation iViews inside the framework page.
However, performance is also dependent on the iViews that are run in an external-facing portal and the resources they require. If resource-intensive (“heavy”) applications are run in an external facing portal, the performance gains may not be as noticeable.
In addition, the Related Links navigation iView uses HTMLB and client-side eventing, so any page with a Related Links iView will not be "light".
Q) Can I use the features of an external-facing portal to improve performance in my internal portal?
A: The performance gains from the use of the navigation cache, short URLs and resource-sensitive page builder can be used in any portal implementation.
The light framework page is designed for use in an external-facing portal.
Q) What functionality do I lose as a result of the performance improvements?
A: The light framework page does not support the WorkProtect mode and session termination features.
Therefore, applications that require these features – including Web Dynpro applications – may not operate properly in an external-facing portal.
No comments:
Post a Comment