Thursday, 11 August 2016

Load testing with the EPM Automate replay command – Part 1

A recent addition to the EPM Automate utility is the ability to generate load on a EPM Cloud instance by replaying Smart View operations, the documentation has the following overview:

“The replay command replays the Oracle Smart View for Office load on a service instance to enable performance testing under heavy load to verify that user experience is acceptable when the service is under specified load. For example, you can test the user experience on a test instance under heavy load to ensure that the service will perform well after you migrate the application from the test instance to the production instance.”

In this post I am going through the process of how to get up and running with the replay command.

It is worth pointing out the replay command will only generate load through Smart View operations so it is a simplistic approach to load testing, there is no load being placed at the client browser level but you can certainly access the application through a browser while the load is being generated to get a feel to how the system is performing.

If you are looking for an automated solution to monitoring how well the system performs through the web user interface, then you should really look to tools like HP load runner to handle this.

As this is a EPM cloud solution you will not see how the underlying server is performing and have to put the trust in Oracle that everything is good in that area.

Before starting out with the load testing it is worth picking out a number of large forms and heavy business rules that will stress the system.

To be able to replay the Smart View operations then you first need a way of recording them and this is achieved by using an excellent free third party piece of software called Fiddler.

One of Fiddlers many functions is that it can log all the HTTP(s) traffic between a client and the internet and as Smart View operates over HTTP(s) this is a perfect tool to capture this.

Installing Fiddler is simple and after a few next, next, nexts you should be ready to go.

Once Fiddler has been installed it needs to be configured to monitor HTTP traffic, currently the PBCS documentation assumes HTTP which is not correct as when connecting to an EPM Cloud instance as it will always be over HTTPS.

Go to Tools > Fiddler Options and select the HTTPS tab.


Enable the “Capture HTTPS CONNECTs” and “Decrypt HTTPS traffic

At this point if try to connect to EPM Cloud using Smart View you might be hit with lots of the following type messages.


You can keep clicking next or you can set up Fiddler generate a root certificate and then add this to the trusted list.


You will then be show a window providing information around adding the Fiddler root certificate to the trusted certificate authority.


Click "Yes" and then confirm you want the certificate add the cert.


The cert should then be added.


The certificate can be removed after generating the load scripts by select the “Reset All Certificates” option.


You should restart Fiddler after adding the certificate and make sure “Capture Traffic” is enabled


Now that traffic is being captured you can go to Smart View, log in and carry out a sequence of tasks such as opening a form, entering data, saving a form and then logging off.

Once you have completed the tasks then if you look in Fiddler you will see all the traffic that was generated when using Smart View.


There is a lot of information that is not actually required, the first section is just dealing with authentication to the identity domain.

The replay command handles the authentication separately so it doesn’t need to be included.

All the information can be left if you like as the replay command should process only the information it requires; I am just removing it for demonstration purposes and to keep it clean.

You only actually need to keep the information from the first connection to the Planning Smart View URL.


If you don’t already know Smart View functions by generating XML code then compressing this using GZIP, posting the information to the server, then a compressed response is received which once again is in XML format.

In Fiddler you can decode and view the XML that is being sent and received.

In the above request Smart View is generating and posting the following XML to the Planning Smart View servlet.


You can see that a connection is being made to the Planning Smart View provider and the SSO token is being posted for authentication, the SSO token is actually generated earlier after the first connection to the Smart View provider.

If you do remove the entries that are not required, then you will end up with something like the following:



In order for the replay command to be able to process the information it has to be saved in a format that it can understand.


This can be done by going to File > Export Sessions > “Export All Session” or “Selected Sessions” if you have selected only the relevant sessions.


The format should be “HTTPArchive” which saves the file in JSON format with an extension of “.har

If you open the saved file, you can see that all the sessions have been transformed into JSON format.


Now that you have recorded one set of activities in Smart View you can repeat the process for all the ones you want to include in the load test, in the end you will have multiple “*.har” files.

Once you have generated all the files the next step is to create a replay file which I am going to cover in the next part.

No comments: