Working Procedure SAP BW Testing

ABSTRACTThis document contain step by step procedure of SAP BW testing approach

Gavaskar .SBW Test Consultant

2

WORKING PROCEDURE OF SAP BW/ BI TESTTING

This paper covers:- Approaches for testing BW solution- Architecture – Case Study- Flow Chart – Project Architecture, Testing Manoeuvre BW/BI Solution- Connectivity –SAP applications- BW Testing Manoeuvre- Customized Reconciliation, a Value-add to Business & Customer- Challenges Faced

INTRODUCTIONClient is a major Nederland Financial Institution and deals majorly in – Insurance, Retail Banking, Investment Banking, Asset Management, Wealth Management etc. It has presence across the globe (UK, Europe, Asia & Pacific) to service the needs of Customers & Clients.Client was looking a single-sourced tightly integrated solution to provide faster, better & efficient Consolidated and Group Reporting Capabilities in order to reduce high number of legacy system and other non-redundant systems. The focus was for getting Statutory and Management reporting for reconciliation of different product & services offered which was very time consuming job earlier.Document highlights the optimised testing manoeuvre involved while testing a SAP BW solution for better, faster and error free solution. Testing process has been formulated keeping in mind the specific Operability, functionality and behaviour pertaining to BW system.

OVERVIEWSAP BW is a comprehensive business Intelligence product centred on a data warehouse. SAP BW also includes preconfigured data extractors, Analysis and Reporting tools .i.e. Analyser, Query Designer, Report Designer. Through BW testing we are validating Objects, Rules, Connectivity, flow of data within BW and various connected Systems \ Applications.Data is pulled from ECC, SAP ERP, SAP PM, and other source like flat file ; cleansed and aggregated data is stored in SAP BW system and pushed to various layer of BW transforms the data into acceptable format and sends it in form of Packages. Consolidated in SAP BW system via Extended Analytics tool. Finally the data is sent to SAP BO for reporting after it is segregated in BW according to categories of report also send to different target system using Informatica.

BW TESTING APPROACHGeneral:

SAP BW system needs to be tested in-&-out for better and smoother performance. Data Quality and Integrity in BW system should be tested. Handshaking/Connectivity mechanism with the external system should be tested. Transfer & Quality of data should be tested while moving in-&-out of BW

Approach:

3

Unit Testing: In this we have perform all the technical tests like testing the data flow, logic in transformation, data loads, query properties etc. Integration & Functional Testing: In this we perform the functional test to check that query is giving output which is functionally correct. Regression Testing: If we are making changes to existing flow and query, it this testing one would like to test that no existing functionality has changed because of newly added changes. Performance Testing: sometimes we write ABAP code in transformations, under this cap you may like to test the data load performance. If data load is taking a long time, you may want to optimize the code and check the performance again. Authorization Test: in this you would like to test all the roles have been set up properly and data level access is also working fine at query level

ARCHITECTURE

CONNECTIVITY

Data

Flo

w

4

PIC :2

PIC :3

Above figure shows the connectivity and movement of data from BOFC to BW via Extended Analytics. Data is being pushed from BOFC Database (Table) to Real-Time Info-cube in BW through Web-services.

5

BW TESTING ACTIVITIES Availability of BW system Availability of ECC System for data extraction Check the availability of Data using extract checker (TCODE: RSA3) Authorization of roles in BW ( TCODE: SU01) Connectivity of source system with BW (TCODE: RSA13) Availability of BW objects (info object, Cube, DSO etc.) (TCODE: RSA1) Validate the definition of BW objects as per the requirement (Active, type, description, settings etc.)

(TCODE: RSA1) Validate the Business rules applied on objects (Routine, transformation(STRANS), ABAP

program( SE16,DB02)) Availability of relevant data in BW objects (LSA Architecture) Validate process chains and its steps (TCODE: RSPC) Check Scheduling options of different jobs/process chains (TCODE: RSPC) Check associated tables and availability of Data in Data target (TCODE: RSA1) Validate the BEx Queries (validate by using Bex designer or Bex analyser or else use TCODE: RRMX or

RSRT1) Check the formatting, look and feel of the Query (validate by using Bex designer or Bex analyser or

else use TCODE: RRMX or RSRT1) Ensure the data quality Check the Formatting, Look and Feel of reports Aggregation of data at query/Cube level Deployment of EA Cube in SAP BW system Availability of data in IS Cube (Real-Time Cube)

FLOW CHART – TESTING OF BW SOLUTION

6

7

RECONCILIATION & DATA LOADINGWhy Reconciliation is required?

One of the major reasons of information loss/error is loading failures or errors during loading. Below errors can lead to inconsistent data e.g.

1. Inconsistent or non-coherent data from source2. Non-integrating data among different sources3. Unclean/ non-profiled data4. Un-handled exceptions or Constraint violations5. Logical issues/ Inherent flaws in program6. Technical failures like loss of connectivity, loss over network, space issue etc.7. Failure due to any of the above issues can result into potential information loss leading to

unreliable data quality for business process decision making.

Data Loading

1.Data loading can be achievable different ways in SAP BW2.Loading data using process chain3.Loading data using DTP’s (Data Transfer Process)4.Loading Data using APD (Analysis process designer)

Major Problem during reconciling and loading data to target.While doing reconciliation following problem will occur with to respect to data

Problem SolutionProcess chain failure Most of the data loading performed in BW

between source to target table performed by process chain, we have make sure that loading parameter has been set, is there any existing failure in chain or activation failure in table , If everything clear then loading will be smooth and perfect.

Data activation failure in Table (DSO’s) This problem will occur mainly loading data using DTP or APD, So when ever we perform manual data load we must activate the data in target table else data inconsistence may occur

