1.1     Overview

The objective of this blog series is to detail the development of solution architecture and technical design specifications of SAP ECC staging Datasources (Blog1) for reports in SAP BW/4HANA & SAP BOBJ dashboard reporting (Blog2) and development of a standalone in SAP Business Intelligence/SAP BusinessObjects. The Dashboard reporting uses the SAP BusinessObjects BI (SAP BOBJ). which is a centralized suite of reporting and analytics tools for business intelligence (BI) platforms. SAP BOBJ consists of several reporting applications that allow users to discover data, perform analysis to derive insights and create reports that visualize the insights through Dashboards. The following topics are covered in this blog series.

• SAP ECC staging Datasources for reports: Solution Architecture & Design (Blog1)
• Dashboard Reporting: SAP BW/4HANA and SAP Businessobjects Analysis for OLAP & Businessobjects WEBI Dashboards (Blog2)

1.2     Functional Requirement

1.2.1    Dashboard REPORTING SCOPE

The existing reports in SAP ECC, which need to be designed and viewed/queried from SAP ECC to SAP BW/4HANA and SAP BOBJ reporting tools. The main objective is to facilitate user self-service, to allow the users to generate their own reports in future as the requirements change.

1.3     Business Process Landscape

The business process landscape below shows the specific scope in the broader context of the overall process landscape of SAP BW/4HANA System. The Dashboard reporting uses the SAP BusinessObjects BI (SAP BOBJ), which is a centralized suite of reporting and analytics tools for business intelligence (BI) platforms.

• Enterprise Data Warehouse Layer (EDW):  This is a combination of Open Operation Data Store Layer (ODS) and Core Data Warehouse layer (CDW) in SAP BW/4HANA LSA++ architecture. Open ODS layer is similar to the data acquisition layer in SAP BW. The open ODS layer is used to integrate data into the Data Warehouse and provides the same functionality as the classic data acquisition layer, but with more flexible data integration possibilities. The CDW layer, is responsible to perform functions like data transformation, data cleansing and consolidation In EDW layer, cleansed, harmonized and consolidated data from different source systems is provided. Source data can be transformed, enhanced and merged, to support broad usage and easy consumption for a wide-range of analysis purposes. Data is not aggregated, but stored at line-item level in EDW Core ADSO’s. These serve as a reusable consistent data foundation used in the next layer if required. The purpose of this layer is the transformation of data in one layer
• Curated Data Layer:  This is also known as Virtual Data Mart Layer. This layer is responsible to combine the data from other layers and to make it available for reporting purposes. This layer contains all the InfoProviders that combine data using join or union, without saving the result: MultiProvider, Composite Provider, etc. You can use this to access data directly in the SAP HANA database, to allow queries on Composite Provider, Open ODS View. Composite provider allows you to merge the data from BW InfoProviders with HANA Modeling views. Union and Joins are performed in SAP HANA and queries can be run on composite providers, like BW InfoProviders. Based on application-specific business requirements, data from EDW core layer is combined and mapped to Data Marts. These structures then serve as query targets for reporting and analytics. This layer will be accessed by Data Scientists.
• Virtual Reporting Layer: Represents logical views of data and does not physically contain data. This layer will be accessed by Data Analysts.
• Visualizations Layer: Provides the Reporting and Analytical layer, it provides the End Users with View Access, and Self-Service Reporting for End Users and Data Analysts.
• ECC- BW Staging Area: The customized data sources through function module will extract the ECC data  to SAP BW InfoProviders from ECC tables

1.4     SOLUTION ARCHITECTURE

The existing custom reports requires more analysis in ECC system, and the business need for a BW 4HANA report/BOBJ Dashboard that shows the same data with the custom report in ECC. In standard cases, the ideal way would be to search for standard business content ECC datasources to extract the ECC data to BW/4HANA. Since standard business content datasources are not available to meet these reporting requirements, there is a need to create custom datasources for ECC  reports in the ECC-BW staging area. There are three main methods explored for creation of custom BW datasources below.

1.4.1    Option 1: Extraction by table/view

Change the existing the custom program of the custom report to fill in a Z table and create generic Datasources on the Z table to extract the ECC data

Steps:

1. Create Z Table
2. Change the Z Program of Report to fill the Z Table
3. Create Datasource; Extraction by View/table. to extract the data

Design & Dataflow

1.4.2    Option 2: Extraction by function module with memory id

Change the existing report code to add the memory ID to store the output results and   create function module to import the output results from memory id and create generic datasource on this function module to pass the output to the datasource

Steps:

1. Create function module to import the output from memory ID and pass it datasource: Report is called by FM Using Submit report with Parameters and return statement along with selection screen parameters. Add the Minor code changes to the existing program of report to save the output results in Memory ID by export statement
2. Add memory ID to the Z program report to store and export the output: Use the function module to retrieve the output results by import from memory Id and pass it to the datasource. .
3. Create Datasource; Extraction by function module. to extract the data: When the function is called to upload an Datasource, the FM code calls the report to generate the data we require through Memory ID to datasource

Design & Dataflow

1.4.3    Option 3: Extraction by function module

 Create a function module with same logic of custom report code and create generic datasource on this function module

In this blog1, the ECC custom datasources for dashboard reporting are configured by using Option Extraction by function module.

1.4.4    Technical design steps and dataflow

1. Create function module: create a function module that exactly behaves the same way as the program logic of the custom report.
2. Create Datasource; Extraction by function module. to extract the data : create a totally new datasource according to a new requirement, by using logic in the existing custom program.

1.5    Testing

The ECC report data is extracted by the relevant custom datasources and unit testing is done with two scenarios. The data is matched with ECC Report to relevant datasources in both scenarios.

Appendix:

• Datasource: Datasources contains a set of fields that provide the data for a business unit for data transfer into BW. From a technical point of view, the Datasource is a set of logically-related fields that are provided to transfer data into BW in a flat structure. When execute the datasource through function module. the data from DB table is passed on to the datasource through Extract structure by function module. The structure of the datasource is called extract structure (T-Codes in ECC, RSO2-for creation of Datasource; RSA3-to check/extract the data in Datasource-; RSA2 – to check properties of data sources ;RSA5 -Install Business content ; RSA6 – Maintain datasources; RSA8 – Datasource Repository ;RSDS:-Datasource)
• Function Group: Function group is a container of Function modules; every Function Module must be saved in a Function group. (T-codes in ECC for creating Function Modules and Function groups are SE37 or SE80).
• Function Module: Function Modules are sub-programs which contains set of re-usable statements with importing, exporting parameters, exceptions. Unlike include programs Function Modules can be executed independently.
• Components of Function Module: Import: These are input parameters of a Function Module. Export: These are output parameters of a Function Module .Tables: These are internal tables which also acts as importing and exporting parameters. Exceptions: Exceptions in Function Modules are used to catch certain type of errors.