sap bw spos for point of sales (pos) data in sap demand signal management (dsim)

7/18/2019 SAP BW SPOs for Point of Sales (POS) Data in SAP Demand Signal Management (DSiM)

http://slidepdf.com/reader/full/sap-bw-spos-for-point-of-sales-pos-data-in-sap-demand-signal-management-dsim 1/62

SAP BW SPOs for Point of Sales (POS) data inSAP Demand Signal Management (DSiM)

A detailed step-by-step how-to guide



SAP BW SPOs for Point of Sales (POS) data in SAP Demand Signal Management (DSiM)

2

TABLE OF CONTENTSINTRODUCTION ......................................................................................................................................... 4SPOs General description ......................................................................................................................... 4Motivation................................................................................................................................................... 5

PREREQUISITES ........................................................................................................................................ 6

BUSINESS USE CASE ............................................................................................................................... 6

APPROACH ................... ........ .............. .............. .............. ............... ....... .............. ....... ............... ....... .......... 7

IMPLEMENTATION ..................................................................................................................................... 8Data Delivery Agreements ......................................................................................................................... 8Modeling ..................................................................................................................................................... 9 Acquisition Layer ......... .............. .............. ............... ....... ....... .............. ............... ....... .............. .............. ....... 9

DataSources ................................................................................................................................................ 9

InfoSources & Transformations ...................................................................................................................11

SPOs ..........................................................................................................................................................12

Propagation layer ........................................................................................................................................18InfoSources & Transformations ...................................................................................................................18

SPOs ..........................................................................................................................................................22

Quality Validation ........................................................................................................................................30Overview ....................................................................................................................................................30

DataSources ...............................................................................................................................................31

InfoSource & Transformations .....................................................................................................................35

SPO............................................................................................................................................................37Stored procedures ......................................................................................................................................42

Process Flow Controller ...........................................................................................................................56Customizing ................................................................................................................................................56Process definition .......................................................................................................................................56

Data Delivery Agreement ............................................................................................................................57

Data Set File ...............................................................................................................................................58

Steps Instantiation ......................................................................................................................................59

ADDITIONAL LINKS .............. .............. .............. ....... .............. ........ .............. .............. .............. ............... ..61




3

Appl ies to:SAP Demand Signal Management (DSiM) version 1.0

Summary:

This document describes the necessary steps, with all related technical details, on how to deploy SAP DSiM(Demand Signal Management) solution using SPOs (Semantically Partitioned Object) instead of regular DSOs to upload POS (Point of sales) data

Authors Amina Bounadja Dr. Yue Chenamina,bounadja@sap,co m yue,ch en@sap,comSAP Canada Inc. SAP AG

Created: January 2014




4

INTRODUCTION

Supporting our customers in their quest to implement the most efficient business processes is one of thecore values of SAP. SAP Demand Signal Management (DSiM) powered by SAP HANA enablescompanies to upload, harmonize, enrich and analyze large amounts of external demand data in order toimprove supply chain, sales, marketing and other business processes. With DSiM, customers can getdeeper, faster and more accurate insight on what is going on in the market (e.g. competitor information or market share information) and also what happens directly on retailer store level. This enables them to reactfaster to any changes in end-consumer demand.

DSiM is a solution and a repository. It allows, this way, to collect and integrate disparate data and storethem into one consistent and centralized repository. This is in order to provide at the end a one DataProvider powered by some analysis for Consuming Applications (e.g. SCM-APO, CRM-TPO).The DSiM repository is an in-memory database leveraged by the power of SAP HANA and from BWperspective; it consists of dedicated DSOs (DataStore Objects) for each layer or processing step within thedata flow.Throughout this document, we will show that DSiM solution can also be utilized and deployed using SPOs(Semantically Partitioned Objects) instead of regular DSOs. We will describe the different and neededadjustments to achieve this, and provide all the technical details and steps on how to do it. This by the meanof a business case as described below.Before getting into the details, let’s have a quick look to What is an SPO?, and explain Why SPOs inDSiM?.

SPOs General description

Below, some key points that we chose to describe SPOs:

New BW objects introduced since BW 7.3

InfoProviders that consists of several InfoCubes or DataStore objects with the same structure

Semantic partitioning is a property of the InfoProvider. It divides the InfoProvider into several small,

equally sized units (partitions) with same structure.

An SPO partition is characterized by partitioning criteria:

oOnly key fields are allowed for a DataStore object

o Individual values and intervals can be used

o Partitions must not overlap




5

SPO components

Source: SAP Education

MotivationHere are some points to highlight the adding values when making usage of SPOs within DSiM:

o Allo w higher data volume by eliminating the technical upper limits of 2 billion records per DSO

o Have independent decoupled data uploads to:

o Reach Higher speed of data upload, through several uploads triggered in parallel, and reduce the

amount of time required to make data available for reporting

o Better Error Handling & Robustness of upload. Indeed, if a request of a given upload ends with an

error, for example, the entire InfoProvider is unavailable for further uploads as well as for analysisand reporting. With a semantically partitioned object, the separation of the data into different

partitions means that only the given partition that caused the error is unavailable.

o Time zones support (report availability). EDW scenarios usually involve several time zones. With asemantically partitioned object, the time zones can be separated by the partitions. Data loading andadministrative tasks can therefore be scheduled independently of the time zone.




6

PREREQUISITES

1. This document is not intended as a general presentation of SPOs. Therefore we highly recommendyou first get familiar with the semantically partitioned object (SPO) wizard. Some useful links for thispurpose have been selected and gathered under the additional links section at the end of thisdocument.

2. A good understanding of the DSiM data model and the DSiM data upload process is also a must aswe will not go deep in such details. We will rather use DSiM concepts assuming that you are alreadyfamiliar with.

BUSINESS USE CASE

