AribaWeb 101: Intro into Session Management

After a short break and really busy time I have decided to put together this quick article which tries to put some light into the Session Management and maybe little about the authentication process within AribaWeb. 

We will start with this simplified object collaboration diagram that captures the request/response process.

**The rectangles represent various objects, which are involved in the communication and the lines between these rectangles represent the relationships (association, composition, dependencies or inheritance) between them. Messages are shown as a labeled arrow that indicated direction of the message. 

Request / Response process - Simplified collaboration diagram 

On the picture above the AWDispatcherServlet dispatches the request depending if it's Direct or Component action into AWRequestHandler impl. class. It then continues down to the AWPage. I think the most interesting part is in the AWRequestContext class which is in the middle of this process where: 

• It initiates the checks for request as well as the session 
• Here is the place where your security starts because it calls validation methods from your AWComponent and SessionHandler where you can decide if your session is valid. If you decide that is not valid you can kick user back to your defined login page (showLoginPage() method) 
• We can also say that from this context AW starts the execution of all three phases (applyValues, invokeAction, renderResponse) even the code itself is inside the AWRequestHandler. 

Let's check out some example. 

We will continue from my last example where I showed you how to layout your application and do not rely on the flat project structure. So this is my project.

Project structure

I think the explanation for this layout was already written in my previous articles. But lets focus for now on the WebApplication class that registers custom session validator. 

I usually register the session validation logic inside my application (the subclass of the AWServletApplication) just like on the picture bellow. In this case we have SessionHandler called MyLoginSessionhandler.

There are three empty methods for which you should provide your own implementation. The first method requireSessionValidationForAllComponents() turns on/off your validation logic and in this step we are telling the AW that we do not want to validate a session therefore we always jump directly into the app homepage.

LoginPage

What if we want to implement some authentication and have custom login page to be shown if the user is not properly authenticated. It's pretty simple to do because if you remember the diagram on the top we are going to attach our functionality to the process that is invoked by AWRequestContext in the handleRequest() method. And this functionality is going to be enabled inside our MyLoginSessionHandler and our LoginPage. 

First thing to do is to enable the validation for the components with the requireSessionValidationForAllComponentActions() method and then return the LoginPage for the invalid session. In this case we modified the code the step above (see pic. bellow) and now we always show the LoginPage because the method validateSession() returns false.

Our LoginPage component should also override the shouldValidateSession() method to turn off the validation completely for this LoginPage.

This all cannot really work without storing user specific information into session. This is usually done inside the AWSession that wraps the http session. This is perfect place to store current user or his/her username or anything you do not want to load every time user clicks on the button.

And the login() method logic can look like this:

• It resets the Navigation Bar state 
• Initialize the session 
• Redirect the request back to the homepage

Once we have this code in place we can modify the SessionHandler to use our new session class. As you can see this is our third modification of this class and now with proper code.

Logoff

Logoff action is going to be really simple. When we decided to use the AWSession we must also follow its rule how the session is closed. For this reason AWSession has method terminate() which does not destroy the session immediately but at the end of the cycle but also  does clean up many things. 

Note: Please never call invalidate() on the HttpSession. The reason is simple while  AW   is trying to render the page it is still using the session and trying to read some stored information from it and when you do invalidate it's gone and your app fail to render the page. 


Other areas to investigate:

Please see this as a pure introduction and if you are serious about the authentication you want to check out how the AWLocalLoginSessionHandler.CompletionCallback works. You will find out that at the end there is something called AWFormRedirect which is also used allot when you are using direct actions.
 

Source code from this article on the request: frantisek@kolar.pro

AribaWeb 101: The Setup (Part 2)

In Part 1 I covered all you need to know in order to setup and run the AW application using standard AW tools. Now we will go to the next step that is setting up AW project completely inside your IDE without including any AW tools.

The reasons you might want to do this are:

• It's fun & useful to figure out how get "under the covers" of how AribaWeb is deployed, especially if you're using AW in a larger project
• Speed: you can squeeze the turnaround-time some if you unbundle the ANT deployment scripts -- useful when you're doing a lot of restarts of the app server during intense development
• You may want to change the defaults on what goes where in the folder structure
• Hey, maybe you want to "gradle-ize" your AW installation?

Read on to find out the details!

First time setup and Project Layout

The first thing we will start with is the layout of the project. I think you do not want to have everything in one directory but you want to have layout that gives you flexibility on where you put resources, java files, test files and others.

When I said that we would work with the IDE I meant IntelliJ IDEA but I think eclipse users can do something similar as well. The first setup is manual but once it’s done you will appreciate the speed.

Create New java project

I expect that you are already IntelliJ IDEA user because I am skipping some of the steps here. This article is not guide how to use this IDE rather how to develop AW application in this IDE.

Select that you want to create new project from the scratch:

Initial Setup

Once your project is created this should be your initial setup:

