P. 1
prtguide60

prtguide60

|Views: 280|Likes:
Published by jorgeb1985

More info:

Published by: jorgeb1985 on Jan 18, 2011
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/12/2011

pdf

text

original

Sections

  • 1 Portal Runtime Technology
  • Introduction and Positioning
  • Concepts and Terminology
  • Portal Environment
  • Portal Application Archive (PAR files)
  • Portal Component Profile
  • Portal Component Config
  • Portal Runtime Mode
  • Portal Object Model (P.O.M.)
  • Application Repository
  • 2 Portal Infrastructure
  • Packaging
  • Core Applications
  • 3 Portal Runtime API
  • Component
  • IPortalComponent
  • AbstractPortalComponent
  • Service
  • IService
  • IServiceContext
  • Request/Response
  • IPortalComponentRequest
  • IPortalComponentResponse
  • 4 Portal Application Archives
  • PAR File format
  • Web Resources
  • Non-Web Resources
  • PAR Building
  • Structure of the Deployment Descriptor
  • Portal Application
  • Portal Application Configuration
  • Portal Components
  • Portal Component Configuration
  • Portal Component Profiles
  • Portal Services
  • Portal Service Configuration Properties
  • Portal Service Profiles
  • 5 Portal Application Life Cycle
  • Overview
  • Application Dependencies
  • Hot Deployment
  • 6 Portal Runtime Architecture
  • Request Dispatcher
  • Dispatcher API
  • Dispatching a Request
  • Portal Runtime API
  • Portal Runtime Core
  • Portal Registry
  • Central Configuration Storage
  • Portal Runtime Cache
  • Properties
  • Caching Expiration
  • Portal Application Repository
  • Portal Connection Framework
  • 7 Request Cycle
  • Node
  • Portal Component Mode
  • Accessing to a Mode
  • Mode Handling
  • Portal Hooks
  • Purpose
  • Adding a new Portal Hook
  • Default hooks
  • Event Handling
  • Internal Portal Runtime Events
  • Request Event API
  • Component Event API
  • 8 JNDI Support in PRT
  • PRT JNDI Support Package
  • JNDI Service Providers
  • JNDI Clients
  • JNDI Service Providers Packaging
  • JNDI Provider Resource File Sample
  • JNDI Concepts and Related Documents
  • JNDI Environment
  • JNDI Context
  • JNDI Context Factories
  • 9 WEB Services Support
  • Approach
  • Portal Services as WEB Services
  • Portal Applications and external WEB services
  • Concepts
  • Architecture
  • 10 PAR IDE
  • Additional Feature
  • 11 Compatibility Considerations
  • EP 5.0 Backward compatibility
  • EP50 Deployment Policy
  • EP50 Class Loading
  • EP50 Archives
  • List of Incompatibilities to EP 5.0
  • UNIX/Windows compatibility
  • 12 Additional PRT Services
  • Notification Service
  • Content Conversion Service
  • Content Converter Service
  • JCO Client Service
  • Service Description
  • Implementation
  • Security Open Issues
  • 13 Configuration Management in Portal Application
  • Create a Config Archive
  • Place your configuration files in folders
  • Important Points
  • Use Export PAR File of the PAR IDE
  • Config Archive properties file
  • Access data
  • Modify portalapp.xml
  • Virtual Components
  • Sharing Configuration between Applications
  • Use the Config Framework API
  • Configuration Event Subscription
  • Implement the interface IConfigEventListener
  • Add a listener
  • Remove listener
  • Start the Config Mode
  • 14 Exception Handling
  • Issue Overview
  • Coding Rules
  • Always pass the original exception
  • Always include a message
  • Always include a message
  • Do not make wrong assumptions
  • Do not have empty exception handlers
  • Do not only print the stack trace
  • Log Important Exception
  • Log important Exception
  • Adding Extra Information
  • Log Viewer
  • Exception Files
  • Exception Catalog
  • 15 Appendix
  • PAR Flow
  • Uploading a PAR File to the Application Repository
  • Deploying a PAR File on all PRT Nodes
  • Local Deployment Consistency
  • Deployment Policy
  • Deployment Hook
  • Text localization and Portal Components internationalization
  • Principle and approach
  • Resource Bundle Name
  • Locale lookup
  • Resource Bundle packaging
  • Portal Component Java Code
  • Request/Response handling
  • Permission model for Portal Components and Portal WEB Services
  • Security Zone
  • Safety level
  • Recommendations
  • Portal Object Name and Alias
  • Name
  • Alias
  • Example
  • Directory structure
  • Local Deployment Overview
  • Local Deployment of Portal Applications
  • Elements of a Portal Application
  • Class Loading in the Portal Runtime
  • Class Loading Examples
  • Deployment Descriptor example
  • Application Example
  • Central Configuration Storage – How to
  • How to get the sub context that belongs to the application?
  • How to store and retrieve config files to/from the central location?
  • SAP J2EE integration and interaction
  • Executing a Servlet as a Portal Component
  • Accessing to the Portal Service from a J2EE object
  • Portal Content Abstraction
  • JNDI Basis
  • Starting Portal Objects
  • Portal Runtime Help Mode
  • Portal Runtime Test Mode
  • Logger configuration
  • JSP Support
  • Declaring JSP as Portal Component
  • JSP selected programmatically
  • JSP packaging/Compilation
  • Class Loader consideration
  • Supported Features in the PRT
  • Portal Runtime extension
  • Tag lib packaging
  • Java Beans
  • Handling Request Events
  • Asynchronous Response API
  • Index

Portal Runtime – Release 6.

0

June, 2003

Table of Contents:
1 PORTAL RUNTIME TECHNOLOGY .........................................................................................................................6 INTRODUCTION AND POSITIONING ...........................................................................................................................................6 CONCEPTS AND TERMINOLOGY ...............................................................................................................................................7 Portal Environment ............................................................................................................................................................7 Portal Application ..............................................................................................................................................................7 Portal Application Archive (PAR files)...............................................................................................................................7 Portal Components .............................................................................................................................................................7 Portal Services....................................................................................................................................................................7 Portal Component Profile...................................................................................................................................................7 Portal Component Config...................................................................................................................................................7 Portal Runtime Mode..........................................................................................................................................................7 Portal Object Model (P.O.M.) ............................................................................................................................................7 Application Repository .......................................................................................................................................................8 2 PORTAL INFRASTRUCTURE .....................................................................................................................................9 PACKAGING .............................................................................................................................................................................9 CORE APPLICATIONS ...............................................................................................................................................................9 3 PORTAL RUNTIME API .............................................................................................................................................11 COMPONENT ..........................................................................................................................................................................11 IPortalComponent ............................................................................................................................................................11 AbstractPortalComponent ................................................................................................................................................12 SERVICE ................................................................................................................................................................................12 IService .............................................................................................................................................................................12 IServiceContext.................................................................................................................................................................12 REQUEST/RESPONSE ..............................................................................................................................................................13 IPortalComponentRequest................................................................................................................................................13 IPortalComponentResponse .............................................................................................................................................13 4 PORTAL APPLICATION ARCHIVES.......................................................................................................................14 PAR FILE FORMAT ................................................................................................................................................................14 Web Resources..................................................................................................................................................................14 Non-Web Resources..........................................................................................................................................................14 PAR BUILDING .....................................................................................................................................................................15 STRUCTURE OF THE DEPLOYMENT DESCRIPTOR....................................................................................................................16 PORTAL APPLICATION ...........................................................................................................................................................16 Portal Application Configuration.....................................................................................................................................16 PORTAL COMPONENTS ..........................................................................................................................................................18 Portal Component Configuration .....................................................................................................................................18 Portal Component Profiles ...............................................................................................................................................19 PORTAL SERVICES .................................................................................................................................................................21 Portal Service Configuration Properties ..........................................................................................................................22 Portal Service Profiles......................................................................................................................................................22 5 PORTAL APPLICATION LIFE CYCLE....................................................................................................................23 OVERVIEW ............................................................................................................................................................................23 APPLICATION DEPENDENCIES................................................................................................................................................24 HOT DEPLOYMENT ................................................................................................................................................................24 6 PORTAL RUNTIME ARCHITECTURE....................................................................................................................25 REQUEST DISPATCHER ..........................................................................................................................................................25 Dispatcher API .................................................................................................................................................................26 Dispatching a Request ......................................................................................................................................................26 PORTAL RUNTIME API ..........................................................................................................................................................27 PORTAL RUNTIME CORE........................................................................................................................................................27 PORTAL REGISTRY ................................................................................................................................................................30 Central Configuration Storage .........................................................................................................................................30

PORTAL RUNTIME CACHE .....................................................................................................................................................31 Properties .........................................................................................................................................................................31 API....................................................................................................................................................................................31 Caching Expiration...........................................................................................................................................................31 PORTAL APPLICATION REPOSITORY ......................................................................................................................................32 PORTAL CONNECTION FRAMEWORK .....................................................................................................................................32 7 REQUEST CYCLE ........................................................................................................................................................34 NODE.....................................................................................................................................................................................34 PORTAL COMPONENT MODE .................................................................................................................................................35 Accessing to a Mode .........................................................................................................................................................35 Mode Handling .................................................................................................................................................................35 PORTAL HOOKS .....................................................................................................................................................................37 Purpose.............................................................................................................................................................................37 Adding a new Portal Hook ...............................................................................................................................................38 Default hooks....................................................................................................................................................................39 EVENT HANDLING .................................................................................................................................................................40 Internal Portal Runtime Events ........................................................................................................................................40 Request Event API ............................................................................................................................................................40 Component Event API.......................................................................................................................................................41 Event Handling .................................................................................................................................................................41 8 JNDI SUPPORT IN PRT...............................................................................................................................................42 PRT JNDI SUPPORT PACKAGE..............................................................................................................................................42 JNDI Service Providers ....................................................................................................................................................42 JNDI Clients .....................................................................................................................................................................43 JNDI Service Providers Packaging ..................................................................................................................................43 JNDI Provider Resource File Sample...............................................................................................................................44 JNDI CONCEPTS AND RELATED DOCUMENTS .......................................................................................................................44 JNDI Environment............................................................................................................................................................44 JNDI Context ....................................................................................................................................................................44 JNDI Context Factories....................................................................................................................................................45 9 WEB SERVICES SUPPORT ........................................................................................................................................46 APPROACH ............................................................................................................................................................................46 Portal Services as WEB Services......................................................................................................................................46 Portal Applications and external WEB services ...............................................................................................................46 CONCEPTS .............................................................................................................................................................................47 ARCHITECTURE .....................................................................................................................................................................48 10 PAR IDE......................................................................................................................................................................53 APPROACH ............................................................................................................................................................................53 ADDITIONAL FEATURE ..........................................................................................................................................................53 11 COMPATIBILITY CONSIDERATIONS................................................................................................................56 EP 5.0 BACKWARD COMPATIBILITY ......................................................................................................................................56 EP50 Deployment Policy..................................................................................................................................................56 EP50 Class Loading .........................................................................................................................................................56 EP50 Archives ..................................................................................................................................................................56 LIST OF INCOMPATIBILITIES TO EP 5.0 ..................................................................................................................................57 UNIX/WINDOWS COMPATIBILITY .........................................................................................................................................57 12 ADDITIONAL PRT SERVICES ..............................................................................................................................58 NOTIFICATION SERVICE.........................................................................................................................................................58 CONTENT CONVERSION SERVICE ..........................................................................................................................................59 CONTENT CONVERTER SERVICE ............................................................................................................................................60 JCO CLIENT SERVICE ............................................................................................................................................................61 RFC ENGINE SERVICE (UNDER CONSTRUCTION) ..................................................................................................................63 Service Description...........................................................................................................................................................63 Implementation .................................................................................................................................................................64

..................................................................................................................................................................................................................................................................................82 PERMISSION MODEL FOR PORTAL COMPONENTS AND PORTAL WEB SERVICES .....................................................................................................................................................................................68 Virtual Components .......................................................................................................73 Do not make wrong assumptions .......................................80 Principle and approach ...........................................................................................................................................................................................................................................................................................................................................79 TEXT LOCALIZATION AND PORTAL COMPONENTS INTERNATIONALIZATION ............................................................................78 DEPLOYMENT HOOK ................................................................................................................................................................................................................................................................................................................................................................................77 PAR FLOW ..68 Sharing Configuration between Applications .....................................................86 Example .........................................................................69 CONFIGURATION EVENT SUBSCRIPTION ..........81 Portal Component Java Code...................................................64 13 CONFIGURATION MANAGEMENT IN PORTAL APPLICATION......................................................................................................................85 PORTAL OBJECT NAME AND ALIAS ........................84 Recommendations...........................................................................................................86 Name........................88 Local Deployment Overview...........................................................................................72 14 EXCEPTION HANDLING..........................................................................................75 Exception Catalog .........................................................................................................................75 Exception Files .............69 USE THE CONFIG FRAMEWORK API .......................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................80 Locale lookup ..........................73 Always include a message ........................................................................................................................................87 DIRECTORY STRUCTURE .....................65 CREATE A CONFIG ARCHIVE .....................................73 Always pass the original exception............................................86 Alias........................74 Do not only print the stack trace .............................................................67 ACCESS DATA ...................................................................................68 Modify portalapp.......................................................................................................................................................................................................................................................................................................................77 Uploading a PAR File to the Application Repository...........................................................73 CODING RULES ...........................................................70 Implement the interface IConfigEventListener .................................................................................................................................................................................................................................84 Implementation ......................................................................................................................................................................................................................................................................xml ....................................................................................................................77 Deployment Policy.........................................................................................83 Safety level...........................88 .............................73 Do not have empty exception handlers ...........................................................................................................................83 Security Zone .................................................................................................................................77 Deploying a PAR File on all PRT Nodes........................................................76 15 APPENDIX..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................66 Use Export PAR File of the PAR IDE...................................................................................................................74 ADDING EXTRA INFORMATION .......82 Request/Response handling ........................................................................................................................................................Security Open Issues...............................................................................................................................................................................................70 Add a listener...........................................................................................................................................................................................77 Local Deployment Consistency.....................................................................................................................................................................72 START THE CONFIG MODE.................................................................................................................................................................................................................................................................................................82 JSP Support ...........................................................................................................................................................................................................................................................................73 ISSUE OVERVIEW...............................66 Config Archive properties file...............................................................................................................................................................................................................................................................................................................................................66 Place your configuration files in folders .........................................................................................................75 Log Viewer.....................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................74 Log Important Exception ............................72 Remove listener.............................................................................................................................................................................................................................80 API...............................................................................................................81 Resource Bundle packaging ....................................................................................................................................................80 Resource Bundle Name.................66 Important Points ......................................................................................................................................................................

.........................................................................................................................................................96 Accessing to the Portal Service from a J2EE object....................97 JNDI Service Providers ..................................................................89 CLASS LOADING IN THE PORTAL RUNTIME ...90 DEPLOYMENT DESCRIPTOR EXAMPLE ........................................................................................................................................................103 Class Loader consideration..............................105 Tag lib packaging ......................................................102 JSP packaging/Compilation ....................................................................................109 INDEX ..................................................................................107 Handling Request Events.....................................................................................................................................................................................................................................97 PORTAL RUNTIME HELP MODE ..........................................................................................................................112 ...................97 JNDI Basis................100 LOGGER CONFIGURATION ............. ...............................................................................................................................................................................................93 CENTRAL CONFIGURATION STORAGE – HOW TO........................................................94 How to get the sub context that belongs to the application? ......................................................Local Deployment of Portal Applications....................................................................................................................................90 Class Loading Examples.................................................................................................................................................................................................................................98 PORTAL RUNTIME TEST MODE ..................................................................................................................................94 SAP J2EE INTEGRATION AND INTERACTION .........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................96 Executing a Servlet as a Portal Component......................................88 ELEMENTS OF A PORTAL APPLICATION ................................................................106 Java Beans........103 Portal Runtime extension.....................................................................................................................................................................................................................................................................................................................................................108 ASYNCHRONOUS RESPONSE API...................101 JSP SUPPORT..............................................................................................................................................................................................................................................................................................................................................................................103 Supported Features in the PRT.....................................................................................................................................................................................................................................................................102 Declaring JSP as Portal Component.............................................................................................................................................94 How to store and retrieve config files to/from the central location? ................................................................................................................................................................................................96 PORTAL CONTENT ABSTRACTION .............................................102 JSP selected programmatically ....................................................................................................................................................................................92 Application Example...................................................................97 Starting Portal Objects ..............................................................................................................................................................

and execute Applications in a Portal Environment by allowing the aggregation and the display of various contents such as rich text. xml. a plug able component designed to be executed into a Portal environment. a component that can be displayed into a portal page. They are: • Portal Components.1 Portal Runtime Technology Introduction and Positioning The Portal Runtime is one basic part of the SAP Enterprise Portal Environment integrated in the SAP J2EE environment. build. the Portal Runtime clearly positions itself as one of the key block used to build and execute any kind of Portal. From a user point of view. From an application development perspective. The portal runtime development model offers a way to implement a clear separation between a Service API and its implementation. The Portal Runtime Technology provides a Java based framework to define. The motivation behind the design and the technical implementation of the Portal Runtime are the following: • • Area of concern: The goal of the PRT is very well identified and restricts itself to the life cycle of portal applications. for example. • Portal Runtime Technology Page 6 /113 . Open and Extensible: Many of the components of the PRT can be changed or customized to be adapted to the environment in which the PRT is executed. different user interface models or different programming models. The Portal Runtime defines and manages two kinds of objects that define a Portal Application. Portal Services. videos etc… The Portal Runtime Technology provides a runtime and its corresponding services as well as a development environment for Portal applications. So the model proposed by the PRT can be extended to support. So. A Component offering a globally accessible function in the Portal.

