Prerequisites:

• SAP BW4HANA – SAP BW Query
  
• SAP BW4HANA – OData Services

In BW4HANA Odata service can be generated automatically from BW query by clicking checkbox “By Odata”, this service is then can be activated in any SAP Gateway system and consumed from there.

In case of any requirements to enhance the system generated service below steps can be followed.

Steps:

Step 1: Generate OData service from BW Query.

Step 2: Create a project in t-code SEGW. Please remember <Project Name>_SRV is going to be the new service name, so please name the project accordingly.

Step 3: Right click on the Data Model and click on “Redefine” -> “OData Service (SAP GW)

Step 4: In this screen it will ask for a service where we need to select the system generated service that needs to be enhanced and click “Next”

Step 5: Click Select all and click on Finish

Step 6: Enhance the Result set with new field and Save.

Step 7: Right click on project and click on “Generate Runtime”

Runtime artifacts will be generated like shown below

Step 8: Go to DPC_EXT (Data provider extended class)

Select GET_ENTITYSET method and click on Redefine button

Step 9: Write the logic to populate the newly added field here. Super class get_entityset code will be shown by default, start the new logic after the default code. Please note that this code will be executed for each and every row in output.

Step 10: Test the output of OData service.

Go to TCODE /IWFND/GW_CLIENT, give the URL in Request URI and click on execute.

Validate the output with written logic.

The post How to enhance system generated ODATA service in SAP BW4HANA appeared first on ERP Q&A.

Overview of the C_BW4HANA_27 Certification:

The C_BW4HANA_27 certification exam for the SAP Certified Application Associate – Reporting, Modeling, and Data Acquisition with SAP BW/4HANA 2. x certification proves that the individual possesses the essential and fundamental knowledge needed for tasks related to modeling, data acquisition, and query design with SAP BW/4HANA. The C_BW4HANA_27 certification also demonstrates that the candidate possesses a comprehensive understanding and advanced technical abilities to contribute as a project team member in a supervised position.

What Is the Level of the C_BW4HANA_27 Certification?

This C_BW4HANA_27 exam is recommended as an initial level qualification. Therefore, any candidate aspiring to become an SAP consultant can take this exam.

What Are the Syllabus Domains?

The C_BW4HANA_27 exam covers the following topics-

• Data Acquisition into SAP HANA
• Fundamentals
• SAP Analytics Tools
• SAP BW/4HANA Data Flow
• SAP BW/4HANA Modeling
• SAP BW/4HANA Project and the Modeling Process
• Native SAP HANA Modeling
• InfoObjects and InfoProviders
• SAP BW Query Design
• Data Acquisition into SAP BW/4HANA

What Are the Preparation Tips to Ace the C_BW4HANA_27 Exam?

Understand the Exam Structure:

Before starting your preparation, it’s essential to understand the structure of the C_BW4HANA_27 certification exam. The exam consists of 80 multiple-choice questions that you need to complete within 180 minutes. The passing mark for the exam is 65%. Understanding the exam structure will help you plan your preparation and allocate the appropriate time for each section.

Review the Exam Topics:

The C_BW4HANA_27 certification exam covers a broad range of topics to check your knowledge. Therefore, go through the syllabus domains and grasp them from the core. The more you are confident about the syllabus domains, the more the scope to attempt a maximum number of questions. We recommend creating a study plan that includes allocating time for reviewing each topic.

Manage Your Time by Creating A C_BW4HANA_27 Study Schedule:

Managing your time is crucial when preparing for the C_BW4HANA_27 certification exam. Creating a study plan that includes allocated time for each exam topic will help you stay on track and avoid last-minute cramming. We recommend starting your preparation at least six weeks before the exam date to ensure you have enough time to review all exam topics thoroughly.

Enroll in a Training Course:

You must enroll in a training course to prepare for the C_BW4HANA_27 certification exam. Various training options are available, including online, instructor-led, and self-paced courses. Choose the training option that works best for you based on your learning style, schedule, and budget.

Use SAP Learning Hub:

SAP Learning Hub is an excellent resource for preparing for the C_BW4HANA_27 certification exam. It provides access to a vast library of training materials, including e-books, online courses, and live training sessions. SAP Learning Hub is also an excellent platform for practicing with SAP systems, which will help you gain hands-on experience with SAP BW/4HANA 2.0.

Learn with Sample Questions:

Practicing with sample questions is an excellent way to prepare for the C_BW4HANA_27 certification exam. SAP provides sample questions on its website that you can use to test your knowledge and identify areas that need improvement. Sample questions can be found in SAP Learning Hub or other online resources.

Take C_BW4HANA_27 Practice Tests to Assess Your Knowledge:

Assessing your knowledge from time to time is essential. Therefore, take C_BW4HANA_27 practice tests to have a real exam-like experience and discover the syllabus domains that need more attention.

Stay Focused and Motivated through the C_BW4HANA_27 Exam Preparation:

Staying focused and motivated is essential when preparing for the C_BW4HANA_27 certification exam. It’s easy to get distracted or lose motivation during the preparation process. We recommend setting achievable goals, rewarding yourself for milestones, and staying positive throughout the process.

What IS SAP BW/4HANA?

SAP BW/4HANA is a modern data warehousing solution designed by SAP to enable businesses to manage large volumes of data from different sources in a single, unified platform. It provides advanced reporting and analytics capabilities, making it easier for businesses to create meaningful insights from their data and make informed decisions.

Benefits of Using SAP BW/4HANA Solution:

With SAP BW/4HANA, data modeling is simplified, allowing businesses to create data models and extract meaningful insights from data easily. The solution provides a graphical user interface for data modeling, allowing users to create and modify data models easily.

In addition to simplified data modeling, SAP BW/4HANA provides advanced reporting and analytics capabilities. It provides a range of reporting tools, including dashboards, scorecards, and ad-hoc reporting, enabling users to create reports tailored to their specific needs.

Benefits of Using SAP BW/4HANA:

Handle Large Volumes of Data:

One of the key benefits of SAP BW/4HANA is its ability to handle large volumes of data in real time, allowing businesses to make decisions based on up-to-date information. The latest in-memory computing technology makes this possible, enabling faster data processing and analysis.

C_TS4C_2023: Get Powerful Insights with Practice Tests to Ace the Exam!

Improve Data Quality:

SAP BW/4HANA also provides tools for data quality management, enabling businesses to improve the quality of their data. It provides data profiling and data cleansing tools, enabling users to identify and fix data quality issues.

SAP BW/4HANA Is Cost Effective:

Another benefit of SAP BW/4HANA is its cost-effectiveness. The solution is designed to be more cost-effective than traditional data warehousing solutions, with a simplified architecture that reduces the total cost of ownership. This makes it an attractive option for businesses of all sizes.

Bottom Line:

SAP BW/4HANA is a powerful and modern data warehousing solution that provides a range of benefits for businesses. Companies can make more informed decisions based on accurate and timely data, from faster data acquisition and processing to improved reporting and analytics. If you want to improve your reporting, modeling, and data acquisition capabilities, SAP BW/4HANA could be your solution. Therefore, to start your SAP career, study hard with practice tests and earn the C_BW4HANA_27 certification.

The post C_BW4HANA_27: Passing Tips to Earn the SAP Reporting, Modeling and Data Acquisition with SAP BW/4HANA Certification appeared first on ERP Q&A.

Many a times you would have observed that there are a few fields present in the extract structure of the SAP BW datasource but are not available in RSA6 or the data source which is replicated in BW.

This blog talks about all steps as to how can we enable fields present in the extract structure of the data source, make them visible in RSA3 and fetch the data in BW.

Let’s take an Example.

Here we take an example of a data source 0COMP_CODE_TEXT No. of Fields in the Extract structure is 7.

No. of fields in RSA3 output of the Datasource is ‘2’:

Fields present in RSA6 in the source system for the data source 0COMP_CODE_TEXT

Data source in SAP BW.

The Reason for this:

The value for the field SELECTION of the table ROOSFIELD for the fields which are not visible in the Data source or RSA3 is maintained as ‘A’.

If a request for a Data Source is scheduled in the Business Information Warehouse, selection conditions are specified across certain fields. The property that determines whether a selection in BW using a field is possible or required is established in the Data Source in the Source System.

In addition, the visibility of the field in BW can be set.

Definition of the individual values:

‘A’: Field is hidden in OLTP and BW; property cannot be changed by the customer.

‘M’: The Data Source requires a selection across this field before it is able to extract data (Required field for the generation of a request); property cannot be changed by the customer

‘X’: The Data Source can select across this field. The customer can change selections and visibility (the field is currently visible and selectable, compare with ‘P’, ‘3’)

‘1’: Pure selection field for the Data Source. The customer can change the selection, but not the visibility (the field is currently selectable, compare with ‘2’).

‘2’: Pure selection field for the Data Source. The customer can change the selection, but not the visibility (field is currently no selectable, compare with ‘1’).