Taste Inc. is a multinational Consumer Products Company/ Manufacturer that produces chocolate and cakeproducts and sells them through retailers. Taste Inc. has retailers worldwide in different regions acrosscontinents. Nevertheless, the most important ones are mainly located in US and Europe. This makes thedata volume of demand data, which Taste Inc. expects/receives, much higher from retailers of these tworegions than the rest of the retailers which are located in different regions than Europe and US.

Taste Inc. uses the standard SAP Demand Signal Management solution to upload process and analyze the

POS demand data. To make a usage of DSiM solution more suitable to Taste Inc. business context, wesuggest deploying the solution using SPOs instead of regular DSOs. This will allow providing multiple datastorage areas (partitions) and dedicating this way one to each region: “EU” (Europe), “US” and one partitionfor the rest of the regions, that we will call “Other”, as shown below.

Note:Data enrichment and Reporting layer are grayed out since they are not in scope for this document




7

APPROACH

To implement the data flow above, we will make use of the Data Delivery Agreement attribute Context (alsocalled CDPA) to ensure data flow split. Below, a high overview on the approach before tackling the technicalsteps and details:

1. For each region we define a group of CDPAs, and related dada delivery agreement, in thecustomizing

2. We use the characteristic CDPA as criteria for SPOs partitioning in each layer and generate relatedDTPs and process chains

3. We set up the DSiM Process Flow Controller in a way that, on runtime, for each region/CDPA, of thehandled Data delivery agreement, the accurate steps/process chains are instantiated/executed

Note:The approach we describe below is not the only way of realizing this business use case. There are other solutions that are possible and need to be validated in a customer project accordingly. Moreover, SPOs canbe used differently and for other business use cases in DSiM. As well, this approach is valid only for point of sales (POS) data. Indeed, market research data is out of

scope of this document.

As highlighted in the data flow above, data partitioning will take place at each layer of the DSiM solution for POS data upload process. In other words, following DSOs will be replaced by SPOs:

DSO

Technical name Description

/DDF/DS01 Sales Data - Acquisition

/DDF/DS11 Sales Data - Propagation

/DDF/DS02 Stock Data - Acquisition

/DDF/DS12 Stock Data - Propagation

/DDF/DS81 Quality Validation



SAP BW SPOs for Poin t of Sales (POS) data in SAP Demand Si gnal Management (DSiM)

8

IMPLEMENTATION

In this section we will illustrate a step by step what has to be done to implement the data flow designedabove using DSiM&SPOs.Data Delivery AgreementsNote:We will illustrate the complete DSiM Process Flow Controller customizing needed, with all necessary details,under the accurate section below; nevertheless, we just wanted to describe the CDPAs definition as theseare prerequisites before the SPOs modeling can start, since partitioning is based on this.Based on the data flow above and considering the DSiM data delivery agreement we can have/create:1 – As many regions as we want (Up to 99 since it is the upper limit of partitions that an SPO can have)2 – Several CDPAs for each region as many as we want/need2 – For each CDPA, we can define as many data delivery agreements as we want/needNevertheless, for more conveniences, and to make our example concise and easy to understand, we choseto go with the setup below:

Region CDPAs Data Deli very Agreement

ID Descript ion

US TASTE_US_1 TASTE_TX Taste Inc. US - Texas

TASTE_US_2 TASTE_AZ Taste Inc. US - ArizonaEU TASTE_EU_1 TASTE_FR Taste Inc. EU - France

Other TASTE_OTHER TASTE_DB Taste Inc. UAE - Dubai

Below how the mentioned data delivery agreements would look like in the system




9

ModelingIn this section we will describe the SPOs modeling and creation. As previously mentioned the assumption isthat you are already familiar with SPOs as the section below is not intended as a “how to” for SPOs, butrather focuses on key points on how to scale POS DSOs in DSiM with SPOs. Acqu is it ion Layer The DSOs in focus for this section are the ones below:

DSO Technical name Description

/DDF/DS01 Sales Data - Acquisition

/DDF/DS02 Stock Data - Acquisition

To avoid redundancy, we will describe a step by step “how to” only for the Sales DSO but you can do thesame for the Stock DSO:

DataSources

1 – Copy DataSource /DDF/SALES, with “TEST_CSV” as source system. Don’t do any change to thesettings, rename/change description as desired and activate.

Note:You can create one DataSource and use it to load data into the 3/all partitions together. Technically this isfeasible/possible. However, for performance reasons, we recommend you create one DataSource for each

partition. Indeed, as we will see later on, the acquisition DTP has Delta as extraction mode. Hence,requests of a given partition will always be handled by the system for an upload attempt into the other partitions. Of course, no upload is done; nevertheless time for processing is consumed.




10

2 – For each DataSource, create an infopackage and in the extraction tab, enter the code below for the filedetection routine

After repeating these steps for Stock DSO as well, you will end up with 6 DataSources and 6 InfoPackagesas shown below:

* File detection routine to get Filename from PFC Run Time DATA lo_bi_api TYPE REF TO /ddf/cl_adu_bi_api. DATA lv_filename TYPE /ddf/filename. DATA lr_cx_adu_bi TYPE REF TO /ddf/cx_adu_bi. DATA ls_msg TYPE rspc_s_msg. CREATE OBJECT lo_bi_api. TRY. CALL METHOD lo_bi_api->get_filename_by_request EXPORTING iv_request_id = p_request RECEIVING

rv_filename = lv_filename. p_filename = lv_filename. p_subrc = 0. CATCH /ddf/cx_adu_bi INTO lr_cx_adu_bi. CALL METHOD lr_cx_adu_bi->convert CHANGING xs_msg = ls_msg. sy-msgno = ls_msg-msgno. sy-msgid = ls_msg-msgid. sy-msgty = ls_msg-msgty. sy-msgv1 = ls_msg-msgv1. sy-msgv2 = ls_msg-msgv2. sy-msgv3 = ls_msg-msgv3. sy-msgv4 = ls_msg-msgv4.

p_subrc = 4. EXIT. ENDTRY.




11

InfoSources & Transformations