a Portal environment is a Web site that serves as a starting point to information.) The Portal Object Model is a runtime representation of the portal structure at request time. The POM is only valid during one request. Portal Component Profile The component profile is a set of properties (name-value pairs) representing the dynamic part of a Portal Component that could be customized to change the behavior of a Portal Application. instantiated. services and applications on the Internet or the Intranet. Portal Application The Portal Runtime technology defines an environment in which Portal Application are deployed. Portal Component Config The component config is a set of properties which configures the Portal Component (class name etc…). Portal Runtime Technology Page 7 /113 .xml). Portal Application Archive (PAR files) A PAR file is an archive file containing a Portal Application. It can also be a JSP.Concepts and Terminology Portal Environment From the PRT perspective. Portal Services It is a service offering functionality to other applications of the portal. Portal Components This is an executable part of the Portal Application. This file describes the portal application itself and provides information required at runtime. Portal Runtime Mode Portal Runtime Mode allows a Portal component to display a different user interface according to the specified mode. It is a hierarchical representation of the components participating in the processing of a request and in the construction of a response. It can be described as a Java Code defined by properties and executed in a particular mode. The state is not kept on the server side. It is the underlying structure of all server-side eventing and it serves as a logical representation of the Portal structure for addressing the request events. accessed and finally released.M. Portal Object Model (P.O. The Portal Runtime offers tools to facilitate the construction of Portal Applications. A PAR file contains the Portal Application Deployment Descriptor (portalapp.

Portal Runtime Technology Page 8 /113 . It also takes into account the application distribution in a cluster installation. it offers a JNDI access to Portal Applications. In its most basis form.Application Repository The Application repository is the persistence layer of the Portal Runtime. It contains every object persisted by the Portal.

On the contrary. In addition to the IRJ file. This set of applications. Concerning the application storage. called core applications are ensured to be loaded before any other applications when the Portal is initialized. Core applications. Applications. The IRJ file contains 3 main parts: • • • Libraries and configuration files. non-core applications are always loaded in the Application Repository. Additional Portal Applications. either because the application has been marked as “load on startup”. The core services of the Portal Runtime. Packaging The Portal Runtime relies on the J2EE architecture implemented by the SAP J2EE Application Server. The main motivation behind the design of the Portal infrastructure is to isolate Portal Application from the environment. or because an element of the application is requested to be executed. a regular application is started only when required. Portal Runtime Technology Page 9 /113 .2 Portal Infrastructure This chapter describes the Portal Runtime Infrastructure. The Portal Runtime and its configuration. As a result the Portal Runtime is packaged in an EAR file called IRJ (iView Runtime for Java). Those applications are also never loaded in the Application repository. the Portal Runtime infrastructure delivers a SAP J2EE service containing all the PRT functionalities and services relying on specific SAP J2EE implementation called PRT bridge as shown in the figure below. SAP J2EE Application Server SAP J2EE Services PRT Bridge Service Core Applications Servlet Container Portal Runtime Other servlets Applications Core Applications The Portal Infrastructure relies on a predefined set of applications to provide core functionalities in the Portal infrastructure.

sap.repository com.portal.portal. Portal Runtime Technology Page 10 /113 .system.runtime.runtime.sap.notification com.system.system. The runtime console giving access to administrative tools of the Portal Infrastructure the The notification service relies on the PRT Bridge to send and receive from one PRT to another Security functionalities to authenticate a user in the Portal.system. User management implementation service.authentication usermanagement Description The application repository itself.portal.The table below shows the list of the main Portal Runtime core applications.runtime.portal.console com. Application name com.runtime.sap.sap.

The Component’s view on the request during Runtime. • Portal Runtime Technology Page 11 /113 . The Portal Runtime calls the following methods during the Portal Component’s life cycle • Init() The Portal Component is created and loaded in the execution environment and then initialized with the init().3 Portal Runtime API The central piece of the Portal Runtime technology is the Portal Runtime API. Encapsulation of information sent to the client by a Portal Component. The complete API documentation can be found in the Portal Runtime javadoc. This is the API to receive and send events with the client’s request or between different components. components. The Portal always initializes one instance of the Portal Component and this instance is shared among different users and sessions. All Portal Components implement this interface either directly or by extending the AbstractPortalComponent helper class. API ELEMENTS Portal Component JAVA NAME IPortalComponent AbstractPortalComponent IPortalComponentInit Portal Service Profile Configuration IService IPortalComponentProfile IServiceProfile IPortalComponentConfig IServiceConfig Request Response IPortalComponentRequest IPortalComponentResponse DESCRIPTION The IPortalComponent is the central abstraction of the Portal Runtime API. Portal Event IPortalRequestEvent IPortalComponentEvent Context IPortalComponentContext IServiceContext Component IPortalComponent This is the central abstraction of the Portal Component API. services) and the Runtime environment. It contains Java interfaces that define the contract between the Portal objects (Applications. Service() The service() method is called when the Portal Component is asked to process the client’s request. The objective of this chapter is to describe the main important interfaces of the API. A view of the context in which the Portal Runtime runs Components and Services. The configuration of a component or a service (static immutable). It defines a Portal Component included in a Portal Application A Portal Service included in a Portal Application. The following table describes the main elements of the API. A set of properties attached to a Component or a Service.

The Portal Runtime is responsible for the creation. Service IService Every objects that want to act as a Portal Service must implement the IService interface. In a situation where several init() methods are invoked. This allows a Portal Service to be notified when the initialization chain is over. as well as request events. this service is then also loaded and initialized by calling its init() method. to dispatch and handle portal events. getProfile() The getProfile() method returns a IServiceProfile instance representing the Profile of the Service. It also gains information about the application it belongs to. The Portal Runtime calls then the following method • init(IPortalComponentInitContext) The Portal Component has an access to its configuration defined in the portalapp. to handle the Portal Modes defined by the Portal Runtime like the Edit. However. the Portal Runtime calls the following methods: • init(IServiceContext) The init method is called when the Portal Service is loaded in memory. The profile can be customized by the administrator. Returns the ILogger implementation to log information. 2. During the life cycle of a Portal Service. afterInit() The afterInit() method is called when the init method returns. AbstractPortalComponent The AbstractPortalComponent provides default behavior for Portal Components. When a Portal Service is referencing another Service. getConfiguration() The getConfiguration method provides a read-only access to the IServiceConfig of the Service. The Abstract Portal Component implements also a interface called IPortalComponentInit to be notified of its initialization. destroy() from memory. The PortalServiceContext provides access to the Resources.xml file. • • • • getResource() getLogger() Returns a IResource object representing a resource. the doEdit() method is bound to the Edit Mode. the Portal Runtime will never make the assumption that a Portal Component needs to be a subclass of the AbstractPortalComponent class. For example accessing a Portal Component in the default mode will invoke the doContent() method of the AbstractPortalComponent. Portal Runtime Technology Page 12 /113 . In the same way. the Portal Runtime ensures that the afterInit() method is called when all the init() methods are ended. The destroy() method is called when the Service is stopped and discarded • • IServiceContext The IServiceContext gives to the Portal Service a view on the Portal Environment in which it is executed. The logic included in this class implements the default behavior 1.• Destroy() The Portal Runtime calls the destroy() method when the Portal Component is discarded from memory either because the Portal is terminating or because the Portal Runtime needs to free up some memory or during the release of its corresponding application when uploading a new one for example. It is recommended to inherit from this class when developing a Portal Component. load and destroy of Objects implementing this interface. The garbage collector then collects the Portal Component. Help and About mode.

ILogger. A ILogger implementation to write information to the logs of the Portal. The following operations are provided through the response: • • • addCookies() write() include() add a cookie in the response. IPortalComponentContext. But it is still permitted for very specific actions. returned to the client from the Portal Component. HttpServletResponse. IUserContext. In addition. the IPortalComponentRequest interface acts as a factory for URLs that the component would have to generate (create component URI. Portal Runtime Technology Page 13 /113 . Objects offering user’s information. It encapsulates all the information. HttpServletRequest. The following Objects are accessible through the request: • ServletConfig.Request/Response IPortalComponentRequest This IPortalComponentRequest is passed to the PortalComponent thought the service() method or the doContent() method. The profile of the component. IRessource. In general accessing those objects is not recommended. Those objects are the original servlet objects. Locale. • • • • • The context in which the current Portal Component is executed A representation of an external resource. IPortalComponentResponse The IPortalComponentResponse is given to the Portal Component through the service() method or the through the specific mode handler methods. Write a string in a response Include the content of another Portal Component into the response or a resource. The underlying default implementation of the request is thread safe. IPortalComponentProfile. IPortalComponentSession. It contains request specific data and it provides access to the environment in which the Portal Component is running. request events…).

Non-Web Resources All files that are under the PORTAL-INF folder of the PAR file are not accessible via an http(s) request to the portal. Within the non-web resources a few folders and files have a special meaning: Folder PORTAL-INF/lib meaning This folder contains all the library files (JAR) that contain definitions of JAVA classes and other class loader relevant resources (e. all files that are NOT under PORTAL-INF fall into this category. The manifest file of the Portal Archive.g. ResourceBundles). ResourceBundles). that can be shared by referencing Portal Applications. In a PAR file. ResourceBundles) that can be shared by referencing Portal Applications. A PAR file contains all the file-based resources that make up a Portal Application.g.4 Portal Application Archives PAR File format This chapter describes the Portal Application archive format and how the format is used and interpreted by the runtime.g. Resources of a Portal Application fall into the following two categories: Web Resources These are all file-based resources that are supposed to be accessible via http(s) requests to a web server that provides access to the Portal. It is described more precisely below. PORTAL-INF/classes PORTALINF/private/lib PORTALINF/private/classes File PORTALINF/portalapp. This folder contains all class files and other files that define JAVA classes and other class loader relevant resources (e. This folder contains all class files and other files that define JAVA classes and other class loader relevant resources (e.xml METAINF/manifest. It contains versioning and origin information. that are used exclusively by the application.mf Portal Runtime Technology Page 14 /113 . This folder contains all library files (JAR) that contain definitions of JAVA classes and other class loader relevant resources (e. The deployment descriptor describes all Application Entities of the application as far as the runtime is concerned. Meaning The XML file containing the Deployment Descriptor of the Portal Application. ResourceBundles) are used exclusively by the application.g.

Read a PAR file and create a project. | +-.lib | +-. • A SAP Java IDE plugin called PAR Open Tool.lib +-.. Write a PAR file from a project. This tool allows to 1.private +-. 2.META-INF +-.classes Non-WEB resources API: jar files only API: classes only CORE: jar files only CORE: classes only PAR Building The Portal Runtime offers two facilities to build a PAR file.MANIFEST.The following picture shows an example of a typical PAR file structure: <Portal Archive> | +-.xml | | | +-..MF +-. Portal Runtime Technology Page 15 /113 .PORTAL-INF | | | +-.portalapp.images +-.classes | | +-. • An Ant task accessible from the SAP Java IDE or from the Ant command prompt.scripts +-..

0" encoding="iso-8859-1"?># <application alias="com.abc. These aliases can be used alternatively to the real application name.name"> <application-config> . See also Class Loading in the Portal Runtime. A property element declares a property by name and value. </application-config> <services> . when referencing the application (see Application Configuration Properties) and Portal Components (see Portal Components). Note: The concept of aliases is meant to be used for backward compatibility reasons. Admissible value comma-separated list of other Portal Application's names or aliases thereof.other. The first thing to know is that the name of the application is the name of the PAR-file. Default n. containing a comma-separated list of aliases on the portal application. The application element may have an attribute alias.. </services> <components> . The root element is the application element. </components> </application> see Application Configuration Properties see Portal Components see Portal Services Portal Application Configuration The application-config element may contain as many number of property elements as you like. Portal Runtime Technology Page 16 /113 . It effectively reserves a name some other application potentially would like to use. The properties specified in this section of the deployment descriptor affect the Portal Application as a whole.Structure of the Deployment Descriptor The deployment descriptor (portalapp.. Portal Application Within the application element the following child elements are allowed: Application-config Components Services Example: <?xml version="1.. the name of the containing PAR file..my..a.. So use it with care. For example <property name="myProperty" value="myPropertyValue"/> The following table describes currently meaningful application configuration properties: Name SharingReference Description This property allows references to other Portal Applications whose API definitions are to be used in this application's API definition.xml) is noted as an XML definition.

See also Compatibility Considerations. "false" False releasable "true". the application as a whole will be "started" (initialized) on startup of the server. Name PreservedConfigPaths Description Depending on the deployment policy (see above). "false" True The following properties are mainly kept for backward compatibility with 5. ClassLoadingPolicy "transitive" startup "true". ServicesReference see above see above Portal Runtime Technology Page 17 /113 . See also Class Loading in the Portal Runtime. Comma-separated combination of "5. The values of this property affects the way class loader resources are exposed by this application to other applications and more. In general see also Compatibility Considerations. See also Compatibility Considerations This property is equivalent SharingReference property.a. DeploymentPolicy This property affects how the Portal Application's resources are treated during local deployment. it is possible to specify a number of folders in the PAR that are to be preserved during local deployment. Nevertheless some critical applications may want to avoid the release of their instance when the system runs low in memory. See also Compatibility Considerations. In particular.0" or <empty> n.0 behavior. PORTALINF/mystuff). If set to "true". this property is also used for backward compatibility since it can be used to enforce the 5. all applications are releasable and the application instance can be dropped at any time by the system.0". In particular this means that it will be locally deployed. "coreAccessInAPI". to the "5.0. See also Class Loading in the Portal Runtime. "transitive" n.a. They should then set this property to false.PrivateSharingReference This property allows references to other Portal Applications whose API definitions are to be used in this application's (nonpublic) implementation. comma-separated list of other Portal Application's names or aliases thereof. Amissable Values A comma-separated list of application local paths (e. Because PRT allows hot deployment.a.g. Default n.

Admissible values are: "servlet". </components> .. The type of the component.component..<portal component name>.Portal Components All Portal Components of a Portal Application are declared in component sections contained in the components section. "jspnative".. </component-profile> </component> . Mandatory No No Default n. Each property is declared as described in Application Configuration Properties. An absolute Portal Component Name is constructed as <application name>.. Portal Component Configuration The component-config section within a component section of the deployment descriptor contains properties that enable the use of a Portal Component with the Portal Runtime. </component-config> <component-profile> . The following XML attributes apply to the component section: Name Name Description The portal component name within the application. This attribute specifies the <portal component name>. <components> <component name="myComponent"> <component-config> .. The properties specified in this section are accessible to Portal Components via the interface com. Default is <none>.portal.sapportals. Mandatory yes Each component section may contain one component-config element and one component-profile element..prt. The main properties the developer must be aware of are the following: Name ClassName ComponentType Description The name of the implementation class of the Portal Component.IPortalComponentConfig.a... <none> Portal Runtime Technology Page 18 /113 .. in which case an implementation of IPortalComponent has to be specified by the ClassName property.. <none>. For example: .

By administrative modification or personalization. See text localization for more details Initial minimal authentication requirements to execute the Portal Component.a.portal.0 version relies on the security zone concept to control access to the Portal Components. the path of the JSP PageLet to implement the Portal Component. This Property is only supported for backward compatibility reason.component. The 6.IPortalComponentProfile interface at runtime. This path is relative to the private resources (under PORTAL-INF in PAR) of the Portal Application A Portal Component can specify the name of a distinguished resource bundle.mycomponent Default Portal Runtime Technology Page 19 /113 . the iView. See Configuration management for Portal Application for more details.prt. The profile is usually abstracted in a personalizable entity. User: The content is private for each user Possible values /com. no Portal Component Profiles The component-profile section contains properties that make up the profile of the Portal Component as accessible from the com.sap. the component belongs to. CachingLevel Shared : The cache content is shared among all users. The values of properties in this section define the default values.myapplication. This bundle will be used to look for descriptive texts in generic personalization dialogs. Some properties are PRT specific: Name ConfigRootFolder Description String representing the path within the overall configuration structure of the component specific configuration. none: also anonymous users Role list : only the roles that are in the list SecurityZone String representing the security zone. no n.JSP In the case of ComponentType=="jspnative". these values may be modified. ResourceBundleName no "localization" AuthRequirement no user: authenticated user admin: administrator only. See Permission Model for components for more details.sapportals.

blue]"/> </property> 2 In this example the property “Color” has two sub properties. Default n.a. the first one “personalization” defines that the property will be in the form during personalization.green. This level is used to cache information related to the browser's sessions ValidityPeriod EPCFLevel Defines whether to use the Enterprise Portal Client Framework or not. Attributes of profile properties are denoted by sub-properties. Additional attributes describe how to handle the properties with respect to personalization and meta-data handling. whether or not a user is connected. If two or more embedded iViews with different EPCFLevel values meet on one page (within the same frame).a. plainDescription n. The portal runtime does not make any assumption concerning the semantic of those sub-properties. the property name. Admissible value n. the effective level is computed as the maximum of all EPCFLevel values on this page. The second one “type” defines the relevant value for this property.a. This will be used if no description attribute is specified. A plain text that can be used in user interfaces to describe the property. 2: This level includes all EPCF features that use pure JavaScript 3: This level includes all features of level 1 and additional features that use applets. The property attributes are basically used at design time (by administration tools) or during personalization. Therefore neither script nor applets will be included. Each property in this section may have further attributes. Portal Runtime Technology Page 20 /113 . For example: <property name="Color" value="red"> <property name="personalization" value="dialog"/> <property name="type" value="select[red. It represents a locale sensitive descriptive text for the property that can be used in user interfaces.Session: The content of the component is cached all the time the (servlet) session is running. Time period in milliseconds 1: This component does not use the EPCF at all. The following table describes the property attributes that the developer should be aware of: Name description Description A text token that can be resolved by accessing the component's resource bundle.

g... Mandatory yes alias no Each component section may contain one service-config element and one service-profile element. non-final non-final Portal Services Portal Services are declared in service elements inside the services element. not shown in personalization no-dialog: per-user storage.. This attribute specifies the <portal service name>.. <services> <service name="myService"> <service-config> . The following XML attributes apply to the service section: Name name Description The service name within the application.type A "visual" type of the property to be respected as a hint by user interfaces. </service-config> <service-profile> ...<portal service name>. iView chain). A fully qualified Portal Service Name is constructed as <application name>.. This attribute specifies how to treat this property with respect to personalization.<option>)*]. a name that can be used instead of the fully qualified service name (see above) when looking up the Portal Service.. not shown in personalization dialog: per-user storage and shown in personalization. For example . boolean. <none> personalization dialog inheritance specifies whether the property can be overridden by a template derivation (e. select[<option>(. </service-profile> </service> . final. </services> Portal Runtime Technology Page 21 /113 . <none> none: cross-user storage.

Portal Runtime Technology Page 22 /113 .Portal Service Configuration Properties The service-config section within a service section of the deployment descriptor contains properties that enable the use of a Portal Service with the Portal Runtime. If set to "true".a. There are no predefined service profile properties. Mandatory Yes Default n.prt.service.service.IServiceProfile interface at runtime. startup No false Portal Service Profiles The service-profile section contains properties that make up the profile of the Portal Service as accessible from the com.sapportals. This class must implement the IService interface. the properties of the service profile may be modified by administrative environments and is available at next start of the service.portal. IServiceConfig.portal.prt. If not.sapportals. the service will be started at startup of the runtime. the service will be started on demand. In contrast to the service config. The properties specified in this section are accessible to a Portal Service via the interface com. Properties of reserved meaning are: Name className Description The name of the implementation class of the Portal Service.

5 Portal Application Life Cycle This section describes the application life cycle and explains how and when information contained in the PAR file is used to deploy Portal Applications and then to load the corresponding objects in memory. it is important to understand that PAR files are stored in the application repository. First of all. Portal applications are also deployed locally (on each PRT node). The Administrator will typically use admin tools to create the portal content. There is only one Application Repository and all PRT nodes of the SAP J2EE cluster are sharing the same content. the local version should not be modified directly. some of them (like the Archive Uploader” are used to upload portal applications into the application repository. The main purpose of the local deployment is to improve performance by providing fast access to resources and avoid too many accesses to the application repository. Overview DataBase server PAR Upload Application Repository / Database Web servers Local Deployment / File system HTTP Request Application Broker Object Instances Portal Runtime Technology Page 23 /113 . In that sense the local deployment is a cached copy of the original version.

For further details about the directory structure please check: Directory Structure page 88 The Portal Application runs and remains in memory unless a new version is deployed or the administrator decides to release the application. If the object is not yet available. The content of the PAR File is split into 2 parts. each PRT node will perform the following operations: • • • • • Check if the application is already loaded and running. the PAR Upload will notify all PRT nodes that a new version of the application is available. This step guarantees that the class loader of application it depends on is ready to use. Internally the portal application broker checks whether the object is already available and returns it. All applications it depends on are deployed and loaded first. the local deployment is updated. Note: Application can be marked as non-releasable in their deployment descriptor. When a new version is available. The system can also discard Portal Application instances when the Java VM requires freeing some memory. This flag has no impact during Hot Deployment. services. PRT checks the dependencies that are declared in the deployment descriptor thanks to the “SharingReference” and “PrivateSharingReference” properties. Upon the notification. and applications) depending on it. Restart load-on-startup services For further detail concerning the PAR Flow please check page 77. Reload the application and the dependents that have been released.When a component or a service of a Portal Application is accessed for the first time (For instance upon an HTTP request) the Portal Runtime has to load the implementation class and instantiate the corresponding object. Each portal application is loaded in its own memory space (cf. the broker loads the class and instantiates the object. This step checks the “revision number” of the application to make sure the local deployment is up-to-date. This space is divided into a public part corresponding to the API of the application and a private part corresponding to the core implementation. Afterwards. PRT tries to get it from the local deployment. Portal Runtime Technology Page 24 /113 . The “non-releasable” property guarantees that PRT will keep the application instance even when the VM runs low in memory. If a new version is available in the repository then step 3 is performed. The deployment process gets the PAR File from the repository and deploys it on the file system. Update the local deployment (like describe in step 3). Hot Deployment In a cluster scenario (n PRT nodes sharing one repository). Application Dependencies When loading the application.: Class Loaders). Release this application and all elements (components. the application will be release in any case.

The first role of the request dispatcher is to match the URL of the request to a Portal connection and forwards the request to this Portal Connection.servlet.system.servlet.allow dispatcher.portal.root dispatcher.properties This defines whether an automatic forward to another servlet is allowed This defines the pathinfo prefix to be used defines the portal root directory defines the portal default properties the portal properties Default value Default information message displayed when a dispatcher exception occurs. it is implemented as a Servlet running in the WEB Server environment. systemdefault. At startup the role of the request dispatcher is to cover the following functionalities: • Initializing the Portal Runtime Environment.contactinfo Description If this situation persists.prefix dispatcher.properties dispatcher.portal.6 Portal Runtime Architecture The objective of this chapter is to describe the architecture of the Portal Runtime by focusing on its configuration and customization. The reason of the exception is always displayed before or in the source code of the HTML page.proper Portal Runtime Technology Page 25 /113 . dispatcher. In the SAP J2EE environment. The Dispatcher can handle all the connections needed. The figure bellow shows the main blocks of the Portal Runtime Architecture Request Dispatcher Portal Connection Portal Registry Portal Component API Cache Portal Application Portal Runtime core Portal Service API Portal Application Repository Request Dispatcher This is the entry point of the Portal Runtime. please contact your system administrator.portal. The Request Dispatcher reads the following configuration files from the file installation: WEB-INF/conf/dispatcher.propert ies system/properties/workplace. However the Portal Runtime must have a least the default servlet connection called portal installed and started to work properly. True Servlet WEB-INF/portal system/properties/prtDefault.properties Property dispatcher.

.sun. javax.dispatcher.jar prtjndisupport.portal.log.com.jar prtutil.resources Dispatcher API The dispatcher contains a set of API that could be accessed from an external Servlet to communicate with the dispatcher.. This phase can also be customized with the following parameters of the prtDefault. javax. META-INF portal. The name of the connection is passed in the URL as follow: /irj/servlet/prt/<Connection Name>. Portal Runtime Technology Page 26 /113 . The different levels of libraries are read from the file installation and the corresponding class loaders are created in memory. Those libraries are packaged into the WEB-INF/lib directory. Dispatching a Request When a request comes in.jar Description The code of the dispatcher itself JDNI support in PRT.protected.protected. The name is used as the key to perform a lookup in the connection bound of the Portal Registry. API of the Portal Registry Utility classes of the Portal Runtime.properties file: Description The directory below WEBINF/portal containing the public library of the Portal Runtime Same for the public classes The directory below WEBINF/portal containing the nonpublic library of the Portal Runtime Same for the non-public classes Prefixes for class names that will not be seen from the dispatcher and below Same for resources Default value lib Property Name portal.jar prtregistry.sun.version The default connection console mode for the dispatcher Automatically generated version information ties portal Verbose • Setup the class loader hierarchy.activation localization.console dispatcher.libs portal. the dispatcher analyses the incoming URL and find the corresponding connection in order to forward the message.classes system/classes com.mail.classes system/lib classes system/lib system/classes portal.defaultconnection dispatcher..mail.xml. Library name prtdispatcher.

JSP support in Portal Runtime. Changing the two following files located in the WEB-INF/portal/system/properties can customize some of the functionality of the Portal Runtime Core. The Portal Runtime API is delivered in a set of 5 JAR files. This file contains Properties that are going to be stored in the Portal Registry. the file is renamed with a .jar prtdeployment. JAR name prtcore. API to handle the format of PAR Files and the deployment descriptor. The Portal Connection API to develop and install a new connection in the Portal.jar prtdeploymentapi. JAR name prtapi. the Portal Runtime reads this file and stores the corresponding objects into the registry.properties. used to manage upgrade of the version of the Runtime.jar prttest. Default logger implementation.Portal Runtime API It defines the contract between the Portal Application and the Portal Runtime. When this operation finishes successfully.jar prtlogger. It also manages the Portal Application life cycle and isolates Portal Application between them by implementing the class loader separation. prtUpdate. File name prtDefault. Portal Runtime Core The Portal Runtime Core offers one implementation of the API. Portal Runtime Testing Framework API. This is the API to build Portal Components and Portal Services. but also the API to cooperate with the infrastructure to extend it and customize it.jar Description The Portal Runtime core. Internal Portal Runtime file. Helper class implementation to handle the format of PAR Files and the deployment descriptor Utility classes of the Portal Runtime.jar concurrency.properties Portal Runtime Technology Page 27 /113 .bak extension.jar Description The Portal Application API.properties Description Default value for the properties of the PRT. During its first startup.jar prt_jspapi. The Core implementation is delivered in a set of JAR files described in the table below and packaged by default in the WEB-INF/portal/lib directory.jar prtconnection.jar prtgluer. Concurrent thread access.properties prtCentral. prtDelete.

doubleByteSupport.addclasspath En us StandardEditDialog false True PortalAnywhere. the access to the security zone is tested.size UTF-8 100 async.defaultDelegate caching.The following table gives a list of the most important properties that can be changed to customize the Portal Runtime behavior.doubleByteSupport Description Indicates if the Runtime will support double byte encoding in the request and the response The type of encoding to use when double byte support is activated in the PRT The pool size asynchronous mechanism for the response Default Value true runtime.runtime.defaultcomponent jsp.default loadlimit. See Security Zone in PRT.pool. If set to production prtroot access is not allowed unless the component belongs to a security zone.response. If set to test prtroot access is allowed for every component that doesn’t belong to a specified zone.pool. If set to development prtroot access is allowed for every component.size The thread pool size to manage the timeout when using the asynchronous response mechanism.defaultlanguage request. 100 default. Classpath element to add when compiling a JSP in the Portal Runtime Number of maximum concurrent requests managed by the PRT.defaultcountry personalization.requests portal.timeout 10000 request. Timeout for the components participating in the construction of the asynchronous response.timeout.encoding async.off Monitor. Name runtime.permission. In that. This is the default language to be used when none is specified Same for the country. If sets to true. monitoring is switched off. Default delegate for the personalization of a component If the PRT cache must be turned off by default.off connection. The default Portal Component to start when none is specified.response.component.mode -1 production Portal Runtime Technology Page 28 /113 .

Portal Runtime Technology Page 29 /113 .

Components and services can access to the context of the application the belongs to by calling the lookup method on the root context. The Portal Runtime is using a set of pre-defined contexts to store objects that are invoked at certain point of time during the Portal execution. The following table gives the list of contexts. The list of request event listeners The list of mode hooks. Context context = PortalRegistry. import javax. The connections known by the Portal Runtime. The Portal Registry is implemented as a hierarchical JNDI context allowing to bind any kind of object.listeners runtime/hooks/mode runtime/connections runtime/prt. The Portal Registry is a singleton offering methods to create sub-contexts. The modes known and handled by the PRT. Portal Runtime Technology Page 30 /113 .Portal Registry The Portal Registry is the entry point for inspection of almost all Portal runtime information.modes Central Configuration Storage The Portal Registry also provides access to a JNDI context which can be used to read/write any kind of data to the repository. The document hooks list.naming. The component hooks list. The context in which deployment hooks bind themselves in order to be notified when a Portal Application is deployed in the Portal. and lookup objects. Registry Sub-Context runtime/hooks/node runtime/hooks/component runtime/hooks/document runtime/hooks/response runtime/hooks/deployment Description The list of node hooks. runtime/hooks/event runtime/hooks/event/request. For further information concerning this topic please check: Central Config Storage – How to page 94. Context applicationContext = context. The list of event hooks installed in the runtime. . In particular. This feature can be used by any portal application to store additional configuration files or resources that are to be shared by all PRT nodes on the cluster. Contains all the response hooks known by the runtime.getCentralConfigurationContext()... In general. This interface is used to read and write the data.lookup(“MyAppName”).Context. the Portal Registry is used for two purposes: • • A global place for an application to store and retrieve objects. in which the Portal Runtime will look for objects to customize its execution. this includes the running services and the Portal Configuration. A sub context dedicated to the application exists by default. bind. The Central Configuration context relies on the JNDI API plus the IStreamSource interface.

long currentTime) returns true it the cache has expired getCachingLevel(IPortalComponentRequest request) returns a CachingLevel object representing one of the 3 values described above. API The ICachablePortalComponent interface offers the following methods to control how the PRT cache will interact with the content of the component. This cache is used to store and retrieve the content of components that want to be cached. Using the Portal Runtime API to control the validity and the granularity of the cache. The node mark has changed on a node. • • Configure the Portal Component by selecting a set of Properties. indicate the validity of the cache in milliseconds. A portal administrator could always force the PRT to use the cache properties defined in the Profile of the component by setting the property ForceProfileCachingParams to true. The request type is a REFRESH An exception is raised when executing the service method that is supposed to be stored in the cache. long creationTime. Portal Runtime Technology Page 31 /113 . In that case. the component needs to change its implementation and inherit from the ICachablePortalComponent interface. hasExpired(IPortalComponentRequest request. But the Portal Runtime will mark the cached content as expired in the following circumstances: A request or a component event has been sent to the component. Caching Expiration In general. 3 values are allowed : • • • Shared : The cache content is shared among all the users (one java virtual machine) User: The content is private for each user Session: The content of the component is cached all the time the (servlet) session is running. Properties A first property identifies at which level the cache needs to be placed by adding the CachingLevel property in your component profile. only the content of the request of type “content” will be stored in the cache. In that case. A content developer has two ways to decide when and how a Portal Component needs to cache content. the cache expiration is controlled by the component either because the validity period expires or the method hasExpired() returns true. whether or not a user is connected. This level is used to cache information related to the browser's sessions The property ValidityPeriod will A second property provides information on the validity of the cache.Portal Runtime Cache The Portal Runtime implements by default a memory cache.

system com. In Addition the Portal Application Repository provides a central storage of application configuration and arbitrary application data. The connection must register itself to the Portal Registry The connection must implement the IServletConnection interface Two connections are provided by default by the Portal Runtime. The Application repository is packaged and delivered as a standard Portal Service providing a JNDI interface to the following contexts: Folder Name com. This can be done during the initialization of a service that has been marked as load on startup. Each implementation might have a different request cycle. Connection implementations are delivered and packaged as regular Portal Applications. public synchronized void init(IServiceContext context){ mm_connection = new MyConnection().sap. Handle any incoming SOAP request.system/applications com.portal. try { PortalRegistry.getInstance(). Connnection Name /runtime/connections/portal /runtime/connections/soap Connection registration at startup: The registration must bind an object of type IServletConnection in the “connections” JNDI context of the Portal Registry.system/archives com.portal.system/configuration Description Root context Folders for PAR files Folder containing the list of applications loaded in the repository. mm_connection).Portal Application Repository The Application Repository serves to provide information on all available Portal Applications (including Portal Components and Portal Services).bind ("/runtime/connections/MyConnection". The constraints are the following: The application must be declared “Load-on-startup” in the application config section of the deployment descriptor. This layer allows to plug several “Connection” implementation to the portal. Portal Connection Framework The Portal Connection Framework offers an API allowing to control the process of a request. The configuration of the Applications. } catch (NamingException e) {}} Type Servlet connection Soap connection Description This is the default connection of the portal.portal.sap.sap.portal.sap. Portal Runtime Technology Page 32 /113 .

Portal Runtime Technology Page 33 /113 . and the response.The IServletConnection interface has defined one method called: • handleRequest(IDispatcherContext) The dispatcher context gives access to the environment in which the connection has been started. It gives access to the request.

Create the Portal Object Model (P. The Dispatcher selects the “Portal Connection” according to some information encoded in the URL. Every Portal Component involved in the process of the request is attached to a Node. the Portal Runtime constructs a tree of special objects called Node. Uses JNDI to get the Portal Object that is to be rendered. c.7 Request Cycle The request cycle starts when the dispatcher receives an HTTP request and ends when the response is sent back to the browser.M. Raise any event defined by using an appropriately generated URL. 5. Start the content collection phase. Authenticate User attached to the request. Portal Runtime Technology Page 34 /113 . the Portal Runtime notifies the participating elements to create their sub structures in the Portal Object Model and notifies them about their ready state. 3. Node When building the POM. This is again a 3 steps phase: a. This chapter describes the request cycle as it is performed by the default “Connection” used by the Portal Runtime. 4. For further detail concerning “Runnable Portal Objects” please check: Portal Content Abstraction page 97. User authentication.). Handle Request Event. It offers methods to: • • • • Construct and traverse the tree. Before content phase. 2. The default connection will perform the following steps: 1. During creation. Store and retrieve data Access to the Portal Component instance attached to it. Send and receive events. Content phase. Create the request's Portal Object Model that represents the structure of all components in the portal that participate in event handling and content creation within this request. After content phase. Retrieve the content of all the nodes present in the POM. The Node semantics is defined in the INode interface.O. b. The name of the Portal Object to start is provided by the prtroot URL parameter. All nodes involved in the POM have a chance to perform special actions before the actual content phase start. An after content event is sent to all the nodes in the POM. A before content event is sent to all the nodes in the POM.

So a mode must represent a situation. the behavior to handle the mode named xxx is to invoke the doXxx(IPortalComponentRequest. on the IComponentURI interface using the CreateComponentURI Mode Handling When deriving from AbstractPortalComponent. IPortalComponentResponse response) { Portal Runtime Technology Page 35 /113 . IPortalComponentResponse) on the Portal Component instance. CONTENT. HELP. EDIT. ERROR. The Portal Runtime API offers similar mechanisms: • • • getComponentContext (NodeMode) on the IPortalComponentRequest. Modes are supposed to be general enough. the Portal Runtime handles a number of pre-defined modes: • • TEST. setNodeMode(NodeMode) method. a Node without any component attached to it and a Node with its Component. Mode Overloading Portal Component implements their own behavior by overloading the doXxx method as follow: public void doHelp (IPortalComponentRequest request. ABOUT. Modes are abstracting a context in which component can react and display an appropriate UI. Portal Node Node a Component B Node b Portal Component Mode Portal Component Mode allows a component to render a different User Interfaces (UI). Accessing to a Mode The default way to render a component in a specific mode is to specify it through the URL used to access the component. For that reason. every components must offer a support for it. The content mode is the default mode of operation when rendering a component. setNodeMode(NodeMode) on the INode interface. The root node called Portal Node.The figure below shows a simple POM with 3 Nodes. LOGON. which is often encountered by most of the Portal Components.

Mode Name Description System delegate Portal Runtime Technology Page 36 /113 .. Mode Delegation The delegation occurs when a Portal Component decides to forward its rendering to another component.xml file as shown in the example below: <component name="mycomp"> <component-config> <property name="ClassName" value="com..modes of the Portal Registry.} response. In the above example.write (“<BR> We are in help mode”). The subsequent request events are also sent to the delegate component until the mode is set to default. </application> System Mode The Portal Runtime comes with a list of pre-defined modes and delegates. Default Mode Delegate The delegation mechanism may be defined as a default way to handle a mode.default"/> </property> </component-config> </component "> When the delegation for the xxx mode takes place. invoking this bound mode on any component will result in invoking the mode handling method on the delegate. To do so. This mechanism allows developing specialized component. the Portal Runtime invokes the doEdit method on the component called DelegateComponent.component.MyComp"/> <property name="mode" value="edit"> <property name="delegate" value="DelegateComponent.sapportals. a component needs to declare itself as the delegate for a specific mode by binding this mode in a specific folder called /runtime/prt. The setup of such a component is also done in the Portal Application configuration as shown in the following example: <application> <registry> <entry path="/runtime/prt. This is done in the configuration of the component in the portalapp.portal.default.modes/admin" name="adminDelegate" type="component” rebind="false"/> </registry> . In that case. the doXxx method is called on the delegate component.prt.

The Portal Runtime defines 5 types of hooks: • • • • • Document hooks.modes/preview /runtime/prt./runtime/prt.modes/edit /runtime/prt. /runtime/prt.modes/test SystemModes /runtime/prt. It could replace the event. Those entry points are called Hooks. the Portal Runtime has defined some points that can be customized to add specific processing.modes/about /runtime/prt. of the StandardEditDialog SystemModes SystemModes SystemModes SystemModes Display the UI of the configuration framework starting from the root plugin of the component. Event hooks Executed before firing any event. POM hooks Executed at every creation of a POM node. Response hooks Executed before and after the service() method of the component. It could add some content or replace the content. Runtime internal usage. Start the component in a test mode. forward it to another object or cancel the publishing.modes/error ErrorComponent /runtime/prt. Display the help text of the component.modes/config Edit and save the profile of a component. In that all the methods signed starting with test and signed with a TestResponse will be invoked. Runtime internal usage.modes/badUserAgent /runtime/prt.modes/_release SystemModes ReleaseComponent Portal Hooks Only internal.modes/help /runtime/prt. Concerned by the construction of the output HTML document. the different hooks are called: Portal Runtime Technology Page 37 /113 . Component hooks Executed before the service() method of the component. The hook can substitute the original response and is notified when the component has finished to use the response. The content conversion feature is implemented as response hook The following picture shows at which of time. Used by the Runtime to display the error returned by a component. Do a preview component. CRITICAL TOPIC REQUIRING EXPERT KNOWLEDGE Purpose During the request cycle. Display a short text explaining the purpose of the component.

This is the reason why the hooking API is packaged into the core of the Portal Runtime. IResponseHook. e. IComponentHook. Each hook implementation defines methods called during the hooks processing by the Portal Runtime. Adding a new Hook Portal is basically done in the following steps. This makes the hooking mechanism. the Portal Runtime will first traverse the list of hooks declared and then Portal Runtime Technology Page 38 /113 . So the usage of this API must be reserved for very few occasions. 2. adding a new Hook in the Portal Runtime will change the default behavior of all applications loaded in the Portal. c. a. very powerful and also very dangerous. IDocumentHook 3.Adding a new Portal Hook In general. INodeHook. b. At hooking point. 1. Deliver a system service that binds an entry in the Portal Registry hooks context. IEventHook. This entry implements one of the Hook interface defined by the Portal Runtime Hook API. d.

but the hook chain is still traversed and the default behavior is going to be executed.perform the default behavior. During the hooks traversal. Default hooks Request Event Hook A portal component can provide a default request event handler... b. The aim is to write the event handling one time and to make it available for all the portal components. ERROR The hook indicates that it encounters a problem during its execution. Hence a portal component that doesn’t provide Any implementation for a request event (does not overload do<<EventName>> or doRequestEvent) would let the event handling to the component that provides a default implementation for this event.listeners/myevent" name="MyEventListener" type="component"/> </registry> <application-config> <property name="releasable" value="true"/> <property name="startup" value="true"/> </application-config> <components> <component name=" MyEventListener"> . </component> </components> </application> Portal Runtime Technology Page 39 /113 . Example: The component named MyEventListener is providing a default implementation for the event named “myevent”. The generic registry tag in the portalapp. The Portal Runtime will continue with the normal process after the hooks chain traversal. <application> <registry> <entry path="/runtime/hooks/event/request. c. each hook returns a status that can have one of the following value: a. SKIP The hook chain is traversed.xml is a suitable place to declare a default event handler. but the default Portal Runtime process is not performed at the end of the hooks processing. OK.

Means that the node/component has been assigned to its parent node in the Portal Object Model on its construction in the request cycle. Means that we enter content collection next. The methods to create the event are defined in the IPortalComponentRequest Object • • IPortalRequestEvent createRequestEvent(String) passed as parameter.ON_NODE_READY_EVENT Means that the node/component has been assigned to its parent node in the Portal Object Model on its construction in the request cycle.ON_NODE_REMOVE_EVENT Request Event API Request Event must be generated by the standard Portal Component API method used to create event. Means that the node is going to be removed from its parent node. IEvent. creates a Request Event with the name IPortalRequestEvent createRequestEvent(String .Event Handling The Portal makes the distinction between two kinds of events: • • Request Events POM Events Events sent by the client set in the URL received by the WEB server. This is can be a good time to release all listener assignments that depend on the current POM structure. Means that content collection is over. This is sent on a preorder traversal of the POM. Portal Runtime Technology Page 40 /113 . Internal Portal Runtime Events Several pre-defined events are raised by the Portal Runtime to inform the Portal Components involved in the request processing of the progress of the request cycle. Receivers that have to assign children in the POM should do it upon handling this event. Events sent by a Portal Component to another.AFTER_CONTENT_EVENT IEvent.BEFORE_CONTENT_EVENT IEvent. IEvent.ON_POM_READY_EVENT IEvent. Receivers that have to assign children in the POM should do it upon handling this event.IPortalRequestEventData) returns a request event corresponding to the name and containing the data passed as parameter. Those events are then generated in the content of the Portal Component and the methods to handle the events have to be written in the Portal Component.

Component Event API
Component Event is a mechanism to send and receive special type of POM events which have name and data. It allows a component to listen and filter events sent by others components. The sender component should create a component event and fire it using the Portal Component API. The receiver component should listen to events and react when the events are received. Those events are generated by the Portal Component API using the following methods on the portal node. • IPortalComponentEvent anEvent createPortalComponentEvent (String name) Events are then published by calling the fireEventOnNode method of the Portal Node of the POM. A component event should be fired on the portal node only. • • fireEventOnNode () publish the event to all the nodes of POM.

addEventListener (EventType.COMPONENT_EVENT, IEventListener, IEventFilter) declare an Event Listener and attach an Event filter to receive only events in which the Portal Component is interested

Helper class is provided for component events (AbstractComponentEventFilters).

Event Handling
When deriving from com.sapportals.portal.prt.AbstractPortalComponent the following default behavior applies for the event handling. Corresponding to the events mentioned above the methods doOnNodeReady, doOnPOMReady, doBeforeContent, doAfterContent, doOnNodeRemove will be called. For Request Events there is a special treatment. Given a name xxx of the Event the default implementation will try to call a method doXxx(IPortalComponentRequest, IPortalRequestEvent). If such a method is not available doRequestEvent(IPortalComponentRequest, IPortalRequestEvent) will be called. For Component Events, a similar treatment is executed. Given a name xxx of the Event the default implementation will try to call a public method doXxx(IPortalComponentRequest, IPortalComponentEvent). If such a method is not available doComponentEvent (IPortalComponentRequest, IPortalComponentEvent) will be called. In addition to that, the filter attached to the listener is invoked before proceeding with normal event handling and the filter can decide to accept or reject the event handling in the following method: • boolean accept (IPortalComponentEvent) returns true if the event handling should take place.

Portal Runtime Technology

Page 41 /113

8 JNDI Support in PRT
The standard JNDI way to get access to JNDI Factories assumes that the JNDI service provider classes are in the class path. Unfortunately PRT (like any J2EE engines) implements a class loading separation feature that contradicts with the JNDI approach. This chapter explains how to use JNDI service providers without loosing the benefit of class loading separation.

PRT JNDI Support Package
The PRT JNDI support package provides a different implementation of the following core JNDI classes: javax.naming.NamingManager javax.naming.DirectoryManager javax.naming.InitialContext javax.naming.InitialDirContext The standard JNDI implementation is not able to find classes that are not in the class path. The implementation that PRT provides simply changes the way the classes are loaded. More precisely, PRT tries its own mechanism and if it fails, delegates to the standard implementation. The PRT Implementation is delivered in the JAR File: prtjndisupport.jar. The classes that should be used to solve class loading issues are the following: com.sapportals.portal.prt.jndisupport.NamingManager com.sapportals.portal.prt.jndisupport.DirectoryManager com.sapportals.portal.prt.jndisupport.InitialContext com.sapportals.portal.prt.jndisupport.InitialDirContext Note that only the package name has been changed (not the class name). As a consequence the impact on the code is minimal since changing the import statement might be sufficient.

JNDI Service Providers
To take benefit of the PRT JNDI Support, JNDI Service Providers will have to compile against this new “com.sapportals.portal.prt.jndisupport” package and delegate to the PRT implementation instead of calling directly the core classes provided by the “javax.naming” package.

import com.sapportals.portal.prt.jndisupport.DirectoryManager; // convert the persistenceObject to a semantic object Object semanticObject; semanticObject = DirectoryManager.getObjectInstance( null, name, this, env, objectAttributes);

Portal Runtime Technology

Page 42 /113

JNDI Clients
JNDI clients have to change the way they get the InitialContext. They must used the PRT Implementation of the Initial Context class instead of the standard one like below:
import com.sapportals.portal.prt.jndisupport.InitialContext; ... try { Context initialContext ; Hashtable env = new Hashtable(); env.put( Context.INITIAL_CONTEXT_FACTORY, "com.sapportals.portal.pcd.gl.PcdInitialContextFactory"); initialContext = new InitialContext(env); Object o = initialContext.lookup(aName); } catch ( NamingException e ) { e.printStackTrace(); }

JNDI Service Providers Packaging
A typical JNDI service provider will be deployed in the portal like any portal application by providing a PAR File. In order to register itself to the PRT JNDI Support, the application have to include a java property file named jndiprovider.properties in its PAR File and be declared as “load-on-startup” in its deployment descriptor. The location of this “JNDI Provider Resource File” in the PAR file must be:
/PORTAL-INF/properties/jndiprovider.properties

This file is a regular “JNDI Provider resource file” and when loading the portal application, PRT uses it to get the following JNDI properties:
java.naming.factory.initial java.naming.factory.object java.naming.factory.state java.naming.factory.url.pkgs

Note that properties for object and state factories might provide a colon-separated list of class names. For more details about these properties, please check the JNDI Tutorial at:
http://java.sun.com/products/jndi/tutorial/beyond/env/overview.html

PRT also expects from that file additional properties defining the schemes that the JNDI Service Provider will support at runtime:
com.sapportals.portal.prt.jndisupport.scheme com.sapportals.portal.prt.jndisupport.schemes

Portal Runtime Technology

Page 43 /113

It allows to organize data hierarchically.portal.providers # # scheme supported by this JNDI service provider # com.sap.url. The Object Factory will be used to get the raw data from the persistence layer and load it in memory as Java objects.sap.com/products/jndi/tutorial/ JNDI Environment The environment is a property set (Hashtable) used to specify various preferences and properties that define the environment for which the contexts are created.factory.prt.jndisupport.factory.TravelInitialContextFactory # # List of packages where to look for URL Context Factory # java.tm. A typical “JNDI Provider Resource File” could be: # # Initial Context Factory # java.html JNDI Context A JNDI context is an implementation of the javax.naming.sap.sun.TravelObjectFactory # Each factory declared in that file are playing a specific role at runtime. This application could have its own factories and its own scheme (tm:).scheme=tm # # State factories # java.factory.initial=com.naming.sun.naming.JNDI Provider Resource File Sample Let’s imagine a “Travel Management Portal Application” that want to plug its own content to the portal. Please check the link: http://java.tm.tm.object=com.application. which provides basic operations like: bind.application.com/products/jndi/tutorial/beyond/env/overview. JNDI Tutorial: http://java.naming.jndi.TravelStateFactory # # # Object factories # java.application.Context interface. This environment typically includes user authentication information.sapportals.pkgs=com.state=com.factory.sap. Portal Runtime Technology Page 44 /113 . JNDI Concepts and Related Documents The JNDI Tutorial provides in-depth information concerning the JNDI API and how to implement it. the state factory will be used to update/store objects in the persistence layer and the scheme will avoid naming conflicts with other JNDI providers. The “Initial Context Factory” will be the root node to the specific content. lookup and list.naming.tm.

3/docs/api/javax/naming/spi/InitialContextFactory.com/j2se/1.com/j2se/1. More detail at: http://java.sun.3/docs/api/javax/naming/Context.html JNDI Context Factories The initial context factory is the object used to create initial context instances. Factories are necessary because only the factory knows about the context implementation. The JNDI Naming Manager internally used factories to get Context instances.sun.html Portal Runtime Technology Page 45 /113 .More detail at: http://java.

In the same way.xml makes the trick.xml property WebEnable=”true” WebProxy=”true” Effect Turn the service into a WEB service Force the use of the proxy of the service Portal Applications and external WEB services External WEB services can be accessed by portal components or portal services. Only the WSDL file of this external WEB service is requested (even if it is only accessible via Internet). the Portal Service is a Portal Web Service. generated with the ToolKitWebServicePRT you have to set the property WebProxy=”true”) . The first one consists in offering Portal services as WEB services. The related tool Portal Runtime Technology Page 46 /113 .9 WEB Services Support A natural extension of the concept of Portal Services is the WEB Services technology. Portal Components SOAP Service LAYER SOAP Protocol . Approach The Portal Runtime offers two convenient ways to use the WEB services. Portal Components and Portal Services can easily access to external WEB Services to build Portal Applications The purpose of this chapter is to describe how work WEB Portal Services. Portal Services as WEB Services Turning a Portal Service to a Web Service is something very smooth and easy after using the open tool (ToolKitWebServicePRT). external components can access to the services and applications developed with the Portal Runtime technology using the SOAP protocol. the Portal Runtime provides tools and facilities to generate Proxies to external WEB Services. It is accessible via an URL of the type : irj/servlet/prt/soap/PortalServiceName?wsdl . A simple modification of the portalapp. The second one allows portal applications to access external WEB services.NET / INQMY / SOAP APACHE WEB SERVICE IMPLEMEN TATION Portal Services … The external WEB service is accessed like every other service within the portal. Thus. By providing a SOAP connection to the Portal Services. Portalapp. The WSDL file informs what are the accessible methods in the service. The following line must be added : WebEnable=”true” (If you want to use a proxy. This done.

The portal service of the requestor is wrapped by the open tool (ToolKitWebServicePRT) from the WSDL file to the external WEB service. Nevertheless as it interacts a lot with the WSDL files it is useful to know a little how it works. Then. Concepts The principle of the WEB services into the portal is shown below. each access to the soap service is converted by the runtime to a soap message. The answer is waited and when this one arrives the process can go on. The open tool do almost all the work needed. It is done if the security is respected (rights. for the provider. It can be seen on the schema. etc…) The needed operations are shown more precisely into the architecture part. And when a soap message is received. identifications. For emitter as for receiver. The whole process (or so) is hidden to the user. There is no intervention of the open tool in the runtime sequence. On the other side. All is wrapped by the portal runtime. All the manipulations done by the open tool are done before making the PAR file. the WSDL file of the soap service within the portal is generated by the open tool (the same as before). Service Requestor Web Services tool (Open Tools) Service Invocation Implementation Service Wrapper Service Provider Web Services tool (Open Tools) D E S I G N Service Implemen -tation WSDL WSDL Generator SOAP Service D E V R U N T I M E Service Invocation SOAP Consumer SOAP Service WSDL Soap Service Service SOAP Connection PRT Service SOAP Message Portal Runtime Technology Page 47 /113 . the soap message is not directly handled by the portal service. Very few things are requested to allow a WEB service to run into the portal.(ToolKitWebServicePRT) allows you to configure your development environment. It is as easy as developing a portal service. the message is interpreted by the runtime and redirected to the specified portal service.

however. SOAP can potentially be used in combination with a variety of other protocols. distributed environment.wsdl Open Tool Open Tool Proxy SOAPProxyP Par Reflection + Connection Information WEB Service development process 1. Soap Framework SOAP is a lightweight protocol for exchange of information in a decentralized. IService Open Tool . A Web Service is an interface that describes a collection of operations that are network-accessible through standardized XML Messaging.Architecture In this part. Portal Runtime Technology Page 48 /113 . the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework. wsdl From External Service IXXXService methodA methodB Simple and Complex Types … IX. the main architectural aspects of the portal WEB services will be detailed. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it. a set of encoding rules for expressing instances of applicationdefined data types. and a convention for representing remote procedure calls and responses. WSDL is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information.

the Portal Runtime will also provide his own implementation to generate proxy for Web services Connection.1 The Portal WEB Services give a common architecture to connect external Web Services. which needs to contact external Web Services. This implies different functionalities as SOAP interpreter. It also allows us to only provide one ServletConnection to understand SOAP Calls.2 The Portal WEB Services give to developer an easy way to create Web Service. a JAXM 1. The portal WEB services implementation is able to receive SOAP Messages. to be connected. These URLs are of this type : irj/servlet/prt/soap/AliasApplication Portal Runtime Technology Page 49 /113 . will also use the portal WEB services implementation to the address them.jar.0 Implementation (based on the JavaTM API for XML Messaging (JAXM) version1. The portal WEB services implementation is also able to deal with the WSDL concept. we use the new libraries inqmysoap. We provide • An interpreter for WSDL Language o o • • • o to make portal services to address external web services Be able to cope with custom types Serializers / Deserializers generator Complex Object wrapper Web services configuration stored in the Central Config Storage 1. o o • o Be listener Address Message to the SM Be able to decode SOAP Message Address call to the good service Decode parameter Construct answer • Implements JAXR Specifications o Publish our service to external new calls Provide WSDL Description of service Automatic process or not • Web services configuration stored in the Central Config Storage Interpreter for WSDL Language One unique entry point The advantage of this approach is that there is no need to provide multiple URL. We provide • Open simple way to receive SOAP Messages. In this case. dynamic service methods invocation…. For that. Java proxies generation. The open tool is able to generate a portal service from a WSDL file.0) which was developed as JSR067 under the Java Community Process. The developer.1.

Soap Consumer The Soap Consumer is in charge of processing the Soap message. A list of processors is maintained by the portal. the Mapping Registry. The difference is that this approach allows us to easily include the Soap listening to our Connection Layer. If the XML Soap Message description is well formatted and if the called service exists on the Portal Runtime environment then the Soap Consumer can work correctly. the only provided processor is a portal service. The service developers need to provide: The exposed methods wanted. selected with the open tool Modify the “portalapp. 2. Proxies Portal Runtime Technology Page 50 /113 . The developer of the Portal Services will have to provide a few extra works. Registries Supported types (serialization and deserialization) are maintained by registries. to recreate the incoming Soap message. extract Soap messages from it and to pass them to the Soap Consumer SOAPConnection Class is able to receive HttpRequest. These serializers and deserializers are included into the deployed PAR files. 5. Some other processors are in development like the WSRP processor. load dynamically the Portal Runtime Services and address them the call. Other ones are linked to services. 3. Soap connection The SOAP Connection registers itself to the Portal Plug in Framework. contains all the Soap types and some common Java types. the Java object is serialized to an xml content (marshal of the soap message). Create the associated PAR file and upload this PAR file. That means that it must verify whether the Soap message is Portal Runtime Compliant. The xml content is converted to java code. Now. It implements IServletConnection. another a type. The Soap Consumer is also in charge of the answer construction. Each service refers to its Specialized Registry to deals with custom types. For processing a soap message you need to unmarshal it. on the contrary. to receive request call. It calls the Service Manager to access the called service. the MimeHeaders and the ServletInputstream. 6. Processor The processor insures the method invocation. The specialized registries are loaded in the class loader of the corresponding service. SOAPConsumer class is able to read the Soap Message and its possible attachments in collaboration with the ServiceManager to retrieve. This process works also on interfaces and copes with inheritance (if a class has no deserializer.ServiceName Easy use of Portal Services The Portal Runtime Services are called dynamically by the SOAP Listener (or Consumer). The Soap message is deserialized to transform it in a java method call. 4.xml” file (description of the portal applications) to declare the service as WebEnabled (proceed the same way for the WebProxy). This class could be compare to the JAXMServlet class from Sun. when a soap message is constructed. An xml tag represents a method. the parent class is asked for it – and so for as many levels as needed). another one the value and so on. It gets from the request. A global one. And.irj/servlet/prt/soap/ApplicationName.

The service then manipulates the proxy for its soap calls. So the normal process of authentication included in the Portal Runtime environment can do the authentication process. 7. Use of the “CRC” principle. Soap messages are included in HttpRequest. Security Soap messages from a SAP Enterprise Portal to our Soap processors may not be encrypted. The proxy is automatically created. it is converted automatically in SOAP Fault Message with the following structure : <SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.w3.org/2001/12/soap-faults"> <SOAP-ENV:Body> <SOAP-ENV:Fault> <faultcode>%TYPE_ERROR% </faultcode> <faultstring>%DESCRIPTION_ERROR%</faultstring> <faultactor>%[SERVER_NAME] COMPONENT NAME%</faultactor> <detail> <stackTrace >%JAVA_STACKTRACE%</stackTrace> </detail> </SOAP-ENV:Fault> </SOAP-ENV:Body> Portal Runtime Technology Page 51 /113 . 8. It means the use of https protocol and single sign on (sso) identification (into the soap header). The other way implemented to increase security for soap messages is to block the method call for users who do not have the permission to use them. The header also contains a way to check the Soap message integrity.e.org/soap/envelope/" xmlns:fault="http://www. outgoing Soap messages) need to be encrypted. Other messages (i. The proxies are also used for the call of external WEB services. The whole process is once more hidden from the user. on request by the open tool.The open tools can generate a proxy for each portal service turned into a WEB service. The proxy externalizes the method call. It provide efficient security to the portal WEB services. There are two ways for doing it. it wraps all the requested methods and decompose them. There is also be a protection/verification of incoming Soap messages in order to avoid the execution of our services via Soap attacks. SOAP Fault Process • The invoked method generates an exception SOAP FRAMEWORK Portal Service SOAP Request Invoked Method Exception throws SOAP Response (Fault) SOAP Fault Message During the invoke of the Web Service’s method if an exception is throw.xmlsoap.

it is possible to disable the display of java stack trace in the SOAP Fault Message. the PRTSOAP Call class in the PRT SOAP Framework generates the SOAP Request (2) and in the case an where an error will be occur in the Web Service Server (3) during the SOAP process. It verifies the compatibility of the round 1 tests with the main soap platform available on the market (systinet. All exceptions throws in the SOAP framework and the Portal Web services are logged in the SOAP Logger. all soap messages are logged in the SOAP Logger if it is enable.In SOAP Admin tool. It contains Interoperability tests (round 1 – to check the compatibility between the portal WEB services and other implementations). You may also find interesting the SAPParWizard (for both Eclipse and JBuilder) for development operations about PAR files. It also contains an example which shows a way of using the WSDL generator (on the fly WSDL file reading and writing). allows searches on Google) and an example of client proxy use (This proxy is open tool generated). and it throws in the WebService Portal Proxy. normally a SOAP Fault message is generated by the WebService and returned as response(4). a proxy generator and a complex objects wrapper. to enable the soap logger to store the soap message and debug information you must select the property “ Log” in the Configuration menu of SOAP Admin component Related tools Some tools are quite useful for developing portal WEB services. For that the property “Debug Mode” must be deselect in the configuration menu. The PRTSOAP Call converts the SOAP Fault message by a PRTFault Exception (extends SOAPServiceException) (5).0 (the name is soap. the SOAP Logger file is stored in the log folder of EP6. The second form of the log is the soap debug information. Within the portal. it exists two forms of log different. It contains an example of external WEB service use (Google WEB service.log). apache…). 9. two other tools can be found. The main one is the ToolKitWebServicePRT (a JBuilder open tool) which contains a WSDL Generator. mssoap. . a serializer and deserializer generator.net. • The SOAP Call return a fault message WEB SERVICE SOAP Request 2 SOAP FRAMEWORK 3 Error Server SOAP Fault Message SOAP (Fault) Response PRTSOAP Call 1 Web Portal Service SOAP Fault Message 4 Create 5 Throws PRT Fault Exception PRTFault When a WebService Portal Proxy Service invoke a webservice method (1). SOAP Logger In the PRT SOAP Framework. Portal Runtime Technology Page 52 /113 . the soap admin tool (for configuration needs) and the Soap test suite. By default the information logger is disable.

iviewstudio. code.com/ Approach The following picture shows the Portal Application development model: A Portal application has to be packaged in a Portal Archive (PAR) file and must be uploaded in the Portal before being executed. Portal Runtime Technology Page 53 /113 . The objective of the PAR IDE is to speed up the Portal Application development process. Create a Portal WEB Services from a WSDL or Portal Service The complete documentation can be found in the iView studio WEB site: http://www. Upload/Execute/Debug Portal Application. Portal Services. Supported objects are Portal Components. PAR Export Upload Create PAR IDE Portal Application Development Cycle PRT PAR Import Execute and Test The goal of the PAR IDE is allow a Portal Application developer to cover all the development steps in one environment: • • • Export/Import/Create PAR files. Edit.10 PAR IDE The PAR IDE is an eclipse plugin supporting the Portal Application development model. It allows to: • • • • Import PAR file Export PAR file Add a Portal Object to a PAR. Additional Feature The PAR IDE offers also an API to register a plug-in that can be called during the creation of the PAR File. Portal WEB Services. It allows Portal Application developers to extend the original Portal Application development model. compile and add resources to Portal Application.

ideSpecific. In order to create such a tool. <extension point="org. And during the unpacking operation. …in order to register to the PAR plugin.ui. In the plugin.eclipse. 3. IParIdePlugin aPlugin).startup"> </extension> In the base class of the add-on plugin (the first class called when the add-on plugin is started. the additional tool will be call after the initial unpacking of the PAR file. Call of the static method of com. 2.api. This add-on is also an eclipse plugin and must follow few simple rules: 1.general.portal. It will allow this add-on to register into the PAR plugin. 1. one for the packing the other for the unpacking.plugin.sap. It must implement two interfaces.eclipse. an add-on plugin must implement the com.sap.. it can register itself to the PAR plugin. it can be assumed that the add-on plugin is loaded at startup.developmentTools.AbstractUIPlugin is extended) the interface org.ui. The plugin id must be unique.You can interfere with both process concerning the packing and unpacking of the PAR file. It must be loaded at the eclipse startup. The interface to implement To register.PortalPlugin class: registerPlugin(String pluginId.developmentTools. 2.Istartup with its unique method (earlyStartup()) must be implemented. and where org.eclipse. 3. Register Now. Eclipse startup The plugin add-on has to be loaded when eclipse starts. Other important notes The add-on plugin has to clearly specify the final state of the operation using the method setFinalState(int status) from the class Portal Runtime Technology Page 54 /113 .eclipse..IparIdePlugin and give the implementation class as parameter when it registers. So in its constructor. 4.xml the following extension point has to be added.ui.portal. During the packing operation. In order to achieve this follow the instructions. you have to produce a PAR plugin add-on. the additional tool will be called before the final packing of the PAR file.

portal. These will be displayed into the task view of Eclipse.api.general.IfinishResult. If the final state is OK or warning then the PAR process will go on otherwise it will be stopped. Portal Runtime Technology Page 55 /113 .developmentTools.com. you can also add as many messages with their level as you want.sap. Inside the IfinishResult.

0".0 version to enable backward compatibility EP50 Deployment Policy The local deployment of a portal application is done taking care of the “DeploymentPolicy” property declared in the application config section of the deployment descriptor.11 Compatibility Considerations EP 5.wcm. This property provides a comma-separated list of paths or file names that are protected.service.sapportals.0" encoding="utf-8"?> <application name="com. - EP50 Class Loading "ClassLoaderPolicy": if set to "5.0” then the deployment is backward compatible with the EP50 version of the portal.portal. Example of deployment descriptor enabling backward compatibility properties <?xml version="1. The 6.km. See also Class Loading in the Portal Runtime. EP50 Archives EP50 PAR Files and ZAR Files were using a different format and the XML based deployment descriptor as it is today was missing.sap.0 model assumes that definitions made accessible via the "SharingReference" property can be considered part of the Applications API and should therefore be also made visible to a referencing application. By default they will. Those files and paths will not be replaced by the new version.KMServiceImpl"/> <property name="classNameFactory" value=""/> <property name="classNameManager" value=""/> <property name="poolFactory" value="0"/> <property name="startup" value="false"/> </service-config> Portal Runtime Technology Page 56 /113 . API definitions of referenced Portal Applications via the "SharingReference" property will not be visible to referencing applications automatically.application" alias="knowledgemanagement"> <application-config> <property name="releasable" value="false"/> <property name="PreservedConfigPaths" value="/PORTAL-INF/lib/config_local. In that case the deployment policy also takes care of the deprecated “PreservedConfigPaths” property. It is important to know that those generated deployment descriptors will by default enable the EP50 Deployment and Class Loading Policy.properties"/> <property name="ClassLoadingPolicy" value="5.0 Backward compatibility The following section describes some mechanisms that were kept or introduced in the 6. If this property is set to “5. In that case the old folder is not removed and the the deployment process simply overrides the folder with the new content. When EP50 archives are uploaded to the portal the EP60 Deployment descriptor is dynamically generated and stored in the repository.0"/> </application-config> <components/> <services> <service name="default" alias="knowledgemanagement"> <service-config> <property name="className" value="com.0"/> <property name="DeploymentPolicy" value="5.

This check produces a warning message each time that the name of the resource in the file system is not the same than the name passed as parameter of the API regarding its capitalization.0 since SP 4. PRT offers a case-sensitive check when accessing WEB resources via the Portal Component API.log. the error will occur only in Unix and will be hidden in Windows. a Portal Application is portable from Windows to Unix.2 UNIX/Windows compatibility As the PRT is written in Java. this is the same in EP 5. the PRT should run on Windows and in development mode by setting the portal.permission. Portal Application developers can fix their applications on Windows without having to wait to see their applications crashing on Unix. and proposes a development model relying on the Java Technology.</service> </services> </application> List of Incompatibilities to EP 5.runtime.mode property to development Portal Runtime Technology Page 57 /113 . The warning message is logged in a new file called diagnostic. With this mechanism.0 • • jco service is deprecated jcoclient service: the different getJCOClientPoolEntry() methods throw a TimeoutException (a RuntimeException). If a file name or a WEB resources is wrongly capitalized. However. To enable this check. a common portability problem often encountered by Portal Application developers when running on Unix an application developed on Windows is the case-sensitive issue. In order to help Portal Application developers to identify those kind of problems on the Windows platform.

runtime.notification The notification Service is responsible to provide a support for communication between PRT instances running in different Portal Environments.sap. The following figure illustrates the architecture of the Notification Service. The notification service has two goals: • Deliver an API to send and receive messages between different WEB servers. This is the only service having such knowledge of the execution infrastructure. The service use to subscribe and receive message ITopicListener.portal. PRT 1 Component A Notification Service PRT 2 Component B Notification Service PRT Bridge PRT Bridge SAP J2EE cluster configuration Portal Runtime Technology Page 58 /113 . The Notification Service implementation must understand the cluster configuration. This implies that a version of the Notification Service should exist for every supported platform. In this example. When the component A publishes on PRT1. the component B on PRT2 is registering to a specific topic and the component A is publishing a message associated to the topic in which the component B is interested in. Interface implemented by objects that want to listen for messages associated to a certain topic. the message is sent to all the PRTs declared in the cluster. Maintain the cluster information. the Notification Service uses the PRT Bridge to manage the communication between the different nodes of the cluster. TopicDataContainer Representation of the message sent from a PRT to another PRT. The PRT Bridge uses the SAP J2EE cluster configuration to obtain this knowledge. In the SAP J2EE environment.12 Additional PRT Services Notification Service Application name: com.system. The API is built around the following objects: o o o • INotificationService.

application. A component that wants to generate a content type other than HTML must specify the property: ContentType in its configuration. The target content type of this conversion is the content type defined by the PortalResponse. If a component wants to change the content type during generation. but a Portal Component can decide to generate content of another type like XML or WML. it can call the method: public void setContentType(PortalComponentContentType type) defined on IPortalComponentResponse. text/wml At runtime such a component receives a PortalComponentResponse in which the component can write multiple content types. IPortalComponentRequest request) Using the parameter request. The Content Conversion Service allows Portal Components to generate such alternative content types. the converter has access to the components resources and can locate any scripts/parameters that the component might provide to perform the conversion.portal. With this mechanism a component can even generate multiple content types during one content generation. a conversion of the content takes place. Content converters are provided to the PRT by content converter factories that implement IContentConverterFactory. The content type defined by the property ContentType is the content type a component generates at the beginning of the content generation.sap. It implements the interface IContentConverter that defines the method: String convert(String content.g. After the component has finished its content generation. This interface contains the method: public IContentConverter getConverter(PortalComponentContentType fromType. A content converter is capable of converting content of one content type to another. The path in the registry where the factories must be registered can be obtained by calling getContentConverterRegistryRoot() defined on IContentConversionService. Such a component can also participate in a WEB service scenario. Portal Runtime Technology Page 59 /113 . The value of ContentType must be the text representation of an instance of PortalComponentContentType. It uses internally the PRT mechanism of a response hook. Content Converters To perform the conversion the service uses content converters. Everything written from this point on is treated as belonging to the content type set.Content Conversion Service Application name: com. PortalComponentContentType toType) The factory must be registered in the Portal Registry.contentconversion In general Portal Components are generating HTML content. The Content Conversion Service will convert them all to the target type which is the type of the PortalResponse.runtime. e.

encode(PortalComponentContentType. String mm_rootKey = contentConversion.HTML. Here is an example that registers myFactory to provide a converter that can convert from RSS to HTML: IContentConversionService contentConversion = (IContentConversionService)mm_serviceContext. See the API documentation for more details: public XSLConverter(File styleSheet. The Content Converter Service registers during startup the following content converter factories: RSS -> HTML XML -> HTML The converters provided by these factories are instances of XSLConverter. String mm_RSSToHTMLConverterRegistryString = fromType + toType. An XSLConverter can be created by specifying a style sheet to be used or/and the converter can look for a style sheet at runtime in the components resources.getInstance().encode(PortalComponentContentType.toString()).RSS. PortalRegistry. Instances of XSLConverter are used to do conversions using XSL style sheets.sap. This is the constructor of XSLConverter.getService(IContentConversionService.bind(mm_rootKey + "/" + mm_RSSToHTMLConverterRegistryString. String styleSheetReference) throws FileNotFoundException Portal Runtime Technology Page 60 /113 . String fromType = URLEncoder.runtime.toString()).getContentConverterRegistryRoot(). myFactory).KEY). String toType = URLEncoder. Content Converter Service Application name: com.The key to register the factory must be the concatenation of the two content types that the factory is able to provide a converter for. The two content types must be URL encoded.portal.application.contentconverter This service provides a generic XSLConverter that implements IContentConverter (see Content Conversion Service).

jcoclient This service is used in EP 5. The JCO Client Service provides the following functionality: • • • • • • Provide JCO clients to Portal Components Connection pooling HTTP session timeout detection Close connections when user logs off Maintain a connection limit (configurable) Authorization Trace (configurable) Following is a usage scenario to explain this functionality: User 1/ Session 1 User 1/ Session 2 User 2/ Session 1 a b c a b b Portal Runtime a c d e JCO Client Service R/3 R/3 System 2 f System 1 f Portal Runtime Technology Page 61 /113 . It exists in EP 6. however is the connector framework.0 as well for backward compatibility reasons.portal. Please refer to the corresponding documentation therefore.JCO Client Service Application name: com. The recommended way to obtain JCO connections with EP 6.0 to provide JCO clients to Portal Components.runtime.0.application.sap.

all JCO connections requested in this session will be closed. each user is allowed to use 10 connections to R/3 System 1 in the scenario above. Connections are pooled. all JCO connections requested in this session will be closed If a connection limit (configurable) is defined in the JCO Client Service for a specific destination. The JCO Client Service maintains a timeout for connections contained in each pool.In the above scenario User 1 is logged on with two different sessions and User 2 with one session. All function modules accessed by a specific user are traced (configurable). than the service ensures that this limit does not exceed the sum of connections in both sessions used by User 1. Connections that are no more referenced in Portal Applications are identified by the VM garbage collector and deducted from the connection limit. JCO Client Service Tutorial. This can be configured per destination. It is assumed that both users use the R/3 System 1 and System 2. a b c d e f Related documentation: • • • JCO Client Service API documentation. In this scenario the JCO Client Service provides the following functionality: If the user logs off from the Portal. Available in iViewStudio. Available in iViewStudio and PRT documentation. If the HTTP session timeout occurs. This is used to generate the user definition in R/3 with the appropriate authorizations to execute a specific business package. this limit is maintained for each user over several sessions. Portal Runtime Technology Page 62 /113 . Technical Article: How to share JCO connections in iViews. If for example.

This service knows and maintains a list of EJBs accessible from R/3 system via a RFC.KEY). IUserContext userCtx) throws Throwable { try { JCO. public JCO.getString("REQUTEXT").getExportParameterList()."ECHOTEXT").setFunctionCallListener ("MY_R3_FUNCTION".getTableParameterList().ParameterList output = function. String nameOfService) IRFCEngineService service = (IRFCEngineService) mm_serviceContext. if (function.portal.rfc. IPRTRFCListener • Portal Service should then register in their afterInit() method the RFC it want to cover using the following function of the RFC Engine Service. • The Portal Application has to reference the PRTRFCEengine Service.getName(). JCO. <application alias="TestRFC"> <application-config> <property name="ServicesReference" value="RFCEngine"/> <property name="releasable" value="true"/> </application-config> • Finally. The implementation of the RFC Engine Service is based on the rfc-engine service provided by SAPJ2ee.getImportParameterList(). setFunctionCallListener(String nameOfFunction.RFC Engine Service The RFC Engine Service allows to invoke a Portal Service from a R/3 system via an ABAP call to the Portal Runtime. the Portal Service must implement the function handleRequest to receive calls from R/3 system.sapportals.Function handleRequest(JCO. “My Service or application name”).Function function. Service Description • Portal services that want to be called via RFC must implement a new interface com.getService (IRFCEngineService. } return function.ParameterList tables = function."RESPTEXT"). output. service.setValue("This is a response from the TestRFCService side!".prt. public class TestRFCEngineService implements Iservice.service.setValue(input. The PRT RFC Engine Service registers itself to the SAP J2EE service as an EJB. Portal Runtime Technology Page 63 /113 .IPRTRFCListener.ParameterList input = function. JCO.equals("STFC_CONNECTION")) { output.

by asking for the IRFCListener registered in the bridge under the name “PRT_RFC”. it looks in its 5. 2. The PRTRFCEngine service is registering itself to the PRTBridge Service. This issue will be fixed in the future version.20 of the rfcengine service.On its start-up the Portal Service listener of RFC registers itself to the PRTRFCEninge Service. With the version SAPJ2ee 6.The PRTRFCEngine is registering the new Function to the SAP J2ee RFCEngine service. IUserContext userCtxt).The EJB transmits the call the PRT RFCEngine 7. 3. which had generated the calls. the parameter IUserContext is not fill in.prt. With the actual version ramp-up and SAP J2ee. we are not able to know what is the R/3 user.On start-up. This triggers the registration of an EJB call PRTBase to the SAP J2EE RFC Engine. Portal Runtime Technology Page 64 /113 .portal.Function handleRequest (JCO.rfc. under the name “PRT_RFC”.The PRTBase EJB transmits the call to the PRT Bridge.service. context.sapportals. to find which is the EJB registered under the function name. Security Open Issues We need an authenticated Portal user in order to interact with some Portal services when being called via RFC.IPRTRFCListener and so to define the method: JCO.Function function. 6. in method handleRequest. which registered the function name.Implementation 1.The Portal RFC engine transmits the call to the Portal Service. This Portal Service has to implement the interface com. 4When an R/3 System calls a function for the registered RFC-destination.

The configuration management of a Portal Application provides a model to: • Define the configuration element of an application. This functionality is based on the Configuration Framework delivered as one of the core services of the Portal Runtime: the Configuration Framework Services.13 Configuration Management in Portal Application The objective of this chapter is to describe how a Portal Application can define.sap. This Framework offers a set of libraries to define and manage configuration elements of an application. A Portal Application defines its own configuration containing any information that needs to be adapted to the environment to customize the behavior of the Portal Application Load in the environment the definition of the configuration. load and manage its own configuration in the Portal. This is achieved by a standard administration UI invoked by but this could also be done during the load of the Portal Application by creating some default instances of the configuration. Read/Write/Update/Delete via an API. those configurations objects and react to changes occurring of those objects. • • • For more information please see: http://help.com/portals/ or refer to the document on meta-data from the Configuration Framework. Manage (Create/Update/Delete) the configuration objects of the Portal Application. Portal Runtime Technology Page 65 /113 . The following points will be covered in this chapter: • • • • • • Create a config archive Package the config archive with the PAR Export Tool Accessing the data Config Framework API React to Configuration events Start the config mode. The load of this configuration is able to merge and upgrade already existing configuration elements.

more precisely the directory in which the configuration is stored (meta as well as data. allows to build the Meta Config Archive and the Config Archive transparently. The names of the directory must match properly under meta and data! From a configuration perspective.portal.sap. In order to build the Config Archive (and its Config Meta Archive) properly.prt. Portal Runtime Technology Page 66 /113 .Create a Config Archive Place your configuration files in folders • • Data files: <project root>/config/data/<plugin name> Meta files: <project root>/config/meta/<plugin name> Important Points • • • The plugin name should be the name of the PAR file (this is a good way to guarantee its uniqueness). The Config Archive will be copied in <root project>/dist/PORTAL-INF/config folder as a consequence it will be packaged automatically in the PAR file and it will be deployed when the PAR is uploaded by the PAR IDE. the Portal Application needs to provide some information in a specific file called configArchive. The Export PAR functionality of the PAR IDE. This is import for ConfigRootFolder considerations (this will be detailed later).config. in this case: com. the plugin name. Use Export PAR File of the PAR IDE The deployment unit of the configuration is called the Config Archive.properties placed at the root of the config folder. It contains the configurables as they were on the file system and it gathers all the config classes (meta data) in a Config Meta Archive.prototype) is called the Root-Plugin.

1 cma.sap.date ca.config.name ca.storage=pcd CA Properties ca.creation.time ca.1 cma.machine Manifest CA-Name CA-Version CA-Dependencies CA-Creation-Time CA-Creation-Date CA-Creation-User CA-Creation-Machine Mandatory No Yes No No No No No Default Project name Time Date User name Machine name CMA Properties cma.user cma.portal.time cma.hello cma.creation.dependencies ca.version ca.version=6.1.name=com.prototype ca.version=6.creation.0.prototype.portal.user ca.date cma.storage cma.machine Manifest CMA-Name CMA-Version CMA-Dependencies CMA-Storage CMA-Creation-Time CMA-Creation-Date CMA-Creation-User CMA-Creation-Machine Mandatory No Yes No Yes No No No No Default Project name The possible values are: • sfs • pcd Time Date User name Machine name Portal Runtime Technology Page 67 /113 .creation.Config Archive properties file The plugin will place automatically the default value If non-mandatory values are specified as shown in the example below: ca.version cma.sap.name=com.prt.1.0.creation.creation.prt.creation.dependencies cma.name cma.config.creation.

config. <component name="HelloWorld"> <component-config> <property name="ClassName" value="com.prt. This represents the path within the overall configuration structure of your component specific configuration. the Config Component will take the name of the application as a default (the name of the PAR file). Portal Runtime Technology Page 68 /113 .sap.sap.portal.runtime.runtime. This is done by adding the following lines in the portalapp.sap. If no ConfigRootFolder info has been specified.portal.prototype"/> </component-profile> </component> Virtual Components Portal Service configuration are managed by creating virtual Portal Component while giving it a right ConfigRootFolder. the Portal Application needs to specify a Private Sharing Reference in portalapp.xml The configuration of an application can be administered via the general Configuration UI or via the config mode of the portal application.system. the application itself does not need a direct dependency on the Config Component.xml: <application-config> <property name="PrivateSharingReference value="com. com.config.portal.xml: <application-config> <property name="PrivateSharingReference" value="com. Configuration data for a service.runtime.config. The virtual Portal Component will use the delegate Component to the config mode.portal.sap.portal.config"/> </application-config> Note that although the Config mode will use the Config FWK component to display the configuration. It just need the dependency on the Configuration Framework service in order to access the APIs.sap.HelloWorld"/> </component-config> <component-profile> <property name="ConfigRootFolder" value="/com. can be administered by using a virtual configuration component To access the Config Framework APIs.Access data Modify portalapp.hooks"/> </application-config> Then the virtual Portal Component is created as an instance of the Config Component.prt. A Portal Component can also specify a property called the ConfigRootFolder.

prt. • Get the Configurable IConfigurable configurable = plugin. • Get the Property Value String text = configurable.portal. • Get the Config Manager IConfigManager manager = service.createContext()).sap.sapportals.prototype").portal.config.portal.prototype. This is the mechanism used to have different Portal Applications sharing the same configuration.getConfigManager(IConfigClientContext.prototype/font"/> </component-profile> </component> Sharing Configuration between Applications If the Root-Plugin name is not the same as the application name then the ConfigRootFolder has to match the Root-Plugin (see also).config.ConfigComponent"/> </component-config> <component-profile> <property name="ConfigRootFolder" value="/com.sap.prt. <component name="FontConfiguration"> <component-config> <property name="ClassName" value="com.portal.runtime. • Get the Config Plugin IConfigPlugin plugin = manager.config.config.sap.runtime. Use the Config Framework API • Get the Configuration Service IConfigurationService service = Configuration.Note that in the example below the ConfigRootFolder is set as the subfolder font of the plugin com. Portal Runtime Technology Page 69 /113 .getConfigPlugin("/com.component.sap.getPropertyValue("value").prt.getInstance().portal.getConfigurable("hello_text").prototype matches the Root-Plugin name. The path /com.

.HelloWorld". CONFIGURABLE_ADDED: A new configurable has been added.CONFIGURABLE_UPDATED) { .Configuration Event Subscription Implement the interface IConfigEventListener If a Portal Application wants to be notified about modifications on its configuration. CONFIGMANAGER_TERMINATED: A configmanager has been terminated.prototype as the application name and HelloWorld which is the component name .. CONFIGURABLE_DELETED: A configurable has been deleted.. } List of events type: • • • • • • • CONFIGMANAGER_INITIALIZED: A configmanager has been initialized. } This will uniquely identify the listener’s application throughout all the applications. public class HelloWorld extends AbstractPortalComponent implements IConfigEventListener { .. } else if (event.config.config.prototype. CONFIGURABLE_UPDATED: A configurable has been updated. • public void configEvent(ConfigEvent event): is called when an action occurred on the specified Configuration public void configEvent(ConfigEvent event) { if (event.portal.sap. } else if (. Of course if within a application there is a need for only ONE Config listener. this application has to implement the interface IConfigEventListener.CONFIGURABLE_ADDED) { . It is a good pattern to use a combination of the application name and the component name.. Portal Runtime Technology Page 70 /113 ..prt.getType() == ConfigEvent.sap. } Add the required methods Two methods have to be implemented: • public String getConfigListenerId(): return the ID of your listener public String getConfigListenerId() { return "com.portal.. CONFIGURATION_UPDATED: The configuration has been updated (by a queued update). CONFIGURABLE_LOADED: A new configurable has been loaded from store.. In this case we have com.the application can just use its name.prt.getType() == ConfigEvent.

.

Page 72 /113 . The system configuration delegue will open the Config Framework UI.getInstance(). it has to remove any listeners of the IConfigEventService.printStackTrace(). // add listener on domain String[] domains = {"/com. eventService. } catch (InvalidEntryException e) { e. the listener receives only the events that are relevant the application.getInstance().printStackTrace(). } catch (InitialConfigException e) { e. Configuration of Portal Service can be displayed by creating a virtual component as described above.getConfigEventServiceInstance().portal. The UI display the configuration starting at the root folder of the component.config"}.printStackTrace().prt. IConfigEventService eventService = configurationService.printStackTrace(). This is achieved as any other mode by adding /prtmode/config/ at the end of the prtroot URL. Remove listener When the application is released. } catch (InvalidEntryException e) { e. Application registers the listener in the method init(IPortalComponentInitContext context) of the Portal Component.sap. IConfigEventService eventService = configurationService. } Elements of domains can be plugins. } Start the Config Mode The configuration of a Portal Component can be displayed by executing the component in config mode.removeConfigEventListener(this). configurables or config items generally speaking. domains). the Portal Application has to subscribe to the IconfigEventService and by specifying domains for which the application wants to receive notifications.Add a listener To be notified about changes on the configuration data. // remove listener eventService. try { // get Configuration Service IConfigurationService configurationService = Configuration.addConfigEventListener(this. } catch (InitialConfigException e) { e. try { // get Configuration Service IConfigurationService configurationService = Configuration.getConfigEventServiceInstance(). Specifying domains allows the Configuration Framework to perform a preliminary filtering on the events that will be sent to the listener. In that case.

").getComponent()).g. Issue Overview Exception handling influences the quality of Java programs because: • • It ensures that the program can continue in error conditions. the original problem might be hidden. It allows the user to find the problem which caused a thread to terminate. However. Coding Rules Always pass the original exception Issue Always pass the original exception on Example (negative)/ Explanation catch (IOException e) { throw new RuntimeException("Problem in I/O.". This chapter also describes a framework implemented by the Portal Platform to enrich the information associated to exceptions. The original exception can be passed on by adding them to the message ("message: " + e). e. An exception that caused the termination of a Portal Application should lead to the causing problem by giving a meaningful information. e) Always include a message Issue Always include a message Example (negative)/ Explanation throw new IOException(). Following example produces a NullPointerException if context is null: throw new RuntimeException("Error in "+ context. this should not introduce problems. } By not doing this. If possible this information should be constructed dynamically. new PortalRuntimeException("Error in I/O. } There are many subclasses of NamingException and the reason might be another. Page 73 /113 . Better is to use a constructor which can take an exception as argument as well.14 Exception Handling This chapter gives general rules and guidelines to manage exception in the Portal Applications. There is always additional information which is useful to the user. Do not make wrong assumptions Issue Do not make wrong assumptions Example (negative)/ Explanation catch (NamingException e) { throw new PortalRuntimeException("Registry not found:" + e).

Log Important Exception Issue Log important Exception Example (negative)/ Explanation catch (IOException e) { throw new RuntimeException ("Exception while reading service parameters: " + e).Do not have empty exception handlers Issue Do not have empty exception handlers Example (negative)/ Explanation catch (Exception e) { // ignore } This interrupts the exception flow without doing something. it might take hours to search and then one ends up in an empty exception handler. the exception is only visible on the console. Nobody can find the problem caused by an exception handled this way. " Exception while reading service parameters. Assuming somebody needs to find such a problem at the customer site. } In general.printStackTrace(). If there is really a need for an empty exception handler there should be a good reason which should be commented and the exception should be logged. The following line logs the stack trace of the exception above: PortalRuntime.getLogger(). In addition there is sometimes to much output on the console thus making it impossible to follow the output. Do not only print the stack trace Issue Do not only print the stack trace Example (negative)/ Explanation catch (NamingException e) { e.g. The console however might not always be there or accessible. The exception caught might be a subclass of the specified one. thus hiding a problem. e. the application was started using javaw which does not open a console.severe(e. when important information is lost in an exception handler because it is not passed on it should be logged."). } If stdout is not redirected. Page 74 /113 . The exception should be logged. thus presenting another problem than expected.

For example: "message: This is the specific message for this exception. Analysis error and exception logged in a specific files. The functionality that analyzes errors and exceptions is a mechanism based on a Exception Catalog made of a set of Exception files containing: • • additional info for the exception. This is the purpose of this key word. by proposing an Exception catalog and a tool to display this information to the users. For the portal. filter information to retrieve the most relevant information out of the Java stack trace. For example: "action: Please contact you system administrator. Exception Files Exception Files are test files containing the following key word: Key word stacktrace Description Give the exclusion filter used to parse the stack trace." You can also add an advise referring to this exception. message action For this specific error you may want to display a particular message.Adding Extra Information The Portal Platform allows a developer to add extra information to exceptions thrown by Portal Applications. The LogViewer offers 4 main functionalities • • • • browse a file system to locate log files. You then specify that you want to exclude them (stacktrace:java. After an exception. Log Viewer The PRT provides a tool called LogViewer used to analyze Portal Platform Log files in order to facilitate the diagnostic of errors and problems occurring in the Portal Platform." Page 75 /113 . The goal of this approach is to help Portal administrators to diagnostic in a very fast and effective way problems occurring in the Portal Platform. you only need to know the relevant stack trace line. Just put it there. View and download log files to a local system.javax) and the first stack trace line starting with anything else than "java" or "javax" will be selected and displayed in the result. Search for specific patterns in a log file or a list of log files present in a directory. the java exceptions are not always relevant.

Action: Check that the test configuration has been set up correctly in the test directory In that case.customer.err will use the stacktrace keyword to filter out from the stacktrace analysis any references to the CustomerInfo application stacktrace:com. Exception Catalog The exception catalog is located in the private errors folder of the LogViewer Portal Application. Example: The Portal Applicaion CustomerInfo PortalApplication sends an exception named com. the catalog will be moved to the Application Repository and Portal Applications will be allowed to enrich the catalog during PAR uploading. every Exception Files defined in the private errors folder of Portal Applications Example: PORTAL-INF/errors/com. All these values will be displayed by the help window of the LogViewer. the class name.portal. That means that the first stack trace line which does not start with “com. as there are no information after “stacktrace”. A new deployment hook will be developed and will store in the PCD.portal.portal.portal. In that case.customer. the method and the line where the error occurred). the keyword can be omitted.testException can be described in the Exception catalog in a file called: com.customer.sap.portal.CustomerInfo” will be kept and parsed (to display the file. For the next version of the PRT (SP2). It contains a pre-defined list of exception files either sent by the Portal or representing the standard Java Exception. only the relevant information is shown.InvalidCustIDException. the help window of the LogViewer will clearly extract from the stack trace the file.testException. The initial error and message will also be displayed.sap. the method and the line where the error occurred). And the message and action information will also appear in the display window. In that case.Example: The com. And of course the message and action will appear.InvalidCustIDException.portal. In that case.err Page 76 /113 . The error occurs in the “CutomerInfo” class but it is the call of that class which is not correct. It means that the first line of the stack trace will be selected as the correct one (indicating the file.sap. the associated Exception file com. So only the caller should be displayed. the method name and the line of the caller of the CustomerInfo application that should be corrected.err containing the following information: stacktrace: Message: A test Exception occurs.sap.sap. It is what the LogViewer is doing.sap.sap.testException.CustomerInfo Message: Customer ID is not valid Action: Check your application to verify that the customer ID has a valid format.portal.customer.

In both cases the upload proceeds in two steps: • • It uploads the PAR file into the Application Repository It notifies all PRT nodes that a new Version of the application is available Uploading a PAR File to the Application Repository The PAR file is stored in the application repository. He or she can also import content to the portal using some external tools that are provided by the persistence layer. It also extracts from the deployment descriptor (portalapp. Basically this the PAR Upload procedure stores the whole archive in the underlying persistence layer (ie: a DataBase). The local deployment avoids additional round trip to the application repository and in that sense must be considered as a cache for portal applications. • • The main purpose of the local deployment is to improve performance at runtime by providing a fast access to classes and to portal application resources. It means that the Upload procedure is to be done only once. Deploying a PAR File on all PRT Nodes Once the Upload to the Application Repository is completed. That step also checks and drops all entities (applications. Local Deployment Consistency The upload process updates all PRT nodes.xml) all information requiring fast access at runtime. The update of the local deployment requires Hot Deployment capabilities. components and services) that are depending on the current application. To solve that problem. The Portal Administrator typically uses the “Archive Uploader” component to upload and deploy a Portal Applications to the portal. Each PRT node proceeds as described below: • It checks if the application is already loaded and drops the corresponding instance. Page 77 /113 . It is important to understand that there is only one Application Repository and all PRT nodes of the SAP J2EE cluster are sharing the same content. PRT also checks the local deployment before loading the application into the memory. It starts the deployment process. This process gets the PAR File from the repository and updates the local deployment by expanding the archive content. this is why all portal applications are releasable.15 Appendix PAR Flow This chapter describes the PAR Flow and explains how PAR Files are deployed to make the corresponding portal application available on all PRT nodes of a SAPJ2EE cluster. This procedure of course can’t succeed when the server is down. the upload process notifies all PRT nodes in order to guarantee that all nodes will take care of the latest changes. It then restarts all portal applications that have been dropped. This step will update the “local deployment” of the portal application on each server.

If the revision number of the local deployment differs from the repository then the local deployment is updated before loading the application. It is important to understand that the EP60 deployment logic assumes that the application doesn’t store any configuration locally. - Page 78 /113 . If the deploymentPolicy property is missing. In that case the old folder is not removed and the deployment process simply overrides the folder with the new content. If this property is set to “5. everything should be store in the repository.The check is done by comparing a “revision number” (updated during the PAR Upload). Deployment Policy The local deployment is done taking care of the “DeploymentPolicy” property declared in the deployment descriptor. a regular deployment is done.0” then the deployment is backward compatible with the EP50 version of the portal. the old deployment folder is removed and then replaced by the new one.

. DeploymentEventType. A IDeploymentHandler instance returned by the deployment hook has then the chance to implement specific code in the following method: • boolean handleEvent(IDeploymentEvent) The deployment event passed as parameter gives access to the PAR currently loaded. the rest of the process is executed..myPackage. The handler can execute custom code on each entry of the PAR. If the value is true. The PAR is about to be deployed in the Portal Environment. If the value is false. DeploymentEventType. 2. <application> <registry> <entry path="/runtime/deployment/com. </service> </ services > </application> This service implements the IDeploymentHook interface defining the following method: • IDeploymentHandler createHandler(IDeploymentEvent) returns a deployment handler depending on the deployment event set by the Portal Runtime.BEGIN_DEPLOYMENT. The boolean value returned by the handler will condition the execution of the normal deployment/upload process. The handler can execute custom code on each entry of the PAR.Deployment Hook The Portal Runtime has implemented a hook called deployment to allow custom code to be executed at some pre-defined points of the deployment process. The PRT defines two kinds of deployment event. 1.BEGIN_UPLOAD The PAR has been loaded in the portal repository. Page 79 /113 . the normal behavior is not executed. A deployment hook is a service delivered in a Portal Application that binds some name in the portal registry deployment folder.myDeploymentHook" name="myDeploymentHook" type="service” </registry> <services> <service name="myDeploymentHook"> .

The Resource Bundle returned by this method depends on the Locale of the application and on the resource bundle name defined in the Portal Application profile. in order: • • • • • localization _fr_CH localization _fr localization _en_US localization _en localization Page 80 /113 .ResourceBundle getResourceBundle() Return the Resource Bundle associated with a Portal Component. all the locale-specific strings and objects are stored in a set of ResourceBundle packaged with the PAR file. How data is presented to the user. resource bundle lookup will search for the following classes. The first part of the internationalizing process is the resourcing. a Locale object specifies a locale. Internationalization is the process of designing or converting an existing program so it is capable of being used in more than one locale. For a Portal Application. Manipulated those data in the Java/JSP code of the Portal Component.util. • Resource Bundle Name The name of the resource bundle is defined by the property ResourceBundleName of the Profile of the Portal Component. Principle and approach The approach used by the Portal Runtime to support internationalized application is based on the choice to use the Unicode character set to take advantage of the Java’s internationalization capabilities in the following 3 areas of a Portal Application. A locale defines a set of culturally-specific conventions for the display. The value returned is determined at runtime depending on multiple parameters described later on. API The Portal Runtime API offers two methods defined in the PortalComponentRequest to make the Portal Application aware of localization aspects.Locale getLocale() Return the locale object associated with a Portal Component. Those modules can then be independently added to or removed from the application. It involves isolating the locale-specific resources of the source code into modules called ResourceBundle.Text localization and Portal Components internationalization This section examines issues involved in designing and developing portal applications that support multi language environment. if the current default locale is en_US. In Java. which is simply a container for strings identifying a particular language and country. format.util. and the resource bundle name is localization. • java. The rules to find the resource bundle are the rules defined by the Java language. • • • How data is passed to the Portal Application by the browser. java. the locale of the component is fr_CH. and collation of data. For example.

properties by the following two properties: a.my_Bundle. <Portal Archive> | +-.MANIFEST. ForcedRequestCountry 2.my_Bundle_fr. request. This is used for example for anonymous user or users without locale defined in their profiles.META-INF +-. User locale .Locale lookup The locale lookup rule implemented by the Portal Runtime follows the order described below: 1.mandatorylanguage b. The Java default locale defined by the system. Administrators to setup a portal environment use this locale. it could a JAR file in PORTAL-INF/private/lib or just a single file in the PORTALINF/private/classes directory. So.defaultlanguage b. This could be used for administration components. The Request locale is defined by the browser. 4. (Either the operating system. a. a. Component locale.classes | | +-.properties and forces a Portal installation to use one and only one local. Portal Mandatory locale. Request locale. System Default locale.mandatorycountry 3.defaultcountry 6.private | | +-. This locale is defined in the prtDefault. This is the local attached in the user’s profile logged in the system.properties Page 81 /113 .PORTAL-INF | | | +-. The locale of the component is specified by the following two properties and allows forcing a component to use one specific local. ForcedRequestLanguage b.… +-. This is defined in the prtDefault. request. the localization properties must be packaged in a folder of the PAR file accessible by the Java Class Loader. Portal Default locale. request. For example.MF +-. 5. or the Java virtual machine) Resource Bundle packaging The Java implementation is excepting the resource bundles to be accessible by the Java Class loading mechanisms.properties | | +-. request.

public class HelloWorldComponent extends AbstractPortalComponent { public void doContent(IPortalComponentRequest request. the corresponding PAR must contain one resource bundle per supported language.portal. The runtime. This is done by specifying the encoding in which the page has been saved in the pageEnconding directive of the JSP file as shown in the following example: <html> <%@page pageEncoding=”shift_JIS” %> … Page 82 /113 .ResourceBundle resource = request. import com.encoding Description Convert data sent by the browser Encoding used to convert the data received from the browser Default value true UTF-8 The data are read in a Unicode format and are then manipulated accordingly.encoding property is also used to encode the data sent by the Portal Component and presented to the user in the browser. response.getString("GREETING")).doubleByteSupport. import com.*. the encoding used by the Portal Runtime is the encoding defined at the servlet container level.util.sapportals.ResourceBundle.doubleByteSupport.portal.doubleByteSupport is set to false.prt.util. the data is converted by the Portal Runtime according to the following properties defined in the Portal Configuration file Name runtime. The locale of the browser can be found by the getLocale() method of the original servlet request.doubleByteSupport runtime. } Request/Response handling When a data is sent from the browser to the Portal Component for processing.write(resource.getResourceBundle().*.resource.encoding property).prt.doubleByteSupport.sapportals. import java. JSP Support When a portal application uses a JSP resource containing double byte characters. IPortalComponentResponse response) { java. the Portal Runtime needs to understand the character set that has been used to create the file.component.Portal Component Java Code The following is a code example showing how to access to a resource bundle from a Portal Component Java code. Thus the Portal Runtime can parse the file in the correct encoding and generates the corresponding Portal Component in UTF-8 encoding encoding (or in any encoding specified in the runtime. In this example. If the property runtime.

Portal Services accessed as WEB Services by the soap connection.runtime Description Zone containing all PRT system components like ErrorComponent. But form an administration perspective it is necessary to normalize the way portal component use this concept. Examples: Security Zone com. Page 83 /113 .portal. any string could represent a security zone. It relies on two concepts: • Security Zone : A catalog containing a set of Portal Components and Portal Services. Examples: Safety Level HIGH_SAFETY Description Administrator rights are required to access objects belonging to this zone Security Zone The security zone provides during the development phase. ConfigComponent • Safety Level : A security level in a zone. The Portal application developer doesn’t have to any knowledge of the name of the roles or of the name of the users that will be present in the Portal environment in which the Portal Application will be installed. The zone defines a logical catalog containing a set of Portal Objects.Permission model for Portal Components and Portal WEB Services This chapter explains the model implemented in the Portal Runtime to control Permission on Components. The goal of this feature is to control the access to the following Portal Objects. a way to abstract the security level that a portal component or a Portal Service will require at runtime. • • Portal Components started using the prtroot URL. Technically the zone is a string defined in the portal application descriptor. From a PRT perspective there is no restriction. It allows to group objects belonging to a zone into different categories. on which ACLs are attached and checked at runtime when accessing to the Portal Object belonging to a zone.sap. The administrator of the Portal Environment has to associate the principal of the system to the zones by creating ACLs defining the permission needed to access to a specific zone.

Page 84 /113 . Each of these safety levels can then be assigned to different permissions by the administrators of the system.wsdl"> </property> </service-config> .TestBO/medium_safety"> </property> <property name="WebEnable" value="true"> </property> <property name="WSDL" value="TestBO. e. It could be any String. content_admin for portal applications User needs to be authenticated. The Portal Runtime recommendation is to use the following values: Safety Level HIGH_SAFETY Description Administrator rights are required to access to a zone. Entries corresponding to the Portal Objects are then created into the zone. <component-config> … <property name="SecurityZone" value="com.xml containing the definition of a zone for a Portal Component. g. Anonymous access is allowed MEDIUM_SAFETY LOW_SAFETY NO_SAFETY Implementation During the load of the Portal Application archive in the system. The check is performed by the application repository by testing if the current user has execute permission for that “security zone”.portal/high_safety"/> … </component-config> Example of portalpp. the Portal Runtime checks if the current user has the permissions required to access to the zone the Portal Object belongs to. to enter the zone. If the user has not enough permissions.test.sap. e. the zones are created if they do not exist. <services> …. Example of portalapp. This zone is defined in the Portal Application descriptor by the property SecurityZone. When accessing a Portal Object (Portal Component or Portal Service). developers can define different safety levels. <service-config> ….sap. a security exception will be returned by the Portal Runtime. has to be member of the system_admin role User has to have certain roles in the system to enter the zone.Safety level Within a zone.xml containing the definition of a zone for a Portal WEB Service. The PRT doesn’t make any assumptions on the value representing a safety level.. This mechanism helps Portal administrators to organize and classify objects belonging to a zone.g. <property name="SecurityZone" value="com.

this is not necessary and only increases complexity.portal com. Page 85 /113 .Recommendations The naming convention for the security zones is the following: {Namespace of business application}/{safety level}/{portal application (optional)} The namespace of the business application is defined as follows: Business Application Portal applications User Management KM Namespace com. is optional. It is the full name of the application the security zone is defined for. This allows the administrator to configure the permissions for one portal application separately.ume com. In most cases.sap.spa.km The third part of the name. the portal application name.sap.

Components are referenced in the URL to be executed and rendered. Page 86 /113 ..<name>. PrivateSharingReference = ApplicationName ServicesReference = ApplicationName getResource(applicationName. • • • Application can have alias. the name of the service can be replaced by the service alias.xml). .<name> Alias The Portal Runtime offers also a concept of alias that allows for compatibility reason to define alternate name for Portal objects. The ApplicationName is defined by the name of the file containing the application. <ApplicationName> == <ApplicationAlias> Component can have alias by using the alias of <ApplicationName>. <ApplicationName>. Examples CharingReference = ApplicationName. The ServiceName or the ComponentName is defined by prefixing the name of the component or a service defined in the portal application descriptor with the name of the application <ApplicationName >. In that case.Portal Object Name and Alias The goal of this chapter is to focus on how to identify and access to the objects manipulated by the Portal Runtime. Application are referenced by either componts or services to access to a resource packaged in the PAR file of the application by calling one of the different getResource() methods of the API. Services are referenced by components or services using the getService() API of the PRT. The following rule apply to declare an alias on Portal objects. using the alias of the application name is not accepted. then the alias can replace without any limitation the name of the application.<name> == <ServiceAlias>. In the case of a Service. For example Service can have an alias. For example. For example. For example <ApplicationAlias>. Components are referenced by other components using the getComponentContext of the PortalComponentRequest object of the PRT API. Each of the Portal Objects are accessed on different occasions summarized by the following table: Object Application Purpose Applications are referenced by other applications to indicate class loader dependencies in the deployment descriptor file (portalapp.<name> == <ApplicationAlias>. Component irj/servlet/prt/portal/prtroot/ComponentName Name The following rules apply for naming objects in the Portal Runtime. the application.) Application Service getService(ServiceName) Service Component irj/servlet/prt/soap/ServiceName getComponentContext(ComponentName) in the URL. Services are referenced in a URL to access WEB services using the soap connection.<name> is not a valid service name.

Page 87 /113 ..service" > .myService.. myApplication or myAlias for the application myApplication.myComponent for the component defined myComponent.service for the service myService. myAlias. <components> <component name="myComponent" > The following name will be valid and recognized by the Portal: • • • myApplication.Example If the myApplication.par defines the following entries: <application alias="myAlias"> <services> <service name="myService" alias="alias. myApplication. alias.myComponent.

irj | +-| | | | | | | +-| | | | | | | | | | | | | | | | | | | | | | | | | | | | portalapps | +-..classes <== CORE: java classes only | | +-.MANIFEST.lib <== API: jar files only | | | +-..ear” file should look like below: Important: Please note that this structure can be change at any time.images +-.logs | +-.< myApplication > <== a subfolder for each portal application | | | +-.xml <== deployment descriptor | | | +-. That should help the developer to understand what are the resources necessary at runtime and how portal applications are deployed locally. style sheets) that are to be accessible from the user-agent (ie: the browser).scripts +-.deployment Local Deployment of Portal Applications A portal application is deployed locally either at startup or on first call (upon HTTP request).lib <== CORE: jar files only | | | +-. Page 88 /113 .MF <== Manifest file | | +-. <== WEB resources <== a subfolder for each portal application WEB-INF | +-.classes <== API: java classes only | +-.Directory structure This section describes the directory structure after deployment.portalapps <== Non-WEB resources | | | +-..private <== Implementation of the portal application | | +-.lib | | | +-. The PAR file content is extracted and split into 2 parts.lib +-. The public part contains Web resources (images.portalapp. The PRT API provides methods to abstract from the real location of resources.<myApplication> | +-.system | | +-. Local Deployment Overview The directory structure after deploying the “irj.lib | | | +-. The java code should not assume that the structure will remain the same in the next release.portal | | | +-.META-INF <== deployment descriptor | +-. <SAP J2EE>\<server>\services\servlet_jsp\work\jspTemp | +-. scripts.

private JSPs. // // Page 89 /113 . style sheets. It is important to understand that the local deployment is a kind of cache. personalization. static html. the deployment descriptor and some application-specific files. etc. Portal Application Web Resources non-web resources web server accesses images.- The private part (ie: the PORTAL-INF folder) is deployed in a secure folder which is not accessible from the browser (ie: under WEB-INF). The private part basically contains the code (API and CORE implementation). a Portal Application is a collection element of the two currently supported types. That means for instance that a change made in the deployment descriptor deployed locally might have no impact at runtime since PRT night use the original version instead. code private code (implementation) use Referenced Portal Application's shared code Shared code (APIs) Referencing Portal Applications access to config. application data. static data files.. . Hosting environment (PRT and more) use From an execution perspective. Portal Component and Portal Service that have a use relation between each other. Elements of a Portal Application The following illustration gives an overview over the elements of Portal Applications from a resource perspective. Note: The local deployment is a copy of the original PAR file content stored in the application repository. etc. scripts...

In the PAR format these are all the definitions in jar files under PORTAL-INF/private/lib and all files under PORTAL-INF/private/classes... A gets visibility to C. A does not have any visibility on C.. In the PAR format these are all the definitions in jar files under PORTAL-INF/lib and all files under PORTAL-INF/classes. not if "5. ServicesReference) or PrivateSharingReference enable visibility of type definitions Class Loading in the Portal Runtime The following illustration shows the class loading relations between Portal Applications. Portal Component u Application Portal Component v . This may be JAVA class definition.Application X alias=Y R Service a alias="p" Application R Application Service b Access by getService(name) provides service instances . Dependencies by SharingReference (incl. On the contrary. The area marked as "core" represents all the private resources of an application as far as class loading is concerned. Page 90 /113 . The areas marked as "API" represents all the public resources of an application as far as related to class loading.. when the reference from B to C is not private. public private default (in EP6 and EP5) by "PrivateSharingReference" default (in EP6) non-default only if "CoreAccessInAPI" policy in use API Core Class Loading Examples The following picture shows the difference between the PrivateSharingReference and the SharingReference attribute: • • When setting the reference from B to C to private.0" policy in use Application Y API Using Application X API by "SharingReference" (or ServicesReference for compatibility) Arrow directions indicate propagation of type definition knowledge by class loading mechanism. but also Resource Bundles for example.

A API B API C API CORE CORE CORE SharingReference: B PrivateSharingReference: C SharingReference: C Page 91 /113 .

exampleapp.sap.ChatRoom"/> </component-config> <component-profile> <property name="AuthRequirement" value="user"> <property name="personalization" value="none"/> </property> <property name="diplayHistory" value="10"> <property name="plainDescription" value="Number of messages"/> <property name="personalization" value="dialog"/> </property> <property name="diplayStyle" value="list"> <property name="type" value="select[list.portal.exampleapp.impl.Deployment Descriptor example This is a deployment descriptor (portalapp.sap.impl. <?xml version="1.portal.ChatService"/> </service-config> <service-profile> <property name="chatHistory" value="100"/> </service-profile> </service> </services> </application> Page 92 /113 .history]"/> <property name="personalization" value="dialog"/> </property> </component-profile> </component> </components> <services> <service name="ChatService"> <service-config> <property name="startup" value="true"/> <property name="className" value="com.xml file) example of an application that contains one Portal Service and one Portal Component. The Portal Service has one property in its profile and the Portal Component has two properties.0" encoding="iso-8859-1"?> <application> <application-config> <property name="releasable" value="true"/> </application-config> <components> <component name="ChatRoom"> <component-config> <property name="ClassName" value="com.

MF com/sap/portal/exampleapp/api/IChatService.xml PORTAL-INF/lib/chatapi.jpg META-INF/MANIFEST.MF PORTAL-INF/portalapp.jar PORTAL-INF/private/lib/chatimpl.jar: META-INF/MANIFEST.jar should contain: META-INF/MANIFEST.jar The chatapi.class com/sap/portal/exampleapp/impl/ChatRoom.Application Example Matching the deployment descriptor above.class Page 93 /113 .class and chatcore. we have the following PAR File content: hello.MF com/sap/portal/exampleapp/impl/ChatService.

naming.lookup(“MyAppName”). used to read/write any kind of data to the repository. Components and services can access to the context of the application the belongs to by calling the lookup method on the root context.naming. As a contrary. . .Central Configuration Storage – How to The Central Configuration Context is a JNDI context. How to get the sub context that belongs to the application? The application can get its own sub context calling the lookup method on the root context. } catch (NamingException e) { . it exists by default and has been created during the PAR Upload.. Page 94 /113 . A sub context dedicated to the application exists by default.getCentralConfigurationContext(). Note that this context doesn’t have to be created by the application. The Central Configuration context relies on the JNDI API plus the IStreamSource interface. Context myContext = context. import javax.getCentralConfigurationContext()..lookup(“MyAppName”). } How to store and retrieve config files to/from the central location? The application can store and retrieve any kind of data as soon as it can provide an implementation of the IStreamSource interface. This interface is used to read and write the data. Context applicationContext = context. import javax. It can creates its own hierarchy thanks to the Context. Context context = PortalRegistry.Context.createSubcontext method. Context context = PortalRegistry. try { context. That interface is simply used to get an input stream to the data source. the application might want to organize it’s data using its own logic.. which can be..createSubcontext("/"+appName+"/"+contextName)... This feature can be used by any portal application to store additional configuration files or resources that are to be shared by all PRT nodes on the cluster.Context.

We can simply load the data source using the IStreamSource. "Operation failed"). try { IStreamSource source = … java.util. try { source = (IStreamSource)centralConfigContext. } Reading the data from the IStreamSource: In our example.Storing a config file To store a config file.properties”. is.util. context. IStreamSource source=null .InputStream is = source.lookup(myConfig). javax. //important } catch (IOException e) { ILogger logger = PortalRuntime. …).properties”.Properties properties = new Properties(). java. It implements the IStreamSource interface and as constructors for common data source (Files.naming. the application typically uses the bind or the rebind. } Retrieving a config file: The application has to use the lookup method to get back an IStreamSource to its config file.getInputStream(). the source refers to a java property file (the application has to know it!).naming.close().rebind(myConfig. } Page 95 /113 .io.isActive()==true) logger.getLogger(). if (logger!=null && logger.severe(e. The StreamSource helper class can be use by the portal application. java. } catch ( NamingException e ) { source=null .Context context = … String myConfig = “/MyAppName/data. } catch (NamingException e) { .Context context = … String myConfig = “/MyAppName/data..Properties properties = … javax. source). try { StreamSource source = new StreamSource(properties). java.properties.getInputStream method. properties.util..load(is).

SAP J2EE integration and interaction
The Portal Runtime supports two types of interaction with object defined and executed in the SAP J2EE environment.

Executing a Servlet as a Portal Component.
Any servlet can be packaged and executed as a Portal Component by packaging the servlet objects in a PAR file as shown in the example below: 1. The ServletTest class defines as shown below a standard servlet.
import javax.servlet.http.HttpServletRequest; import javax.servlet.http.HttpServletResponse; import javax.servlet.http.HttpServlet; public class ServletTest extends HttpServlet { protected void doGet(HttpServletRequest req, HttpServletResponse resp) try { resp.getWriter ().write ("I am a servlet "); } catch (Exception e) { } }

{

2. The PAR file should declared the Servlet object as a component of type servlet.
<components> <component name="ServletTest" > <component-config> <property name="ClassName" value="com.sapportals.portal.prt.component.ServletTest"/> <property name="ComponentType" value="servlet"/> </component-config> </component>

3. The Servlet object should be packaged in the PAR.
<Portal Archive> | +-- META-INF +-- MANIFEST.MF +-- … +-- PORTAL-INF | | | +-- private | | +-- lib | | +-- servletTest.jar

Accessing to the Portal Service from a J2EE object.
Under construction

Page 96 /113

Portal Content Abstraction
The Portal Content Abstraction is an API that provides to PRT the ability to start and render any kind of “portal objects”. The simplest portal object that can be started is of course the portal component, but PRT doesn’t make any assumption on the object type and PRT knows nothing about the source of the object and about its implementation. The benefit of this content abstraction is quite clear. PRT does not depend at all on the structure of the content itself. The concept of Roles, Worksets, iViews, Pages, Templates or whatever has no impact on the portal runtime.

JNDI Basis
The API used to achieve this abstraction is based on the JNDI API. This approach assures to benefit from JNDI defined operations and to adhere to this existing standard. This allows to keep the API thin. All metadata regarding authentication (and more) are passed using standard JNDI properties.

JNDI Service Providers
Any portal application that want to play the game will have to register its own JNDI Service provider under a name space (the scheme). This JNDI provider does not just serve the PRT, but everything running in and (potentially) next to the PRT. The contract between the content provider and PRT is the following: The JNDI provider must be able to provide objects implementing the IPropertyContentProvider and IPropertyContent interfaces. The IPropertyContent implementation must provide at least the CodeLink property. This property is used to get the corresponding PAR File (and therefore the implementation) from the application repository

For further detail concerning JNDI Providers please have a look to: PRTJndiSupport page 42.

Starting Portal Objects
When PRT receives an HTTP request, the prtroot URL parameter specifies the unique name of the object that is to be started. This name here is a JNDI name and the syntax used is not PRT-Specific. To get the object PRT simply calls the lookup method on an Initial JNDI Context.
Object o = null ; try { o = initialContext.lookup(prtroot); } catch ( Exception e ) { } if ( o!=null && o instanceof IPropertyContentProvider ) { provider = (IPropertyContentProvider)o; } else { throw new PortalRuntimeException("Portal object not found: "+prtroot ); }

As shown in the code above, PRT checks if the object implements the IPropertyContentProvider interface. That interface is the entry point providing all information that PRT needs to find the portal archive, the portal application and finally the implementation class that will be responsible of the rendering.

Page 97 /113

Portal Runtime Help Mode
The objective of this chapter is to describe how the default Help Mode is implemented in the PRT. The Help mode allows a content developer to ship help texts in a PAR and to render a Portal Component in the help mode by displaying this help text. The Portal Runtime supports 4 kinds of help text sources: • • Help Text is stored in the PAR file of the component that is rendered in help mode. The structure is totally free and should only respect the public/private rules of the PAR file structure. Help Text is stored in the PAR file according to a pre-defined structure that supports localization of the texts. The help texts must be stored in the public folder named help. When retrieving the text files, the Portal Runtime will except this text file to be located in a subfolder corresponding to the language of the user. Help text is accessed with an external URL. In that case, the help can be displayed in a separate frame. This behavior is defined by another property of the Portal Component called HelpIsolationMode. Help text is retrieved from another Portal Application. It allows the packaging of the help texts in different PARs. This approach does not support text localization.

• •

This configuration is done by using the two following properties. • • HelpURL HelpName Description gives the location of the help text to display when the Portal Runtime renders a Portal Component in the Help Mode. Many formats are supported. HelpName Gives the name of the help text file that needs to be located in a subfolder of the help public folder of the PAR. Examples docs/help.html docs/myhelp/index.html http://www.sap.com/help/ip.html /com.sap.par.help.default/docs/index.html Index.html

Property Name HelpURL

Page 98 /113

the Portal Component should set the value of the property HelpIsolationMode to URL.The Portal Runtime will look first to the HelpName property and then will inspect the value of the HelpURL property.sap. This is the typical scenario where the help text is shipped in the PAR of the Portal Component. the help text is shipped in a separate PAR.yahoo. /com. In that case.html located in the following directory: help/{user_language}/index. To use this feature. it uses the top level file without any language code.html where {user_language} is the language of the user accessing the component .com Description Connect to the specified URL to get help for the Portal Component.html HelpName Portal Component property behavior Example Index. This is the case when the help texts are stored in an external web site.html in the docs directory of the Portal Application. docs/index. the Portal Component can decide to display the content of this external web site in a separate frame.html Access to the file named index. if a language specific version is not found. In that case. Access to the files named index. This format is absolutely free and does not support text localization. Example http://www. Page 99 /113 .html in the docs directory of the helpcomponent Portal Application.html Description Access to the file index. If none of those properties is set. HelpURL Portal Component property example.portal.helpcomponent. an error message is displayed. The two following tables show examples of different values of those two properties.default/docs/index.

Format the output of the test to HTML or XML format. Invokes every test methods defined in the Portal Component. } } Each test methods invoked by the Test Mode execution. String msgLog. The Portal Component is invoked in test mode by using the following URL: • /irj/servlet/prt/portal/prtroot/<MyComponent>/prtmode/testComponents/testRendering/html Page 100 /113 . String msgId) stops the execution of the test when the test condition fails by outputting a message in the test output. A Portal Component provides support for the test mode by implementing the ITestable interface defined in the PRT API. are written against the following pattern: public void testXXX (IPortalComponentRequest aRequest. Rendering a Portal Component in test mode will perform the following operations: • • • Checks if the Portal Component provides support for this mode. The IPortalComponentTestResponse is an IPortalComponentResponse enriched with the following test methods • • log(String mgLog. String msgId) logs a message in the output of the Portal Component assert (boolean condition. public class MyAbstractPortalComponent extends AbstractPortalComponent implements ITestable { public String getTestName () { return "MyAbstractPortalComponent". IPortalComponentTestResponse aResponse).Portal Runtime Test Mode The objective of this chapter is to describe how the Test Mode is implemented in the PRT.

xml in the WEB-INF\portal\system\xml directory. • Administrator view.logger.portal. • Application Developer view. By default those methods return an ILogger object. <Logger name loggerInterface isActive pattern <LoggerClass className level <param filename append limit </param> </LoggerClass> <LoggerClass className level > </LoggerClass> </logger> = = = = "default_logger" "com.logger.log" = "false" = "800000"> = "com. A logger is associated to one or many logging class defining the output channels.… +-. a Java interface. Every loggers of this list are following an implementation a model proposing two views on the loggers. getLogger(String) on the Service Context.Logger configuration Every logger accessed by the Portal Logging API are defined in the following files: • • Logger.xml in the PORTAL-INF/logger folder of the PAR file.prt.sapportals. It contains Internal Portal Runtime loggers like the default logger.logger.prt.ConsoleLogger" = "SEVERE" Page 101 /113 .SimpleFileLogger" = "WARNING"> = "logs/workplace. the Portal Runtime offers a way to define and return another interface. A logger is defined by its name.xml The logger configuration file gives a list of Portal Runtime loggers.ILogger" "true" "%d # %20t %15s %m #"> = "com.MF +-.portal. However.sapportals. a string formatting pattern.PORTAL-INF | | | +-. One a logger has been defined it is accessed through the Portal Runtime API: o o getLogger(String) on the Portal Component Request. The following example shows a part of the logger.portal.prt. This separation allows the developer to be isolated from the logging infrastructure and let the administrator manage the locations of the log files without disturbing the application behavior.xml | | +-.sapportals. Logger.MANIFEST. the default activation flag and a logging level.logger.logger | | +-.META-INF +-.xml used to define the default logger of the Portal Runtime. Each Portal Application can define its own logger by packaging a logger configuration file in its PAR as described in the following example: <Portal Archive> | +-.portalapp.

write("calling pagelet checkresult. The Portal Runtime supports two ways to use JSPs in the Portal: • • Declarative way: the JSP lives in the portal as a component on it's own. } In that case. response.include(request. jspResource).jsp").include(request. public class CheckBoxComponent extends AbstractPortalComponent { public void doContent(IPortalComponentRequest request.jsp"). response. the PRT will find a JSP called foo under the directory jsp in the component JSPValidation. the PRT will find a JSP called checkresult under the directory jsp. Property JSP ComponentType Value path/FileName jspnative Description Relative path to the JSP in component resource Tells the PRT that this component is based on a JSP The first access to such a component will indicate to the Portal Runtime framework to compile the JSP into a real IPortalComponent instance and then execute it.IPortalComponentResponse response) { response. Declaring JSP as Portal Component Two properties in the profile of the Portal Component indicate that a JSP needs to be compiled into a Portal Component.jsp").getResource("JSPValidation".getResource("jsp". IResource jspResource = request.jsp"). "jsp". Page 102 /113 .write("calling pagelet checkresult. "/jsp/include/foo. } In that case. The second example shows how to access to JSP files belonging to another Portal Application. jspResource). IResource jspResource = request. public class CheckBoxComponent extends AbstractPortalComponent { public void doContent(IPortalComponentRequest request.IPortalComponentResponse response) { response. "jsp/checkresult. The location where to find the JSP is the property "JSP" JSP selected programmatically The JSP file is selected programmatically into the code of the Portal Component by including it as a resource in the response: The first example below shows how to access to a JSP file packaged into the caller Portal Component. Programmatic way: any Portal Component can access any JSP brought with its PAR file or that belongs to another Portal Component.JSP Support The objective of this chapter is to describe how application developers can integrate and use JSP technology into a Portal Component.

properties" can be used to define where to find the tools.home defines by JDK. If It's not retrieved a property "jsp. In order to compile the generated JSP pages at run-time. The JSP file found is generated into a java Portal Component file and then compiled into a class file.jar of the JDK.http.portal.IPortalComp onentResponse javax.select.3.jar must be set in the class path of the WEB server environment.jsp will be compiled under the package name jsp.1. Supported Features in the PRT Implicit Objects The JSP standard implicit objects accessible via scripting in the JSP are also accessible in a compiled Portal Component. The structure reflects the java packages.jar file which are not retrieved by the class loader.sapportals.prt. The tools. Class Loader consideration When accessing a JSP file.java.servlet. the class path used by the Java compiler is build with the JARs file and class files accessible from the class loader that have been used to create the Portal Component using the JSP file.servlet.prt.default in file _sapportalsjsp_entry. By default this jar is retrieved with the system property java.HttpSession (specific implementation) Page 103 /113 .addclasspath=C:/Java/jdk.PageContext (not all functionnality are supported) com.IPortalComp onentRequest javax.jar.ServletRequest com. For example a file named jsp/select/customer/default/entry. PRT needs to locate the tools.customer. After compilation.1_01/lib/tools. # # This specifies jars to add to the classpath for JSP compilation # jsp. Objects request response pageContext component request session Description original request object portal component response the page context for this JSP page the portal component request the session object requesting client created for the Type javax.JSP packaging/Compilation The JSP must be located in the par file under the private section in any directory: Directory any path Description Contains the page that will be compiled into a Portal Component The JSP file is compiled when the Portal Component is accessed for the first time.sapportals. the generated classes are added to the class loader of the Portal Component.addclasspath" in the file "prtDefault.jsp.portal. the Class Loading separation philosophy of Portal Runtime is preserved.servlet. During compilation.

application out config page the servlet context obtained from the servlet configuration object an object that writes into the output stream the servlet config for this JSP page the instance of this page's implementation class processing the current request.lang. must be accessible by the Portal Component class name.portal.ServletContext javax.Throwable that resulted in the error page being invoked java.IportalCompo nentContext exception the uncaught java. The PRT returns the Portal Component Context of the Component that is associated to the JSP pages. javax. supported not supported.jsp.sapportals.Throwable Page directive The page directive accepts the following parameter: <%@page page_directive_attr_list %> page_directive_attr_list ::={language="scriptingLanguage "} {extends="className "} {import="importList "} {session="true|false "} {buffer="none|size kb "} {autoFlush="true|false "} {isThreadSafe="true|false "} {info="info_text "} {errorPage="error_url "} {isErrorPage="true|false "} {contentType="ctinfo "} {pageEncoding="peinfo "} The following table shows the actual support of the page directive in the Portal Runtime: Directive language extends import session buffer autoFlush isThreadSafe Description scripting language used in scriptlets fully qualified class name of superclass of the class to which the JSP Page is transformed java types describing the types that are available to the scripting environment indicates if the page requires participation in a Session Specifing the buffering model for the initial out JspWriter to handle content output from the page Specifing if the buffered output should be flushed automatically Indicates the level of thread safety implemented in the page.servlet.servlet. must be accessible by the Portal Component supported supported.servlet.ServletConfig com. Support java class name.JspWriter javax.prt. always multithread Page 104 /113 .lang. the JSP standard implementation is returning the servlet.

/.SubComponent prt:componentres:MyComponent. directive/action <jsp:include page="[path]" /> <%@ include file="[path]" %> description content is not parsed. This is used to know in which not supported supported (See Portal Runtime extension) Supported (See Portal Runtime extension) Supported Supported errorPage contentType pageEncoding Portal Runtime extension The following chapter describes the extension implemented by the Portal Runtime.jsp Directory same as current JSP Description Includes the JSP relatively to the Page 105 /113 . it is included at the runtime content is parsed by the JSP container Supported Supported Supported.../.info isErrorPage Defines an arbitrary string that is incorporated into the translated page indicate the current JSP page is intended to be the URL target of another JSP's page...default.jsp prt:component:MyComponent..jsp Directory private folders private folders private folders private folders Description Redirects to the JSP relatively to the current JSP if error Redirects the given component if error Redirects the given component if error Redirects to the JSP that belongs to given component include directive/action The include directive is used to include text and/or code at JSP page translation time... ErrorPage Attribute The attribute errorPage is changed to add more flexibility for referencing a Portal Component that can handle and display an error in a Portal page./errorpage./test/anot her/j1../custom. The following values are accepted by the Portal Runtime: [path] . if true the implicit variable exception is defined Defines an URL resource to which any Java Programming uncaught Exception will be forwarded Defines the character encoding for the JSP page and for the response of the JSP page Defines the character encoding for the JSP page.default prt:component:MyComponent. The following table shows the different supported value of the [page] value for the errorPage attribute <%@ page errorPage="[page]" autoflush="false" %> [page] .

<%@include file="copyright.current JSP (belongs to the current component) prt:componentres:MyComponent.default prt:component:MyComponent./custom.default . of a copy-right file. If the JSP page is include in a component as a resource. at translation time.default..jsp Examples The following example requests the inclusion. The JSP file that is referencing the tag library can use the custom tag library definition property to reference the tag Library as follow: <%@ taglib uri="[uri]" prefix="custom" %> [uri] ./. Profile none custom=/taglib/custom. The id here is custom./ test/another/j1... Directory private folders private folders private folders private folders Description includes the jsp relatively to the current JSP includes the given component includes the given component Includes the JSP that belongs to given component Tag lib packaging All Java Server Pages that are compiled into a Portal Component can use custom tags lib by following the rules described below: The class file that implements the tag lib definition must be packaged in the lib or classes directory of the Portal Component PAR file..SubCompo nent prt:componentres:MyComponent./test/another/j1. The file may have elements which will be processed too.jsp prt:component:MyComponent.tld prt:taglib:custom Directory same as current JSP private folders Description takes the tag library definition file relatively to the current JSP the tag library is referenced by an identifier which must be defined in the profile of the component../.jsp private folders Includes the JSP that belongs to given component The include action is used for the inclusion of static and dynamic resources in the same context as the current page.html " %> Syntax <%@include file="relativeURLspec "%> The relativeURLSpec is relative to the private resource Portal Component distribution file. the tag library must be defined in the profile of the component. [path] ../custom..tld Page 106 /113 ..

This accessibility is achieved by packaging the beans into the lib or classes directory of the PAR file. References to objects with application scope are stored in the component context associated of the Portal Component that activates the page. the beans instance is stored in the context of the component that is using the JSP page that contains the useBean directive. The jsp:useBean action associates an instance of a Java programming language object defined within a given scope and available with a given id with a newly declared scripting variable of the same id. References to objects with page scope are stored in the pageContext object. The basic semantic tries to find an existing object using id and scope . If the object is not found it will attempt to create the object using the other attributes.Objects with application scope are accessible from pages processing requests that are in the same application as the one in which they were created.CheckTest" /> When using the application scope.Objects with request scope are accessible from pages processing the same request where they were created. • application . • session . References to objects with request scope are stored in the request object.checkbox. Passing a Java beans to the JSP page can be achieved by storing the beans into the request.tld The JSP file that is referencing the tag library can use the custom tag library definition property to reference the tag Library as follow: <%@ taglib uri="prt:taglib:tlhtmlb" prefix="hbj" %> Java Beans Java Beans referenced in JSP must be accessible at compilation time and at execution time. its exact semantics depends on the attributes given. Page 107 /113 . • page . The JSP semantics is respected when translating a JSP page to a Portal Component. All references to the object shall be released when the runtime environment reclaims the PortalComponentContext. References to objects with session scope are stored in the PortalComponentSession object associated with the page activation.Objects with session scope are accessible from pages processing requests that are in the same session as the one in which they were created.Objects with page scope are accessible only within the page where they are created. • request .Using the taglib provided by Portal Services All Java Server Pages that are compiled into a Portal Component can use tags libraries provided by Portal service by following the rules described below: The Tag Lib Definition file must be referenced into the Portal Component Profile as follow: Property tlhtmlb Value /SERVICE/htmlb/taglib/htmlb. <jsp:useBean id="name "scope="page|request|session|application" typeSpec > body </jsp:useBean> The jsp:useBean action is quite flexible. However the name spacing associated to the application scope is modified and is associated to the context of the Portal Component like in the example below: <jsp:useBean id="foo" scope="page" class="beans.

<% logger. IPortalRequestEvent loEvent = componentRequest.data). loEvent)%> > <br/> Page 108 /113 .createRequestEventData(). %> <!-.createRequestEvent("oneEvent".Handling Request Events Request Event must be generated by the standard Portal Component API method used to create event.getNode(). Those events are then generated in the content of the Portal Component and the methods to handle the events have to be written in the Portal Component.createComponentURL(componentRequest. IPortalRequestEventData data = componentRequest.setComponentRequest(componentRequest). Here is an example of possible use of Portal Component Evens in JSP page.Gets all logger names from admin logger service --> <FORM type=POST ACTION= <%= componentRequest.

Another entry also specifies the timeout thread pool size (it should roughly corresponds to the rendering thread pool size). The entry is async.This method returns immediately.sapportals.prt. A component can use a special asynchronous response that provides some methods to include nodes asynchronously (asyncInclude method in interface IAsyncPortalComponentResponse). This API provides two features: Multithreaded rendering to speed up the rendering (managed by a thread pool) Timeout for components.MyClass"/> </component-config> <component-profile> <property name="timeout" value="2000"/> </component-profile> </component> </components> … It is also possible to supply a timeout value in the AsyncPortalComponentResponse constructor : Page 109 /113 .size and is also set to 100 by default. if the component takes too long to render (given a timeout value) 3 scenarios are possible: Either a valid cache content is available for the component. The default value is set to 100.timer. If the thread pool has no more threads available then the rendering will be done in the current thread.async).pool.xml … <components> <component name="MyComponent"> <component-config> <property name="ClassName" value="com. in that case this cache will be used and the component won’t be rendered. This value can be customized for each component in the profile using the property timeout.properties contains a special entry to configure the rendering thread pool size. the timeout feature is disabled for the component . in that case the component won’t be rendered and a timeout message can be displayed.response.core. This API is only available from the core (package com. Is there is no more threads available in the timer thread pool.Asynchronous Response API PRT provides an internal API to make the programming of gluer components more powerful. (async. Thus a method to wait for the end of all the nodes rendering has been implemented in the asynchronous portal component response (method waitForAllIncludesDone ()) The component can be notified (IAsyncResponseListener) when the content for the included node is available with the status of the inclusion of the node (See AsyncIncludeStatus) Configuring the thread pool size The file prtDefault. Either the component has an obsolete cache content available: in that case this obsolete cache content will be displayed but the component will be rendered as well and the cache will be updated with the new content outside the request cycle.properties (10000ms). Configuring the timeout The default timeout value for component is also defined in the prtDefault.portal. Example of a component declaring a timeout of 2 seconds in its portalapp. Either the component has no cache content.pool.sapportals.response.size).portal.

this) resp.public AsyncPortalComponentResponse (IPortalComponentRequest request. node 1 takes too long to render (timeout case) and has an obsolete cache. r). IPortalComponentResponse r) { IAsyncPortalComponentResponse resp= new AsyncPortalComponentResponse (req. long timeout) If this constructor is used the timeout cannot exceed this value even if the component has defined a longer timeout in its profile.waitForAllIncludesDone (). node 2 has no cache content and has enough time to finish its rendering node 3 has some valid cache content (does not need to rendered) public void doContent (IPortalComponentRequest req. … resp.asyncInclude (request. node1.writeToParentResponse () } Page 110 /113 . // Simply writes all the content to the parent response resp.asyncInclude (request.asyncInclude (request. IPortalComponentResponse parent. node3. this) resp. this) resp. Below a simple example : A component includes 3 nodes asynchronously and writes the content to the original response. node2.

asyncInclude (node3) Check for Node3 Cache Content: available and valid. resp) { getContent (). node2 and node3 Node2 : do nothing because the rendering is already finished Outside Request cycle Updated cache Content for node 1 Page 111 /113 . } doContent (req.Here is a schema that shows how the rendering is done throw the time: Time Main thread resp. launch a rendering thread resp.waitUntilAllIncludesDone () doContent (req. launch a rendering thread resp. resp) { getDatabaseValues ().asyncInclude (node1) Check for Node1 Cache Content: Not up to date.asyncInclude (node2) Check for Node2 Cache Content: Not available. } Thread 1 Thread 2 Regular Request cycle timeout node1 Returns to browser timeout node2 Node1 : Returns old CacheContent waitUntilAllIncludesDone () returns : Content is available for node1. return cache content resp.

96.0 UNIX/Windows Component Component Configuration Component Type Component Component Profile Component Type ConfigRootFolder Configuration Framework Content Abstraction Content Conversion Service Core Application D Deployment Deployment Hook Hot Deployment Local Deployment Deployment Descriptor Deployment Policy EP 5.M. PAR Deployment PAR File EP 5.0 ClassName Compatibility issues Backward compatibility EP 5.O.0 Directory structure E Exception Handling Exception Catalog Exception Files 73 76 75 79 24 88 16.Index A AbstractPortalComponent Alias API Asynchronous Response API Component Event API Dispatcher API Event API Portal Runtime API Application Configuration Application Dependencies Application Life Cycle Application Repository C Cache Central Configuration Storage Class loading Class Loading EP 5.0 PAR Flow PAR IDE PAR Upload Permissions Portal Application Portal Application archive Portal Component See Portal Object Model 77 14 56 77 53 77 83 9 See PAR File 11 58 35 98. 102 19. 66 65 97 59 9 12 86 109 41 26 40 11 16 24 23 23. 32 H Hook Deployment Hook Portal Hooks I InitialContext INode Internationalization IPortalComponent IService IServiceContext IStreamSource J JCO Client Service JNDI Class loading Initial Context JNDI Clients JNDI Packaging JNDI Provider Resource File JNDI Service Providers jndiprovider.properties JSP compilation Component Type L Locale Logger M Mode Component Mode Test Mode N Notification Service P P. 92 78 56 88 31 94 42 90 56 18 56 56 57 18 102 19 18. 100 81 101 61 42 43 43 43 44 42 43 102 103 102 43 34 80 11 12 12 94 79 37 Page 112 /113 .

xml See Deployment Descriptor PORTAL-INF 14 PrivateSharingReference 17 Property ClassLoaderPolicy 56 ClassName 18 ComponentType 102 DeploymentPolicy 56 PrivateSharingReference 17 SharingReference 16 PRT bridge 9 prtroot 97 R Request Cycle Resource Bundle Resources Non-Web Resources Web Resources revision number RFC Engine 34 80 14 14 78 63 S Safety Level SAP J2EE Security Zone Service Service Configuration Service Profile Servlet Component Type SharingReference SOAP T Tool LogViewer tools. 21 portalapp.jar U Upload URL parameter prtroot W WEB Services WSDL 46 47 77 97 75 103 83 9 83 22 22 96 16 48 Page 113 /113 .Portal Object Model 34 Portal Registry 30 Portal Service 12.

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->