‘3‘: The Data Source can select across this field. The customer can change selection and visibility (the field is currently not visible not selectable, compare with ‘P’, ‘X’)

‘4’: The Data Source cannot select across this field. The customer can change visibility (the field is currently not visible, compare with ‘ ‘)

Summary:

Here are Steps to make the field visible in RSA3 and to populate data into BI.

Let’s consider the filed DATETO (Valid-to date) to be displayed in RSA3 and in the Data source so that the data can be extracted into BI.

STEPS to be followed:

1. Create a test program through the transaction SE38. Write the below code in the program. Activate it and then execute.

2. After execution you would see that the value of the filed selection has been changed from ‘A’ to ‘P’.

3. Go to RSA6 and find the data source 0COMP_CODE_TEXT and select Change.

4. Put a check in the checkbox Selection if you want it to be a part of the selection in RSA3 and in the Infopackage and Generate the data source.

5. Go to RSA3 and you will find the new filed DATETO in your output.

PS. Note: If there is data it would automatically get populated in this case there isn’t any data in the new filed

6. Go to the BI System find the data source and Replicate it.

7. After replication the new field will appear in the data source.

To Summarize following the above steps you can un-hide / enable the fields present in the Extract Structure of an SAP BW Datasource.

The post Enable hidden Fields of SAP BW DataSource appeared first on ERP Q&A.

Innovate your IT landscape with SAP Data Warehouse Cloud, which is SAP’s strategic target solution for all data warehousing use cases, in line with SAP’s data-to-value portfolio strategy. This blog post provides SAP BW and SAP BW/4HANA customers an overview of how existing on-premises investments can be converted to the cloud. More importantly, a Cloud Transformation Checklist which can be used when preparing the project and during the actual conversion to SAP Data Warehouse Cloud. The checklist contains the various conversion paths (Shell- and Remote Conversion), and their individual steps in different tabs, including the corresponding SAP Notes. The checklist is in no way intended to replace a dedicated project plan, but rather to provide support for effort orientation. For initial project planning and rough structuring, it makes sense to think through all project parts one by one. The checklist is available for download as an attachment to SAP Note 3141688. Tip: Click on the figures of the individual project phases below for better readability.

Overview

SAP Data Warehouse Cloud is SAP’s strategic public cloud product for data warehousing. It improves agility, accelerates time-to-value, and unlocks innovation with unprecedented business user enablement, a new form of openness, and embedded partner offerings. Looking at conversion, SAP offers the possibility of a tool-supported move of SAP BW or SAP BW/4HANA investments to SAP Data Warehouse Cloud, SAP BW bridge (see figure 1). SAP BW bridge is a feature of SAP Data Warehouse Cloud, that provides a path to the public cloud for SAP BW and SAP BW/4HANA customers. It enables connectivity and business content via proven SAP BW-based data integration (extractors) from SAP source systems. In addition, it provides staging layers of SAP BW to manage data loads (including deltas) with partitioning, monitoring, and error handling. This allows customers to leverage their existing SAP BW skills and protect their SAP BW investments in the public cloud.

In any conversion, manual interaction and re-design is required (see Figure 2). The degree of these manual tasks varies from customer to customer and depends on the configuration and state of the SAP BW or SAP BW/4HANA system. SAP has developed tools to automate this renovation where possible and feasible, but they are not built or intended to fix badly designed models or clean up neglected systems. The tools will transfer objects based on XML files via RFC from SAP BW Release 7.30 to 7.50 (on SAP HANA or Any-DB), and SAP BW/4HANA 2021 to SAP Data Warehouse Cloud, SAP BW bridge. Each transfer is based on a selection of a specific scope, i.e., a set of SAP BW objects, e.g., a data flow that can be transferred together in a consistent way. Please note that SAP BW 7.40 and lower are already out of maintenance.

SAP provides a Pre-Check Tool (see SAP Note 2575059) that identifies important steps customers need to take to ensure their system is compatible with the conversion process. The tool determines which objects are compatible with SAP Data Warehouse Cloud, SAP BW bridge and which objects are not available in SAP Data Warehouse Cloud, SAP BW bridge. In addition, it checks which objects can be automatically converted, deleted, or need manual adjustments (see figure 2).

Regardless of the type of conversion (see figure 3), the Simplification List (currently in preparation, see SAP Note 3154420) and the Conversion Guide are suitable as a starting point. The Simplification List describes in detail, on a functional level, what happens to individual data models and objects in SAP Data Warehouse Cloud, SAP BW bridge. The individual Notes explain what needs to be done in the conversion process. The Conversion Guide is the end-to-end documentation of a conversion to SAP Data Warehouse Cloud, SAP BW bridge. Note: There is an individual Conversion Guide for the Shell Conversion (see Link) and an individual Conversion Guide for the Remote Conversion (currently in preparation; Remote Conversion is planned for release 2205).

Shell Conversion to SAP Data Warehouse Cloud

Shell Conversion: General Sequence

Shell Conversion (see figure 4) is offered by SAP to convert an SAP BW or SAP BW/4HANA system into SAP Data Warehouse Cloud. It does not include the transfer and synchronization of existing data sets. Instead, customers can choose to load data from original sources, load data from the sender SAP BW or SAP BW/4HANA system, or simply ignore historical data and start fresh. For SAP BW systems on releases from 7.30 to 7.50 (running on SAP HANA or Any-DB) and SAP BW/4HANA 2021, a shell conversion can be performed.

Shell Conversion: (T1) System Requirements

Shell Conversion: (T2) Pre-Checks

Shell Conversion: (T3) Custom Code Check

Shell Conversion: (T4) System Provisioning

Shell Conversion: (T5) Remote Conversion

Shell Conversion: (T6) Post Conversion Tasks

Shell Conversion: (T7) SAP Data Warehouse Cloud Core Tasks

Shell Conversion: (T8) Go-Live

Remote Conversion to SAP Data Warehouse Cloud

Remote Conversion: General Sequence

Remote Conversion (see figure 5) is offered by SAP to convert an SAP BW or SAP BW/4HANA system into SAP Data Warehouse Cloud. It enables customers to move whole data flows or transfer only selected data flows including data. Customers are able to decide whether they want to build a clean system, leave old and unused objects behind. For SAP BW systems on releases from 7.30 to 7.50 (running on SAP HANA or Any-DB) and for SAP BW/4HANA 2021, a remote conversion is planned. Attention: Currently not available, the Remote Conversion is planned for release with SAP BW bridge 2205.

Remote Conversion: (T1) System Requirements

Remote Conversion: (T2) Pre-Checks

Remote Conversion: (T3) Custom Code Check

Remote Conversion: (T4) System Provisioning

Remote Conversion: (T5) Remote Conversion

Remote Conversion: (T6) Post Conversion Tasks

Remote Conversion: (T7) SAP Data Warehouse Cloud Core Tasks

Remote Conversion: (T8) Go-Live

The post Conversion to SAP Data Warehouse Cloud: Conversion Paths and Cloud Transformation Steps appeared first on ERP Q&A.

The limitation is that for BW Live models, the platform has no awareness of Fiscal / Financial periods. SAC offers no native mechanism to dynamically present common reporting scenarios such as Financial Year to Date, or even just Current Financial Year. All dynamic options Calendar based only.

The Requirement

My organisation needed a solution which allowed Self Service users a way to easily build Stories which rely heavily on Financial Year time periods (July – June FY in Australia). The solution had to be:

• As simple as possible for end users to understand and use
• Flexible, so that users could define their own dynamic ranges (we couldn’t predict every scenario, so proliferating measures in models was not viable)
• Dynamic, so that users would not need to manually update filters in Stories as time moved on
• Rapid to implement from a development perspective
• Low maintenance from a BW perspective – no additional staging of data or loads
• Easy to roll out to all relevant existing Composite Providers and queries.

Below I describe an architected solution enabling users to create dynamic Restricted Measures or just add dynamic time filtering to Stories in SAC.

Step 1: Establishing the Building blocks

To start off, I first needed to address another age-old limitation which is that the delivered BW time characteristics cannot have custom attributes added to their master data. The solution here was simply to create two new standard InfoObjects which would carry the attributes that could not be added natively to 0FISCYEAR and 0FISCPER3.

• Two new InfoObjects are created in BW, named FISCYEAR and FISCPER3.

FISCYEAR is created as NUMC(4), with Master Data and also Texts (optional) selected:

Six attributes are then added. The first four are a simple flag and so are typed as CHAR(1). The last two are CHAR(5) to contain some offset values which will be calculated. All are marked as Navigational.

Not all of these are critical for the solution, in fact only the last two will be exposed to SAC later in the demo. The other flags we have in use for specific unrelated modelling requirements.

FISCPER3 is created as CHAR(3) to mimic 0FISCPER3. It just has Master Data defined.