1. Copy the first InfoSource IN for the Acquisition Sales DSO, highlighted below, rename as desiredand activate

2. Copy the related transformation, highlighted above where:

a. Target is the InfoSource you created aboveb. Source is the partition DataSource

and activate

3. Repeat step 3 for every you have (in our case 3)

4. Copy the second InfoSource IN for the Sales DSO, highlighted below rename as desired andactivate

5. Copy the related transformation, highlighted above where:a. Target is the InfoSource you created above (point 3)b. Source is the InfoSource you created above (point 1)

and activate




12

After repeating these steps for Stock DSO as well, you will end up with a data flow similar to the one belowfrom DataSources up to InfoSource IN for the SPO:

Up to here we have all necessary BW objects to create the SPOs, so let’s start!

SPOs

1. Copy the standard Sales DSO. Give it an appropriate name and description and most important

check the “Semantically Partitioned” flag highlighted below:




13

2. Create the partitions for the regions we set above where CDPA is the characteristic criteria andusing the CDPAs we previously created as shown below. Activate to physically create the partitions:

3. Create transformation where the target is set per default and the source is the InfoSource IN 2 youpreviously created and activate

4. Create the DTPs, but first create a DTP template which is the parameters configuration thatcorresponds to the settings that can be configured in a DTP. These settings are applied when DTPsare generated and they are same as the standard DSiM DTP from DataSource to acquisition DSO :




14




15

5. Now we reached the last step and that consists in generating the process chains: one for each DTPas shown below:

Note:It is technically possible and feasible to create one process chain to include all DTPs. However, tohave independent decoupled data uploads, and benefit from all adding values we mentionedabove, we highly recommend creating one process chain for each DTP. Indeed, this way you ensurethat there is no overlap between the different process chains and that they therefore can beexecuted in parallel. This will allow Process Flow Controller to trigger uploads in all partitions inparallel, whereas with one process chain an upload for a given partition can only be triggered if noother partition/upload is already making usage of the process chain




16

At this stage, we are done with the acquisition layer and have the related SPO! The data flowresulting should look like the below:

6. Adjust the process chains, generated via the SPO wizard, to complete them by adding:a. The accurate InfoPackageb. And the DSiM process type “Update step status”, with both variants/status values: 0070 (Status

Complete) and 1400 (Status Error - Data Delivery Agreement Level (Subsequent Steps)):




17

Hint:

1. The process chains generated via the SPO wizard are all located under the display component shownbelow:

2. We suggest you create new process chains to include/wrap the infopackage, process chain generated bythe SPO wizard and the DSiM process type “Update step status”. The completed process chains shouldlook like the one shown below:




18

3. For a clean set up and better visibility, we recommend to create your own display component and move allyour process chains there. Below how it for instance our look like:

Propagation layer The DSOs in focus for this section are the ones below:

DSO


/DDF/DS11 Sales Data - Propagation

/DDF/DS12 Stock Data - Propagation

To avoid redundancy, we will describe a step by step “how to” for the Sales DSO and you can do the same,adjusting, to the Stock DSO:

InfoSources & Transformations

1. Copy the first InfoSource IN for the Propagation Sales DSO, highlighted below, rename as desiredand activate

2. Copy the related transformation, highlighted above where:a. Target is the InfoSource you created aboveb. Source is the partition of the Acquisition Sales SPO you previously created

and activate

3. Repeat step 2 for every partition you have (in our case 3)




19

4. Copy the second InfoSource IN for the Sales DSO, highlighted below, rename as desired and save.Do not activate yet!

If we check this infocource we will notice that InfoObject /DDF/CDPA is not part of the availableones. We therefore need to add it first and then activate




20

Resulting InfoSource will look like the below:

Note:The CDPA is set as a key field for the two following reasons:

a. It will later on be used for SPO partitioningb. SPOs can be partitioned only via characteristics that are part of the key fields

5. Copy the related transformation, highlighted above where:a. Target is the InfoSource you created above (point 4)b. Source is the InfoSource you created above (point 1)

Don’t activate yet!

6. Adjust transformation to include/link CDPA and activate




21

After repeating these steps for Stock DSO as well, you will end up with a data flow similar to the one belowfrom acquisition SPOs partitions up to InfoSource IN for the SPO:

Up to here we have all necessary BW objects to create the SPOs, so let’s start!




22

SPOs

1. Copy the standard Propagation Sales DSO. Give it an appropriate name and description andmost important check the “Semantically Partitioned” flag highlighted below:

2. Adjust the SPO to add CDPA characteristic to the key fields as shown below




23

3. Create the partitions, same as you previously did, for the regions using CDPA as shown belowand activate to physically create the partitions:

Hint:Before you activate the partitioning we suggest, for sake of higher performance, to perform a DBpartitioning using characteristic 0CALMONTH as shown below. This is possible, because0CALMONTH is already part of the DSO characteristics whereas for acquisition layer this is not the

case.




24

4. Create and activate transformation where the target is set per default and the source is theInfoSource IN 2, you previously created for propagation SPO

5. Create the DTPs, but first create a DTP template which is the parameters configuration thatcorresponds to the settings that can be configured in a DTP. These settings are applied whenDTPs are generated and they are same as the standard DSiM DTP from Acquisition DSO toPropagation DSO:




25




26

6. Adjust the DTPs filter to add the business logic below for Delivery and for Process ID same as itin the DSiM standard DTPs for propagation layer

* Business logic for Deliverycal l method / ddf / cl _bw_dt p_f i l t er =>f i l t er _by_known_del i very

expor t i ng i r_ request = i _r _r equest i _ f i el dnm = i _ f i el dnm

i mpor t i ng e_subr c = p_subr c

changi ng ct_range = l _t _range[ ] .

* Business logic for Process IDcal l method / ddf / cl _bw_dt p_f i l t er =>f i l t er _by_known_pr ocess_i d

expor t i ng

i r_ request = i _r _r equest i _ f i el dnm = i _ f i el dnmi mpor t i ng

