Problem solve Get help with specific problems with your technologies, process and projects.

Client side scripting on Enterprise Portal

In principle, every computation can be implemented on server side for Web development.

In principle, every computation can be implemented on server side for Web development. But this results in a lot...

of round-trips with requests being sent to the server from the client side and then receiving the response. This results in lot of delays. Also, the client side processing power remains untouched with client being used only for rendering the Web pages. To remedy this, use client Side scripting. Client-side scripting allows you to create Web applications to compute data and communicate with each other locally. They also help reduce the network and server load. Enterprise Portal offers Client Framework Functionality. The framework supports lot of features like: 1) A common communication channel for JavaScript applications communicating on the client side, based on an eventing-mechanism. 2) A client side Java object, called the client data bag, which serves as a cross-iView storage mechanism for JavaScript and Java applet applications. 3) a module, called the Distributed Session Management (DSM), which enhances the performance of the server session management. The framework defines a Javascript object called EPCM (Enterprise Portal Client Manager). Each Framework functionality is accessible by a method of the EPCM-object, which is visible inside the portal page and in each isolated iView that is generated by the Portal Builder. An example for Client Side Eventing follows. Client Eventing allows iViews to exchange data with each other via an anonymous communication mechanism.The Eventing mechanism is realized as a multicast service, i.e. it defines an 1:n relationship between one sender (event producer) and multiple receivers (event consumer). Each iView which wants to receive information of a given type has to subscribe the corresponding event, by passing a function reference to the framework. An iView which wants to spread new data raises an appropriate event and passes a data object as an argument. The framework distributes this event to all iViews which are registered to this event regardless if the iView is embedded or isolated. Code for subscribing to events:

EPCM.subscribeEvent( nameSpace, eventName, eventHandler )

nameSpace : String the event name-space as an URN (i.e. the theme or scope of the event). 
eventName : String the event name (i.e. the name of the action or data which a iView is interested in), or '*' to subscribe for all events of this name-space. 
eventHandler : Function a function reference which points to the event handler. 
For example :
<SCRIPT language ="JavaScript">
function onWakeup( msg, eventObj ) {
 alert( "got a wakeup call from " + eventObj.data + ": " + msg );
}
   ...
 EPCM.subscribeEvent( "urn:com.sap:alarmClock", "morningCall", onWakeup );
   ... 
 EPCM.subscribeEvent( "urn:com.sap:alarmClock", "*", onWakeup );
<SCRIPT>

Code for Raising events
EPCM.raiseEvent( nameSpace, eventName, dataObject )

nameSpace : String the event name-space as an URN (i.e. the theme or scope of the event). 
eventName : String the event name (i.e. the name of the action or data which a iView is interested in). 
dataObject : Object a data object (String, Number, Boolean or Object) with information describing the event. 
sourceId : String (optional) the component id of the event source (i.e. the id defined during design-time) or null if the parameter is omitted. 

For example:
<SCRIPT language ="JavaScript">
   ...
 EPCM.raiseEvent( "urn:com.sap:alarmClock", "morningCall", "Good morning ladies and gentlemen", "MorningAlarm" );
   ... 
<SCRIPT>
So whenever the event "morningCall" is raised in the above example, a windows pop-up message is shown.

The enterprise Portal also offers other features. For more details please refer to Portals Development Kit Documentation.

The Portal should run on several platforms and browsers. However the Client Framework implementation has to take into account that the JavaScript and Java engines differ from browser to browser and browser version to browser version. There are several adoptions of the Framework script-include-file one for each kind of JavaScript/Java engine. To avoid the development of redundant sources, common parts of the Framework source which are the same for all or some browsers are kept in one file and only those parts which differ along the several script engines are tagged in the source files and filtered during the build. The portal page includes only one script file depending on the browser type and version. The portal builder runtime decides, which include to take, when the portal page is generated.


This was last published in April 2003

Dig Deeper on SAP NetWeaver Enterprise Portal

Start the conversation

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

-ADS BY GOOGLE

SearchERP

SearchOracle

SearchDataManagement

SearchAWS

SearchBusinessAnalytics

SearchCRM

SearchContentManagement

SearchHRSoftware

Close