Four attributes are defined, in this case all are CHAR(1) just containing a flag.

Step 2: Adding the Master Data

In order to provide dynamic master data to these new objects without requiring any additional data loads or persistence, a choice was made to provide virtualised master data sourced from a HANA View.

We can natively read an SAP HANA Calculation View to provide master data for an InfoObject, but in this situation I wanted to script the logic so began with two Table Functions which were then exposed through Calculation views.

SAP HANA Table Functions

The Table Function for FISCYEAR master data provides a generated list of Financial years, determining all the required attributes in addition to the Display Text used in other reporting:

FUNCTION "_SYS_BIC"."ZBW.Functions::TF_FISCYEAR_MASTER" ( )
    RETURNS TABLE ( FISCYEAR       VARCHAR(4),
                    CURR_YEAR      VARCHAR(1),
                    LAST_YEAR      VARCHAR(1),
                    CURR_YEAR_LP   VARCHAR(1),
                    LAST_YEAR_LP   VARCHAR(1),
                    YEAR_OFFSET    VARCHAR(5),
                    YEAR_OFFSET_LP VARCHAR(5),
                    TXTSH          VARCHAR(20))
    LANGUAGE SQLSCRIPT
    SQL SECURITY INVOKER
    DEFAULT SCHEMA SAPHBW AS
BEGIN

DECLARE CURR_YR INT    = YEAR(CURRENT_DATE);
DECLARE CURR_YR_LP INT = YEAR(ADD_MONTHS(CURRENT_DATE,-1));

IF MONTH(CURRENT_DATE) > 6
    THEN CURR_YR = CURR_YR + 1;
END IF;

IF MONTH(ADD_MONTHS(CURRENT_DATE,-1)) > 6
    THEN CURR_YR_LP = CURR_YR_LP + 1;
END IF;

RETURN
    SELECT
        ABAP_NUMC(GENERATED_PERIOD_START, 4)    AS FISCYEAR,
        CASE GENERATED_PERIOD_START
            WHEN :CURR_YR THEN 'X' ELSE ''
        END                                     AS CURR_YEAR,
        CASE GENERATED_PERIOD_START
            WHEN :CURR_YR - 1 THEN 'X' ELSE ''
        END                                     AS LAST_YEAR,
        CASE GENERATED_PERIOD_START
            WHEN :CURR_YR_LP THEN 'X' ELSE ''
        END                                     AS CURR_YEAR_LP,
        CASE GENERATED_PERIOD_START
            WHEN :CURR_YR_LP - 1 THEN 'X' ELSE ''
        END                                     AS LAST_YEAR_LP,
        CASE
            WHEN GENERATED_PERIOD_START - :CURR_YR = 1  THEN 'NEXT'
            WHEN GENERATED_PERIOD_START - :CURR_YR = 0  THEN 'CURR'
            WHEN GENERATED_PERIOD_START - :CURR_YR = -1 THEN 'LAST'
            WHEN GENERATED_PERIOD_START - :CURR_YR < -1 THEN '-' ||
                 ABAP_NUMC(GENERATED_PERIOD_START - :CURR_YR,2)
            ELSE ABAP_NUMC(GENERATED_PERIOD_START - :CURR_YR,2)
        END                                     AS YEAR_OFFSET,
        CASE
            WHEN GENERATED_PERIOD_START - :CURR_YR_LP = 1  THEN 'NEXT'
            WHEN GENERATED_PERIOD_START - :CURR_YR_LP = 0  THEN 'CURR'
            WHEN GENERATED_PERIOD_START - :CURR_YR_LP = -1 THEN 'LAST'
            WHEN GENERATED_PERIOD_START - :CURR_YR_LP < -1 THEN '-' ||
                 ABAP_NUMC(GENERATED_PERIOD_START - :CURR_YR_LP,2)
            ELSE ABAP_NUMC(GENERATED_PERIOD_START - :CURR_YR_LP,2)
        END                                     AS YEAR_OFFSET_LP,
        ABAP_NUMC(GENERATED_PERIOD_START - 1, 4) || '/' ||
            ABAP_NUMC(GENERATED_PERIOD_START,2) AS TXTSH
    FROM "PUBLIC"."SERIES_GENERATE_INTEGER" (1, 1970, 2100);

END;

The above function returns several flags based on the determination of the current Financial Year, derived from the current system date.

It also calculates offset values from the Current Determined Financial Year which are the ones critical to this solution.

You will notice two variations in the flags and offsets determined above. One set will support reporting where the user needs to include derivation from the current open Month, and the second set calculate values based on the last Period.

Within my organisation most financial reporting takes place against completed periods, so the current open period is generally excluded. Some reporting requirements however do need to reference the current month. Providing both sets allows flexibility for end users while building their SAC Stories.

It is worth noting that the above code assumes the Australian Financial Year, beginning in July and ending June the following calendar year. Within my organisation we do not have a requirement to support international reporting for different Financial Year Variants. If there was a requirement to do so, then the likely approach would be to compound FISCYEAR against 0FISCVAR as per standard BW, and enhance the code above to provide determinations for the different Fiscal Year Variants.

Noting also that this function leverages SERIES_GENERATE_INTEGER to provide a generated input list of Years. I chose to provision data for a range of 1970 – 2100. This range could be enlarged or reduced by updating the parameters, or even dynamically determined using the current year to provide a sliding window.

For the ‘Year Offset’ values, I chose to provide unique text values for the Current, Next and Last Financial Years to improve the SAC user experience, but these could be omitted and just left as numerical values depending on preference.

The function outputs a list of values similar to the following:

The Table Function for FISCPER3 master data provides a generated list of Financial Periods from 000 – 012, determining all the required attributes for both contexts of based on current open period, or last completed period.

FUNCTION "_SYS_BIC"."ZBW.Functions::TF_FISCPER3_MASTER" ( )
    RETURNS TABLE ( FISCPER3 NVARCHAR(3),
                    CURR_PERD NVARCHAR(1),
                    LAST_PERD NVARCHAR(1),
                    YTD_L_PER NVARCHAR(1),
                    YTD_C_PER NVARCHAR(1))
    LANGUAGE SQLSCRIPT
    SQL SECURITY INVOKER
    DEFAULT SCHEMA SAPHBW AS
BEGIN

-- Generate initial list of periods using SERIES_GENERATE_DATE
-- The years of the dates passed to SERIES_GENERATE_DATE are not critical as we just need one record for the 1st of each month
-- Initial DUMMY SELECT starts table with record for period '000'
-- Current and Last Period flags derived from current system date, so are calendar based
PeriodTab =
SELECT '000' FISCPER3,'' CURR_PERD,'' LAST_PERD FROM DUMMY
UNION
SELECT
     ABAP_NUMC(ELEMENT_NUMBER,3) FISCPER3,
     CASE WHEN MONTH(GENERATED_PERIOD_START) = MONTH(CURRENT_DATE) THEN 'X' ELSE '' END CURR_PERD,
     CASE WHEN MONTH(GENERATED_PERIOD_START) = MONTH(ADD_MONTHS(CURRENT_DATE,-1)) THEN 'X' ELSE '' END LAST_PERD
FROM SERIES_GENERATE_DATE('INTERVAL 1 MONTH', '2000-07-01', '2001-07-01');

-- Return statement uses initial generated table plus two extra columns derived for the Current and Last Period
-- The inline nested SELECT statements look inefficient but performance is actually better than assigning Scalars up front
RETURN
SELECT
    FISCPER3,
    CURR_PERD,
    LAST_PERD,
    CASE WHEN FISCPER3 <= (SELECT FISCPER3 FROM :PeriodTab WHERE LAST_PERD = 'X') THEN 'X' ELSE '' END AS YTD_L_PER,
    CASE WHEN FISCPER3 <= (SELECT FISCPER3 FROM :PeriodTab WHERE CURR_PERD = 'X') THEN 'X' ELSE '' END AS YTD_C_PER
FROM :PeriodTab;

END;

SERIES_GENERATE_DATE is used to supply a source list of dates which are processed for the attributes. The generation start and end Years are not important as long as the months align with the start and end months for the required Financial Year construct.

Again if you needed to support multiple fiscal year variants then the object could be compounded to 0FISCVAR and the function updated accordingly.

The function outputs a list of values similar to the following:

Graphical Calculation Views

Now that we have the two HANA Table Functions in place, two graphical Calculation Views are created to just present the output directly. Since there is no additional logic contained in the Calculation views, I have not included additional detail for these. They are configured with a Data Category of ‘Dimension, and just use a single Projection node to map all the Table Function fields to the Semantics.

Populating the Master Data

Mapping the output of the Calc Views to the InfoObjects is performed via configuration of the Read Access for the InfoObjects on the Master Data/Texts tab for the InfoObjects.

The results are now visible in the Master Data view for the InfoObjects:

Step 3: Adding Dimensions to the Composite Provider

