How Requests Are Handled (by
Server)
The Java EE application for the portal defines the following two servlets:
· Gateway: A servlet that handles requests for the portal home page.
· Portal Runtime Dispatcher: A servlet that handles requests for running a specific PRT (native) component, or iView.
The detailed process flow for running and rendering a PRT component starting with this dispatcher servlet, including what methods are called in your portal component, is described in the How Requests Are Handled (by Portal Runtime).
Process Flow
The simplest way to enter the portal is to enter the following URL:
http://<server>:<port>/irj/portal
The following describes what occurs when AS Java receives such an HTTP request:
...
1. The J2EE engine identifies the request as belonging to the irj application, and checks the web.xmlfor that application to determine how to handle the request.
The web.xml file defines two servlets for handling portal requests:
○ Gateway servlet
○ Portal Runtime dispatcher servlet
The J2EE engine selects a servlet based on the URL and the <servlet‑mapping> entries in the web.xml.
The following are the key elements of the web.xml file, which is located in root/WEB-INFdirectory of the J2EE application directory for the portal (irj):
<web-app>
...
<!--Gateway Servlet-->
<servlet>
<servlet-name>gateway</servlet-name>
<servlet-class>com.sap.portal.navigation.Gateway</servlet-class>
...
<!--URLs for standard and anonymous requests-->
<init-param>
<param-name>portal_entry_point</param-name>
<param-value>/servlet/prt/portal/prtroot/
com.sap.portal.navigation.portallauncher.default</param-value>
</init-param>
<init-param>
<param-name>portal_anonymous_entry_point</param-name>
<param-value>/servlet/prt/portal/prtroot/
com.sap.portal.navigation.portallauncher.anonymous</param-value>
</init-param>
<init-param>
<param-name>portal</param-name>
<param-value>anonymous=0,proxy=0,low_bandwidth=0,
include_in_url=1,include_application_name_in_url=1</param-value>
</init-param>
</servlet>
<!--PRT dispatcher servlet-->
<servlet>
<servlet-name>prt</servlet-name>
<servlet-class>com.sapportals.portal.prt.dispatcher
.Dispatcher</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<!--URL/servlet mapping-->
<servlet-mapping>
<servlet-name>gateway</servlet-name>
<url-pattern>/portal/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>prt</servlet-name>
<url-pattern>/irj/*</url-pattern>
</servlet-mapping>
<servlet-mapping>
<servlet-name>prt</servlet-name>
<url-pattern>/go/*</url-pattern>
</servlet-mapping>
...
</web-app>
2. The request is sent to the gateway servlet, which does the following:
a. Checks the URL and determines the alias, or path following the /irj, that was used in the request URL.
b. Matches the alias to one defined in the web.xml, and retrieves the settings for that alias, for example, whether the request requires authentication or the request can be accessed anonymously.
The aliases are defined as parameters of the gateway servlet.
c. Redirects the request to the relative URL for either the standard component of the portallauncher PRT application, or to the one that enables anonymous requests.
These URLs are defined by the portal_entry_point andportal_anonymous_entry_pointparameters of the gateway servlet.
3. The J2EE again checks the web.xml to determine how to handle the redirected request, and this time sends it to the PRT dispatcher servlet.
4. As part of the PRT engine process flow for running a PRT component, the standard portal connection is called. This connection does the following:
a. Checks the component application’s portalapp.xml to determine if anonymous access is permitted, that is, the AuthScheme property is set to anonymous.
b. If authentication is required, the portal checks if the user is authenticated by checking if one of the following exists:
■ Valid logon cookie
■ Valid user name and password
If neither exists, the user is redirected to the J2EE user management logon page, ad the following occurs:
■ The user enters a valid user name and password.
■ A logon cookie is created for the user.
■ The request is redirected again to the PRT dispatcher servlet.
■ The portal connection again checks for a valid cookie, and since one now exists, the process flow continues.
5. The PRT engine checks the security zone for the requested component, in this case the portallauncher application.
○ If the current user has permission, the component is run.
○ If the current user does not have permission, an error is displayed.
All users, even anonymous users, have permission to the components of the portallauncher application.
6. The portallauncher component calls the desktop service to get the appropriate desktop for the current user and renders the framework page for the current user.