e_subr c = p_subr cchangi ng

ct_range = l _t _range[ ] .




27

Make sure you do this for all DTPs of the propagation layer, following what is highlighted below:

7. Now we reached the last step and that consists in generating the process chains: one for eachDTP as shown below:

Note: As previously mentioned, it is technically possible and feasible to create one process chain to

include all DTPs. However, to have independent decoupled data uploads, and benefit from alladding values we mentioned above, we highly recommend creating one process chain for eachDTP. Indeed, this way you ensure that there is no overlap between the different process chains andthat they therefore can be executed in parallel. This will allow Process Flow Controller to trigger uploads in all partitions in parallel, whereas with one process chain an upload for a given partitioncan only be triggered if no other partition/upload is already making usage of the process chain




28

At this stage, we are done with the propagation layer and have the related SPO! The data flowresulting should look like the below:

8. Adjust the process chains generated via the SPO wizard, to complete them by adding the DSiMprocess type “Update step status”, with both variants/status values: 0070 (Status Complete) and1400 (Status Error - Data Delivery Agreement Level (Subsequent Steps)):




29

Hint:

a. The process chains generated via the SPO wizard are all located under the display component shownbelow:

b. We suggest you create new process chains to include/wrap the process chain generated by the SPOwizard and the DSiM process type “Update step status”. The completed process chains should look like theone shown below:

c. For a clean set up and better visibility, we recommend to create your own display component and move allyour process chains there. Below how it should/could look like:




30

Quality ValidationOnly one DSO is in focus for this section and is the one mentioned below:

DSO


/DDF/DS81 Quality Validation

Note:

1. Quality Validation is technically part of the Acquisition Layer. Nevertheless, for a better structureand visibility of the document we chose to allocate a dedicated section, to ease theunderstanding.

2. In all coming sections we will refer to Quality Validation by the abbreviation QVOverview

The QV process has actually two aspects when it comes to the usage of SPOs. On one hand, it requiressome adjustments because we now have new data storage areas, after we introduced SPOs in theacquisition and propagation layer, and therefore the business logic needs to be adjusted to consider them,instead of DSiM regular/standard DSOs. On another hand it also requires some adjustments to introduce anSPO, to store the QV KPIs, instead of the regular DSO DS81.These two adjustments are independent and whereas the first adjustment is mandatory the second oneis optional. Indeed, without it the QV process will still be properly functional. Nevertheless, we highlyrecommend to implement it as it allows to have independent decoupled data uploads, and benefit from alladding values mentioned at the beginning of this document.




31

In the section below we wanted to first list the main settings that we need to perform in order to deploy thispiece of the process using SPOs and will afterwards describe for each of them the necessary technicalsteps. This is to allow you get a picture of what needs to be done, and where, beforehand

1. CDPA is not part of the characteristics in DS81. Hence, to substitute DS81 by an SPO we willneed to add it in all places starting from data source up to the new SPO

2. The QV business logic or checks are wrapped into some HANA Stored Procedures. Thesestored procedures read or consider only data from the acquisition standard DSiM DSOs. Since byintroducing SPOs we now have new data storage areas, we will need to:

a. Provide new HANA Stored Procedures, based on the DSiM standard ones, to read from the

accurate SPO storage areas

b. Make sure the new provided stored procedures are called instead of the DSiM standard ones

during the QV process

3. QV status is computed via some business logic included and executed via the DSiM process type/DDF/QVDEC highlighted below.

Same as for the stored procedures, this process type reads or considers only data from theacquis ition standard DSiM DSOs. We will therefore need to:

a. Copy the DSiM process type to a new `Z` one

b. Adjust related business logic to read from the accurate SPO storage areas

c. Use the new process type in the generated process chains instead of the standard one

Note:

1. From the list above, only point 2 is part of the mandatory adjustment, whereas points 1 and 3 are

needed only if you decide to substitute DS81 by an SPO

2. In case for any reason you don’t plan to substitute DS81 by an SPO, you can skip the sections below

and jump directly to the stored procedures one.

DataSources

1. Use transaction code SE11 and copy structure /DDF/S_QV_KPI_ES, rename and save

2. Enhance the new structure by adding the CDPA field as shown below:




32

3. Use transaction code SE37, copy Function Module /DDF/QV_KPI rename and save. Adjust the codeof the new FM to add business logic to fill the CDPA field newly added. Below we highlight the linesof code to add/adjust and you can refer to the code line number to ease the task. These adjustmentsare minor, not complex and don’t change the standard business logic.

Note:

Another alternative to the FM code change is BADI RSU5_SAPI_BADI that you can use/explore




33




34

For more conveniences we posted below the code statements that need to be added/adjusted:

4. Use transaction code RSO2 to create a transactional DataSource similar to/DDF/DATA_QUALITY_VALIDATION . Use the new extractor structure and the new function moduleand save

5. Repeat step 4 for every partition you have (in our case 3)

Note:You can create one DataSource and use it to load data into the 3/all partitions together. Technically thisis feasible/possible. However, for performance reasons, we recommend you create one DataSource for each partition . Indeed, as we will see later on, the QV DTP has Delta as extraction mode. Hence,requests of a given partition will always be handled by the system for an upload attempt into the other partitions. Of course, no upload is done; nevertheless time for processing is consumed.

6. Replicate the BW DataSources you created by following one of the ways below:

a. Choose Replicate Metadata in the Data Warehousing Workbench (transaction RSA1) in the

DataSource tree through a DataSource context menu.

b. Or transaction RSDS where you can select the DataSource to replicate

7. For each DataSource, create an infopackage and in the Data selection tab, for the selectionhighlighted below, enter the related ABAP routine posted right after:

*SPO - Add new variable to fecth data delivery agreement attributes => 1* DATA lv_data_agreement TYPE /ddf/data_agreement.

DATA l s_dat agr eement _data TYPE / ddf / s_dat agreement_ data.

