OPSO-SAP BW Out bound interface and SAP BW Reporting

-by Hema Subhash 23rd April 2012

CONFIDENTIAL: For limited circulation only

© 2010 MindTree Limited

Slide 1

based out of Istanbul. CN and VN. TH.Introduction to SAP BW Reporting and OPSO’s role in it ● ● ● ● A set of 12 SAP BW Report were developed for use by Group 1 countries of MY/SG. As of now. Data from a set of 22 tables (interchangeably called as ‘Interfaces’) from the OPSO Staging Layer is interfaced with SAP BW via SAP PI at 2 00 AM SGT everyday. ID. These reports were developed by SAP BW teams. Turkey. Data for these reports is sourced from Opsolight+ Staging DB. post completion of the daily replication job. the SAP BW Support team. based out of Pune oversees issues related to this track. Report Name Budget Details Budget Report Commitment Phasing Report Category Brand By Objectives Customer Brand Performance Report Category Brand by Mechanics Category ScoreCard PromotionMatrix Budget Cube Promo & Budget Cube ROI Cube Promotion KPI Cube Budget Reports Technical names for the BW Reports ZOS_M001_Q006_70 ROI Cube ZOS_M001_Q004_70 Category Scorecard ZOS_M001_Q003_70 Performance Report ZOS_M001_Q001_70 Objective Report ZOS_M001_Q002_70 Mechanics Report ZOS_M002_Q001_70 budget report ZOS_M002_Q003_70 Budget Cube ZOS_M002_Q002_70 Budget Details ZOS_M003_Q001_70 Commitment Phasing ZOS_M004_Q001_70 Cube Budget& Promotion ZOS_M005_Q001_70 KPI & Evaluation Cube © 2010 MindTree Limited Slide 2 CONFIDENTIAL: For limited circulation only Cube Promotion Reports .

● Data for 22 tables listed below are interfaced from OPSOLight_Staging_group1 DB: KPIMaster BudgetHolder BudgetMaster PhasedBudgetMaster AccountBudgetHolderMapping Bundle Promotion PromotionKPI PromotionMechanicsDetails PromotionAccountAllocation PromotionInvestmentDetails PromotionInvestmentDetailProducts ROIBaselineStaging PromotionPlanningSalesTarget PromotionPlanningTimeLine PromotionQualitativeEvaluationResults ChildPromotion ChildPromotionAccountAllocation PostEvaluationScanData PromotionBudgetMapping PhasedPromotionBudgetMapping PromotionActuals CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 3 .What role OPSO plays in SAP BW Reporting The only role we have to play in SAP BW Reporting: ● Sending correct delta data to SAP BW via SAP PI. ● Data that is being sent to SAP BW. should be in agreement with the data in the transaction databases.

these records are either updated or newly created. 5.Delta Data logic implemented by Opso 1. Record with status "I" means. 2. 4. OPSO would be generating the delta record set with the status "I" & "D" only. OPSO Team would be providing the list of columns for each table to identify a unique record. 3. SAP BW has to identify the unique record based on this key combination and if the record already exists delete and re insert the whole record else only insert the record. SAP BW has to delete records based on the key combinations to identify unique record and with status "D" CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 4 .

