EPCF Levels

EPCF Service

To reduce the server/client events, following functions can be performed on the Web client:

Enhance the user interface on the Web client with context sensitive entry helpers.

Validate user input (for example, only numbers are valid in an input field) on the Web client increases the usability and the overall response time.

The HTML Business for Java (HTMLB) includes functionality to perform these tasks also.

 

Whenever a Portal application uses more than one iView the EPCF service has to be used to exchange events and data between the iViews.

 

EPCF Levels

The level influences the amount of HTML data is generated, that is finally sent to the Web client. A higher level generates also more HTML data. The EPCF supports three levels.

Level 0: no EPCF

This level generates no JavaScript or Java applet framework functions. Communication between iViews is not possible.

Level 1: JavaScript

This level generates framework functions for JavaScript.

Level 2: JavaScript and applet

This level generates framework functions for JavaScript  and Java applet.

 

EPCF Functions

 

 

 

Notes: 1* : Additional, a pure Javascript based implementation is available since Enterprise Portal version 5.0.1.3.

 

Enterprise Portal Client Framework - Features

The Client Framework has some built-in features which are automatically enabled by the framework or used by the EPCF implementation. There is no API for these features they are used implicitly.

 

Automatic browser support

The implementation of the Enterprise Portal Client Framework takes care of the usual web application variables:

Different browser implementations

Different browser versions

Different portal page structures (frameset hierarchies)

The Client Framework implementation adjusts the differing browser implementations of JavaScript and Java Applet Engines. Therefore different implementations of the EPCM for different user agents and JVMs are available.

 

The JavaScript Origin policy

controls the access to the Document Object Model between different frames. Scripting between 2 frames must be only allowed if both frame sources originate from the same top level domain. Examples:

 

The EPCF automatically relaxes the document domains to top level.

 

Distributed EPCM implementation

IViews can access the EPCM object from every Enterprise Portal page or frame. Every iView of the portal runtime includes the EPCM .Hence every embedded or isolated iView can use the framework in the same way:

EPCM.subscribeEvent( nameSpace, eventName, eventHandler );

Each EPCM object dispatches method calls automatically to the adjacent EPCM objects in case they these calls are targeted at other IFRAME s.

The client Java classes are realized as Singletons , so each class has only a single instance in each portal session, regardless if frames are reloaded or not. The applet object is instantiated inside each portal page frame, but this causes only minimal overhead, since the applet serves only as a class factory for the Singletons . The Java Virtual Machine (JVM) is started only once during a browser session (i.e. during the lifetime of the browser process). Class files which are used inside the JVM are loaded only once and this holds also for the jar files containing the Java bytecode.

 

Automatic Server Session Termination

The Internet protocoll HTTP is connectionless. However typical businnes applications provide information about the user session.

The Enterprise Portal session management controls session state in application via SAP Internet Session Protocol (SISP). It avoids locks/deadlocks and also releases objects in case the user leaves an application, closes the browser or logs off from the computer. This functionality uses the same SAP Internet Session Protocol which was introduced with Workplace 2.10 and 2.11.

The Enterprise Portal delivery contains 2 implementations that differ in the kind of communication between client and server. The proper implementation is selected automatically depending on the browser capabilities and the used framework level.

The Automatic Server Session Termination functionality is available with EPCF level 1.

The Client Framework API

The Client Framework API exposes its functions as methods of a 'global' JavaScript object called EPCM .

Public methods are invoked in the following way:

EPCM.[API_method_name]( [Params]* );

The Client Framework API consist of three parts:

The System API, which provides methods to retrieve the version and level of the framework and other stuff.

The Client Eventing API , which allows iViews to communicate with each other and with the portal environment itself in the client user agent. This can be done using client-side JavaScript functions which are invoked upon browser events like onload , onclick , etc. The implementation of this feature is JavaScript and therefore available with EPCF level 1.

And the Client Data Bag API , which allows iViews to store data during the Portal session (i.e. as long as the user is logged on to the Portal). IViews can store each JavaScript type and retrieve them even after the iView or the whole portal page is reloaded. There are two available implementations that differ by storage mechanism:

JavaScript only (EPCF level 1) - values are stored as cookies in the browser

Java Applet (EPCF level 2) - values are stored as a Java class attribute

The proper mechanism is automatically selected depending on the browser capabilities and the used framework level.

The Client Data Bag is available with level 1.

 

Additional Remarks

Performance

JavaScript is much slower than Java or C++, but this poses not a performance drawback. The framework does neither do complex computations on large data structures nor allocates a lot of memory, so the user won't notice delays caused by the script functions.

Data Protection and Security

All browsers support the JavaScript Origin policy , so foreign web sites are unable to retrieve data from the Portal Page or the iViews . An analog origin policy is also relevant for the JVM . Classes/objects can only interact with classes/objects which are loaded from the same location. Therefore it is impossible for a foreign applet to access the data inside the Client Data Bag or use the Client Data Channel .

Portability

The development of the Client Framework takes into account that the browsers have different JavaScript versions running. The Java applet (which is necessary for Framework level 2) uses only JRE 1.1 functionality.