With the new InfoObjects now available, they need to be added in to the Composite Providers as required. This can be done just with a field mapping in the Target scenario

Once the target fields are created and associated with the new InfoObjects, then the existing source fields for 0FISCYEAR and 0FISCPER3 can be directly assigned.

In the Output tab, all Navigation Attributes are then enabled for both FISCYEAR and FISCPER3.

With the Navigational Attributes now available in the Composite Provider, they can be added directly to any Queries used as BW Live data models in SAC. The new Nav Attributes will then become available as dimensions within the Live BW Model.

Using the new Dimensions

In their simplest form the new dimensions can be directly added to any Story in SAC. The example below is for illustration purposes to see how the dynamic dimensions come through.

Note that for the flag based dimensions, short texts have been maintained in BW just for presentation purposes.

Probably the main purpose for the new Dimensions however would be to create dynamic Restricted Measures for use in charting and reporting. The benefit being that as time moves forward, the parameters for the Restricted Measures do not need to be updated as the values in the Dimensions will change according to the date.

For example, creating a Restricted Measure for YTD Budget values (not including the Current Period):

Because the Period flags have been added to FISCPER3 rather than FISCPER, it is generally necessary to restrict on the Fiscal Year dimension also to avoid a selection spanning multiple years. However in some situations this also may be useful. For example, in the figure below the Financial Year filter has been intentionally omitted from the Restricted Measures. Instead, a breakdown by Year is performed indicating the year on year performance against budget for the same YTD time frame. Here a filter is applied at the Widget level, selecting the LAST, -02, -03, -04, -05, -06 & -07 relative years. This time window would also increment dynamically as the years rolled over.

KPI widgets for showing Current Period values are as simple as filtering the widget for Current Period = YES (or ‘X’) and Year Offset = CURR. Again the selection is dynamic and will roll forward automatically.

The post Enabling Dynamic Fiscal filtering in SAC (BW Live) appeared first on ERP Q&A.

This blog post is about a strategic feature of SAP Data Warehouse Cloud, namely the SAP Data Warehouse Cloud, SAP BW bridge. SAP offers its customers through RISE with SAP, the opportunity to move with a business transformation as a service (BTaaS) to the cloud. For BW customers, this means SAP BW to SAP Data Warehouse Cloud. SAP positions SAP Data Warehouse Cloud as the strategic target solution for Data Warehousing in the public cloud, with SAP BW/4HANA Private Cloud Edition (PCE) as an option to start the transition. In this context, SAP BW bridge offers customers the opportunity to implement their new data warehousing use cases directly in the cloud environment while protecting, and retaining their existing on-premises investments. The blog provides an overview about SAP BW bridge, explains how to move from an existing SAP BW system to the cloud, and gives insights with a complete end-to-end greenfield scenario including a system demo in SAP Data Warehouse Cloud.

Overview

SAP Data Warehouse Cloud is SAP’s offering for all data warehousing use cases. This SaaS (Software-as-a-Service) is based on SAP HANA Cloud. It combines data, and analytics in a cloud solution that offers data integration, database, data warehouse, and analytics services. This enables customers to realize the full potential of a data-driven business. As a way to improve the integration with SAP ERP systems, the SAP BW bridge enables ABAP-based data extraction and staging capabilities within SAP Data Warehouse Cloud (see figure 1).

In the future, a tool-based transfer of existing SAP BW and SAP BW/4HANA staging scenarios will be enabled. Then the SAP BW bridge will enable a seamless transfer of existing ETL processes in a dedicated SAP BW bridge Space in SAP Data Warehouse Cloud. Here, the extensive functions of ODP extractors, and ABAP code within the SAP Business Technology Platform (SAP BTP) ABAP environment can be adopted in SAP Data Warehouse Cloud using the Cross-Space-Sharing approach.

SAP BW to SAP Data Warehouse Cloud

Within SAP BW bridge, customers are able to implement data extraction and staging scenarios up to the CompositeProvider level. In other words, it is not possible to create new queries within the SAP BW bridge environment. In this regard, within the SAP BW bridge, there is no support for OLAP engine, and functionality dependent on OLAP (e.g., analysis authorizations, query as info provider, query execution). Front-End tools do not have the possibility to access SAP BW bridge artefacts directly.

The SAP BW bridge environment is primarily intended for ODP-based source systems, which means that the connection scenarios only become available via Operational Data Provisioning (ODP). Non-SAP sources will be connected directly to SAP Data Warehouse Cloud (see figure 2). Objects from source SAP BW system(s) will be converted to the SAP BW bridge environment using Conversion Tools, including the SAP BW queries.

To take the full advantage of SAP’s data warehousing offerings, customers today need to deploy both SAP BW/4HANA, and SAP Data Warehouse Cloud. In the future, the SAP BW bridge will enable customers to merge these offerings into a single data warehouse solution in the cloud. With SAP BW bridge, SAP addresses BW customers that are looking for a way forward from SAP BW NetWeaver, and SAP BW/4HANA (See figure 3).

SAP BW Customers will have the option in 2022 to convert their existing on-premises investments to the cloud via remote, and shell conversion. First, the SAP BW bridge conversion will be offered for SAP BW 7.4, and SAP BW 7.5 systems (initially as shell conversion, followed as remote conversion), subsequently the conversion for SAP BW 7.3 systems (shell and remote conversion) will be available. Additionally, the conversion will be available for SAP BW/4HANA 2021 (shell and remote conversion). Regarding release coverage, please consider the details in the roadmap. Customers with lower SAP BW releases will need to upgrade their system(s) first, and then convert the required scope to SAP BW bridge in SAP Data Warehouse Cloud. Please note that SAP BW systems 7.40, and lower are already out of maintenance (see figure 4).

The SAP BW bridge artefacts out of the Business Technology Platform (SAP BTP) ABAP environment are available via remote tables using SAP HANA Cloud Smart-Data-Access (SDA) in a dedicated SAP BW bridge Space in SAP Data Warehouse Cloud. The remote tables in the SAP BW bridge Space can then be used in the regular SAP Data Warehouse Cloud Spaces via the SAP Data Warehouse Cloud cross-space sharing approach.

Add-ons are not supported in SAP BW bridge. Therefore, planning is not available within SAP BW bridge. In this regard, SAP positions SAP Analytics Cloud Planning as the planning application, and in the future (earliest end of 2022) SAP Data Warehouse Cloud as the planning foundation for the data. Application development is not supported in SAP BW bridge. Any app development should be done via the Business Technology Platform App Building on SAP HANA, for which customers need to license, and use the stand-alone version of SAP Business Technology Platform ABAP Environment.

Target Scenarios for SAP BW bridge

Greenfield with SAP Legacy Sources

Customers building a new data warehouse in the cloud with SAP Legacy systems as data sources that will only be migrated to a cloud-based system in the future. Expecting the same level of data integration, and convenience functions as known from SAP BW/4HANA.

Conversion with SAP BW NetWeaver & SAP BW/4HANA

Customers with an SAP BW (SAP BW 7.3 and upwards, any DB) moving their data warehouse to the cloud expecting to retain their data, and their legacy data flows, but renovating their data consumption layer with SAP Analytics Cloud or 3rd party clients on top, and expanding their data footprint to cloud, and non-SAP sources.

Hybrid with SAP BW/4HANA

Customers with an on-premise SAP BW/4HANA looking for a path into the cloud for their data warehouse workload. Starting with hybrid scenarios for consumption to combine SAP BW/4HANA data, and SAP Data Warehouse Cloud data, and then easily moving more and more of the SAP BW/4HANA data flows to the cloud, and successively transition them to modern SAP Data Warehouse Cloud data ingestion approaches.

End-To-End Greenfield Scenario

As an example, the Greenfield approach is demonstrated in the following use case (See Figure 5). This means when the customer operates SAP Data Warehouse Cloud together with SAP BW bridge to connect SAP on-premises systems. This provides proven SAP BW-based data integration technology for ABAP-based SAP systems, and enables the rich feature set of extractors in SAP Data Warehouse Cloud.

The SAP BW bridge data, and processes are administered, and managed via an SAP UI5 environment called SAP BW bridge Cockpit. The implementation of new objects is done within Eclipse via SAP BW Modeling Tools, and ABAP Development Tools. Within the SAP Data Warehouse Cloud, the SAP BW bridge artefacts are available via remote tables, and can be used via the SAP Data Warehouse Cloud cross-space sharing approach. An SAP GUI is not required to access the SAP BW bridge environment.

SAP BW bridge: Development-Environment

In the following data flow (see figure 6) it can be seen, that the Eclipse environment with SAP BW Modeling Tools, and ABAP Development Tools are used. The well-known SAP flight data model is the foundation for this use case.

