Entering content frame

Function documentation Portal Application Lifecycle Locate the document in its SAP Library structure

Use

The PAR files are stored in the application repository. There is only one application repository and all PRT nodes of the SAP J2EE cluster share the same content. The administrator will typically use administration tools to create the portal content; some of them are used to upload portal applications to the application repository.

Portal applications are also deployed locally (on each PRT node). The main purpose of the local deployment is to improve performance by providing fast access to resources, and avoiding too many accesses to the application repository. In that sense the local deployment is a cached copy of the original version; the local version should not be modified directly.

PAR Upload Process

This graphic is explained in the accompanying text

Activities

...

       1.      When a component or a service of a portal application is accessed for the first time (for example, upon an HTTP request), the PRT has to load the implementation class and instantiate the corresponding objects. The portal application broker checks internally whether the object is already available and returns it.

       2.       If the object is not yet available, PRT tries to get it from the local deployment. This step checks the revision number of the application to make sure the local deployment is up-to-date. If a new version is available in the repository, then step three is performed. Afterwards, the broker loads the class and instantiates the object.

       3.      When a new version is available, the local deployment is updated. The deployment process gets the PAR file from the repository and deploys it on the file system. The content of the PAR file is split into two parts.

       4.      The portal application runs and remains in the memory unless a new version is deployed or an administrator decides to release the application. The system can also discard portal application instances when the Java VM needs to free up some memory.

Application Dependencies

When an application is loading, all the application dependencies are deployed and loaded first of all. Then the PRT checks the dependencies that are declared in the deployment descriptor using the SharingReference and PrivateSharingReference properties.

This step guarantees that the class loader of application it depends on is ready to be used. Each portal application is loaded in its own memory space. This space is divided into a public part corresponding to the API of the application and a private part corresponding to the core implementation.

Hot Deployment

In a cluster scenario (N numbers of PRT nodes shares a single repository), the PAR upload will notify all PRT nodes that a new version of the application is available. Upon the notification, each PRT node will:

·        Check if the application is already loaded and running

·        Release this application and all elements (components, services, and applications) depending on the application

·        Update the local deployment

·        Reload the application and the dependents that have been released

·        Restart load-on-startup services

This graphic is explained in the accompanying text

Applications can be marked as non-releasable in their deployment descriptor. This flag has no impact during hot deployment, so the application will be released in any case. The “non-releasable” property guarantees that PRT keeps the application instance even when the VM runs low in memory.

 

 

Leaving content frame