Forcing browsers to clear cache

When updating Production environments, there is usually an issue with browser cache. Some styles (css) are modified and you need to manually clear cache in your browser to check the result. This is fine for developers, but what about users? Are you going to tell all the users of a public website to manually clear browser cache?

This problem could be solved by disabling caching of the pages, in the page header or even in the template header, the following line can be added and browsers would not cache anything:

<META HTTP-EQUIV="CACHE-CONTROL" CONTENT="NO-CACHE">

However, an Oracle WebCenter application, as many others nowadays, relies heavily on cache to speed up loading processes, so this approach does not seem to be the best one.

My recommendation is to add a version parameter to the css file reference. Navigate to the place where the css include is located, usually in the page template, and add the following text: ?ver=1.1 The version value could be any of your choice.

For instance, in the WebCenter template file, the following line would force the client browsers to clear cache with the new modifications:

   <af:resource type="css" source="/../shared/css/portal/main.css?ver=1.1"/>

Next time the page is loaded in browser, it will load a new version of the style classes. This may checked using Firebug.



The best part is that you will not need to update the name of the css files, just ensure that include statements are updated when css are changed: 1.1, 1.2, 1.3, etc. It could also be applied to javascript files.

References

htaccess - How to force the client's browser to clear the cache?

Force browser to clear cache

Oracle Access Manager Error page customised

WebCenter Portal is usually integrated with Oracle Access Manager (OAM) to manage its authentication. This integration has several advantages such as enabling Single Sign On (SSO) across all Oracle products, but it may cause some problems to end users.

Issue

Recently, a client with a private users area received complaints regarding an unexpected error page been displayed in Portal. Even a user tweeted that page tagging the company, so the problem was considered critical to the top management. The page was the following standard unfriendly OAM error page:

The URL was: /oam/server/auth_cred_submit.

Firstly, we tried to reproduce the issue, which was not easy because users did not remember the actions they performed. After some testing, the issue was reproduced:

1. Access protected URL.
2. Portal application login page is displayed.
3. Introduce valid credentials.
4. Portal home page is accessed.
5. Click browser Back button.
6. OAM error page appears.

We tried to map that URL (auth_cred_submit) as an error by web server configuration, but that was not a solution because it was actually the URL that performs login too.

The explanation of this error is:

• The login page submits the "request_id" or the "OAM_REQ" value sent by OAM when redirecting to the external login page. 
• When user introduces credentials and click login, a value for request_id is set into the HTTP Header.
• The back button does not reset the values already set via cookie or Header information into the browser. 
• The second time "auth_cred_submit" is accessed, the values from the previous login are sent to the server, which interprets them as invalid because are from a different session. 

So Oracle Support was contacted about this problem. If that page could not be avoided, at least we wanted to have it customised.

Solution

 

Apparently, that OAM page cannot be customised, but the engineer managed to reproduce the issue and built an effective workaround. It involves deploying a custom pages application in OAM application server.

