12 demantra application load testingminisites.qaiglobalservices.com/stc2012/paper_...

Demantra Application Load

Testing

Rupesh Garg & Mehar Sheikh

© 2012 WIPRO LTD | WWW.WIPRO.COM | CONFIDENTIAL1

Rupesh Garg & Mehar Sheikh

Introduction

Overview about Oracle Demantra Applications


Demantra Planning Engine Overview

Demantra Components

Load Testing Approach

Challenges and Solution in Load Testing

Conclusion

6

7


Glossary8

Introduction


Introduction

Today, a significant number of organizations across have implemented Oracle Enterprise Resource Planning (ERP) system. For most companies, the ERP system has become the information backbone of the organization. Different implemented modules of Oracle applications like CRM, Demand planning, financials makes it more useful but at the same time makes it even more complex to test. In today’s complex web application world, complete testing needs to be done on applications that incorporates complex technologies like Oracle Demantra that goes beyond simple HTTP-based pages and uses oracle forms. This stresses on thorough testing of not only online transactions involved, but also the complex batch jobs like


of not only online transactions involved, but also the complex batch jobs like Demantra planning engine.

Load testing of Oracle Demantra application involves both OLTP and batch jobs execution. Workload characterization of Demantra application also comprises of frequently used online transactions from source instance data like ‘Purchase Order’, ‘Worker Order’ etc. along with batch jobs. Not only does this paper address the load testing approach of Demantra application which includes batch jobs and online transaction; but also how to handle load testing of multiple instance releases (planning and sourcing).


Oracle has acquired Demantra, a leading global provider of demand-driven planning solutions. Demantra is a best-in-class provider of demand management, sales and operations planning, and trade promotions management solutions.

Benefits of using Oracle Demantra:

• Oracle Demantra is expected to significantly reduce total cost of


• Oracle Demantra is expected to significantly reduce total cost of ownership while increasing customers’ ability to operate an integrated, information driven enterprise.

• It will enhance demand visibility with powerful analytics for more accurate enterprise planning, forecasting and monitoring.

• It will facilitate transformation of customers’ supply chain operations to leading-edge infrastructure that improves competitive advantage.

Demantra Planning Engine



Demand Management covers forecasting of demand using statistical techniques and sales and operations planning to facilitate consensus demand and supply planning. Demand Management consist of three modules that can be licensed and implemented separately.

• Demand Management (DM)

• Advanced Forecasting & Demand Modeling (AFDM)

• Real-Time Sales and Operations Planning (RTSOP)


Demantra Demand Management: Demand management helps in understanding historical demand and predicting the future demand. Demand management cycle consists of

• Collecting historical data

• Generating forecast

• Review and approve forecast

• Publish the forecast

• Analyze the forecast accuracy


Demantra Advanced Forecasting & Demand Modeling: This is extended module for

Demantra demand management. It supports six more forecasting methods listed below

• Auto and Linear Regression (ARIX)

• Auto Regressive Logistic (ARLOGISTIC)

• Dual Multiplicative Linear Regression (DMULT)

• Multiplicative Monte Carlo Regression for Intermittent

• Multiplicative Monte Carlo Regression for Logistic (LOGISTIC)


• Multiplicative Monte Carlo Regression for Logistic (LOGISTIC)

• Multiplicative Monte Carlo Regression for Modified Ridge Regression (MRIDGE)


Demantra Real-Time Sales & Operations Planning: Sales and Operations Planning

brings different functions to collaborate in business demand and supply and operational

planning. It consists of four critical steps

• Finance Planning

• Supply and operations review

• Demand Planning

• Supply Planning


Demantra Components


Demantra Components

• Collections - Provides ability to collect data from the Source instances.

• Dimensions - Provides 2 seeded dimensions Item & Location. All hierarchies are created on these two dimensions.

• Series - Data sets in Demantra identified as Series (Example: Sales History, Booking History etc.)

• Forecast Functionality - Provides ability to create forecast using different Statistical Models based on History Data and Ability to tune forecast engine at nodal level.


forecast engine at nodal level.

