Portal Runtime (PRT) 

The Portal Runtime (PRT) is the system that gathers and runs iViews. It is open and extensible, allowing changes to its components, and supports different programming and user interface models.

Access to the PRT is done by means of the PRTBridge service and Portal Runtime Container that are implemented in the SAP Web Application Server. The integration between the PRT and the SAP Web Application Server enables the portal to leverage the J2EE standardization and implementation.

In addition, the PRT is a host to Portal Applications. A portal application consists of Java software that is programmed for the portal. The PRT manages the following objects for portal applications:

·        Portal Components

A portal component is an object that can be executed in a portal application. For more information, see Portal Components.

·        Portal Services

A portal service is an object that is available to every portal component. For example, the User Management service connects to the User Management Engine (UME). For more information, see Portal Services.

The Portal Runtime container enables the PRT to analyze any URL request, and to find out if a request is intended for the portal. It then handles connection for that request only if it is intended for the portal.

Default functionality in the PRT is that it recognizes only two messaging mechanisms:

·        A servlet connection - the default connection of the portal

·        A SOAP connection - for handling SOAP messages

A request consisting of commands, instructs the PRT to perform some specific tasks such as, running a specific routine, or fetching a set of attributes or values for a specific component.

The PRT directly or indirectly obtains two types of requests from the Portal Framework:

·        A set of queries

·        A set of commands

A request in the form of queries may ask for a specific portal component, information about that component, and the content for its iViews. For example:

·        Create a static list that describes all the iViews relating to a specific portal component.

·        Check whether a specific user requesting the content of a specific iView is authorized to access the iView.

A logical relationship exists between the portal runtime and iViews. This relationship facilitates separation between the communication requirements of the portal from the implementation of iViews. For example, an iView can be implemented to use any suitable portal component.

How the Portal Works

On initializing the portal for the first time, a set of predefined portal applications, such as the security and authentication mechanisms, user management functions, notification and other tools, are loaded by the PRT.

When you start the portal, you initiate a request for an initial page and the content of iViews in that page. Within the page, you can navigate and launch requests for the content of other iViews, or for other pages.

The two types of requests sent to the PRT are for either a page or an iView.

When a request is launched for an iView, the Web server activates the request cycle. There are components responsible for passing incoming requests to the PRT.

The PRT then loads the implementation class and instantiates the corresponding object. Internally the portal application broker checks whether the object is already available and then returns it.

If the object is not yet available, PRT tries to get it from the local deployment. If a new version is available in the repository then the local deployment is updated. Afterwards, the broker loads the class and instantiates the object.

The deployment process gets the PAR file from the repository and deploys it on the file system.

The following is an illustration of the processes that are set in motion in the portal when it receives a request from the browser:

       1.      When a user launches an iView, the client sends an HTTP or HTTPS request to the Web server.

       2.      The Web server recognizes the URL as a PRT request and then it triggers the PRT.

       3.      The PRT parses the request and identifies the following:

¡        Requested object from the PCD, either a page or an iView

¡        User related data, such as personalization data, logon language, page personalization, iView personalization.

¡        Additional pieces of information.

       4.      If the user that made the request has permissions for the requested object, the following information is obtained:

¡        Portal component to be executed, for example the Page Builder.

¡        Profile (set of properties) to be passed to the portal component. This may be a set of properties of an iView or page.

The PRT obtains an instance of the portal component to be executed, and provides it together with other information obtained from the PCD.

If the request is for a page, the activated portal component is the Page Builder. The Page Builder component parses the information, assembles the page, and produces the HTML.

If the request is for the content of an iView, the PRT activates the appropriate components, which in turn may use portal services to produce the HTML.

For example, the initial portal page, including its content, are assembled and produced by the Page Builder. Navigation in the portal page can activate a request for either the content of an iView or other pages.

       5.      The HTML is then returned to the browser.