How to Load Test Siebel CRM

Oracle’s Siebel CRM Technology provides the server framework to support Siebel Applications. It delivers comprehensive on-premise and on-demand Customer Relationship Management (CRM) solutions. Siebel CRM is specifically popular among banks and banking systems (see our article on Core Banking System Test Automation), since it has a lot of ready-made configurations that are convenient to use, i.e. Siebel CallCenter, Siebel Finance, Siebel Loyalty Management, etc. In this article, we share our thoughts on CRM testing meaning, why you have to load test Siebel CRM and our life hacks on how to do it.

Why is Load Testing a Must for Siebel CRM?

It is this particular multifunctionality that makes it an absolute must to load test Siebel CRM to avoid potential problems. CRM is responsible for many business processes, customer requests processing, and, often, for financial operations, too. Inside the system, the business processes are often customized and very complicated, so performance testing services is necessary to be able to assess how it really works.

For the users, Siebel CRM looks like a graphical interface, or a graphical add-on over a database. You see a screen, inside it there is view mode, and the main elements for user interactions are applets, specifically form applets and list applets. In cases where Siebel CRM integrates with APIs, especially for high-performance architectures, using a robust gRPC load testing tool ensures that the system remains scalable and efficient, even under significant load.

Siebel CRM: What to Test

Siebel is a huge system, so you won’t be able to test the entire circuit: it consists of 20+ integrations. So the first step is to choose what to test. We opted for daytime and nighttime traffic flow from users.

In this part, it is quite simple: traffic gets to the web servers through the load balancer, or HAProxy, and then it is sent to the application servers, among which there are front, back and Gateway servers, which also go inside the back servers and, among other things, processes various batch operations. These are associated with an Oracle database. Next, we added different third-party integrations, all of them absolutely necessary:

• CDI with multiple large tables;
• 3CRD and CFT, similar to CDI, but smaller;
• Maxoptra – some minor updates on activities;
• MFMS as a service to message users.

Part of the system to be tested

As a third step, as a solution for all third-party integrations, we created emulators in Java. They had a roughly similar structure. For MFMS, a visible bank stub was installed, configured using PostMan.

Our solution

Creating Testing Profile for Siebel CRM

Our next step was to create a load testing profile in the absence of information from business analysts. For some reason, we were not given a profile, and this can happen to you, too. With the nighttime profile, it was rather regular. You need to have some data from the production system, to look at these uploads, look for the 90th percentile, load the old data, try whether they work correctly, and if everything works, you are done.

With the daytime profile, it was more complicated. We looked at the logs that we received from the prod, wrote a lot of SQL queries to understand which events happened most often, and got data on which applets people interacted with. The names of those elements partially indicate where they are located, and it helps to create usable scenarios. If it was still difficult, we turned to the developers and discovered a rather useful solution to search for the necessary elements, Siebel Tools.

In Siebel Tools there is all the data you may need: the elements, the tables, all the fields from the database, and relationships between them. After having collected and analyzed logs from the prod for several months, we sorted them by the most frequently executed events, manually lined up events in business processes by percentage of execution and searched for the necessary elements using Siebel Tools.

Lack of help from the side of the customer and our purely empirical approach led to an interesting discovery. The real-life actions of users sometimes included operations that were not supposed to happen, according to the documentation. For example, in our customer’s Siebel CRM configuration, it is established that they do not form reports or documentation, but in fact people did just that: they used Siebel to interact with overdue debtors, and it was convenient to upload their lists to call these customers. The experts did not even know about that and blindly denied the real facts, so we had to adjust the tests to what we saw in reality.

Testing Siebel CRM: Problems and Solutions

SIebel is a huge system, so you won’t be able to test the entire circuit: it consists of 20+ integrations. So the first step is to choose what to test. We opted for daytime and nighttime traffic flow from users. In this part, it is quite simple: traffic gets to the web servers through the load balancer, or HAProxy, and then it is sent to the application servers, among which there are front, back and Gateway servers, which also go inside the back servers and, among other things, processes various batch operations. These are associated with an Oracle database. Next, we added different third-party integrations, all of them absolutely necessary:

Problems we faced when updating scripts after releases:

With the nighttime profile, we used emulators in Java, and a really helpful tool here is Quartz API planning package. You may need it, since file uploads occur periodically, for example, once in an hour, once in every 20 minutes, etc. This frequency can change, so to be able to configure it, it is convenient to have a separate element where the corresponding configuration is sent. There are two main entities inside Quartz API: JobDetail and Trigger. Transfer of parameters to the task was a little more difficult to implement. After the trigger task is executed, a limited time of operation of this emulator is set, so that at some point after the test expires, it stops working.

Testing Results

The daytime profile passed all the tests positively, since all the loads on the prod were relatively small and everything worked just fine. Maximum performance was above the set threshold, and the system proved to be reliable enough. Still, when preparing the scripts, communicate with business consultants and analysts as much as possible, so that they understand what is happening.

Most of the problems occurred with the nighttime profile, because it represents operations from the tech window, huge uploads, integrations with the database, the work of back servers, etc. And indeed, after running the test once, it turned out that everything was super slow and the problem was in the disks, although when we were preparing the testing methodology, we agreed upon the volume of disks with the customer. Although the documents indicated that there were HDDs on the prod, in fact there were SSDs. Probably, they did not even think that this factor can influence the system performance, too. In fact, processing time of the disk subsystem request reached 8 seconds, execution time of the disk subsystem request reached 910 ms, and the length of the disk queue reached 184. Anyway, as the tests have shown, if a testing stand with SSDs still endures the load, clearly, with HDDs it will only work better.

We were able to achieve significant results in our Oracle’s Siebel CRM load testing case!

If you’re looking for engineers to test your Siebel CRM, PFLB specialists would be happy to help. Contact us to schedule a free demo.