Standardization is a key aspect of SAP BW Layered, Scalable Architecture (LSA), SAP’s best practice in Enterprise Data Warehousing. One of the ways to realize standardization in the data staging process is developing generic, reusable ABAP building blocks with a comprehensive interface.

From an Enterprise Data Warehousing perspective, the process of Data Unification can be classified as a modeling pattern. The Data Unification Services' ABAP building block and central control tables are designed to standardize and facilitate this process.

In this blog I will discuss Data Unification Services, the concept behind it and how to use it in the transformation.

I developed a working version of the Data Unification Services which I am going to share via a document. It will cover all details on creating the ABAP Objects classes, including the source code and all necessary ABAP Workbench objects.

Conceptual Overview

Data Unification in an LSA context is all about supplementing data records with administrative characteristics. Usually it concerns the following characteristics:

• Data Domain;
• Organizational Unit;
• Request ID;
• Timestamp;
• Origin.

Data Domain is related to domain partitioning or strategic partitioning and is applicable to transactional data flows. Please refer to my blogs Pattern-based Partitioning using the SPO BAdI - Part 1: Introduction and Pattern-based Partitioning using the SPO BAdI - Part 4: Use Cases for more information.

Domain partitioning is not always applicable: Data Acquisition Layer, Corporate Memory Layer and master data flows in general. In these cases it's transparent to assign data to domain 'X' (cross-domain and domainless).

Data Unification Services is positioned in the Harmonization & Quality Layer.

Figure 1: Positioning in LSA (source: SAP AG)

The following figure shows an example of an LSA compliant transactional data flow.

Figure 2: Data Unification Services in the Data Flow

The yellow callout indicates where Data Unification Services is implemented. The transformation is positioned between the Data Acquisition Layer outbound InfoSource and the Harmonization Layer Pass-thru DSO.

For other data flows it is slightly different. In master data flows the transformation is positioned between the Data Acquisition Layer outbound InfoSource and the Harmonization Layer intermediate InfoSource. In Corporate Memory flows the transformation is positioned between the Data Acquisition Layer outbound InfoSource and the Corporate Memory DSO.

Note that in all cases this transformation is exclusively used for Data Unification Services.

Control Tables

For transactional data flows the basic rule is that domain partitioning is applied. Data Unification Services needs help to be able to determine Domain and Organizational Unit automatically. Therefore we have to introduce 3 control tables.

Exclusively for transactional DataSources the following control tables have to be maintained:

• YBWUNISRC - Domain Driving Source Field DataSource;
• YBWUNIVAL - Value Assignments;
• YBWUNIREF - Reference Domain Driving Characteristic.

Table YBWUNISRC is always mandatory to be maintained for every new transactional DataSource. It is used to store the domain driving source field of the DataSource and the corresponding InfoObject.

Figure 3: Control Table - Domain Driving Source Field DataSource

Table YBWUNIVAL is used to store the value assignments. It has to be maintained less frequently since already existing value assignments can be reused. E.g. InfoObject Company Code and its characteristic values are already maintained. Every next DataSource can reuse these value assignments, there is no need to maintain them more than once. There might be a future need to maintain the entries if new Company Codes are introduced.

Figure 4: Control Table - Value Assignments

In some cases you might encounter that multiple InfoObjects are used for the same entity. In such cases it must be avoided that the value assignments are entered more than once. That is why the reference domain driving characteristic functionality was introduced. Table YBWUNIREF is used for this purpose.

Figure 5: Control Table - Reference Domain Driving Characteristic

Using Data Unification Services

Prerequisite for using Data Unification Services is the presence of the administrative characteristics in the target structure of the transformation. I.e. you have to add these characteristics to the DSO or InfoSource (depending on the data flow). The example below shows a DSO where you have to add the characteristics to the Data Fields section.

Figure 6: Adding Administrative Characteristics to DSO

The Data Unification Services building block is realized as an ABAP Objects class. One of the following public methods has to be called in the transformation (end routine or expert routine):

• EXECUTE_END - Execute Transformation End Routine;
• EXECUTE_END_X - Execute Transformation End Routine (Only Domain 'X');
• EXECUTE_EXPERT - Execute Transformation Expert Routine;
• EXECUTE_EXPERT_X - Execute Transformation Expert Routine (Only Domain 'X').

You can see in the screenshot below an example of the limited source code to be entered here.

Figure 7: Example of Data Unification Services in the Transformation

The source code can easily be inserted by using the appropriate ABAP Pattern. Click on push button Pattern, choose option Other Pattern and select the appropriate pattern in line with the type of routine (end routine or expert routine) and domain.