*SPO - Use the new structure that holds CDPA => 2* DATA ls_kpi_data TYPE /ddf/s_qv_kpi_es.

DATA l s_kpi _dat a TYPE zspo_qv_kpi _es .

*SPO - Use the new structure that holds CDPA => 3 * STATICS st_kpi_data TYPE /ddf/t_qv_kpi_es.

STATI CS st _kpi _dat a TYPE zspot_ qv_kpi _es.

"SPO - Read data delivery agreement attributes to get the CDPA => 4* ev_data_agreement = lv_data_agreement

es_dat agr eement _dat a = l s_dat agr eement _dat a ) .

"SPO - Replace by the new variable that holds the DDAGR => 5 * iv_ddagr = lv_data_agreement

i v_ddagr = l s_datagr eement _data- dat agr mnt - ddagr

"SPO - Add a new line to fill the CDPA => 6 l s_kpi _dat a- cdpa = l s_dat agr eement _data- dat agr mnt - cdpa.




35

InfoSource & Transformations

1. Copy the InfoSource highlighted below, rename as desired and save. Do not activate yet!

If we check this infocource we will notice that infoObject /DDF/CDPA is not part of the availableones. We therefore need to add it first and then activate

* Business logic for both: Data Delivery ID & Process IDCALL METHOD / ddf / cl _bw_pf c_cal l =>deri ve_f r om_i nf opackage

EXPORTI NG i v_i nf opackage = p_i nf opackage i v_f i el dnm = p_f i el dname

I MPORTI NG ev_subrc = p_subr c

CHANGI NG

ct _r ange = l _t _range[ ] .




36

Resulting InfoSource will look like the below:

Note: As previously mentioned, the CDPA is set as a key field for the two following reasons:

a. It will later on be used for SPO partitioningb. SPOs can be partitioned only via characteristics that are part of the key fields

2. Copy the related transformation, highlighted above where:a. Target is the InfoSource you created above (point 1)b. Source is the partition DataSource

Don’t activate yet!

3. Adjust transformation to include CDPA and activate

4. Repeat step 2 for every partition you have (in our case 3), and activate




37

After completing all the steps, you will end up with a data flow similar to the one below from DataSources toInfoSource IN for the SPO:

SPO

1. Copy the standard QV DSO. Give it an appropriate name and description and most importantcheck the “Semantically Partitioned” flag highlighted below:




38

2. Adjust the SPO to add CDPA characteristic to the key fields as shown below

Create the partitions, same as you previously did, for the regions using CDPA as shown below and activateto physically create the partitions:

3. Create and activate transformation where the target is set per default and the source is theInfoSource IN, you previously created for QV SPO

4. Create the DTPs, but first create a DTP template which is the parameters configuration thatcorresponds to the settings that can be configured in a DTP. These settings are applied whenDTPs are generated and they are same as the standard DSiM DTP from QV DSO:




39




40

5. Now we reached the last step and that consists in generating the process chains: one for eachDTP as shown below:

Note: As previously mentioned, it is technically possible and feasible to create one process chain toinclude all DTPs. However, to have independent decoupled data uploads, and benefit from alladding values we mentioned above, we highly recommend creating one process chain for eachDTP. Indeed, this way you ensure that there is no overlap between the different process chainsand that they therefore can be executed in parallel. This will allow Process Flow Controller totrigger uploads in all partitions in parallel, whereas with one process chain an upload for a given

partition can only be triggered if no other partition/upload is already making usage of theprocess chain




41

At this stage, we are done with the Quality Validation and have the related SPO! The data flow resultingshould look like the below:




42

Stored proceduresThe HANA Stored Procedures are one of the key elements in the process o f QV. This is where the data isread and checked, based on some rules, to provide KPIs to the outside. Below a screenshot to show wherethese stored procedure reside in the HANA content:




43

The list of the executed HANA Stored Procedures and the order or sequence of their execution is controlledby a customizing that resides under the IMG path shown below:

The focus in this section is not to explain this customizing, as you have the freedom to set this up at your conveniences to fit your own business context, but instead the focus here is to:

1. Identify the stored procedures that need to be replicated to read data from the SPOs newlyintroduced

2. Highlight the adjustments that need to be done to the new stored procedure

3. Show how to proceed to have them called instead of the standard ones

Each of these points will be explained by a step by step ``how to`` below:

Stored procedures to adjust

To identify these stored procedures we need to identify all the ones, among the list shown above, that readdata form the Sales and/or Stock DSOs. In more details, all stored procedures that fetch data from HANA DBtables of DS01 and DS02. Below how to proceed:

1. First thing to do is to identify HANA DB tables of DS01 and DS02. For this just follow the stepshighlighted through the screenshots below




44

Write down the DB table name and proceed the same way for DS02




45

2. Open a stored procedure in the HANA Studio as shown below:

3. Use the find feature to check if one of the HANA DB tables, (/1DD/ADS0100 & /1DD/ADS0200), youpreviously noted down, is used into the given stored procedure. If the search is successful writedown the name of the stored procedure

4. Repeat step 2 and 3 for all stored procedures you need

Hint:To minimize the effort, we suggest you first set up your QV customizing to have the exact list of thestored procedures you need/want to call and then apply step 2 and 3 above to check only the exactlist for the stored procedures you require

We did the exercise above for our implementation and here is the list of the stored procedures we found out:

DETERMINE_HISTORIC_DELIVERY_IDSDETERMINE_MIN_MAX_DATE_FROM_POS_DATAKPI_NO_OF_POS_WITHOUT_LOCATION_MASTERKPI_NO_OF_POS_WITHOUT_PRODUCT_MASTERKPI_NO_OF_PRODUCTS_WITH_QUANTITY_GT_ZEROKPI_NO_OF_STK_WITHOUT_LOCATION_MASTERKPI_NO_OF_STK_WITHOUT_PRODUCT_MASTER

Considering that we plan:

a. to upload only transactional POS data (Market Research data is not in scope for this document).b. and to use the QV sequence shown below:




46

Our final list o f the stored procedure that needs to be replicated is as follows:Related to Sales DSO:KPI_NO_OF_POS_WITHOUT_LOCATION_MASTERKPI_NO_OF_POS_WITHOUT_PRODUCT_MASTERRelated to Stock DSO:

KPI_NO_OF_STK_WITHOUT_LOCATION_MASTERKPI_NO_OF_STK_WITHOUT_PRODUCT_MASTER

Replicate stored procedures

As we previously proceeded, to avoid redundancy, we will describe a step by step “how to” for the SalesDSO and you can do the same, adjusting, to the Stock DSO:

1. First thing to do is to identify the HANA DB tables of all DSOs/SPOs you have. For this, you canproceed as we previously highlighted. Below a summary of all HANA DB tables we need:

DSO SPO Partitions

name HANA DB

table

HANA DB table Partition name

DS01(Sales) /1DD/ADS0100 /BIC/AZTDS010100 EU/BIC/AZTDS010200 US

/BIC/AZTDS010300 Other

DS02

(Stock)

/1DD/ADS0200 /BIC/AZTDS010100 EU

/BIC/AZTDS010200 US

/BIC/AZTDS010300 Other

2. Define a new package under the HANA content and copy the stored procedures previouslyidentified. Since we have 3 partitions in our SPO we will need one stored procedure per partition. After completion of this step you will have something that looks like below:




47

3. In each of the newly created stored procedure replace the Sales DSO HANA DB table with theaccurate Sales SPO partition HANA DB table

Hint:You can use the find/replace feature here and have to be very careful as any mistake might

lead to a wrong process that might not be easy to find out later on

4. Check and activate

Call the new stored procedures

To ensure that your stored procedures are called instead of the DSiM standard ones you need to implementBADI /DDF/CALL_PROCEDURE provided in DSiM for this purpose. This BADI is provided under the IMGpath below and we highly recommend you take a look to the related documentation before you start:

Below a code snapshot for each method OF this BADI that we provided for our SPOs setup described in thisdocument

GET_SP_NAME (Mandatory)

METHOD / ddf / i f _cal l _pr ocedure~get_sp_name.

DATA l v_spo_sp_pat h TYPE s t r i ng.

DATA l v_spo_sp_name TYPE s t r i ng.

ev_sp_name = i v_sp_name.

*Assign the SPO stored procedures path within the HANA content

CONCATENATE ' " ' ' _SYS_BI C' ' " ' ' . ' ' " ' ' abqvspo. tastei nc/ 'I NTO l v_spo_sp_pat h.

*Check the submitted CDPA and return the stored procedure name accordingly

CASE i v_cont ext .WHEN ' TASTE_US_1' OR ' TASTE_US_2' .

*Return the SPO stored procedure name based on the submitted QV function for

US partition

CASE i v_f unct i on .

WHEN ' NO_OF_ POS_WO_LOC_MSTR' .CLEAR ev_sp_name. l v_spo_sp_name = ' KPI _NO_OF_POS_WI THOUT_LOCATI ON_MASTER_US' .

WHEN ' NO_OF_POS_WO_PROD_MASTER' .CLEAR ev_sp_name.

l v_spo_sp_name = ' KPI _NO_OF_POS_WI THOUT_PRODUCT_MASTER_US' .

WHEN ' NO_OF_ STK_WO_LOC_MSTR' .CLEAR ev_sp_name.

l v_spo_sp_name = ' KPI _NO_OF_STK_WI THOUT_LOCATI ON_MASTER_US' .




48

WHEN ' NO_OF_STK_WO_PROD_MASTER' .CLEAR ev_sp_name.

l v_spo_sp_name = ' KPI _NO_OF_STK_WI THOUT_PRODUCT_MASTER_US' .ENDCASE.


EU partition

WHEN ' TASTE_EU_1' .CASE i v_f unct i on .

WHEN ' NO_OF_POS_WO_LOC_MSTR' .CLEAR ev_sp_name.

l v_spo_sp_name = ' KPI _NO_OF_POS_WI THOUT_LOCATI ON_MASTER_EU' .


l v_spo_sp_name = ' KPI _NO_OF_POS_WI THOUT_PRODUCT_MASTER_EU' .

WHEN ' NO_OF_STK_WO_LOC_MSTR' .CLEAR ev_sp_name.

l v_spo_sp_name = ' KPI _NO_OF_STK_WI THOUT_LOCATI ON_MASTER_EU' .


l v_spo_sp_name = ' KPI _NO_OF_STK_WI THOUT_PRODUCT_MASTER_EU' .ENDCASE.


OTHR partition

WHEN ' TASTE_OTHR_1' .

CASE i v_f unct i on .WHEN ' NO_OF_POS_WO_LOC_MSTR' .

CLEAR ev_sp_name. l v_spo_sp_name = ' KPI _NO_OF_POS_WI THOUT_LOCATI ON_MASTER_OTHR' .


l v_spo_sp_name = ' KPI _NO_OF_POS_WI THOUT_PRODUCT_MASTER_OTHR' .

WHEN ' NO_OF_STK_WO_LOC_MSTR' .CLEAR ev_sp_name.

l v_spo_sp_name = ' KPI _NO_OF_STK_WI THOUT_LOCATI ON_MASTER_OTHR' .


l v_spo_sp_name = ' KPI _NO_OF_STK_WI THOUT_PRODUCT_MASTER_OTHR' .ENDCASE.

ENDCASE.ENDMETHOD.




49

GET_DSO (Optional)

Hint:

1. To find out the partitions DSO name you can proceed as highlighted below:

METHOD / ddf / i f _cal l _procedure~get _dso.

I F i v_dso = ' / DDF/ DS01' .

CASE i v_cont ext .

WHEN ' TASTE_EU' . ev_dso = ' ZTDS1101' .

WHEN ' TASTE_US' . ev_dso = ' ZTDS1102' .

