Understanding RDC Page Turn times and caching

At this year's OCUG, I have heard a few discussions about RDC Page Turn times and how opening the "first page" takes a bit longer than opening subsequent pages. While it is true that page opening time profile varies (based on the state of the cache, among several other factors), strictly speaking, generic notion that opening the 'first page' takes longer is not technically correct and I feel the term 'first page' is used ambiguously in discussions.

Also at OCUG, Hauke Kindler had a good session where he presented a nicely co-related results of page opening times and bandwidth consumption under different conditions. Following clarifications here should throw more light on the data he presented and help understand RDC performance profile better.

Besides several other techniques, RDC 4.5.3 uses caching at various levels to improve overall performance and particularly to improve the page turn times. It's caching strategy is distributed across several application tiers. On the middle-tier, caching is leveraged at various application components such as: Oracle WebCache Server (at the very front of the request), Web server and the Application Serer. Typically, these mid-tier servers cache configuration is a one time activity which should be taken care by the RDC system administrators following product installtion.

On the other hand, Client tier caching in the end user's browser can have significant impact on the overall page turn experience and here is why.

The "very first time", when a new user (a user who never logged into RDC app before) accesses the RDC application, RDC app downloads a bunch of static files (like images, icons, templates, CSS files etc.,) and a compacted AJAX library file. If the browser cache is configured correctly, this will be a one time only deal and these files will never be downloaded again (unless they have been updated on the server due to upgrades/patches). Depending on the end user's network quality, this one and only time download may have a noticeable impact (only for users with poor connections) on the page turn times. To be very clear, while these files are cached, users don't incur this cost ever again event if the user closes the browser and comes back later and logs into the RDC app again.

So, the notion - images, templates and other static files are downloaded for the "first page" is incorrect but rather they are downloaded only during the "first ever time".

The next level client cache will kick into action, when a user opens a 'new CRF' for the "first time". Let me explain what I mean by 'new CRF' and 'first time' here. It means - user has never clicked on a particular CRF ever before 'in any study for any subject for any study-site'. In RDC 4.5.3, CRF html layout is only a template and is a seperate object from the data that is displayed inside it. In otherwords, for a given CRF, the same CRF html template file is used repeatedly to fill-in and display data for all subjects across all studies. So, if the CRF is accessed for the 'first time', then it will be downloaded only once from the server and cached on the client. So, once again, if the browser cache is configured correctly, user should be downloading a CRF template file only once for each CRF during it's life time. If a new version of a CRF layout is generated on the server using the layout editor tool, then it will be treated as a new CRF for caching purposes and will be cached afresh on the client.


The above behavior is true for next/prev buttons in the Data entry (DE) window also. When user launches a data entry window and clicks on the next/prev buttons, DE window follows the above cache behavior for opening the next/prev CRFs, and downloads the CRF html page only if it is not already cached.

So, a CRF template file is downloaded once and cached locally 'the very first time it is opened' and it has nothing to do with the "first page" notion and it doesn't really matter whether it is opened 'first' (by launching the DE window) or 'later' (by clicking on the next/prev button in the DE window).

Infact, it is not only the CRF html pages, but html for all dialog windows that pop-up in the data entry window (such as the discrepancy dialog, approve/verify dialog, blank tool dialog and scores of others) is all cached in the exact same above manner (cache on first time access) in the client tier.