• Forecast Load / Entry - Provides ability to manually enter forecasts or load forecasts from files

• Worksheets - Worksheet functionality to layout, analyzes, manipulate and collaborate.

• Forecast Upload - Upload the Publish forecast to Advanced Supply Chain Plan.


Plan, build and execute are the three important phases of any Oracle Demantra load test.


Load Testing Approach – Plan Phase

Plan Phase - In this stage, effort and cost estimates for the project would be prepared and finalizes on the Test Plan.

Activities

• Requirement Gathering• Preparation of High Level test plan with activities and Review with Test Manager

& ops lead• Capacity Planning• Test effort estimation


• Test effort estimation• Resource planning and determining roles and responsibilities.• Training requirement

Deliverables

• Test Plan/strategy document • Effort estimation document • Review capacity plans & schedule KT by project teams

Load Testing Approach – Build Phase

Build Phase - This phase involves creation, verification and rework of test cases & test scripts. Test data is identified/created and is reviewed and then reworked as well. Test environment set-up is one of the critical aspects of testing process and can be done in parallel with Test Case Development Stage.

Activities

• Create test cases, automation scripts (if applicable) • Review and baseline test cases and scripts• Create test data (If Test Environment is available) or fetch the data from source instance.

Before fetching data from source instance we must have to collection batch jobs.


Before fetching data from source instance we must have to collection batch jobs.• Understand the required architecture, environment set-up and prepare hardware and

software requirement list for the Test Environment.• Setup test Environment and test data creation for online transactions as well as Batch jobs• Perform sanity test on the build

Deliverables

• Test cases/scripts• Test data creation• Environment readiness with test data set up• Sanity test results

Load Testing Approach – Execute Phase

Execute Phase - During this phase load test team will carry out the testing based on the test plans and the test cases prepared. Bugs will be reported back to the development team for correction and retesting will be performed.

Activities

• Execute batch jobs and online tests as per plan

• Document test results, and log defects for failed cases


• Document test results, and log defects for failed cases

• Map defects to test cases

• Retest the defect fixes

• Track the defects to closure

Deliverables

• Result Summary Report

• Defect reports

Load Testing Approach – Overall Simulation



Below are few challenges in load testing of Demantra applications :

• When a load test for a planning instance need to be conducted, another sourcing

instances can’t go for load tests

• Before starting the load testing of Demantra applications, all source and planning

instances must go for DB restore.

• During load test all dependent source instances should be up.

• Making sure during batch job execution, no major activity in source instances are

planned and running.

• Few batch jobs like ‘Engine run’ should be tested as a separate scenario outside the

normal day and worst case scenario load tests.


normal day and worst case scenario load tests.


Below is the proposed approach on how to manage load tests between planning and source engine:• ERP source instances load tests running in parallel to planning instance will increase the time taken

for a single dry run from 14 hours to 18 hours (1 day). • All instances have to be restored before going for load test. After restore 4 hours will be spent for

the first batch job run example ‘collection batch job’ in source instance. This activity will stop other planning and source instances execution.


• The load testing for ERP Instance 1, 2 and 3 can be accommodated in parallel by sharing the same load testing environment. Here unlike a regular load test, the instances will not restore after every test from the database backup. During the Planning instance load test window, if there is a restore in the middle at the source ERP side (either ERP Instance 1 or Instance 2), it will delay the start of the Planning instance test by 10 to 11 hours (24 hrs. in total). This is due to the time taken by the first batch job run of the collection program for source ERP instances after the restore.

• This way it will limit the number of load tests for each instance to 5 per 2 weeks. In the above mentioned way we can together accommodate load testing of two parallel running instances.

Conclusion


Conclusion

The activities and deliverables involved in Plan, build and execute phases of load testing is

explained briefly which helps in better understanding of load testing approach followed for

complex applications like Demantra.

From the approach explained above different releases can be managed more effectively

when running in parallel. This in turn enhances planning needed for each release load

testing activities.


Mehar & Gautam

Test Lead & Engineer


12 demantra application load testingminisites.qaiglobalservices.com/stc2012/paper_...

Documents