In this scenario, the tables “Flight” for transaction data, and “Airline carrier” for master data are considered. The left branch of the data model handles transaction data, the data is loaded from an SAP ECC system respectively an SAPI Extractor. The right branch of the data model handles master data, the data is loaded from a CDS view. As it can be seen, there is still the subdivision into master data texts, and master data attributes. Within the data flow, transformations, and data transfer processes are used to load data into the advanced DataStore Object, and the master data-bearing InfoObject. Within the Composite Provider, the data is then combined with a join.

The SAP BW bridge component is primarily intended for ODP-based source systems. In this regard, customers have the option to create source systems in the context of ODP. This means that ODP-BW, ODP-HANA, ODP-SAP, ODP-CDS, and ODP-SLT based source systems can be connected. This offers the additional benefits of the Operational Data Provisioning Framework, such as Extract Once Deploy Many, data compression, and more.

Dedicated process chains are created for both branches in order to load data into the InfoProviders. The process chains are modelled in the SAP UI5 environment for SAP BW bridge called SAP BW bridge Cockpit (see figure 7).

SAP BW bridge Space in SAP Data Warehouse Cloud

If a customer wants to use SAP BW bridge, a provisioning process is triggered by SAP. With that, there will be a dedicated Space for SAP BW bridge in the SAP Data Warehouse Cloud Tenant itself, generated by the provisioning process. This space then has a specific type “SAP BW bridge” (see figure 8).

In the generated SAP BW bridge Space, a connection (see figure 9a) to the SAP BW bridge environment, within the SAP Business Technology Platform, will be generated that contains an SAP HANA Cloud Smart Data Access endpoint, and a HTTP ABAP endpoint. It is possible to connect only one SAP BW bridge System to an SAP Data Warehouse Cloud Tenant.

The SAP HANA Cloud Smart Data Access endpoint is used to connect to the external schema of SAP BW bridge’s SAP HANA Cloud Database that contains the read-only views to the data tables, for moving over the data. The HTTP ABAP endpoint is used to be able to call Monitor UIs via Single Sign on with a named user, and to get Meta Data e.g., for a value help or import of SAP BW bridge Objects (see figure 9b).

The new connection type cannot be edited by a user in the SAP BW bridge Space, as this connection will be generated by the SAP BW bridge provisioning process automatically. The credentials for the SAP HANA Cloud Smart Data Access connection are provided when the connection is generated. The data tables of the Business Technology Platform environment for SAP BW bridge are exposed as remote tables in the SAP BW bridge Space.

Important: The SAP BW Service Key should be copied, as this needs to be entered when an SAP BW bridge project is set up in Eclipse.

Inside the SAP BW bridge Space, the Create-Button for new connections is disabled, as this Space is restricted to the SAP BW bridge only. The Real-Time Replication Status is inactive for this connection, as it only allows Remote Tables (see figure 9c).

SAP BW bridge Space: Data Builder for importing remote tables

The main purpose of the Data Builder regarding the SAP BW bridge Space (see figure 10) is to import, and share the remote tables for other Spaces, using the Cross-Space Sharing Approach of SAP Data Warehouse Cloud. Unlike the regular Spaces of SAP Data Warehouse Cloud, it is not possible to create Tables, Graphical Views, SQL Views, Entity Relationship Models, or Data Flows within the Data Builder of a SAP BW bridge Space. SAP Data Warehouse Cloud artefacts using the SAP BW bridge remote tables can only be created in other spaces based on the shared remote tables.

Using the Import button in the Data Builder, then via “Import Remote Tables”, the tables of SAP BW bridge InfoProvider can be accessed via the underlying connection (see figure 11).

In the “Import Remote Tables” wizard there is only one connection available, the connection to the SAP BW bridge System (see figure 12). By selecting the defined connection, the connection gets validated. If the validation process is successful, the next step is available.

The wizard for the data tables of SAP BW bridge InfoProvider contain the following data tables, which are then available as Remote Tables in SAP BW bridge Space in SAP Data Warehouse Cloud itself.

• Advanced DataStore Object (Reporting View)
• Composite Provider
• Master Data Tables
  • Attributes
  • Texts

The data tables are displayed by InfoAreas (see figure 13). It is possible to multi select tables to support a mass take over. It is also possible to select an entire InfoArea, then all the tables underneath the objects are selected. Afterwards it is possible to deselect some tables (then the InfoArea can be deselected).

The last step displays the list of objects which are ready for import. There is one more section for Remote Tables, which are already in the repository of SAP Data Warehouse Cloud. The user can also change the technical name, and the business name of the appropriate object. Via “Import and Deploy” the remote tables will be generated with Semantic Usage as Relational Dataset. The Master Data Text tables can be generated as either Dimension or Text (see figure 14).

Next, the remote tables located in the SAP BW bridge Space in SAP Data Warehouse Cloud need to be shared with the regular SAP Data Warehouse Spaces. As already outlined before, the main functionality here is to import, and share the remote tables for other spaces. SAP Data Warehouse Cloud artefacts using the remote tables can only be created in other spaces, based on the shared remote tables.

In my example, I have created a standard SAP Data Warehouse Cloud Space “DENIZBWBRIDGE”, which consumes the artefacts, and allows further implementation within the SAP Data Warehouse Cloud (see figure 15).

SAP Data Warehouse Cloud Space: Consuming Shared SAP BW bridge Artefacts

Within standard SAP Data Warehouse Cloud Spaces, the shared SAP BW bridge Remote Tables can be accessed, and other SAP Data Warehouse Cloud functionality can be applied accordingly (see figure 16).

The following SQL code of the previous graphical view (see figure 17) states that the view within the standard SAP Data Warehouse Cloud Space accesses the remote tables of the SAP BW bridge Space in SAP Data Warehouse Cloud.

SELECT *
FROM (("BWBRIDGEDEMO.ZDOFLIGHTREPORTING" AS "ZDOFLIGHTREPORTING"
INNER JOIN "BWBRIDGEDEMO.ZDO_AIRLATTRIBUTES" AS "ZDO_AIRLATTRIBUTES" 
ON "ZDOFLIGHTREPORTING"."CARRID" = "ZDO_AIRLATTRIBUTES"."ZDO_AIRL") 
INNER JOIN "BWBRIDGEDEMO.ZDO_AIRLTEXT" AS "ZDO_AIRLTEXT" 
ON "ZDO_AIRLATTRIBUTES"."ZDO_AIRL" = "ZDO_AIRLTEXT"."ZDO_AIRL");

Figure 17: SQL-Code of Graphical View

SAP Analytics Cloud: Story based on SAP BW bridge data

Finally, based on the analytical data set of SAP Data Warehouse Cloud, which in this case processes SAP BW bridge data, a visualisation of the data can be done via SAP Analytics Cloud (see figure 18) or any other 3rd party front end solution.

Like for other data models in SAP Data Warehouse Cloud you can use SAP Data Warehouse Cloud Live Data Connection of SAP Analytics Cloud. However, SAP Analytics Cloud generally has certain limitations with SAP Data Warehouse Cloud Live Data Connection, detailed information is available in SAP Note 2832606.

SAP BW bridge Space: Data Integration Monitor

Within the SAP BW bridge Space only Remote Tables are available. For the Data Integration Monitor of the SAP BW bridge Space that means, that the View Persistency Monitor, and Data Flow Monitor are not visible (see figure 19).The available functionalities here are the Remote Table Monitor, and Remote Query Monitor. In addition, access to the SAP BW bridge Cockpit is possible via the Data Integration Monitor of the SAP BW bridge Space.

The post SAP Data Warehouse Cloud, SAP BW bridge: Overview and Technical Deep Dive appeared first on ERP Q&A.

Overview of the C_BW4HANA_27 Certification:

C_BW4HANA_27 certification proves that the candidate is versed with an overall understanding and in‐depth technical skills to become a project team member under a mentor’s guidance.

C_BW4HANA_27 or the SAP Certified Application Associate – Reporting, Modeling, and Data Acquisition with SAP BW/4HANA 2.x certification exam acts as the proof of the candidate’s core and fundamental knowledge needed for the profile of modeling, data acquisition, and query design with SAP BW/4HANA.

Target Audience for the C_BW4HANA_27 Exam:

The C_BW4HANA_27 certification is for candidates interested in utilizing the benefits of SAP BW4HANA in their work. The exam is recommended as an entry-level qualification, so any candidate can take the exam.

What Do You Need to Study During the C_BW4HANA_27 Exam?

The C_BW4HANA_27 exam deals with the following topics-

• SAP BW Query Design
• Data Acquisition into SAP BW/4HANA
• Data Acquisition into SAP HANA
• Fundamentals
• SAP BW/4HANA Modeling
• SAP BW/4HANA Project and the Modeling Process
• SAP Analytics Tools
• SAP BW/4HANA Data Flow
• Native SAP HANA Modeling
• InfoObjects and InfoProviders

How to Ace the SAP C_BW4HANA_27 Exam?

Learn about the C_BW4HANA_27 Exam Pattern:

The C_BW4HANA_27 exam consists of 80 questions. The C_BW4HANA_27 exam is 80 questions long, and a candidate should cover the exam within 180 minutes. The aspirant must get 65% marks to pass the exam. Make yourself ready to face multiple-choice questions of single answer and multiple response-based.

Cover All C_BW4HANA_27 Syllabus Topics:

The syllabus of the C_BW4HANA_27 exam is almost equal percentage-based, so the candidate should emphasize more on covering every syllabus section to attempt a maximum number of questions.

Having a firm grip on the whole C_BW4HANA_27 syllabus is the key to a candidate’s success in the exam. If you are not confident on some of the syllabus topics, don’t ignore them completely, but have the determination to learn the fundamentals of those sections.

Set A Specific Study Time:

Choose the specific study time from your daily schedule. Every candidate is productive at a different time, therefore don’t go after some else’s schedule and devote at least two to three hours from your productive time.

Join the SAP Training:

SAP provides specific training for every SAP exam. An aspirant must follow the C_BW4HANA_27 training to learn from the experts and enhance their knowledge regarding the syllabus topics.

Search for the Reliable Practice Test and Leave Dumps:

Only studying is not enough. You must assess yourself easily through C_BW4HANA_27 practice tests. The practice tests are highly useful in making you realize your time spent during the exam. You might be highly prepared, but still, you can’t score well if you fail to manage time.

C_S4HDEV1909: PDF Sample Questions & Practice Test to Conquer the Programming in S/4HANA for NetWeaver ABAP Programmer Exam?

It would be better to avoid dumps for the C_BW4HANA_27 exam. Dumps are easily available materials, might be cheaper too, but doesn’t give you the assessment power. You can only read from a dump.

But when it is about the C_BW4HANA_27 practice test, the result section is helpful to guide about the section you are unable to answer. A candidate can score well in the exam if he follows the guidance well. Finding a reliable practice test is the task to score well in the exam. Depend on google search and testimonial reviews for choosing a premium practice test.

Overview of SAP BW4HANA:

SAP BW/4HANA solution is the next generation of SAP BW, which works only on SAP HANA. The solution uses SAP HANA libraries and engines. The user gets the flexibility of using cloud deployment with BW/4HANA. SAP BW/4HANA is available in three forms, and based on the Business demand; a candidate can choose the deployment option.

Some Benefits of Using BW4HANA Solution:

Capitalize the full Value of All Your Data:

Make digitization across all lines of business with a Big Data warehouse while leveraging digital business platform solutions from SAP.

Make Simple Provisioning of Timely Business Insights:

To get greater agility, change data practices to deploy live insights at scale, both on the cloud and on-premise.

Have One Source for All Insights:

Enhance business adoption with advanced analytics, tailor applications to fit your demands, and reimagine your business with integrated machine learning.

Bottom Line:

If you are keen to apply the enormous benefits of SAP BW4HANA in your work and flourish your career with SAP certification, the C_BW4HANA_27 certification could be a great career builder.

The post C_BW4HANA_27 Exam: How to Ace the Exam on Your First Attempt? appeared first on ERP Q&A.

• Re-folder the InfoObject grouping
  
• Change the InfoObject sequence
  
• Insert a new compounding child InfoObject
  
• Insert a new compounding InfoObject (parent and child)
  
• Maintain RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD

As explained in the blog posts from Frank Riesner, note 3006437 brings a new RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD, that allows us to control the threshold limit of the number of records, beyond which the system triggers a remodeling request. However, in large enterprises, the possibility of having ADSOs, with more than 100 million records is very common. Thanks to the note 3019867, this limitation has been addressed.

For the scope of this blog post, The following scenarios are tested. For space reasons, scenarios 1 – 4 and 7 are part of this blog. Scenarios 5 and 6 had the same results with all other regrouping scenarios. Scenarios are checked in both a SAP BW/4HANA 2.0 SP06 and in a SAP BW 7.5 SP15. Screenshots are from the SAP BW/4HANA system.

Let’s see the details now:

Implement Note 3006437

Scenario 1:

Conditions for scenario:

• Add a compounding InfoObject into the dataflow
  
• No RSADMIN parameter is maintained in both source and target system.
  
• The ADSO is of type “Standard”
  
• ADSO contains less than 50,000 records in the Development system.
  
• The InfoObject is compounded with two parent InfoObjects, “Source Ssystem” and “Controlling Area”.
  
• Parent InfoObjects are already part of the ADSO model:

Observations:

• No remodeling request is generated.
  
• System is checking if RSADMIN parameter is maintained.
  
• If not, then the 100,000,000 takes care of the checks.
  
• New InfoObjects are added in the entire data Flow: Composite provider, source ADSO, target ADSO.

• Transport to target system does not generate a remodeling request and all objects are activated during the transport process.
  
• No of records of the ADSO in target system is less than 100 million

Scenario 2:

• Re-foldering of ADSO,
  
• Change the InfoObjects sequence,
  
• no maintenance of RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD in both source and target systems.

ADSO is type “standard” and scope of the test case is to validate the system doesn’t generate any remodeling request once you change folders, or change the InfoObject sequence of “Data fields”.

Sub scenario 2.1:

Conditions for scenario:

• In Development system: No of records in ADSO = 0
  
• Change InfoObjects sequence on “Data fields” area:

Observations:

• No remodeling request is generated
  
• No impact on dependent Composite Provider: it is still active, however Transformation and DTP are getting inactive: you need to activate and collect them in your transport.
  
• SE11 Table structure: As there are no data, it seems that the table structure is changed

Sub scenario 2.2:

Condition for scenario:

• We take the same ADSO as sud-scenario 2.1, but this time with data.
  
• In Development system: No of records in ADSO is appr. 3.5 million
  
• Change the sequence of 2 InfoObjects

Observations:

• No remodeling request is generated:

• TRFN and DTP are getting inactive: you need to collect them in your transport

Sub-scenario 2.3:

Conditions for Scenario:

• Continue with same ADSO as sub-scenario 2.2.

Check 1: Add a new group in the ADSO and regroup the infoobjects:

Observation:

• No remodeling request is generated:

Check 2: Add one more Group and move all the key figures:

Observations:

• No remodeling request is generated but the interesting part is that table structure as per SE11 is not adjusted as well!

SE11: No changes in the table structure: however, the real picture of table can be taken from Hana only.

Check 3: Moving the changes to the target system, we see as per the transport log, no remodeling request is generated and all dependent objects are activated (1 Composite Provider, 2 ADSOs, 2 Transformations, 2DTPs): Target ADSO has 517.772 entries.

SE11 structure of ADSO before import the change:

Changes imported to Target system without any errors, and the new groups are created:

SE11 structure of ADSO after the change is imported into the target system:

Scenario 3:

Condition for scenario:

• Re-foldering of ADSO
  
• Change the InfoObject sequence, regrouping,
  
• Maintenance of RSO_ADSO_ONLINE_CONV_THRESHOLD with a limit less than the ADSO no of records in target system only

Development system:

ADSO: No data, RSO_ADSO_ONLINE_CONV_THRESHOLD is not maintained.

Create an additional Group and move the change to target system. No remodeling request is generated.

Transport to target system:

Observation in Dev System:

No remodeling request is generated, all objects are activated (1 Composite Provider, 2 ADSOs, 2 Transformations, 2 DTPs).

Target system:

RSADMIN parameter is maintained with value as 50,000 (less that the entries in target DSO, which is 517,772):

SE11: No changes in the data structure:

Please take a look into table structure through Hana Studio: the only change is happening due to the addition of child compounding infoobjects. All other changes (regrouping, infoobject sequence) are not affecting the table structure.

Observation in Target System:

• No remodeling request is generated, all objects are activated

Scenario 4:

Conditions for scenario:

• Add a new compounding child infoobject in the ADSO.
  
• Maintenance of RSO_ADSO_ONLINE_CONV_THRESHOLD with a limit less than the no or records of my ADSO in target only

In Development system:

• ADSO: No data, RSO_ADSO_ONLINE_CONV_THRESHOLD is not maintained
  
• Add a new compounding IO (child only)

Observation in Dev System:

ADSO is activated – no remodeling request is generated, however there are warning about potential remodeling: (Please do not be confused, It is just a warning!!)

In Target system:

• RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD value set to 50,000.
  
• Transport log of the target system:

Observations in Target System:

• Remodeling request generated.

Is it very important to check the log; we are informed that a remodeling request is generated by ADSO and on top, all dependent objects are SKIPPED. All dependent objects should be taken care by remodeling request.

As we can understand, the remodeling request is hidden in the transport log. In most of the cases, developers or transport managers ignore the warning messages that generated during the transport.

As a result, developers recognize the issue only during their test and you can understand the risks its entails!!

Remodeling Request: (transaction RSMONITOR)