WHEN ' TASTE_OTHR' . ev_dso = ' ZTDS1103' .

ENDCASE.ENDI F.

I F i v_dso = ' / DDF/ DS02' .

CASE i v_cont ext .WHEN ' TASTE_EU' .

ev_dso = ' ZTDS2101' .

WHEN ' TASTE_US' . ev_dso = ' ZTDS2102' .

WHEN ' TASTE_OTHR' . ev_dso = ' ZTDS2103' .

ENDCASE.ENDI F.

ENDMETHOD.




50

2. To avoid hardcoding of the CDPAs, especially if you have many, we suggest the following approach:

a. Define a Z customizing table to hold the list of Regions (abbreviation/ID and description) youneed to handle

b. Define a Z customizing table where you can associate a group of CDPAS to each of the regions

c. In the BADI implementation:

i. Use the CDPA of the submitted DDAGR to identify the region abbreviation youcustomized in point b.

ii. For each region you have return the appropriate stored procedures name

Process typeTechnical details on what needs to be done, to define a custom process type, can be found in the “how to”guide and the sap help doc listed under the additional links section below.Below we will illustrate the step by step how to proceed to create the new process type to compute the QVstatus using KPIs stored in the new SPO that replaces DS81

Define new process type

1. Use transaction SE24 and copy class /DDF/CL_BW_PC_TYPE_QV_DECISION, give it a name,for our example we named it ZSPO_CL_BW_PC_TYPE_QV_DECISION, and save. Don’tactivate yet!

2. Call transaction RSPC, or use th e icon in the Adm inistr ator Work bench. Open any of th e existin gprocess chains i n d i t m ode. Call t he m ainten ance of th e process ty pes as sh ow n in th e screen- sh otbelow (m enu ‘Settin gs=> M aint ain Pro cess T ypes’).

3. Copy the entry of the QV custom process /DDF/QVDEC type highlighted below:

4. Enter the new class you previously created/copied as shown below:




51

Note:No further attributes should be changed here, except the class/interface you entered

Done! You now have your new process type that you can find under the DSiM process types category shownbelow:

Read QV KPIs from SPO

In this section we will show what to adjust, and how, in class ZSPO_CL_BW_PC_TYPE_QV_DECISION sothat KPIs stored in the SPO are consideredIf you check method READ_DSO of class /DDF/CL_BW_PC_TYPE_QV_DECISION, using transactionSE24, you can see the place, as highlighted below, where the DSO name is hardcoded as DS81

Since with SPO we have several partitions/DSO, and ideally we would like to use our new process type in allprocess chains no matter the partition, the task we have here is to implement a business logic that




52

dynamically detects (meaning during runtime) the SPO partition to read from. Otherwise, we would need tohave as many process types as partitions we have which might not be convenient and considerable effortwise!

1. Use transaction SE24 and create a private method READ_DSO_NAME in classZSPO_CL_BW_PC_TYPE_QV_DECISION,with the signature below, and save:

2. Edit the method you created above and copy/paste the code below:

cl ass- methods r ead_dso_namei mport i ng

! i _l ogi d t ype rspc_l ogi dexport i ng

!ev_i nf opr ov_name t ype r si nf opr ov.

DATA l v_pr ocess_chai n TYPE r spc_chai n.DATA l t_var i ante TYPE rspc_t _var i ant e.DATA l t _i nf o TYPE rs_t_rscedst .

FI ELD- SYMBOLS <f s_i nf o> LI KE LI NE OF l t _i nf o.FI ELD- SYMBOLS <f s_vari ant e> LI KE LI NE OF l t_var i ante.

*1 - read the process chain ID

CALL METHOD / ddf / cl _adu_bi _ut i l i ty=>get_met achai nEXPORTI NG

i v_l og_i d_subchai n = i _l ogi dI MPORTI NG

ev_met achai n_i d = l v_pr ocess_chai n.

*2 - read the process chain variants

CALL METHOD / ddf / cl _adu_bi _ut i l i ty=>get_ pr ocesschai n_var i antEXPORTI NG

i v_pr ocess_chai n = l v_pr ocess_chai n

I MPORTI NG et _var i ant e = l t_var i ante.

*3 - look for all DSOs of the given DTP=> Assumption here is that the current

*process chain holds ONLY ONE DTP!

LOOP AT l t _var i ant e ASSI GNI NG <f s_var i ant e> WHERE t ype = ' DTP_LOAD' .

CLEAR l t _ i nf o.CALL FUNCTI ON ' RSPC_API _PROCESS_GET_I NFO'

EXPORTI NG i _t ype = <f s_var i ant e>- t ype i _vari ant = <f s_var i ant e>- vari ant e

TABLES e_t_i nf o = l t _i nf o

EXCEPTI ONS not _avai l abl e = 1OTHERS = 2.

I F sy- subr c <> 0.* Implement suitable error handling here

ENDI F.

*4 - look for the target DSO in the found DTP =>Target DSO is indeed one of

the partitions we want to write KPIs in

LOOP AT l t _i nf o ASSI GNI NG <f s_i nf o> WHERE f nam= ' DTA_ODSO' . ev_i nf opr ov_name = <f s_i nf o>- l ow.

EXI T.ENDLOOP.EXI T.

ENDLOOP.




53

As highlighted above, this business logic is valid only if the QV process chain holds only oneDTP. Otherwise, several target DSOs are detected and it won’t be possible to know the one we need

3. Edit method READ_DSO of class /DDF/CL_BW_PC_TYPE_QV_DECISIONwe previouslymentioned and adjust the code as shown below, where variable lv_infoprov_name is of type rsinfoprov:




54

Adjust process chains

1. We suggest you create new process chains to include/wrap the infopackage, process chaingenerated by the SPO wizard, the Z process type created for QV status/decision and the DSiMprocess type “Update step status”. The completed process chains should look like the oneshown below:




55

2. For a clean set up and better visibility, we recommend to create your own display componentand move all your process chains there. Below how it should/could look like:




56

Process Flow Controller Now that we have all necessary BW setup and objects, we will describe how to customize the Process FlowController to ensure a proper data upload into accurate partition per/for each region.Note:

1. In all coming sections we will refer to:a. Process Flow Controller by the abbreviation PFCb. Data Delivery Agreement by the abbreviation DDAGR

CustomizingProcess definition

This is the first set up to tackle. It consists on defining the required PFC steps, and related executionsequence, for data upload. To do this we can follow one of the options below:

a. Define one process definition for all DDAGRsOr

b. Define one process definition for each DDAGR

We chose to go with option a mainly to show you, as described under coming section, how stepsinstantiation works in this context.

1. Go to the DSiM IMG path for Process Definition creation, highlighted below:

2. Create a process definition similar to the one shown below, where you have to make sure youproperly set the reference key field to:

a. Keep it empty for steps that have to be executed for uploads regardless the region. In other

words, the steps that are common to upload for all regions/DDAGRs

b. Assign the same key/value to uniquely identify all steps that have to be executed for uploadof a given/specific region/DDAGRs




57

As highlighted below:

Data Delivery Agreement

In this section we will complete the customizing we already started as mentioned under the implementationsection above. Please find the step-by-step guide to complete the definition of the DDAGRs that wepreviously created, below:

Region CDPAs Data Deli very Agreement

ID Descript ion

US TASTE_US_1 TASTE_TX Taste Inc. US - Texas

TASTE_US_2 TASTE_AZ Taste Inc. US - Arizona

EU TASTE_EU_1 TASTE_FR Taste Inc. US - France

Other TASTE_OTHER TASTE_DB Taste Inc. UAE - Dubai




58

1. Assign process definition you created to each DDAGRs and perform the dataset definition asshown below

Hint:

To ease the exercise above, we suggest you choose in advance a naming convention, or anyother mean, that can help to know, just by a glance, for each DDAGR/Region, what are therelated steps as we did and shown above

Data Set File

1. For each DDAGR define a file set definition as highlighted below:

2. Complete the definition by assigning to each file the accurate data set and save




59

Steps InstantiationThis section is only relevant if you defined one process definition for all DDAGRs. If that is not the case justskip it and can already start test your set up!When we define one process definition for all DDAGRs, we need to help PFC to identify, on runtime, whatare the steps to instantiate, and hence the ones NOT to instantiate, for the handled DDAGR. To do this we

need to implement the BADI shown below, provided in DSiM for this purpose as explained below:

This BADI has only one method and the idea behind is as follows:

a. Considering that we previously associated a “reference key” to identify steps of CDPAs/region

b. on runtime based on the CDPA of the submitted DDAGR, we identify the steps to instantiate

c. steps to instantiate are the ones that hold the reference key of the given CDPA

d. Instantiated steps, hold accurate process chains to bring/load data into the correct partition




60

Below a “proposal“ code snapshot, for the set up mentioned in this document, that you can use as exampleIndeed, you can copy and paste the code below only if you did follow the exact same set up and used theexact same naming convention for the following: CDPAs and Reference key for each partition

GET_RELEVANT_STEPS

Hint:To avoid hardcoding of the CDPAs, especially if you have many, we suggest the following approach:

1. Define a Z customizing table to hold the list of Regions (abbreviation/ID and description) you need tohandle

2. Define a Z customizing table where you can, to each of the regions associate a group of CDPAS

3. Use the region abbreviations you entered as reference key in the step definition

4. In the BADI implementation:

a. Use the CDPA of the submitted DDAGR to identify the region abbreviation you customizedin point b. This abbreviation is also the step reference key as described in point c

b. do not refresh/clear table ct _st ep_r el evant , but instead filter out/delete all steps thathave a reference key and this reference key is different from the one you identified

METHOD / ddf / i f _ex_step~get_ r el evant _st eps.

DATA l v_ref _key TYPE / ddf / r ef key.

FI ELD- SYMBOLS <f s_s t ep_out put > LI KE LI NE OF ct _st ep_r el evant .FI ELD- SYMBOLS <f s_s t ep> LI KE LI NE OF i t _s tep.

REFRESH ct _st ep_r el evant .CASE i s_dat a_agreement - cdpa.

WHEN ' TASTE_US_1' OR ' TASTE_US_2' . l v_ref _key = ' US' .

WHEN ' TASTE_OTHR' . l v_ref _key = ' OTHR' .

WHEN ' TASTE_EU_1' . l v_ref _key = ' EU' .

ENDCASE.

LOOP AT i t _step ASSI GNI NG <f s_s t ep>.I F <f s_st ep>- r efkey I S I NI TI AL OR <f s_s t ep>- r ef key = l v_ref _key.

APPEND I NI TI AL LI NE TO ct _st ep_r el evant ASSI GNI NG <f s_st ep_out put >. <f s_s t ep_out put >- st ep_no = <f s_st ep>- st ep_no.

ENDI F.

ENDLOOP.ENDMETHOD.




61

ADDITIONAL LINKS

BW 7.30: Semantically Partitioned ObjectsCustom process typeHow to implement custom process type



© 2014 SAP AG. All rights reserved.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP

BusinessObjects Explorer, StreamWork, SAP HANA, and other SAP

products and services mentioned herein as well as their respective

logos are trademarks or registered trademarks of SAP AG in Germanyand other countries.

Business Objects and the Business Objects logo, BusinessObjects,

Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and

other Business Objects products and services mentioned herein as

well as their respective logos are trademarks or registered trademarks

of Business Objects Software Ltd. Business Objects is an SAP

company.

Sybase and Adaptive Server, iAnywhere, Sybase 365, SQL

Anywhere, and other Sybase products and services mentioned herein

as well as their respective logos are trademarks or registered

trademarks of Sybase Inc Sybase is an SAP company

www sap com

sap bw spos for point of sales (pos) data in sap demand signal management (dsim)

Documents