Projects:Login Process Perfomance Improvements/Specs

Contents 1 Functional Requirements 2 Technical Specs 2.1 Menu Generation Speed Up 2.2 Quick Menus 2.3 Javascript Static Code 2.4 Merge Requests

Functional Requirements

The main functional goal of this project is to keep the log-in process of the backend working as usual, but with a better performance in terms of scalability thanks to the changes that will be introduced.

Technical Specs

A set of different sub-tasks will be applied along this project. All these sub-tasks together will bring a general improvement of the log-in process.

Menu Generation Speed Up

One of the most time consuming parts when requesting for the Application component is the generation of the Application Menu. For this reason, the code used to retrieve the available menu elements for a role will be improved as much as possible within the MenuManager class.

Quick Menus

Via the quick menus the user can quickly open application windows or create new documents.

A request is fired for each menu during the log-in process in order to create the Javascript datasource object:

 
OB.Datasource.create({
    createClassName: '',
    ID: '99B9CC42FDEA4CA7A4EE35BC49D61E0E',
    potentiallyShared: true,
    dataURL: '/erp_pi_pgsql/org.openbravo.service.datasource/99B9CC42FDEA4CA7A4EE35BC49D61E0E',
    requestProperties: {
        params: {
            _skinVersion: 'Default',
            _create: 'true',
            Constants_FIELDSEPARATOR: '$',
            _contextUrl: 'https://livebuilds.openbravo.com:443/erp_pi_pgsql',
            Constants_IDENTIFIER: '_identifier'
        }
    },
    fields: [{
        name: 'icon',
        type: '_id_10'
    }, {
        name: '_identifier',
        type: '_id_10'
    }, {
        name: 'id',
        type: '_id_10'
    }]
});

Besides, the first time that the user clicks on these menus, a datasource call is fired (with the object mentioned above) in order to retrieve the list of elements that can be launched from each one. However, this very same information can be retrieved from the data obtained with the menu generation.

Therefore, by keeping this information cached in the client, we will avoid the following requests:

• 2 requests for the generation of the datasource objects (during log-in process). These objects will be no longer needed.
• 2 datasource calls (the first time the user clicks on the menus)

With this solution, we can also safely delete the java classes in charge of the datasource calls: QuickCreateDataSource.java and QuickLaunchDataSource.java.

Javascript Static Code

Some parts of code being generated during a log-in with freemarker templates (layout, menus, navigation bar components...) which do not need to be generated dynamically will be moved to static code. This will help to reduce the time spent in subsequent log-in operations because static code will be cached by the browser.

Merge Requests

In order to improve the scalability of the log-in process, one of the objectives is to reduce the number of request done during this process. Thus, there is a set of requests which will be merged into just one:

• org.openbravo.butler.communitybranding/CommunityBranding.html: The Community Branding Widget performs a request to the MyOpenbravoActionHandler in order to retrieve the URL used to display the contents of the widget. That URL can be retrieved in a different manner: instead of performing that request, the URL can be retrieved as part of the data obtained with the request for the Application component.
• org.openbravo.client.kernel/OBCLKER_Kernel/ApplicationDynamic: generates the OB.User and OB.AccessibleEntities javascript objects.
• org.openbravo.client.kernel/OBUIAPP_MainLayout/Properties: generates the OB.Properties object containing all the preferences that applies to the current user/role.
• org.openbravo.client.kernel/OBUIAPP_MainLayout/Application: generates the layout, navigation bar and application menu contents.
• org.openbravo.client.kernel/OBMYOB_MyOpenbravo/MyOpenbravo: generates the Workspace.
• org.openbravo.client.kernel?_action=org.openbravo.client.application.HeartBeatPopupActionHandler: retrieves the kind of registration pop-up that must be shown (when applies).
• org.openbravo.client.kernel?command=data&_action=org.openbravo.client.application.navigationbarcomponents.UserInfoWidgetActionHandler: retrieves the context data used in the Profile navigation bar widget.

All of these requests are generating dynamic (session) data dependent of the user/role used to log-in. Since this project we will name the components used to generate this data as session dynamic resources. This kind of components will grouped and generated on each login by a new class called SessionDynamicResourceComponent.

Note: In order to avoid the Application request, the navigation bar elements are generated in a static way. In case a module adds a navigation bar element not generated in this new way (using the previous way), the Application request will be fired in order to ensure backwards compatibility.