Execution of remodeling request was successful, ADSO is adjusted and all dependent objects are activated.

Scenario 7 – Implement note 3019867

After the implementation of note 3019867, SAP removes the fixed 100 million limit and it is customer responsibility to define the limit through the RSADMIN parameter.

Responsible of the check is method IS_ONLINE_CONV_POSSIBLE of class CL_RSCNV_ADSO_HDB. Default value 100 million is still valid, however RSADMIN parameter value controls the process of ADSO activation.

So, for our scenario, I maintained RSADMIN parameter RSO_ADSO_ONLINE_CONV_THRESHOLD with a value of 2 billion in my target system and I enhanced an existing ADSO type “DataMart” with a child compounding infoobject

My ADSO keeps 1.7 billion records in the target system. Total number of columns (characteristics and key figures) = 90.

ADSO active table view from Hana Studio:

Add child compounding infoobect in Development system:

As expected, no remodeling request is generated, however there are warning messages for potential remodeling if ADSO is not empty.

Target system:

RSADMIN parameter is maintained as 2 billion.

Changes moved to the target system; here the transport log;

• Transport takes approximately 10 mins
  
• All dependent objects are activated during the transport
  
• As expected, no remodeling request generated.

The post ADSO Remodeling: Cases after implementation of notes 3006437 and 3019867 appeared first on ERP Q&A.

In this blog post I will focus on our firsthand experience with remote conversions and point out the steps needed for a successful migration. A remote conversion consists of 2 Steps. Step 1 the Meta data conversion is being described in this blog post. Step 2 the Data Conversion is not discussed in this blog post.

Prerequisite to Remote Conversions

With an In-place conversion the customer first needs to upgrade its BW system to BW 7.5 compatibility mode. For a client that is currently on BW 7.4 this requirement will add a step to navigate on their route from earlier versions of BW to SAP BW/4HANA For many customers, the Remote Conversion offers a way to avoid the initial upgrade to BW 7.5. Remote conversions can originate out of BW systems from BW7.3 and up. In addition, the sender system does not need to be on a Hana data base while an in place conversion requires to have a Hana DB as a starting point.

Variations of Remote Conversions

Shell Conversion

In a Shell conversion only the meta data is migrated from the old BW sender system to the new SAP BW/4HANA receiver system. All Info Providers, Data flows, Process chains etc. are migrated but the data is not migrated over to the receiver system.

This is a simpler form of Remote Conversion since many issues in a classic Remote Conversion originate in the data transfer phase.

In a Shell Conversion only the structures are migrated, and the data will be loaded from SAP S/4HANA/ECC

Classic Remote Conversion

In a Classic Remote Conversion both the Meta data and the data are migrated from a legacy BW sender system to the new SAP BW/4HANA system.

This conversion is the more complicated than the Shell Conversion, but it will create an exact copy of the clients existing BW system under the new SAP BW/4HANA landscape.

This is a good approach if SAP S/4HANA / ECC does not have all the data the client needs, and the reporting consumers are expecting the full historical data volume.

In a Remote Conversion both data and structures are migrated

Carve Out

The Carve Out is a variation of both Remote and Shell Conversions. In a carve out the client will choose data flows to be converted. Only flows that you want to continue to use will be converted.

During the carve out the conversion algorithm will check on the inter dependencies of the chosen structures with the rest of the system. The conversion will fail if any needed dependency is missing. Once carved out objects cannot be re-integrated into the conversion. Therefore, a carve out option only applies in cases in which the client is sure that the carved-out structures are not needed anywhere else.

The carve out can be done either with data ( Classic remote) or no data ( Shell Conversion)

Early Preparations

Early preparation should start well ahead of the actual migration. The Prep is an optional exercise and can be done by the client. This exercise will cut down on Project Timeline and staffing resource costs during the migration.

Request Reductions

Note 1431315 and the instruction in transaction “RSREQREDUCE should be carefully studied and implemented well in advance. No Info-provider can have more than 1000 request. Request reduction can have hidden issues that need time for resolutions. Lessons Learned (old 3X data-flows had hidden not fully promoted request and inconsistent tables which stopped reduction.)

Virtual Info Cubes

Are not supported in SAP BW/4HANA and would need to be redesigned before conversion.

Fix all Multi-provider Compounding Issues

Note 1045683 – Compounding problem (CMP problem)

3x Queries with “Calculation before Aggregation” setting

Replace with supported exception Aggregation.

3x data flow clean up

The conversion will not allow any 3x data-flow objects to be present in the system.

Often clients still have 3x data-flow used in master data load scenarios. In addition, the automatic conversion of 3 x data-flows does not delete the transfer structures. Even if the client has completed the 3x conversion in the past a considerable amount of work is needed to clean up the old transfer structures. These old transfer structures also will be associated to old requests which will cause issues with request reduction and structure deletion. Lessons learned : Do not think you are done with 3x flow clean up if you did a flow conversion in the past.

Code Analysis

When executed Code analyzer returns a report.

All Objects Marked in red need to be addressed.

Since this is a first very early run not all the code changes need to be made at this point. Its good practice to get familiar with the issues and to address anything that can be done without causing issues in the old environment. Some code changes will have to wait for the actual Migration Prep.

Typical Code changes ( some must happen after migration)

• Abap functions being called that do not exist in BW4.
  
• Program Includes used that do not exist in BW4
  
• Look-Ups against tables that changed names e.g active table for DSO has different naming convention than active table in Adso.
  
• Automatic Master Data Look-up in Transformation does not work because in BW4 the full key is needed to access aDSO
  
• Changes to Info Object Length (e.g. 0material)
  
• Types and Classes do not exist anymore

Reporting Analysis

Questions to be asked during Analysis.