Scenario . OPSO would be interfacing the latest values.0000000 1000. AccountID.1500000 947.7500000 Status I I I There is an increase/decrease in I value. ProductID . 2.Update on some records ID 307931 307933 307934 PromotionID BrandProductID 10041156 10041156 10041156 441638036A50321:20 441638036A50321:20 441638036A50321:20 AccountID ProductID E5786:20 E5796:20 E5798:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 AdjustedBaseLineDuring 760. Scenario .4500000 553.Delta Data logic implemented by Opso ROIBaselineStaging is taken as an example to explain the same. data at the BW end I would be updated or overwirtten with the new data sent from OPSO.7500000 Status I I I Slide 5 CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited . (Check Unique Key Identifiers for more details) 1.5000000 1500.5000000 1600.Combination of these columns would help in identifying a unique record.7500000 966.Initial load ID 307931 307933 307934 307935 307936 307937 307938 307939 307940 307941 307942 PromotionID BrandProductID 10041156 10041156 10041156 10041156 10041156 10041156 10041156 10041156 10041156 10041156 10041156 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 AccountID ProductID E5786:20 E5796:20 E5798:20 E5800:20 E5801:20 E5802:20 E5803:20 E5811:20 E5812:20 E5814:20 E5996:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 441638036A50321:20 AdjustedBaseLineDuring 755.6000000 959. to identify I unique record.4000000 533. I AccountID.6500000 696. I In this example. ProductID).0000000 956. PromotionID.0000000 1149. I I SAP BW has to identify whether it is an update or insert based by key I combination(in this case Promotion.6000000 1173.

2 00 AM SGT.6000000 959. ProductID the record has to be deleted. Application Table Application table deleted Job: OpsoSAPBWDelta_Job Description : Calls the SSIS package that identifies delta data and inserts the same into BWStaging tables. BW staging table Mode of Data movement : SSIS packages Data Moved : Incremental data – governed by Lastextracteddate in the Extractcontrolmaster.Delta Data logic implemented by Opso 3. Frequency : Daily.4500000 Status D D Based on the key combination (to identify unique record). Scenario . AccoutID. in this case PromotionID. CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 6 .Delete of some records ID 307940 307941 PromotionID BrandProductID 10041156 10041156 441638036A50321:20 441638036A50321:20 AccountID ProductID E5812:20 E5814:20 441638036A50321:20 441638036A50321:20 AdjustedBaseLineDuring 947.

Lastextracteddate: Specifies the date from which the delta data will be generated. else delta won’t be interfaced. Key columns: Interfacename: Lists names of the tables from which data will be interfaced Delta Push CCID: List of country company ids for which delta data will be interfaced. CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 7 . the extractcontrolmaster. Isactive: If ‘Y’ then delta for that interface will be pushed into the corresponding Bwstaging table. The lastextracteddate is updated by the package to indicate the date till which delta data has been pushed to the BWstaging tables (the start of current date).Extractcontrolmaster As the name suggests. controls the extract that will be pushed during that instance of job execution.

This delta data corresponds to delta starting from 1/1/2007 till 5/23/2011 3. that need to be processed by SAP PI. In the Countrycompanymasterbwstaging table. 2. The extract was created on 5/23/2011 InterfaceID InterfaceName CountryCompanyMaster DT20110523-INTF1-EXT1FC1 1 GUINumber RecordsCount Status DeltaStartDate DeltaEndDate 34 N 1/1/2007 5/23/2011 ExtractStartTime ExtractEndTime CreatedDate 5/23/2011 5/23/2011 5/23/2011 CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 8 . indicates the following: 1. there are 34 records with the GUID DT20110523-INTF1-EXT1-FC1.Reading data from SAPBWControltable • The sample records from the SAPBWControltable.

'PromotionActuals'. status • During business hours this query shouldn’t return any values. status from sapbwcontroltable where status in ('N'. GUIs. 'PromotionBudgetMapping'. 'BudgetHolderAttribute'. 'PhasedPromotionBudgetMapping'.'BudgetHolder'. 'Promotion'.'PromotionMechanicsDetails'. status. 'PromotionInvestmentDetails'. 'ChildPromotionAccountAllocation'. CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 9 . 'PromotionTimeLine'.10) GUIs. status order by interfacename . GUIs.'I') and interfacename in ('PromotionPlanningTimeLine'. GUIs [Date]. 'ChildPromotion'. count(*) [Number of GUIs not picked by SAP PI] from ( select interfacename. 'ROIBaseLineStaging'.'AccountBudgetHolderMapping'.left(guinumber. 'KPIMaster'. 'PromotionInvestmentDetailProducts'. 'PromotionAccountAllocation'. if it does please let the PI team know and perform a re-push of data if the status “I” and “N” records are loads before the last completed load. 'PromotionQualitativeEvaluationResults') )a group by interfacename. 'BudgetMaster'. 'PromotionPlanningSalesTarget'. 'PostEvaluationScanData'. 'Bundle'. 'PhasedBudgetMaster'.On-going support required 1/ Ensuring PI picks up data from OPSO Staging • At least once a week the query given below should be executed in Opsolightplus_staging_Group1 select interfacename. 'PromotionMechanicsDetail'. 'PromotionKPI'.

'PromotionPlanningSalesTarget'. 'PostEvaluationScanData'. count(*) [Number of GUIs not picked by SAP PI] from ( select interfacename. GUIs. 'ChildPromotionAccountAllocation'. 'Promotion'. CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 10 . 'PromotionInvestmentDetailProducts'. status from sapbwcontroltable where status in (‘F'. status • If this query returns any values then.'PromotionMechanicsDetails'. 'PromotionKPI'. 'BudgetHolderAttribute'. 'PhasedPromotionBudgetMapping'. 'PromotionInvestmentDetails'.'BudgetHolder'. 'Bundle'. 'KPIMaster'. 'PromotionAccountAllocation'.10) GUIs.‘S') and interfacename in ('PromotionPlanningTimeLine'. status order by interfacename . re-push of data starting from the delta date on which “F” and “S” records are found.On-going support required 2/ Ensuring the OPSO ETL doesn’t generate status ‘F’ and ‘S’ records and monitoring the OPSO_SAPBW_DeltaPush job on SGPSAPPW064 server. 'PromotionTimeLine'. 'PromotionMechanicsDetail'.'AccountBudgetHolderMapping'.left(guinumber. • Check the Delta data job for any failures at least once a week. 'PromotionBudgetMapping'. 'ROIBaseLineStaging'. 'ChildPromotion'. 'PromotionActuals'. 'PromotionQualitativeEvaluationResults') )a group by interfacename. 'BudgetMaster'. • At least once a week the query given below should be executed in Opsolightplus_staging_Group1 select interfacename. GUIs. 'PhasedBudgetMaster'. GUIs [Date]. status.

the data in PostEvaluationdata. the Postevaluationdata should be updated with the PS and Actual values received. is that post PS processing (45 days after end of a month). then incidents due to data mismatches between OPSO and BW reports can be minimized.On-going support required 4/ Apart from ensuring delta data loads have been successful. Evaluationdata and ROIBS and PA have to be synchronized as per “Primary Sales processing” process followed in OPSO. • If this process is followed diligently. CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 12 . • The agreed process as of now.

the ROI Cube report and the ROI Cube based reports are compared with the OPSO Promotion measures reports. * For mismatches between ROI Cube based reports and the Promotion measures report. * For mismatches in other reports. then at the OPSO end.Commonly encountered issues and their fixes 1/ Data mismatches between OPSO and SAP BW Reports • • Out of the 12 SAP BW reports. firstly check if the delta data for the promotion(s) with the mismatch has been flowing correctly. check the ROIBAselinestaging table. the delta pushed for the promotion should match the data in the transaction tables for this promotion. As an outcome of Step 1. In other words. consult the BW team for the source tables that feed into the respective BW report. the SAP BW Support team should confirm that the mismatch is not being caused due to an issue at the BW end. CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 13 . confirms that the issue isn’t being caused due to unexpected behavior at their end. As the first level of analysis. if the BW support team. Process chains failing at the BW end) Step 2. If mismatches occur between these BW reports and the OPSO Promotion measures report then the following checks need to be done in the order specified: Step 1. (Such as.

Therefore run the following queries for the promotionid in error: Opsolightplus_Group1: Select sum(GSVBefore+GSVDuring+GSVPost) from ROIBAselinestaging Where promotionid= <<>> Select GSVActaul from Postevaluationdata Where promotionid=<<>> CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 14 . This is done by comparing the KPI’s in the two tables. For e. ActualGSV in Postevaluationdata is calculated as the sum(GSVBefore+GSVDuring+GSVPost) from the ROIBS table in the SP: usp_getinsertpostevaluationdata. If the mismatch is not being caused due to delta data issues. then check if the data is synchronized between the Postevaluationdata and the ROIBaselinestaging tables.g.Commonly encountered issues and their fixes Step 3.

CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 15 . Then once the entire formula for the mismatching measure is understood. Then if the measure is derived from the Postevaluationdata or evaluationdata tables then. 2. by looking at the usp_getinsertpostevaluationdata and usp_Getinsertevalutiondata SPs. understand how these measures are arrived at from the ROIBS and PA tables.Commonly encountered issues and their fixes Step3 explained in detail. Validate if it is logically correct to compare that BW measure with the OPSO measure reported. then ask for the OPSO measure that it is being compared with. 1. 3.. 5. then understand the way the OPSO measure is derived at by looking at script for usp_promotionmeasures 4. If yes. When mismatches are reported for a certain BW measure. then try to see if the measure in the Postevaluationdata is as expected.

since we don’t perform Postevaluation processing for these promotions. the whenever data is being modified in the 22 transaction tables in concern here. As a solution to this. This could happen due to two reasons: 1. The SP that updates the modifieddate in the transaction tables is not updating the modified date as expected. 2. Mismatches are expected for these promotions. Due to changes in the data from the back-end without diligent changes being made to the modified date. 3/ Modified Date in transaction tables not getting updated when data in it is updated.Commonly encountered issues and their fixes 2/ Non-ROI promotions in SAP BW ROI Cube reports • • As per the BW report design. CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 16 . the modified date should also be updated so that the right data flows to the downstream systems. Non-ROI Promotions are also present in the ROI Cube report and other related reports.

causing divide by zero error at the BW end due to which data will not be uploaded to the BW targets. • If there are any records that remain to be processed in either status “N” or “I” after the scheduled PI loads. thus causing mismatches. CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 17 . • • As a workaround. these NULL or 0 conversion factors in the ROIBaselinestaging table are updated to 1. And the modifieddate of all the updated records are updated to getdate() so that the updated information flows to BW during the successive delta load. If conversion factors have not been shared by SAP ECC for SKU with this issue then the concern needs to be raised with the SAP ECC team. 5/ Null or 0 conversion factors in ROIBaselinestaging.Commonly encountered issues and their fixes 4/ Incomplete processing by SAP PI team. then we would need to do a re-push starting from the date on which GUIs in these statuses were identified.

causing data mismatches. 00:50:00 IST contains data from the 19 th of October till the 22nd of October.g. For e.Commonly encountered issues and their fixes 6/ Data across multiple days being processed at once by the PI team. In this case there will be duplicates in the payload since the same budget ids could have undergone modifications between the dates of 19th till 22nd October. In order to avoid this from recurring the data that is pushed from Opso (on a daily basis) has to be loaded daily so that the duplicates are not present in a single payload. The payload that was processed on 23 Oct 2011. The screen shot below shows that the single payload has data for the 19th of October 22th of October  CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 18 .

data mismatches have occurred due to mismatches in key combinations between OPSO and BW. to ensure that the key combinations for the interfaces are as expected. CONFIDENTIAL: For limited circulation only © 2010 MindTree Limited Slide 19 . due to incorrect join conditions in the SP: usp_SAPBWReportingGenerateDeltaExtractQueries (in Opsolightplus_staging_Group1 Db). This job ensures that the Service queues that were disabled due to poison messages are reenabled and the deleted messages that are buffered are sent to the application deleted tables before they are replicated into the staging layer. 8/ Data being missed out in the OPSO Delta loads. • As a fix for this issue a job Job_RP_EnableServiceBrokerDeleteQueue was created and scheduled to run at 11 00 PM SGT before the start of the replication job. 9/ Deleted records not flowing into the Applicationdeleted tables in the transaction DB. • The solution for this is a design change at the BW end. due to which data is not updated or deleted as expected. This query is responsible for creating the delta data for all the interfaces.Commonly encountered issues and their fixes 7/ Previously.