So, if users browser cache is configured correctly (follow Oracle's recommendations), then only thing that gets downloaded 'everytime' from the server is 'NOTHING BUT PURE DYNAMIC DATA' that gets merged into and displayed in the corresponding CRF html template.

Btw, 4.5.3 browser clients don't need to send a request to the server to check whether a cached file is changed on the server or not. Even though there is no data exchange between the client and server, those pings will still have a severe impact on the overall performance. Thus we avoid them. In case if a locally cached file is changed on the server due to an upgrade/patching, RDC 4.5.3 automatically takes care of pushing the latest file to client and replacing the cached file. Individual browser clients don't need to worry about that.

It's OCUG time again..

It is almost one year since I last wrote here. Let me hide behind the usual lame excuse - "I am very busy"!

A lot of things going on at work and hopefully those of you attending this year's OCUG will not have to wait too long to hear about some of them..

First, we are not Oracle LifeSciences Applications group anymore. Instead, we are a brand new, independent "business unit" within Oracle now. Our Business Unit is called "Health Sciences Global Business Unit (HSGBU)". Being a business unit, we hope to be a lot more agile and busienss (customer) focused than before. Within HSGBU, we now have two major lines of products, one for HealthCare Industry and another for Pharma/LifeSciences industry (former OPA/OLSA team).

I will be attending this year's OCUG. At OCUG, I am going to talk about RDC 4.5.3 architecture in one of the RDC focus group sessions. This year, few others from our group are going to present on RDC. I highly recommend my colleague Arnab Gupta's session on RDC 4.5.3 scalability in the Admin focus group.

First OLSA User Group (India) Meeting - A report by Dr. Arshad Mohammed

Last week, our IDC (India Development Center) team in Bangalore has organized their first ever Indian Oracle Life Sciences Applications User Group conference. Thanks to my colleague Dr. Arshad Mohammed for obliging my request for this report. Read on..

Oracle Life Sciences team organized for the first time a conference for its Indian customers of Oracle Life Science Applications. The purpose of this meeting was to facilitate exchange of information amongst users, partners and Oracle and provide a platform to share experiences, ideas and solutions within the user community. Due to the growing interest expressed by potential customers to attend this event, they were also invited to participate in this annual meeting. The conference was a two day event which included presentations and discussions on technical and functional aspects of the Oracle Life Science Application suite.

The conference was organized at Golden Palms Resort and Spa located in the outskirts of Bangalore on 26th and 27th Oct 2007. The attendees of the conference included representatives of pharmaceutical companies (Ranbaxy, Torrent, Astra Zeneca, Panacea Biotec and Dr. Reddys), CROs’ (Quintiles, Reliance, Jubilant Biosys, SIRO Clinpharm, Bioserve, Manipal Accunova, Asian Clinical Trials, CliniRx, Clintrac International, Paragon Biomedicals, Kinship Technologies, Vimta Labs and E-Merge Tech Global Services) and partner companies (Tata Consultancy Solutions, Infosys, Satyam, HCL Technologies, Cognizant, DBMS Consulting and CSS Informatics) from all over the country along with the Oracle representatives from development, support, sales, product management and consulting groups across the globe which made up the attendee number close to 100. The attendees represented their companies from various departments including IT, data management groups, clinical operations department, pharmacovigilance, medical affairs and also some CEO’s and CFO’s.

The first day of the conference started at 12 noon which included an introduction of Oracle and OLS Application group and its presence in India along with presentations and demo on Oracle LS applications and the future plan for the products. The day ended with interactions, networking and discussions over drinks and dinner at the pool side of the resort.

Day two started early morning with presentations from our customers and partners on general topics as well as their experience on the applications and how they have improved their performance with the help of the OLS applications. Some of our partners presented their experience and how they have provided added value to their customers by integrating various applications at their premises.

The customers were quite happy to meet face to face and share their concerns and experiences with other users who attended the conference. The potential customers also benefited from the conference as they heard about the application from not only Oracle but also from other users. They also gathered information on the implementation partners and their services and what they have experience in regarding the applications. Partners were happy as well as they saw the growing opportunity in India and could get their leads from the conference with whom they can follow up.

The conference ended with a discussion on formation of the India User group, which can potentially be collaborated with the OCUG.

IE 6 woes..

Yesterday, I was at the Ajax conference in Boston. This is where you can expect to meet the leading developers as well as the thought leaders who are pushing the limits and shaping the future of the Ajax technologies.

Here, my worst fears came true when I mentioned that I have architected an IE only solution and worst yet IE6 is the primary target platform. Several of them I talked to, looked at me like I am a crazy person. Throughout the conference, and through several presentations, I have not seen anyone opening an IE browser! It is a well known general consensus among the technical community that IE is not a suitable platform to build current generation web applications, and RDC 4.5.3 development experience is no different.

To begin with, current generation browsers (IE or otherwise) are not a suitable platform to build RDC like applications anyway, and that is a topic for a different post. But IE (specifically IE6) significantly lags behind others like Firefox both as a development platform as well as the final deployed runtime environment.

A top notch debugger + profiler + network analyzer all combined into one Firefox extension called Firebug alone is the reason why it is a joy to develop serious AJAX clients in Firefox. There is nothing equivalent available for IE. We ended up creating our own profiler for IE and continually switched between Firefox and IE for development. I can't imagine how much time we could have saved, had the Firefox been the target platform.

We had to find and fix significant memory leaks in IE, which to a major extent non-existent in Firefox. There is a considerable performance difference between IE6 and IE7 let alone between IE and Firefox. We had to do significant re-design and optimization work to bring IE6 performance to acceptable levels. To add to the list, Firefox supports SVG natively and IE does not. Native vector graphics support is one of the critical needs for RDC 4.5.3 and for several others I met at the conference. We had to code work-arounds for significant bugs we found in IE6.

Bottom line is - on one hand businesses are demanding all applications to be web applications and run them in a browser. But on the other hand, they seem to choose an inferior platform to deploy these applications. It is time businesses start giving serious consideration and start looking at better IE alternatives available in the market today or influence Microsoft (if they can) to give us a better and feature rich browser..

The truth about RDC URL parameters

I found OCUG sessions as a great source of information and a rare opportunity to learn a lot about the industry and how customers use our products. However, in one or two particular sessions, I felt some details about our products deserves more positive treatment.

For example, in one session on RDC application, a significant emphasis was placed on appending the RDC app URL with some additional URL parameters to put that user session into debug mode. Listening to the particular way the subject was handled, I felt the same information could have presented in a better light.

So, let me explain..these URL parameters are no accident and not a common weakness one could exploit. They are there because development intentionally put them there and backs them with code behind them. These are mostly to help provide additional information to the support and dev personnel when customers run into issues at sites. These parameters are no big secret and we welcome everyone to know about them. The only reason, if at all, for any of these to be not widely publicized is that - often it is not enough to know about the existence of these parameters but most importantly one need to know about how to interpret the information (often notoriously cryptic) collected from turning them on. For example, in RDC 4.5.3, we have introduced a new parameter to profile the client code. And for the most part, information collected via this parameter makes sense only if one is intimately familiar with the code, otherwise it is kind of gibberish.

Also, collecting debug information by logging to a file or disk impacts application performance. So, we have provided two seperate ways to turn on debugging logs. First, just for a user session by way of URL parameters and second for all users connected to the application by way of server side configuration setting parameter. See, that's a good thing, right? I wish that's how it was presented.

Having said that, I wish options such as specifying a database name to log into and switching between production/testmode are not made into URL options as we currently do. I wish they rather follow the standards and be presented as explicit options in the UI on the login screen. I want to see them disappear from the url some day.

Other outrageous example I have seen in the same session is - a weak attempt at some how associating a universally known fact about decompiling java class files with the topic of debugging RDC application.

First of all, every java developer on the planet worth any, knows about how to decompile java class files and at the same time a very small fraction of them may have ever done it for a truely useful purpose let alone for debugging a third party product that they are not working on. As a customer, if you have to get to the level of decompiling the source files, figure out our code, and tell us back about what is wrong in the code, then probably we all don't deserve to be get paid from Oracle :-). My sincere and useful advice to you is - don't ever think about decompiling java classes to resolve not just our product problems but for any other products from any other vendors. Instead, file a bug and demand a fix from support.

I will write in detail about all the URL parameters supported in 4.5.3 later..

Running RDC 4.5.3 in non IE browsers

Yesterday, at OCUG someone asked - why can't RDC 4.5.3 run on a MAC? It's a web application!

First I thought the gentleman is asking about running the 4.5.3 middle tier on MAC and a thousand reasons flashed in my mind about why we can't do that right away. But later I understood the real question is - why not we support 4.5.3 on other browsers such as Firefox and Opera. Few others asked me the same question later.

Leaving the support details aside, let me offer the technical perspective on this issue as I anticipate others also wondering about the same in future (or more importantly to save myself from the gibes expected from fellow tech community for coming out with a cutting edge AJAX app that runs only on IE!!).

I agree, it is a web application, and in theory it should run on all browsers. Ignoring the existing plethora of implementation differences across different browsers that currently exist for - HTML, CSS, and JavaScript, still the main reason for not supporting other browsers in this particular release is the lack of a common vector graphics-rendering library that is natively supported across all browsers.

In 4.5.3, all the line graphics drawn by customers on a CRF using the backend layout editor tool need to be translated into equivalent graphics elements and finally be custom drawn on a web page. For rendering a CRF page in a browser, we cannot simply use standard HTML elements such as input, checkbox, radio button etc.,

In the absence of a common graphics library, we need to generate a different version of a CRF for each browser separately using a different technology. For example, to support Firefox and IE, we need to generate SVG version for Firefox and VML version for IE. Of course, one might argue SVG is available in both Firefox and IE. But the problem with SVG on IE is that IE still requires and depends on an external plug-in (Adobe) to render and view SVG. As you all know - "plug-in" is a big taboo for 4.5.3.

Given the tight schedules, we couldn't do both - SVG for Firefox and VML for IE. And of course IE is higher on business priority. However, the good news is - we have architected RDC solution to support different browsers, if there is a demand in future. In fact, most of our client code developers use Firefox extensively. They do this by simply ignoring the layout element graphics for the most part as rest of the application works just fine. I can't help but wonder what a joy it would have been, had we chose Firefox instead of IE, as we could have spared ourselves from all the IE related issues that we had to chase and fix for 4.5.3.

My real wish and hope for future is - all browser vendors (or at least one particular one :-) comes to terms and start natively supporting a standard technology for drawing graphics on web pages.

OCUG '07 - Day 2 Morning

Typically, Day 2 of the event marks the begining of the conference with welcome message and administrative updates from the OCUG committe. One thing to look forward during this brief opening session is the video with montages from the past conferences. This year, they edited the video to super impose the faces of Greg and couple of other OLSA team members' faces on top of the merrily dancing bodies dressed up in mini-skirts!! It was hilarious.

Greg Jones opened up the Oracle plenary session showing interesting historical pictures of Oracle. He showed pictures of Oracle's first birthday party and a small garage where it all started. You should be able to see them by downloading his presentation.

Greg made the following key announcements:

a) combining global Life Sciences Development, Strategy, Sales, Consulting and Support teams into a single organization
b) substantially increasing the size of each team and enhancing them with deep industry experience
c) a new team for ondemand EDC SaaS offering

He also gave an update about OLSA policy for supporting the products for 2 years after next release ships which basically gives atleast a 4-5 years average support window for a given release.

more updates later..