Figure 8: Inserting the Data Unification ABAP Pattern

The following ABAP Patterns are available:

• YBW_END_UNI - Execute Transformation End Routine;
• YBW_END_UNI_X - Execute Transformation End Routine (Only Domain 'X');
• YBW_EXPERT_UNI - Execute Transformation Expert Routine;
• YBW_EXPERT_UNI_X - Execute Transformation Expert Routine (Only Domain 'X').

All Data Unification functionality is provided by the class. The source package and/or result package are processed dynamically. The relevant information is fetched from the control tables. Any exceptions are handled appropriately: they terminate the process in a controlled way and fill the monitor log with information on the errors.

Conclusion

From an Enterprise Data Warehousing perspective, the process of Data Unification can be classified as a modeling pattern. The Data Unification Services' ABAP building block and central control tables are designed to standardize and facilitate this process.

In this blog we discussed Data Unification Services, the concept behind it and how to use it in the transformation.

Pre requisites: The reader understands and has extensively used APDs. Yoou just need the basic knowledge of an APD.

1. APD's are not designed to work with large amounts of data. Make sure you are filtering out all the data that is not needed, let us say you need to quickly dig into  past 2 months of invoices data-> do not pass all your historical invoices data through your APD.

2. Remove the option in the performance settings- > process in memory, if the data amount is still large enough -> 2 months of invoices data is big

3. Try to schedule the APD as a background job through the program- > RSAN_PROCESS_EXECUTE.

4. If you are using the infocubes or multicubes as your apd source, try partitioning the Infocube and compressing the requests, if the apd has to mine 2 months of data from f- table it has to query on all the requests, instead of the partitions (calmonth or fiscper)

5. table partitioning and compression, is a recommended practice, as a part of administration, which would also improve your apd performance.

Next Blog: To be determined..

The activation operation of a standard data store object (DSO) in BW 7.30 on HANA has been optimized for HANA. It has now all the performance advantages of the HANA-optimized DSO which has been originally shipped and that required an explicit conversion step during the migration to BW-on-HANA. This is now obsolete. Also, older data flow setups can now benefit from some of the advantages. The necessary changes are planned to ship with BW 7.30 SP10 and HANA revision 56. Alternatively, BW 7.30 installations on SP8 or SP9 can apply code changes offered in OSS note 1849497. In summary, this yields a significant simplification.

The availability of the active and not-active data concept in HANA allows to maintain a materialized change log of the standard DSO at no impact on main memory consumption. It is even more efficient as the (on the fly) calculated change log of the HANA-optimized DSO consumes quite some memory at the moment it is accessed. So overall, the reworked standard DSO provides all the advantages and requires no conversions. As a consequence, the HANA-optimized DSO becomes obsolete. It will still be supported. So don't worry if you are using this type of DSO. It continues to work as before. A re-conversion tool will be provided in June. Details can be found in this document.

This blog is cross-published here. You can follow me on Twitter under @tfxz.

After executing report in WAD (Web Application Designer), we see lot of options enabled on right click of report data as shown below

Requirement is to keep only required right click option for the end users:

Steps to restrict or to select only required options:

1)  Insert Context menu web item from Miscellaneous tab to the Web template Layout

2) On the property tab for Context Menu, select only required options. Undo/off Broadcast and currency translations.

3) Save and execute the report.

4) Displays result data with removed navigation – Currency translation and Broadcast.

Note: Context menu web item is just the behavior of the web report and will not get displayed like other web items.

  In some scenarios, these options helps to avoid confusion to end users since most of the time calculations and translations are implemented as part of query design and broadcasting is restricted to power users .

Bex Query: Formula variable using Replacement Path:

We can create formula variable at the bottom of the available operands (key figures listed).

Then assign it to a calculated key-figure or local formula.

Requirement1: To calculate Sales per No. of seats.

Sales value is coming as key figure

No. of seat(characteristic) is attribute of Profit Center and has data-type as NUMC length (4).  

We can not use characteristics in the calculated key figures or in the local formula.

and We need to get the attribute value w.r.to characteristic value of Profit Center (0PROFIT_CTR).

We will convert it into number using formula variable.

We have selected ref. char. as Profit Center and attribute as No. of Seat.

No of seat has mapping with profit center. We will do exception aggregation with profit center.

Now we can use this CKF to get Sales per Seat.

Output1:

  If we use result as summation for Sales per seat, result will be like below:

Output2:

Another Scenario: Requirement2:

1.  

         To get term in days = Maturity date(End of Term) – Start date. Where dates are available as characteristics.

         We can create formula variable using replacement path and data-type as date. Create one formula variable for Maturity date and one for Start Date.

         Note the info-object in the reference characterisitcs of general tab.

         for e.g.: total term period, remaining term period can be required in case of Insurance where we have Maturity date,

         start term date, As-of date(evaluation date).

Either create Calculated key figure or create a local formula (key-figure Section) to get term in days.

  In   In Requirement1: we have converted info-object:attribute value to number,

        In Requerement2: we have converted Info-object:key value to date.

        thanks& regards,

        Vikas

      ---

In

SAP CRM

SAP CRM Marketing: Campaign Management, Lead Management

SAP CRM Sales: Sales Planning, Sales Order Management:

                  Sales: Opportunity -> Inquiry/Quotation -> Contract -> Order 

SAP CRM Service: Service Order Management : Complaint -> Service Request

Advantages:   Improve customer service, Assess and motivate employees, Optimize Organization,

                      Reduced expenses,Effective processes, Improved turn-around-time.                       

Definitions:

1.   1. SAP CRM Marketing: The Marketing module helps you introduce a new product to existing and new customers and

        engage them through campaigns.

        After we identify a prospective customer (i.e. lead) group that would be interested in the product,

        we can automatically convert the prospect to an opportunity.

        We can use the Sales module to create the opportunity and generate a sales quotation for the customer.

        If the customer agrees with the quotation, we can then create a sales order.

1.   2.  SAP CRM Marketing: Using Segmentation tool, we can identify customers with similar interests and attributes

             and form customer segment groups or customer groups and the  process of grouping is known as Segmentation.

             for e.g. working class, students or retired people.

       With Segmentation  we can create more effective marketing campaigns and we can address

       the needs of customers better. It also helps in gathering data for analysis purpose.

3. SAP CRM Marketing: The Marketing programs, activities that are plan, run and tested to generate awareness

              among potential customers are defined as Campaigns. We can create campaigns to promote a product or

              service to your customers. These marketing activities include identifying customers, drafting the information

              we want to communicate and selecting the medium to transfer the information.

              We can run campaigns by using telephone, advertisements, e-mail or SMS.

        Apart from promotion of product,we also get feedback from customers.

4. Organizational Data: represents Internal view of organization

      As we have in ECC, Sales structure: Sales Organization, Distribution channel, division

      CRM side, we have Organization attributes:

      Sales Organization, Sales office, Sales Group, Service Organization

      General attributes:

      Country, Division, Distribution channel, Postal code, Region.

3.   5. Business Partner: contains relationship mapping:

  •   Employee, Vendor, Customer, associated parties 

  •   Can be an individual or organization

  •   Sold-to-party, Ship-to-party, Bill-to-party, Payer

  •   Contact Person, Employee/Personnel responsible or (Field Sales Representative).

  •   A Contact/Prospect may or may not be a Customer.

•      

4.    6. Territories:  Reflects Market View of an organization

  •  are defined w.r.to business unit, business partner, product, field sales representative, region, country

  •  Territory Management can be used to distribute or classify data correctly.

  •  Reporting is done on Customer/Product/Region.

  •  Reporting is also done on ORU/MRU(Organization reporting unit or Management reporting unit – structure or hierarchy).

7.  Master data: e.g.  

Organizational mapping data, Territory information, Region information , Business Partner Information, Material or Product, Address, Region

Territory(0CRM_TR), Business Partner(0BPARTNER), Business Partner: CRM Sales View (0CRM_BP_SAL),

Sales Office(0CRM_SALOFF or 0SALES_OFF), CRM Sales Group(0CRM_SALGRP), Region(0Region),

Organizational Unit(0ORG_UNIT or 0CRM_SALORG), Product(0CRM_PROD), Prospect(0CRM_PROSPE),

Origin Opportunity/Lead(0CRM_SOURCE).

Transaction data: e.g. Sales data, Stock data, Billing, Deliveries .

       Tables: CRMM_TERRITORY, CRMM_TERRITORY_T.

thanks & regards,

Vikas

----

Hi All,

STEP:1 :- Go to RSRV, inorder to resolve the inconsistency..

STEP:2 :-  Give the PSA Table name (DSO's Change Log Table Technical Name)...

STEP:3 :-  Select "Consistency between PSA Partitions and SAP Admin Information

STEP:4 :- Execute

STEP:5 :- Select PSA and click on the " Correct Error", which will remove the correctable error..

STEP:6 :-

Check the log...

Which will give us the reason for the error correct it.

STEP:7  :- Repeat the step, hence the DSO activation will be completed successfully.

Please post your valuable comments and suggestions in case of any modifications required for this content.

Thanks,

Chandra.