Overview
When a business decides to implement a new financial system, they are doing so to gain efficiency, visibility, accuracy, and to mitigate risk among other things. Implementers have the same goals when testing applications. Performance testing is critical in determining the validity and stability of an application, but the challenge is mimicking the burden that all of the concurrent users will place on the live system. After all, we are just one person with only one machine, so how can we simulate we are many? Fiddler, a free web debugging proxy, paired with the EPM Automate Replay command provides us with that answer. Fiddler is a useful tool with a variety of applications including web session manipulation, security testing, web debugging and performance testing. This post will focus on the setup and performance testing capabilities of Fiddler when used in conjunction with EPM Automate. Fiddler can be utilized with the following Oracle Cloud Services:
- Oracle Planning and Budgeting Cloud and Oracle Enterprise Planning and Budgeting Cloud (PBCS and EPBCS)
- Oracle Financial Consolidation and Close Cloud (FCCS)
- Oracle Tax Reporting Cloud (TRCS)
- Oracle Profitability and Cost Management Cloud (PCMCS)
- Strategic Workforce Planning
Recently, our team was tasked with designing and building a daily forecasting/planning tool utilizing PBCS. From the onset, a large area of concern surrounding this need was performance, especially considering the Block size we would be throwing at PBCS and the underlying Essbase database. In this regard, Fiddler became an invaluable addition to our tool belt. We were able to test 50, 40, 30, 20, 10, and finally 1 user running different processes in the system all at once. In the graph below, you can see that timings for different processes remained relatively stable from 1 to 30 users. Once we hit the 40 user mark, the jump in process times were very evident.
Without Fiddler, my team would have been unable to determine a performance benchmark and identify areas for efficiency improvements. To utilize Fiddler and gain the most out of your performance testing follow the steps outlined below.
Setting up Testing Scenarios
If you have not already done so, download Fiddler and EPM Automate and install them on your machine. Determine a few different areas in the application that end users will constantly be interacting with. Some of these areas may include manipulating and saving web forms, running business rules, performing an ad-hoc retrieve, or performing an ad-hoc submission. Testing may include any process that an end user can run through in Smart View.
Once you have determined your process, you will need to record your Smart View session and create a HTTP Archive file, or HAR file for short, using Fiddler. When you open Fiddler, you will notice that Fiddler will begin recording HTTP and HTTPS sessions.
Make sure to close any applications such as web browsers or email applications that may cause a session to be tracked by Fiddler. Then, remove all sessions by clicking on the ‘X’ and selecting ‘Remove all’ to begin with a clean slate.
Regardless of what process you are recording, the first step will be logging into Smart View. Logging in cannot be omitted or EPM Automate will be unable to run the resulting HAR file. When recording the process, avoid unnecessary clicks, such as opening of unneeded folders. Tracking unneeded actions will make consolidating session results more difficult in the end.
Once you have gone through an entire process in Smart View, export the Fiddler session into a HAR file. To do this, select ‘File’ -> ‘Export Sessions’ -> ‘All Sessions.’
Select ‘HTTPARCHIVE v1.1’ and select ‘Next’ to save the file.
Repeat these steps until you have a few different HAR files that each outline a common task that an end user would normally perform.
Once you are satisfied with your HAR files, you will need to create a CSV file that EPM Automate will use to run the HAR files. Each row in the CSV file correlates to a different user taxing the system at the same time. The CSV file is made up of three columns.
- The first column contains the user name of a native directory user
- The second column contains the corresponding password
- The third column contains the file path to the HAR file.
- Note: The same user may be used for each row
Use the replay command in EPM Automate to call the CSV file, which will in turn call the HAR files. The syntax for the replay command is as follows:
The file path to the CSV file is required, but both the duration and trace parameters are optional. If the duration parameter is not included, EPM Automate will only run each HAR file one time. If included, each HAR file will continue to rerun until the duration period, expressed in minutes, is reached. The completion of the duration period will not stop a running HAR file. Setting the trace parameter to true will create a Smart View trace file for each row in the CSV file that Oracle Support can then use to help trouble shoot issues. For the purposes of performance testing, the trace parameter is not needed.
After running the replay command, EPM Automate will display a breakdown of each step performed within each HAR file.
To easily rerun the replay command, we recommend setting up two simple batch scripts to run the task. One batch script will run the EPM Automate commands, while the other will be utilized to call the previous batch script and log the results.
The first batch script opens EPM Automate, logs in, runs the replay command, and logs out. When saving the file, be sure to use the file extension .bat.
The second batch script calls the EPM Automate script above and records the results in a log file. Again, be sure to save the file with an extension of .bat.
The resulting log file can be seen below.
Reviewing Results
When reviewing results it is important to check that each process ran successfully and was not skipped by the system. In the example below, we mimicked a single web form being opened and saved by the equivalent of 50 users. The web form had a business rule attached that ran on save. As we can see from the results, the form took about 5 seconds to save on average. When reviewing the results we noticed that the screen, action, and object cells, where the “Save Form” process should be located, were blank.
When filtered on only the “Save Form” lines you can see that a heathy number of “Save Form” actions were skipped. The duration on the skipped “Save Forms” actions was much shorter than on completed “Save Forms” actions, throwing off our results. The mean time goes from around 5 seconds down to 3 and a half seconds when the skipped actions are included.
Compiling Performance Tests
Once you have verified that your runs are clean, you can then consolidate the results into your preferred format for easy analysis.
Alas, using one machine to follow the steps above, we became multiple users interacting with an Oracle EPM application all at the same time. We now can determine what the performance times will be when 1, 10, 50…500 users are utilizing our system at the same time. As Sir Francis Bacon said, “Knowledge is Power”, and now we have that power to solve for the fear of adverse system performance during a go-live. By using Fiddler, we can ensure that the stress is placed on the system, and not on the users. If necessary, we can then optimize, redesign, enhance application artifacts and methodologies to ensure users have the best experience adopting a new application.