• Which reports are based on Info Sets? (its is possible that they are not needed since most of the time Info Set based reports are abandoned due to performance issues. Info set conversion could be de-prioritized.
  
• Which reports are still pointing directly at Cubes or DSO’s ? These will have to be copied over to the Multi-provider and tested before migration.
  
• Which reports are depending on APD’s ? APD’s will have to be rebuild and reports may be impacted.
  
• Which reports are based on data-flows that are based on de-commissioned data sources ? Later a detail analysis is needed to make sure all field are still available.
  
• Any Reports on Virtual Info Providers ( not supported in SAP BW/4HANA)

APD Rebuild

Transaction RSB4HAPD is providing SAP migration tool for APD’s

SAP is currently not providing a fully operational conversion tool for APD’s. The existing tool works only for the simplest APD’s. Most APD’s have to be rebuild.

APD’s can be rebuild before the migration. The functionality needs to be built into End- or Expert- routines using transformations. In addition, DTP’s with filter functions can be used. The workflow being used in the APD will need to be rebuild using a Process chain. Lessons Learned (do not trust the APD conversion tool. Start early to build out APD replacements)

Data source Analysis

All data sources will need to be ODP compliant.

Almost all Data sources commonly used in a BW implementations are whitelisted for use in ODP as well.

SAP Note 2232584 contains the updated list of data sources that are released for ODP.

Checking the ODP whitelist against the list of utilized data sources is an important first step and can start early.

If the transactional system remains to be SAP ECC its is important to check that your release supports ODP data sources. For SAP BW/4HANA the SAP ECC source system should have the following minimum release (picture source SAP)

Team training

Start to train the team early. Below a list of the most important SAP classes

• HA100 – SAP HANA – 360° Introduction
  
• BW410 – SAP BW/4HANA Data Warehousing
  
• BW430 – SAP BW/4HANA Modeling
  
• BW450 – SAP BW/4HANA Data Acquisition
  
• BW462 – SAP BW/4HANA
  
• BW405 – SAP BW/4HANA Query Design and Analysis

Migration Steps Option 1

System Copy Approach

• Advantage: Less reliance of SAP involvement through reduction of the remote migration complexity. Currently SAP team must assist in ending phase of Meta data and throughout the data conversion due to missing SAP documentation.
  
• Disadvantage: Only works if SAP S/4HANA/ECC environments have roughly the same data volume. Data catch up needs additional data quality testing

In this option the actual conversion is only done once.

1. System copy of BW 740 Production System to create Remote Conversion Sender System
   
2. Application of all needed Notes and all needed prep to Sender system
   
3. Standing Up of the SAP BW/4HANA System and application of all needed notes
   
4. Application of all needed notes to SAP BW/4HANA System
   
5. Meta Data conversion using conversion cockpit and transport of copies to to SAP BW/4HANA receiver System.
   
6. Data conversion into SAP BW/4HANA receiver system
   
7. System Copy’s of the SAP BW/4HANA receiver system to SAP BW/4HANA- Dev,QA and Prd.
   
8. Data catch up from S/4HANA/ECC sources for all three systems.

Migration Steps Option 2

Classic SAP Conversion approach

In this option the conversion is done for each System using one Task list

1. Stand Up SAP BW/4HANA- Dev, QA and Prd System and install all necessary notes to Dev.
   
2. Application of all needed Notes and all needed Prep to BW 740 Sender system
   
3. Remote Conversion from Old BW 740 Dev system to new SAP BW/4HANA- Dev system
   
4. Transport of Notes and task list from BW 740 Dev to BW 740 QA. The task list log will also be transported
   
5. Transport prep from SAP BW/4HANA Dev to SAP BW/4HANA QA
   
6. Remote conversion Old BW 740 QA system to new SAP BW/4HANA QA system
   
7. Transport of Notes and task list from BW 740 QA to BW 740 Prd. The task list log will also be transported
   
8. Transport Prep from SAP BW/4HANA QA to SAP BW/4HANA Prd
   
9. Remote conversion Old BW 740 Production system to new SAP BW/4HANA Production system

Prep at Beginning of Migration Project

Initial Note implementation

Many Notes need to be applied in BW sender 7.X system and SAP BW/4HANA receiver system

In a first step read Note 2541557 which will allow you to download the note analyzer. Install the program in both sender and receiver systems. run the analyzer throughout the project. Running the downloaded program and using the xml file for remote conversion will provide you with the list of notes that need to be installed in prep of the migration

Here is a list of Notes ( which is constantly changing and just an example )

At this point you will find yourselves in a transport freeze if you choose the classic SAP Migration Approach ( Option 2) .If you choose Option 1 you will have to first make a system copy of your production BW system to create the migration Sender System. The existing BW Landscape will remain untouched when using Option 1 ( system copy approach).

From here on all additional Prep will be done either in the BW development 7.X system ( Option 2 ) or in the System Copy of the BW.7x Production System (Option 1)

2nd round of code resolution

Now we can do all code resolutions that would have interrupted the old system

• Replacing functionality of missing System functions or includes
  
• Changing any fields routine logic that still refers to transfer structures
  
• Changing custom functions called out by code scan
  
• Clean up Process Chains with deprecated functions like PSA delete , Change log delete, cube compression, cube index deletion.
  
• For look ups instead of the select statements, use the API (cl_rsda_infoprov_query=>select) to get that data.

ODP Data Source migration in Transactional System (SAP S/4HANA/ECC)

ODP capable Data sources need to be converted to ODP in the SAP ECC or S/4HANA system prior to conversion. Non ODP capable Data sources need to be replaced. SAP Note 2232584 describes the process in detail.

To enable use of ODP data replication you must first implement the Support Packages or SAP Notes described in the following SAP Notes in your system:

– SAP Note 1521883 (ODP Replication API 1.0 ) for SAP_BASIS < 730

– SAP Note 1931427 (ODP Replication API 2.0 ) for SAP_BASIS >= 730

Run program BS_ANLY_DS_RELEASE_ODP in the SAP source system to release all Business Content extractors.

Run program RODPS_OS_EXPOSE in the SAP source system to release all custom extractors to ODP.

System Landscape before conversion

SAP S/4HANA/ECC system needs to be connected to Sender- and Receiver BW Systems

Last Steps for both conversion options

• Making sure that all objects in the system are active
  
• Making sure that all delta queues are healthy
  
• Making sure all delta requests that have already been received are fully promoted to all Info providers
  
• No Info Provider has more than 1000 request
  
• All change logs are purged
  
• We know what to carve out
  
• Sender and Receiver system are connected to same SAP S/4HANA/ECC System
  
• Change all Data sources to ODP if transactional system is not SAP S/4HANA
  
• Min of 20 percent of the database size available in Sender System

Additional Steps for Option 2 Conversions

• Block all users in Sender System in Sender System
  
• Stop V3 update jobs in SAP S/4HANA/ECC

Migration

Scope Collection and Meta Data Import to Receiver System

In Scope Collection phase several tasks need to be performed

• Carve Out any not needed Objects ( Be careful. Once these Objects are carved-out, they can not be re-introduced within the same package)
  
• Collect additional data sources that are not automatically connected ( e.g., all Asset Accounting data sources )
  
• Name the write optimized aDSO’s that will replace PSA’s
  
• Assign transport packages to all entries
  
• Makes sure everything is flagged for conversion
  
• Tip: Do not plan to use several smaller packages. Everything needs to go together in one BIG-BANG Package. Lessons Learned ( Verify with Team that nothing in here is missing and obtain sigh off)

In Scope Collection error list

• Scope Collection Step will return a list of issues that will have to be performed to migrate the scope. Here you must fix what was missed during Prep.
  
• There are 2 iteration. In a first one the scope collection will complain if something larger is missing. ( Missing Transport package assignments, Missing aDSO names for PSA replacements, Missing datsources, )
  
• In the 2nd finer one the scope collection has completed but the transports are not yet released yet. Here the errors can be numerous. Inactive objects, corrupt info packages, process chain variants that do not have assignments, missing objects that have been carved out by accident

Transport of copy request generation

• At the conclusion of the Scope Phase Transport of Copy requests will be created
  
• In a next step these requests need to be imported into the receiver system
  
• At the end of this phase the receiver system should contain all selected data-flows in a converted SAP BW/4HANA format
  
• Verify the objects and make sure that all new objects in the receiver system are active .

The Task List has a manual confirmation step before data migration can start, This confirmation has to happen after the team has confirmed the successful import of the Migration transports into the receiver system. After this confirmation the Data Transfer Phase can start.

The post Remote SAP BW/4HANA Meta data conversion in detail appeared first on ERP Q&A.

BW Workspaces are dedicated areas in a BW system where new models can be created based on central BW and local data files (i.e. flat files). The BW Workspace environment itself needs to be created, maintained, and controlled by IT. Once IT setup the BW Workspace, then the business users can subsequently use the BW Workspace to combine data from BW with data in flat files in order to react quickly to new and changing requirements.

There are some prerequisite for creating workspaces and those are: Activate the following ICF services in transaction SICF:

• RSL_UI_MY_WORKSPACE
  
• RSL_UI_CREATE_COPR
  
• RSL_UI_CREATE_PROVIDER
  
• RSL_UI_CHANGE_WORKSPACE
  
• RSL_UI_CHANGE_QUERIES
  
• RSL_UI_SUBMIT_DATA
  
• RSL_UI_CREATE_LCHA
  
• RSL_UI_CREATE_LCHY

Create the required roles and authorizations/authorization profiles. The authorizations are assigned using authorization object S_RS_WSPAC (workspace name and activities).

Authorization:

The following authorization templates are delivered for the three user roles:

• BW Workspace Administrator (S_RS_TWSPA)
  
• BW Workspace Designer (S_RS_TWSPD)
  
• BW Workspace Query User (S_RS_TWSPQ)

The below are steps to create/edit workspace:

Step 1: Go to transaction RSWSP

Step 2: Enter the name of workspace and click on create.

Step 3: Enter description of workspace.

Step 4: Setting Tab: This is general settings of workspace. Here add the expiry date for the workspace, set a prefix for the providers in the workspace so, all providers and transient queries in the workspace are then given this prefix, you can also mention the contact of the developer who needs to be contacted if the workspace encounters any errors.

Step 5: Central Providers tab: Add the required info provider to workspace as a central provider and select the required fields from it.

Step 6: Submission targets: Here you can add the required target info provider in which you want to load the data from workspace to BW. For our demo we are not using any targets.

Step 7: Remaining tabs will be automatically gets filled when business user use workspace later like local providers, queries and other things will be created. Just activate workspace as below.

There are two web-based environments for business users are available which includes BW Workspace Designer and BW Workspace Query Designer.

BW Workspace Query Designer

SAP BW Workspace Designer is a SAP UI5 based tool used by business users to create and edit queries and local providers on the top of BW workspaces.

There are some prerequisite for using SAP BW Workspace Designer i.e. activate the following ICF services in transaction SICF: /sap/bc/ui5_ui5/sap/rsl_wqd and /sap/bw/modelling.

For starting the application use transaction RSWQD or select the following directly in a web Browser enter following URLs in your browser, depending on which port is configured (HTTP or HTTPS).

http://<Web Server Host>:<Web Server Port>/sap/bw/wqd/index.html

Step1: Select the workspace “ZWS_DEMO”

Step2: Create Info provider (Local provider). Say create from local data on popup screen enter name and select file which needs to be loaded and hit save button.

Step3: Create local composite provider: Select create to merge local data option and in popup enter name and select central provider and hit save.

Step 4: Add new dimension “Material Description” from local provider.

Step 5: Add new dimension’s name and select mapping column from available columns.

Step 6: Select option local provider and choose our created local provider ZWS_LP1 and add column from local provider to composite provider with mapping material number and transfer values and save it.

Step 7: Create local query as below and save and run it.

Step 8: Local query output: Shows added dimension material description with central provider data.

This is how we integrated new column from excel file with BW info provider’s data.

The post BW4HANA Workspaces appeared first on ERP Q&A.