Simple project created - nothing else

And now lets get back to the layout. As you know each real project has it’s own specific structure that lets you well organize your resources. In IDEA please create following layout:

Initial setup

This is something we can start with. No more one-directory layout but structured project that is divided into two areas main and test. I think the names describe themselves. 

Directory	Description
ariba	Here I put all the ariba resources directories where the locales are stores. The reason for this is that you need to be able to work with these files maybe change or fix translations or even extend it (override it). You do not want dig all this inside jar files and all the time rebuilding the AW distribution. This is something, which needs to be available.
config	This directory plays two roles: Place to put all your application settings . Extension directory. AW is great at branding and extending and there is already build-in behavior that lets you override what is inside ariba directory. E.g. If you have under ariba resources some localization csv file and you want to change some translated value you simply place the file with the same structure under config directory and AW takes your modifies version instead of the one which came with AW the distribution
java	Here are your java files.
webapp	Into web app I put web.xml

This simple layout lets you organize your files well. Since AW relies on specific structure as I already mentioned in Part 1 so the next thing you need to do is to extend AWServletApplication and specify where to look for files. 

But before we do some programming we need to add some libraries into the project so AW classes are recognized.

Adding AW library. I already created global library so I do not have to do this for every single project

You can add individual files or create global library from $AW_HOME/lib

Finish the awl application

Let’s create several java files that are needed for this setup.

First thing to do: extend the servlet and AW application

FILE	Description
MainDispatcherServlet	This is your custom servlet file that returns reference into your custom application.
WebApplication	This is the heart of your application. Here we need register our custom directory structure so the RapidTurnaround works even for this setup. Also we are overriding method to retrieve application name. Now the URL will be: http://<host>:8080/example/Main instead of /example/AribaWeb
java	Here are your java files.
webapp	Into web app I put web.xml that refers to our custom servlet.
docroot	This is directory containing your static web resources. Here you have your css files and branding images if you need to.  The only thing you need to do is to take already assembled docroot directory from one of the examples. This is one time operation.

After little coding we have created little project, which looks like this:

IDE Project pane showing created files as well as how files are organized

Create Artifact

Now it is time to create thing called artifact. Basically we tell the IDE how to build and pack the application for our development purposes. Artifacts are created inside your IDEA project settings.

We are starting with directory structure:

Selecting exploded web app

Once you are done the artifact might look like this:

Final directory structure for the deployment 

Do not forget to update your resource patterns for compiler. Otherwise your .oss or .awl file would not be moved to the output directory.

IDE settings where we have extra extensions needed by AW

Tomcat Setup

The only thing that is left is to setup Tomcat application runner, which needs know what artifact to use, and we are done.

Selecting tomcat configuration: Local

Here is the tomcat configuration:

Select that artifact + what context path should be applied for this webapp

We can also enable RapidTurnaround by adding ARIBA_AW_SEARCH_PATH variable.

Setting up Tomcat with extra env. variables. 

Run and Debug

Now the final run or debug.

Once we have everything configured we can simply click on Run/Debug just in any java application

Using AW tools you are able to run your application as external process and then you used remote debugger to connect to the application. 

In this method (Without AW tools) you are running IDEA tomcat process, which is all built-in and what is more important you have full control over the application now.

Idea out window

Do not be mistaken I still use build scripts (we are using currently grandle) that manages the process for the continuous integration server but for the development it is only IDE. 

In this article I tried to show you different ways how you can structure and develop your real AW application where the key points are: 

• Full control over the application not the other way. 
• You need to know all the magic behind. Not rely on high-level tool. 
• Directory layout for real application. 
• You need to understand if you rely on the ant script you always run the full cycle (clean, compile, build, war, start, etc…) and if you have really large application this can be time consuming. In my case you really focus on the development because you do not have to wait if you changed something for the whole build cycle in order to startup the application again. 
• If you look at the project you can see one file called pom.xml, which I use as a library loader and checker. You do not have to use maven only for building project. In Idea you can use maven to monitor dependencies between your libraries and it can also automatically update your project settings with jars from the pom.xml.

Other areas to investigate:

Once again to finish up this article here are some points that you can check out in order to extends the capabilities of this project. 

AWConcreteServerApplication. registerResourceDirectories():
This one is responsible for scanning all of your directories and jar files and registering all your resources.  

JRebel: 

If you want to really speed up the development process you can integrate JRebel. This little tool let you do hotswap even on classes where you add or remove methods or properties and even more. 

ResourceService. getStringsForLocale(): 

We created ariba and config directory for specific reason that is to support extension of the application and branding. When you check out this method you will better understand how AW lookups its resources. 

Also try to understand how the AW is initialized, how are jar files scanned, from where all files are loaded, how ant build scripts assembles the docroot directly.


When I mentioned that I am using the grandle please have look how such build file might look like to  compile & build whole AW project:

build.grandle example