Oracle Forms Challenges
As the CIO running Oracle, you are ultimately responsible for the health and security of Oracle Forms, an expensive software technology running the business. Chances are that every nook and cranny of your organization relies on Oracle Forms.
Competitive demand brings pressure to improve and build greater capability without user disruption. For CIOs in organizations built on Oracle databases, this is much like asking the heart surgeon and his team to replace a heart-valve without stopping the heart. Achieving optimal Oracle Forms user experience is no easy task. Like that surgeon, you need the right people, the right tools, and the right training for a good result. You cannot afford a bad result — corrupted or inferior production forms — nor can you afford inefficiency. (Unlike that surgeon, however, almost nobody will thank you for the effort, making it hard to justify the resource requirements.)
How can you and your team manage this critical, ubiquitous, and very complex business process?
What best-practices can you instantiate, what tools can you provide, to bring confidence that your Oracle platform can meet demand?
Until recently there were no tools for confidently testing and automating Oracle Forms. Today there is a revolutionary tool from AuraPlayer called Auratester for testing and monitoring Oracle Forms and EBS and radically improving the quality and user experience of your applications.
The Challenges to Oracle Forms Performance
To understand the scope for optimizing performance, you should have some contextual background. Oracle Forms, the user interface to Oracle databases, began its life running as a server-side, character mode terminal session, and it relied on a simple and direct connection to the Oracle database itself. As user needs and demands grew with the advancing technology, Oracle Forms was ported or modified to work in other scenarios — notably to client-server applications, and now to the web. The result is a bit of a hybrid system, with legacy structures and routines progressively modified to work with emerging technologies. Each additional participant in the process introduced performance challenges. Today, the Oracle Forms architecture is built on, or relies on, three layers of dependency: the client portion where the visual work is done, a middle layer for business logic, and the database. Each layer handles multiple processes that add exponential complexity to the job of performance tuning. On the client, Oracle Forms uses Java applets to draw the screen and accept inputs.
The application server sits between the client and the database. It controls all the business logic either executing the logic in the application server or in the database. To further complicate things, the application server also hosts a physical executable that is yet another client-server process! Imagine the threads running through all those routines and you begin to understand how difficult it is to test merely the application server. Until recently there was no tool on the market to fully evaluate this server’s performance.
And of course, the Database server is a big Oracle Forms dependency. If it’s running slow, nothing runs fast.
Why Oracle Forms Testing & Automation Matters
Performance in terms of speed, accuracy, and reliability is always important, but it is critically important to the technology that interfaces directly with human beings. End-users’ perception of the organization is directly influenced by the technology they use to connect and work with it. Marketers call this a branding moment.
Therefore, users’ interface, technical or not, should have a significant place in the organizations’ list of priorities. Many of the world’s most successful organizations rely on Oracle to maintain their market leadership. For those organizations, Oracle Forms is the technical face of the brand. Therefore, it is critical for those Forms to deliver superior user experience.
One Forrester study calculated that improved testing and automation of an organization’s applications offered up an ROI of 287%! Cost savings and efficiencies came from added sales from faster and improved customer experience, IT hardware and professional services, software licensing fees, annual fixed costs associated with maintenance, hardware storage costs, and many more. (Source: TEI of CA Technologies Test Data Manager Solution-2015.)
It is a major challenge to optimize Oracle Forms for the fastest and most seamless user experience, and it gets harder the longer the Form has been in place. But, end-users — customers or internal stakeholders — don’t care how you make the technology “disappear”, nor do they want to spend time and money on your technical problem. They have other options.
Therefore, since the organization has heavily invested in expensive Oracle applications, the more money and time it can take out of the Forms Testing and Automation, the better.
High availability configurations introduce even more complications
A simple configuration can again add exponential factors to investigate for performance issues. Think about all the configurations affecting just several desktops and internet applications, several Oracle HTTP servers (either on several different machines or WebLogic servers), each with load-balancing, and several database servers. Testers should figure out not just which process has the problem — and there may be hundreds of those — but which host has the problem.
So, you have five days before rolling untested Forms out to production.
How confident are you the Forms will not destabilize the production environment?
How are you going to effectively tune their performance?
Perhaps more important, how are you going to resolve issues quickly?
To answer those questions, we begin with the Five Pillars.
The Five Pillars of Oracle Forms Automation & Testing
The Five Pillars approach improves, in a systematic, reproducible manner the performance and reliability of your Oracle Forms application. Recall that Oracle Forms has some legacy baggage. New versions have tools to help clean up some of the old ways of doing things, and tools to optimize not just the form design, but the routines that interface with the client, the application server, and the database itself.
1) Fine-tune Client Startup Time
We start with what may be the best place to start, the portion of Oracle Forms that sits on the client. Fixing this can dramatically improve the end-user experience. And with feature updates, Oracle has been helping Oracle Forms Admins in recent years.
Prestart
When you first load a form by entering a URL, Oracle Forms will immediately initialize multiple form sessions (application run time sessions). This minimizes the time it takes to load another form, and can be very helpful. But you can configure this to suit your environment. I recommend configuring this to be less than five. To do this, see PrestartInit parameter information in Configuring and Managing Forms Services | Advanced Configuration Parameters (Section 4.2.5.7) documentation on Oracle’s Online Help Center.
Perception
The other low-hanging fruit to is to let the user know something is happening. On startup, if users don’t see anything happening, they don’t believe anything is happening. To let them know that the Form is working, that it has acknowledged them, Oracle provides two helpful parameters, the splash screen and background image. You can configure both in the formsweb.cfg file with the splash or background parameter set to equal any GIF.
<PARAM NAME=”splashScreen” VALUE=”ex: images/myfile.gif”>
Note: Specifies the .GIF file that should appear before the applet appears. Set to NO for no splash. Leave empty to use the default splash image. To set the parameter include the file name (for example, myfile.gif) or the virtual path and file name (for example, images/myfile.gif).
<PARAM NAME=”Background” VALUE=”ex: images/myfile.gif”>
Note: Specifies the .GIF file that should appear in the background. Set to NO for no background. Leave empty to use the default background.
Optimize load sequence and module size
Oracle Forms are stored on disk as binary “.FMB” files. The way the system first treats FMB files is to draw all the canvasses defined by the file — each field, each screen element — and then display the canvas that should be on top, or “first visible”. Be mindful of the order and sequence that items are drawn on the first screen. It is also helpful to limit the number of items on the first tab. You can do this by optimizing two FMB load-time parameters, raise on entry and visible, both of which are set to either TRUE or FALSE.
Many times, each canvas’ configuration inefficiently includes raise on entry = true and visible = true. Change this so that only the canvas the user should see first has raise on entry TRUE. Set raise on entry FALSE for items not needed during initial session.
If there are canvas’ that should not be visible to the user, say they are old versions you don’t want to delete just yet, set visible to FALSE. Make sure that a canvas doesn’t have a setting conflict: visible is FALSE where raise on entry is TRUE.
Another tip: break large modules into small ones. The more canvas’ and window definitions in the FMB file, the more resources it takes up. Look for ways to keep the FMB small. For example, if you must have many tabs or canvas’, a rule of thumb is to keep the number of canvas’ to less than 5 and the windows to less than 3. You can always load another FMB to get the form real estate you need, and in fact this is more efficient in the Oracle Forms world. Oracle Forms will handle multiple FMBs better than it will handle too many canvas’ or windows in a single FMB.
2) Reduce Client Resources
The client draws the screen. The more elements it must draw, the more meta data it must carry and the more time it must take to complete. There are two major areas to focus on here. Both are straightforward, but require a steady investigation through all the FMBs in the organization. (More on a way to speed this up later.)
Associate Prompts
You can and should reduce the number of boilerplates with Oracle Forms’ new “attach prompt” feature. Boilerplates are what most designers call “prompts”, the text that describes the field or prompts user action. In the old days, this text was neither a field property, nor a text character, but a graphical element. (Remember where Oracle Forms came from!) But now, with Oracle Forms v4 or higher, you can make these legacy prompts a text-based property of the field. To do this, use the “attach prompt” function in Oracle Forms designer, also referred to as “associate prompt”. This process can dramatically improve the Forms’ speed at the client.
Reduce X & Y Coordinates and replace arcs and circles with rectangular shapes.
The network call between the client and the application server is a collection of Java applet commands. For the client to draw the screen, the way Java must work is to send x,y coordinates for each pixel. Like people, computers plot and draw rectangles much more easily than circles! For ‘easily’, you can correlate “less data intensive”. Using rectangular objects rather than curved ones can greatly reduce the clients’ need for bandwidth from the application server.
3) Use the Network More Efficiently
There are several potential network issues related to speed and reliability, and they are addressed from all three layers: the client, the application server in the middle, and the database server.
Reducing client dependency on network communication
To improve network traffic to the client:
Put all your images and icons into JAR files. The JAR file is purpose-built to efficiently store and serve images. When a form is loaded, beginning the session, it will download a compressed JAR file to the local client. This brings two big advantages: the client will not have to download the image every time it draws the screen, and it takes good advantage of the local cache.
Try to avoid mouse triggers and use them only in specific ways. Mouse triggers add a great deal of traffic. A MOUSE-DOWN triggering event always generates a second MOUSE-UP message. Mouse triggers should never be used at the block level. Best-practice is to use java beans rather than mouse triggers. If you must use mouse triggers, use them only at the item level, and only on specific items such as mouse-double-click.
Be wary of the word SYNCHRONIZE. It’s not abracadabra! Back in the old days it was a light-weight function used to get rid of code artifacts or to load data. Early on it meant “refresh the client”, now it means “redraw the entire canvas.” Synchronize now introduces unnecessary delay and disruption and is a heavy activity in Oracle Forms’ world. If you see many occurrences of SYNCHRONIZE in your FMB files, try to minimize its use; it can introduce unnecessary lag to the user experience.
Replace legacy timers. Timers used to be the best functions for defining progress bars, page refreshes, etc. Today there are Javabeans (PJCs) to replace those statements. Browse to http://forms.pjc.bean.over-blog.com/article-1807657.html for a Javabean component to replace internal Oracle Forms’ internal timer.
Accomplish as much as possible in one network conversation
The other aspect of testing and improving the efficiency of network traffic comes from using the advanced data packaging feature. This allows Forms designers and admins to group settings, or promote similarities, and thus efficiently package data transmissions, which fine-tunes web traffic. Organizations who deploy with this feature get a significant reduction in network traffic. Here’s how it works. Oracle Form sends a message, usually from the client to the application server, which triggers a series of back and forth transmissions, each introducing a delay waiting for response, and consumption of bandwidth. If a message has several functions or parameters that are the same trigger, such as set item property, the new grouping feature will send that one message with a simplified set property statements. To use this feature, group settings into like groups, or in the UI promote similarity by object libraries or visual attributes. On new applications use object libraries and visual attributes for your items going forward. Here are some other specific tests to optimize your Oracle Forms network efficiency:
Bundle events. Try to bundle or consolidate events, and test your FMB to make sure the number of events is within reason. It is very possible, and in fact desirable, to group things into one trigger. For example, instead of having three triggers when the user leaves a field, use one.
Try to use object libraries for code (such as PLL)
Minimize graphic images, and optimize them before sticking them in the JAR file. Studies have suggested that reducing the file size or footprint of an image can speed page loads by 15%, but even better, it can improve user engagement by twice that!
Use sub-classing. Oracle built the foundation of a very efficient sub-classing system, allowing meta data. This greatly reduces the amount of code, and as a result, reduces the time data spends moving round-trip across the network.
4) Review the Infrastructure
The importance of reviewing the infrastructure prior to production release cannot be overstated. Managers should think about sizing before moving Oracle Forms into production. Testing should generate expected load metrics. In addition, monitoring is equally important to capture unexpected or unplanned events.
Rehearse before you go on stage. Do performance testing before you move to production to get an idea of requirements. It is much better to learn of server production expectations before the fact, rather than by user complaint and stakeholder rebellion. The more concurrent users and the larger the FMBs, the greater the demand on the server. Testing with AuraTester helps determine whether the current server configuration will handle the load and help to determine what additional CPU and RAM resources will be sufficient to handle increased FMB load. Things change. Marketing may deploy hundreds of seasonal telemarketers. If you’re not watching the system, monitoring the server for performance, e.g., management and operations are reacting to problems rather than fixing them. AuraTester’s monitoring agent periodically tests your Forms servers by running Test cases, any failure or performance outside set performance requirements are immediately emailed to the administrator.
Proximity matters with Oracle Forms. Latency can kill the user experience. The complexity of the Oracle Forms application and database server layers can introduce latency on even the fastest networks. Try to keep them close to each other and consider this issue when configuring new deployments.
5) Benchmarking
Often, service ratings are subjective, and as such, are obstructive to the people responsible for fixing problems. Specific, easy-to-identify metrics are far more useful for diagnostics. They are also helpful in ranking the factors that affect performance.
Oracle Forms’ testing and automation best-practice is to measure the days between bug discovery or system failure. But as important as those events are, watching their trends can be even more important. Perhaps it is obvious now, reading this, but administrators are more interested to know if the number of bugs per month or quarter is increasing than they are in knowing of a single event. Trends often suggest more appropriate mitigation.
Achieving high quality service is subjective until something goes wrong.
Trends over time are useful, but it is much better to start with a reproducible, measured quality of service. Such a measure is known as a benchmark. Running an application and putting it through its paces at regular intervals will identify poor performance and quality issues.
Management needs proof that things are stable, and improving. Constant monitoring, with comparisons against the baseline or original benchmark delivers that assurance. A well-defined benchmark and monitoring capability should track all modifications to the Forms environment and compare its KPIs to previous periods. This proactive and systemic approach will deliver a vastly better operation than one depending on user feedback.
Conclusion
The deep complexity of Oracle Forms can set an unprepared organization up to fail. To have confidence in the organization’s Oracle system, and know it can keep up with demand, the organization should have a solid, enterprise Oracle Forms testing and automation system. But the intricacies combine to make that a truly giant challenge that cries out for an enterprise solution.
By any measure, the risks jeopardizing the operation with under-performing surface technology, or worse, transmitting bad data, are too great to put on ad-hoc and manual debugging routines.
Dozens of experienced people could spend hundreds of hours peering into every nook and cranny of the production technology stack– and risk fouling it up in the process — and still not find all the issues affecting the Oracle Forms’ user experience.
AuraTester addresses management’s challenges with a comprehensive toolset in a single optimized enterprise application. The light-weight application runs on a desktop or server, and as long as it has access to the relevant layers, will run non-intrusive tests to find problem areas, suggest resolutions, and establish solid reporting and benchmarking.
About AuraTester
AuraTester was developed by the Oracle experts at AuraPlayer, Inc. Recognized for superior Oracle process improvement, the company has more than 20 years’ experience working directly with Oracle and other Fortune 500 companies to optimize the business processes that rely on Oracle Forms.
AuraTester provides a frictionless solution for Oracle Forms Testing and Automation. It is an out-of-the-box solution that allows you to easily and inexpensively:
- Add Oracle Forms to your Continuous Integration (CI)/Agile QA plans
- Integrate your Oracle Forms testing cycle into any testing framework
- Decrease the time it takes to upgrade Forms
- Identify system bottlenecks and application bugs before they occur in production
- Stabilize production with sanity, functional, load or regression testing
- Perform capacity planning deployments of Oracle Forms based systems