1. Copy oamcustompages.war file in a local machine. This file is located in the following path: $IDM_HOME/oam/server/tools/custompages/
2. Unpack this war file.
3. Navigate to the "pages" folder inside the uncompressed war and create a page named: Error.html. That page would contain the HTML code to be displayed in the reproduced scenario, so it should include the cient look&feel.
4. Other pages in that folder may be deleted.
5. Compress the folders back to oamcustompages.war. Then rename that file, i.e. oamcustompages1.war.
6. Deploy the war in the application server where OAM is running. For information about deploying an application to WebLogic Server, check this link.
7. OAM Custom Pages must be updated using WLST:
   7.1 Start WebLogic Scripting Tool (WLST) in OAM Oracle home, located under the installation folder: /Oracle_IDM1/common/bin).
   
   7.2. Connect to the Weblogic AdminServer as the Weblogic Administration User.
   For instance:
   wls:/offline> connect();
   Please enter your username [weblogic] :weblogic
   Please enter your password [welcome1] :Oracle
   Please enter your server URL [t3://localhost:7001] :t3://oamadminserver.oracle.com:7001
   
   7.3. Execute the following WLST command:
   updateCustomPages(pageExtension ="html", context="/oamcustompages1");
   
   Where context is the name assigned to the war file in step 5.
   You should receive the following message: "Custom page configuration updated successfully"
   
   8. Test the scenario. A new error message should be displayed, defined in Error.html file.

This solution works perfectly for our scenario, but we also wanted to avoid displaying an error page to the final users. So Error.html was modified to add a javascript redirect to OAM logout page:

<meta http-equiv="refresh" content="0;url=/../oam/server/logout?end_url=/myApp">

As this content is in the page header, as soon as it starts loading, user is redirected to logout page, where session cookie (OAMAuthnCookie_) is removed. Eventually, the login page is displayed to the user, this is specified by the URL parameter end_url. So customers would not even see the error page.

References

Oracle Service Request: SR 3-10186096271 : OAM how to avoid auth_cred_submit page to be displayed to users
Installing and Configuring OAM with WebCenter Portal
Benefits of Oracle Access Manager
Deploying Applications to WebLogic Server
WebLogic Scripting Tool Command Reference 
Enabling Error Page Customization
Using meta refresh to create an instant client-side redirect
Configuring Centralized Logout for OAM 11g

Forcing maintenance page in WebCenter

When a WebCenter environment requires a shutdown or a restart, it is advisable to present a friendly error page instead of the traditional "Failure of server Apache bridge". This can be easily achieved by implementing a static html page and configuring OHS. This can be applied to other applications too.

The maintenance page could have a html structure similar to the web template, or it could just be an image with a friendly message. For example, maintenance.html could be defined as follows:

<!doctype html>

<html>

<head>

<meta charset="utf-8">

<meta http-equiv="X-UA-Compatible" content="IE=edge">

</head>

<body>

    <div>

        <img src="/Static/ClientPages/img/Maintenance.jpg">                   

    </div>   

</body>

</html>

Once page is uploaded to the server, some code must be inserted inside the OHS virtual host element in the configuration file (mod_wl_ohs.conf). For instance, the following code redirect all the OHS requests to the plain maintenance page.

RewriteEngine On

RewriteCond %{SCRIPT_FILENAME} !/Static/ClientPages/*

RewriteRule ^.*$ /Static/ClientPages/maintenance.html [R=503,L]

Header Set Cache-Control "max-age=0, no-store"

After that, OHS instance needs to be restarted using the opmnctl command.

Also, it is interesting to set error pages to different HTTP status codes. The following lines force the display of error and maintenance pages depending on the type of errror: Internal server error (500) or Service unavailable (503).

ErrorDocument 500 /Static/ClientPages/error.html

ErrorDocument 503 /Static/ClientPages/maintenance.html

Other options are:

• IP exceptions: It is possible to set IP exceptions to the redirect operation, that could be developers' addresses.

           RewriteCond %{REMOTE_ADDR} !^123\.456\.789\.000

• Checking first if the maintenance page exists.

           RewriteCond /Static/ClientPages/maintenance.html -f

• External switch to enable and disable maintenance: OHS redirects to maintenance pages if a file exists.

           RewriteCond /Static/ClientPages/maintenance.enable -f

These options are well explained in this post.

References:

Redirect Site to Maintenance Page using Apache and HTAccess
Setting a WebCenter Maintenance Page
HTTP status codes
Apache mod_rewrite

Agile Development applied to projects in my company and adaptation to distributed teams

 Introduction 

Agile is a set of methodologies for Software development that was first published in 2001 by Agile manifesto. Since then, it has experienced a huge success and Agile adopters are increasing relentlessly, even becoming mainstream.  Also, Agile philosophy has expanded to other industries, one of the best Agile examples is Zara, the Spanish clothing company. 

The core values of Agile are in the Agilemanifesto, which may be explained as:

• Development and Business teams close collaboration.
• Importance of direct onsite communication.
• Short period deliveries of functionalities.
• Flexibility with updates in customer requirements.

Basically, Agile methodologies seek the rapid adaptation to changes with a high standard of quality and reduced costs, removing any unnecessary processes, such as excessive documentation.

Scrum Methodology 

Currently, VASS is successfully running a project using one of the most famous methodologies of Agile: Scrum.

Scrum is a very flexible methodology of Agile, indicated for high changeability projects and is characterised by the split in iterations called sprints.

Figure 1: The sprint-driven Scrum project flow (Schuh 2004)

Sprint time is usually set to two weeks, so twice a month the client receives a new release of functionalities. Apart from the daily scrum meeting to monitor progress, Scrum has five milestones:

1.                             Product backlog: list of all functionalities to be implemented. The IT team provide the estimated effort to complete them based on the information provided. 

2.                             Sprint plan: In the beginning of the sprint, the client defines the functionalities of the sprint, which are chosen from the product backlog.

3.                             Refining or grooming: Two days before the release date, a meeting is held to discuss cancelled and new functionalities included in the current sprint.

4.                             Retrospective: A day after refining, the whole team meets to talk about pluses (positive points) and deltas (points to improve). An action plan is implemented to fight most important deltas.

5.                             Demo: The last day of the sprint, a demonstration is made to the client, showing all the requirements of the sprint working. The whole IT team attends this meeting too.

Agile Key Factor

Agile practitioners need to fight resistance to changes and distrust for new methods, also results usually take some time to be positive. Without strong commitment and support from the management tier, those issues would provoke a failure. So the key to success in Agile projects is: Support from top management.
VersionOne survey shows most of Agile professionals believe the main problems for Agile adoption are related to management support too. 

 Agile Benefits and Drawbacks

The most important advantages of Agile are:

• Flexibility
• Client gets directly involved in the project    
• IT team acquires business point of view
• The team gets full functional and technical knowledge of the implementation
• Iterative validation to manage expectations and provide frequent feedback
• Daily meetings and team estimations build a higher commitment in the team 
• Dependencies on particular individuals are removed

As the most important disadvantages:

• Management of change gets more difficult in fixed price contracts due to continuous requirement changes
• Longer inoperative time of the team, having a lower reaction time
• Forecasts deviation occurs frequently as they are estimated by an independent team
• Dependencies from non-Agile projects
• When deadlines are in place, the Project is quite difficult to manage 

  Agile Limitations

Some authors highlight the limitations of Agile regarding the type of project, especially when dealing with fixed cost contracts, critical functionalities and distributed teams. In the following table Agile characteristics are compiled. Most of Agile projects has some non-Agile characteristics, however, the more they have the more difficult to manage.

  

Figure 2: Agile and Non-Agile project characteristics (Schuh 2004)

Challenges in Agile Distributed Teams

Looking at the reasons for adopting Agile, the IT teams in this survey usually point out to the acceleration of product delivery and the ease to manage changes, but the enhanced management of distributed teams is the last one. Therefore, most of the companies consider little benefit from applying Agile methodologies to distributed teams. Moreover, according to Agile principles, face-to-face communication is crucial, and some authors consider offshore Agile development as a near impossible task.

The following figure shows the problems of distributed Agile categorised by: communication challenges, lack of control and lack of trust.

 Figure 3: Agile challenges with distributed development (Ramesh et al. 2006).  

    Despite all those challenges, there are some good success stories with offshore Agile, such as:

•      The Nokia Siemens Networks experience (Korhonen 2012), which measured an increase in motivation, visibility and product quality over a period of twelve months.
•     The SirsiDynix distributed scrum (Sutherland et al. 2007), it was a distributed Agile project where productivity was greatly improved, compared to the traditional waterfall approach and even to collocated scrum.  

Changes in Agile Distributed Teams

As Agile is all about flexibility, project managers should be able to take the Agile principles that best fit with remote teams, avoiding others that bring no benefit. Companies have adapted Agile to face distributed challenges by implementing the following practices:

1.     Requirement and design iterations: In Agile projects, requirements are usually flexible and the design is not defined in detail. In remote projects it is recommended to assign the first iterations to close the critical functionalities and develop the architecture. Also, the requirements should be documented, instead of relying completely in informal communications.
2.     Postpone critical functionalities: Instead of tackling the critical requirements in the early stages of development, distributed teams should work first with the well-known functionalities. This way the team gains confidence adapts quicker to the new project methodology despite the distance. This approach contradicts Agile principle of delivering best value to client as soon as possible.
3.     Flexible time-boxed iterations: It is useful to be flexible with the iteration time, because sometimes developers could need more time to clarify doubts and define the solution.
4.     More formal communication and coordination: To avoid misunderstandings, companies can define a role in each location who is responsible of communication between the teams. Also, project management roles gain importance for coordinating the different locations.
5.     Using online communication tools: As face to face communication is not possible, companies need to rely in applications to improve collaboration and communication, as Oracle WebCenter. There are even tools specially designed for Agile projects such as VersionOne. These tools should contribute to build a cohesive group.
6.     Visits: In order to build trust, it is strongly recommended to plan face-to-face interactions between members of different locations. These visits would not just apply to development teams, they would include customer staff too. Despite the cost of traveling, these interactions are crucial to build trust in distributed teams and make everybody feel they are part of the same team, especially in the beginning of the project.
7.     Informality under control: To reassure informal communications, documentation is required in critical functionalities, even though it is usually delivered after it is implemented. Added to this, the QA team must check the quality standards of the different locations.
8.     Team optimisation: The size of a standard Agile team is recommended to be under 50 members. However, for distributed teams, the limit is usually set to 15. Regarding team mix, it is important to use a decentralised model, where different roles are distributed in different locations, having a multi-directional information flow.
9.     Practices optimisation: As a general rule, each Agile practice should be analysed and if it is not useful to the team, it should be removed.

Figure 4: Mapping between Agile Distributed Development challenges and practices that address them (Ramesh et al. 2006) 

Conclusions

Despite some criticism, Agile development is widely used in the IT industry. Many companies are introducing this concept to gain more flexibility in their projects, so it is important to understand the values of Agile, which are usually misunderstood. It is also crucial to learn the limitations of this concept and the scenarios where the use of Agile would not be recommended.

Although Agile was not conceived for distributed teams, in recent times there are good examples of successful implementations using Agile with both onshore and offshore members. The key resides in adapting Agile flexible practices to a scenario where face-to-face communication is not possible, without losing their core benefits. In order to help managers with this difficult task, this document compiles specific recommendations based on real-world projects that could support a successful offshore Agile implementation.
 

 References

Agilemanifesto

Korhonen, K. 2013, "Evaluating the impact of an agile transformation: a longitudinal case study in a distributed context", Software Quality Journal, vol. 21, no. 4, pp. 599-624.  

Ramesh, B., Cao, L., Kannan, M. & Xu, P. (2006), "Can distributed software development be agile?", Association for Computing Machinery.Communications of the ACM, vol. 49, no. 10, pp. 41. 

Oracle WebCenter

Schuh (2004), Integrating Agile Development in the Real World, Charles River Media, Hingham, MA, USA.  

Sutherland J., Viktorov A., Blount K., Puntikov N. (2007), Distributed Scrum: Agile Project Management with Outsourced Development Teams, IEEE.

VASS

VersionOne 9th annual state of Agile Survey  

VersionOne website