Ajax framework explained in detail

Ajax framework or commonly called as AFP is one the most discussed features NW 7.0 Ehp and more as a part of NW Portal 7.3 release. Though tons of presentations, articles and Wiki are published on AFP, I still felt a need for something written in simpler terms and easy to understand. Something that can be understood in the first reading itself. Having said this, it pretty much clears the motive of this post.

First of all, let us talk about what are the building blocks of Ajax Framework, henceforth referred as AF. Before we move in details of AF, I’d like to mention here that AF is not just about Ajax calls and APIs. It’s just one part of the structure and believe me, there is a lot more than Ajax calls.

AF is divided into 5 system or functional blocks and are as follows. Please note the sequence which starts from the front-end and drills down to the service providers. I will explain each one of them in detail later in this post.

Signature design or in simpler terms, portal screens and UI

AF core composed of Controller, Model & Service

Delegation box composed of Navigation Servlet and action handlers

Service delegation EJB aka Navigation EJB

Core Service responsible for providing navigation service

PS: Delegation box & service are not std. terms. They are devised from the context of their function.

In addition to these 5 boxes, there are data exchange formats like JSON and Ajax JS & EJB APIs used as well.  

Signature Design:

Signature design is also a theme provided by SAP and this may vaguely refers to presentation layer. This layer consumes services provided by underlying layers and data suppliers. This is where client side configurations like caching the navigation paths of the user are stored. This layer interacts with immediate underlying AF Core layer via JavaScript APIs which are responsible for making the Ajax calls.

PS: I would like to bring your attention to one interesting point here. Though we can make Ajax calls using JavaScript but there’s a glitch in the way browsers react to Ajax requests.

Different browsers react differently to Ajax requests. For example, IE always caches all the Ajax requests. Caching Ajax could be considered a bug because the main purpose of Ajax is to update content dynamically. You’d never want Ajax requests to be cached. This is where jQuery comes to rescue. Writing a simple function can tell the browser not to cache Ajax calls. You can accomplish this simply by writing the following code into your portal component.

 $.ajaxSetup ({cache: false});

AF Core:

Moving to the next functional box of the AF, the Core of AF is composed of three components.

Controller - Responsible for the navigation process & enables hook to navigation using registerOnNavigate(func) method. 

Model - Responsible for providing data (services and APIs) to the presentation layer.

Services - Responsible for providing std. services such as logoff, navigate etc

In addition to above three components, there are action handlers as well which are favourites and search centric.

This layer provides a JavaScript library to interact with lower layers and provides an interaction between presentation and data supplier ( Navigation Service) layer. This interaction is done by exchange of data using JSON (JavaScript Object Navigation) data exchange format. However, explaining JSON is out of the context of this post. 

LSAPI – L-Shape API - an API responsible for interacting with the Ajax contents. This renders a separate iFrame which holds Ajax contents.

Whatever we discussed until now is part of Client side of AF. Now let us see the server side of AF.

Delegation Box:

This functional box is composed of a servlet that handles navigation service and action handlers. Navigation servlet delegates the data provided by navigation EJB to the AF Core, which is the immediate upper layer of delegation box. AF core then further delegates this data to the presentation layer for rendering and then LSAPI finally hold this data in an iFrame.

Connection to this servlet is done by making Ajax calls. Navigation servlet also provides methods for fetching the navigation data. GetSubTree & GetSelectedPath are some of these methods that would be used to formulate the navigation hierarchy.

It is worth mentioning here that this navigation hierarchy is cached at the client side so that for the repetitive calls to the navigation are served from cache instead of calling navigation services again. This is a major plus of AF.

Service delegation (Navigation EJB):

This EJB encapsulates portal navigation service and provides the navigation hierarchy for the further delegation. This EJB is exposed as a web-service. Interaction between navigation EJB and the immediate upper layer which is delegation box, is done via EJB APIs.

Core Service (Navigation service):

This is the core of the server side of the AF. This is responsible for providing the navigation service and one entry point to the entire navigation data. It provides basic navigation services and a helper service which provides extended navigation data.

Before we close this post, there are yet a few points which are worth mentioning.

AF is a stateful framework. In simpler terms this means that AF remembers the navigational paths and states of the user. This makes navigation easier and faster.

Also because of the Ajax APIs are used for the interaction, there is no need for clearing the browser cache manually. For instance, while making change in the theme, if the change is not reflected, we always used to clear the browser cache. However, AF has done away with this manual clearance of the cache. Every time when content is changed or user’s navigation hierarchy is changed, browser cache is cleared automatically.

I hope this post will be able to clearify AF architecture at least to some extent. If you have any thoughts on this, please feel free to comment below.