Wrong filter in DTP’s Due to wrong selection applied over the filter in dtp which cause the issue in reconciliation

Wrong field mapping in Transformation Wrong filed mapping in transformationMaster data unavailability and inactive data Empty master data table or inactive data in

table are causing the issue in data load as well as reconciliation

Failure in data extraction from source system Before loading data into BW we need to ensure data extracted from source system else

8

target table updated with 0 record

 Methods Used For Reconciliation

1. Manual reconciliation using different tables2. Using SQL statements3. BOBJ Reporting4. BEx Queries

Reconciliation between Systems Reconciliation between BW and various systems used in Customer Reporting Solution

1. Between ECC and SAP BW2. Within layers of SAP BW (LSA) 3. SAP BOFC and SAP BW 4. SAP BW and SAP BOBJ

Reconciliation between ECC & BW

9

· Reconciliation between ECC & BW using below methods1. Using T-Code RSA32. Using Tables3. Record count in Acquisition layer4. Manual checking of records details

Reconciliation within BW Layers

· Reconciliation within layers of BW using below methods1. Reconciliation by SAP BW tables via SQL developer2. Reconciliation by SAP BO WEBI Reports using MS Access3. Manual Reconciliation within layers by checking the record count and aggregation of data

10

Reconciliation BW & BOBJ

11

· Reconciliation between BW & BO using below methods1. Reconciliation by SAP BO WEBI Reports with BEx output2. Manual Reconciliation by checking the record count and aggregation of data

CHALLENGES· Architecture is more complex due to involvement of multiple applications (new), which makes

testing even more complex.· Some of the major challenges are:1. Integration of BW with different systems2. Newer applications makes testing more challenging and it requires more attention & skills3. Data reconciliation possesses a major challenge4. Extensive customization using ABAP5. Availability & Dependencies on other systems/applications for data

REFERENCE:REFER BELOW MENTIONED LINK WHICH WILL BE HELPFUL TO FIND RIGHT TCODE FOR SAP BW.

http://www.tcodesearch.com/

Test Data Management

Testing on relevant, production-quality data is the only way to ensure comprehensive and efficient testing. However, data in DEV is often too stale to use for unit testing, resulting in changes promoted to QA with little or no testing. Waiting for the next refresh is not an option and trying to manually create data is not only time consuming, but complex data is difficulty to accurately recreate.

TD maxim and CBlue along side with SAP TDMS provide data management capabilities that enhance testing and strategic process improvements. Designed to cancel out the need for workarounds, the software solution is built with the agility and flexibility to move configuration, master data, and specified selections of transactional data into testing environments.

SAP Teams can quickly select, secure and copy subsets of only relevant data from production or non-production sources to non-production targets. Any criteria can be used to identify data for replication. Using our Test data management solution, build the perfect test client and maintain relevant, up-to-date data for testing.

Dramatically reduce the time and effort to acquire test data Reduce development and bug-fix cycles by providing current data in DEV

12

Provide relevant data for testing of new functional implementations, new processes, rollouts, enhancement package upgrades or support packs

Snap, Slice, Segment copies of SAP Data

TD maxim and CBlue allows SAP users to quickly define and copy transactional data needed

from a source, such as production, to non-production targets. Offering the greatest flexibility

and ease for entering the data selection criteria, users are able to Snap, Slice or Segment data.

Data Snap is a very a quick method to pick a data type, enter simple data criteria such as

a document number, and export data. Data Snap is ideal for troubleshooting data issues,

for within minutes affected data can be in the QA system where the problem can be

safely debugged.

Intelligent Slice provides a single screen interface to create a dynamic and

comprehensive selection. Being able to easily incorporate many different data

hierarchies or data elements such as date range, company code, sales org, lists of

customer/vendors/materials, and so on, the data slice from a system is perfect for

performing a refresh.

Scenario Segment allows for defining a specific set of data for use in a particular need,

such as unit testing. A developer, for example, can quickly identify recent sales orders

from production that have an open delivery status. The “in process” sales orders can be

copied into a target, such as Sandbox or Development, for use in testing

All selection criteria are reusable, extendable, and dynamic. Data that meets the selection

criteria and all relative sub data is exported from the source and then imported to the target—

replicated exactly as it resides in the source. Using our clear and clean export-import process,

also allows an export to be used for multiple client imports, or even a quick reload of the data

Secure, Transform and Purge Data

Data Transform provides extensive and powerful data transformation in a clean and easy-to-use interface, making complex scrambling functionality as easy as point and click. Sensitive data can be scrambled or masked to preserve data security in potentially less secure systems.

Standard transformation rules, delivered and ready to use straight out of the box, can be modified or copied as the base for a user’s new rule creation. The field level scrambling rules,

13

which can be selected on the fly, transform or secure data at export—protecting sensitive data before it reaches the target system. Default rules can even be established and made mandatory allowing certain data to always be transformed at export.

Transformation options include: Blank, Fixed Value, Random Number, Random Date, List, Derived, Reference and executing a Custom Function.

Data Discard allows users to identify, select and delete data from non-production sources.

SUBSET SELECTION IN SAP BW

TD Maxim and CBlue allows business data warehouse teams to quickly select and copy subsets

of relevant data from Production or Non-Production sources to Non-Production targets.

Selection criteria are saved as reusable and modifiable Scenarios, defining exactly what data is

required. Data that meets the selection criteria and all relative data is exported from the source

and then imported to the target, without any impact on post processing steps.

With Data Recast, the BW team has the ability to maintain control over what data exists in their

target clients, for process owners have the ability to control specific selections of Master and

Transactional Data for replication to Development, QA, and Training clients. No longer will the

BW team need to wait on other teams or rely on business or administration assistance, as they

will be able to easily shift data per their requirements

TD Maxim Architecture:

14

15