|
Sep 16, 2014
10 Golden Rules for SAP BW on HANA Migrations
Sep 10, 2014
Posted by Thomas Zurek
This is yet another question that I get from all angles, partners, customers but even colleagues. BW has been the spearhead SAP application to run on HANA. Actually, it is also one of the top drivers for HANA revenue. We've created the picture in figure 1 to describe - on a high level - what has happened. I believe that this not only tells a story on BW's evolution but underlines the overall HANA strategy of becoming not only a super-fast DBMS but an overall, compelling and powerful platform.
Fig. 1: High level comparison between a classic BW and the two versions of BW-on-HANA. Here as PPT.
Classic BW
Classic BW (7.3ff) follows the classic architecture with a central DBMS server with one or more application servers attached. The latter communicate with the DBMS in SQL via the DBSL layer. Features and functions of BW - the red boxes in the left-most picture of fig. 1 - are (mostly) implemented in ABAP on the application server.
BW 7.3 on HANA
At SAPPHIRE Madrid in November 2011, BW 7.3 was the first version to be released on HANA as a DBMS. There, the focus was (a) to enable HANA as a DBMS underneath BW and (b) to provide a few dedicated and extremely valuable performance improvements by pushing the run-time of certain BW features to the HANA server. The latter is shown in the centre of fig. 1 by moving some of the red boxes from the application server into the HANA server. As the BW features and functions are still parameterised, defined, orchestrated from within the BW code in application server, they are still represented as striped boxes in the application server. Actually, customers and their users do not note a difference in usage other than better performance. Examples are: faster query processing, planning performance (PAK), DSO activation. Frequently, these features have been implemented in HANA using specialised HANA engines (most prominently the calculation and planning engines) or libraries that go well beyond a SQL scope. The latter are core components of the HANA platform and are accessed via proprietary, optimised protocols.
BW 7.4 on HANA
The next step in the evolution of BW has been the 7.4 release on HANA. Beyond additional functions being pushed down into HANA, there has been a number of features (pictured as dark blue boxes in fig. 1) that extent the classic BW scope and allow to do things that were not possible before. The HANA analytic process (e.g. using PAL or R) and the reworked modeling environment with new Eclpise-based UIs that smoothly integrate with (native) HANA modeling UIs andconcepts leading also to a reduced set of infoprovider types that are necessary to create the data warehouse. Especially the latter have triggered comments like
"This is not BW."
"Unbelievable but BW has been completely renewed."
"7.4 doesn't do justice to the product! You should have given it a different name!"
It is especially those dark blue boxes that surprise many, both inside and outside SAP. It is the essence that makes dual approaches, like within the HANA EDW, possible, which, in turn, leads to a simplified environment for a customer.
Sep 2, 2014
Concepts on BW,Understanding Connections
|
Aug 25, 2014
The HANA Journey: Determining When HANA is Right for You
Via Content in SCN
I would like to thank my colleague Robert Hernandez, Director of In-Memory Services, North America for his collaboration and input to this blog.
If you're reading this blog, SAP HANA has caught your attention. By now, you've probably heard a significant amount about SAP HANA. It's the next-generation platform with blazing speed, real-time reporting, and powerful analytics, able to capitalize on unprecedented opportunities and deliver significant competitive advantages. As the SAP HANA topic has matured, you've probably also heard of different ways to deploy it in your business; solutions such as SAP Business Suite accelerators, SAP HANA applications, SAP BW on HANA, SAP Business Suite on HANA, and more. You've possibly heard so much in fact that you feel the need to take a step back and ask - so what does it all mean to me? It's fast – great. It can help me – fine. But, where do I start, and how do I take advantage of it? Do accelerators help me? Should I start with SAP BW on SAP HANA? Does the introduction of SAP Business Suite on SAP HANA now change everything? Like other break-through innovations, SAP HANA on its own will not deliver value. But, SAP HANA applied to a particular business problem or challenge can deliver exceptional value. So, if you still have some questions about whether SAP HANA is right for you, or more importantly, how it's right for you, then read on to determine how best to realize value from SAP HANA.
Beginning the HANA Journey
I would like to thank my colleague Robert Hernandez, Director of In-Memory Services, North America for his collaboration and input to this blog.
If you're reading this blog, SAP HANA has caught your attention. By now, you've probably heard a significant amount about SAP HANA. It's the next-generation platform with blazing speed, real-time reporting, and powerful analytics, able to capitalize on unprecedented opportunities and deliver significant competitive advantages. As the SAP HANA topic has matured, you've probably also heard of different ways to deploy it in your business; solutions such as SAP Business Suite accelerators, SAP HANA applications, SAP BW on HANA, SAP Business Suite on HANA, and more. You've possibly heard so much in fact that you feel the need to take a step back and ask - so what does it all mean to me? It's fast – great. It can help me – fine. But, where do I start, and how do I take advantage of it? Do accelerators help me? Should I start with SAP BW on SAP HANA? Does the introduction of SAP Business Suite on SAP HANA now change everything? Like other break-through innovations, SAP HANA on its own will not deliver value. But, SAP HANA applied to a particular business problem or challenge can deliver exceptional value. So, if you still have some questions about whether SAP HANA is right for you, or more importantly, how it's right for you, then read on to determine how best to realize value from SAP HANA.
Beginning the HANA Journey
1. Understanding Value Opportunities in Your Business: before deploying SAP HANA, an organization should take the time to understand where SAP HANA can deliver maximum benefit based on your business goals. Some examples to consider:
- Are analytics a problem in your organization? Do you have plans to grow the business, but need to stay lean in terms of your total operations? Would access to real-time information allow you to accomplish that more economically? Are you an SAP BW customer, looking to improve the way you deploy your analytics today?
- What about your day-to-day business processes? If you could run your materials planning processes faster or differently, would that change your business? For Consumer Products, do you have access into the real-time demand in your various markets, allowing you to focus on the right ones? For Retail, could you grow customer loyalty and in-store excellence through access to customer data by your sales personnel while your customers are still in the store?
- Finally, are there new business processes you could create today, something that could transform your business but you haven't thought about doing because of technical limitations? Could a new application be developed, purpose-built to bring these new ideas to reality? For Healthcare, is there a way to manage patient data, allowing you to better serve patients or deliver medical care.
2. Map Value Opportunities to SAP HANA Solutions: once an organization understands the business value – how SAP HANA can enable business soluti ons – you next need to understand how to implement SAP HANA. As identified in the opening to this blog, SAP continues to enhance HANA and offer additional capabilities.
- For the customer looking at real-time analytics to grow the business, perhaps an agile data mart deployed on SAP HANA is the answer. Or, for existing SAP BW customers or customers requiring a complete Enterprise Data Warehouse, BW on HANA may be the right place to start.
- For the customers needing to enhance operational processes, perhaps SAP Business Suite on SAP HANA is the right option. Or, if you need a smaller first step, beginning with a focused accelerator powered by SAP HANA targeting a single, specific process may be the logical place to begin.
- For the customers looking at creating a new, transformative solution, perhaps an application powered by SAP HANA is appropriate.
3. Deploy SAP HANA: at this stage you've identified the business value, you understand what type of SAP HANA solution should be implemented to realize that value, now it's time to evaluate your deployment options.
- For those organizations with strong IT operational capabilities deploying SAP HANA in-house, on-premise may be the most efficient. It will allow you maximum control of your own environment and positions you well to grow your HANA deployment alongside SAP's growing HANA coverage.
- If your organization is looking to quickly deploy SAP HANA and doesn't have the time or resourcing to manage it in-house, SAP's HANA Enterprise Cloud (HEC) may be the right approach. This allows you to utilize all the benefits and capabilities of SAP HANA, but leaves the environment manag ement to someone else allowing you to focus on solving the business problem.
- Ultimately the right solution might involve a hybrid between an On-Premise and SAP HANA Enterprise Cloud approach. Perhaps business timelines can't wait on hardware procurement and thus a HEC approach for your development and test environments with an on-premise production system allows you to deliver on time. Or perhaps there are some applications you would prefer to deploy on the cloud, while your core business applications reside on SAP HANA in-house. Either way it's all about finding the right combination that fit s your needs.
- Finally, whether on-premise or in the HEC, Rapid Deployment Solutions (RDS) should be part of any customer's HANA deployment decision process. SAP has constructed many pre-packaged solutions in a box targeted at the most common HANA use cases. Perhaps one of these RDS fits your business needs and provides a low risk, out-of-the-box approach to quickly roll out SAP HANA. Even if the RDS only covers a portion of your business need, it may provide a stable foundation to quickly deploy business value on top of which you can then build.
Standardizing Data Flow Patterns using Data Flow Templates
Via Content in SCN
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 using Data Flow Templates.
SAP BW release 7.3 introduced a new modeling object called Data Flow. A Data Flow acts as a container for storing the data modeling objects of a data flow, e.g. InfoProviders, Transformations, DTPs, etc. It can also be used to incorporate documentation belonging to its data modeling objects. Furthermore, it's possible to define customized / tailor-made Data Flow Templates to facilitate standardization of data flow patterns in the context of your SAP BW implementation and architecture guidelines. Please refer to SAP Help for more information on Graphical Modeling, Data Flows and Data Flow Templates.
In this blog I would like to discuss standardizing data flow patterns using Data Flow Templates, creating new Data Flows based on such a Data Flow Template and the advantages of this approach.
An example of a Data Flow Template can be found in the next screenshot.
Figure 1: Example of Data Flow Template
The data modeling objects are represented by the blocks. These blocks act as place holders for the future data modeling objects which can either be created from scratch or reused as an already existing object. The technical name gives an implementing hint for the proper naming convention to be applied.
You can also store documentation. In the context of Data Flow Templates, you can find here modeling tips and procedural aspects.
The following screenshot shows an LSA compliant example implem entation with Data Flow Templates Please note a strict segregation between Data Warehouse Layer and Data Mart Layer.
Figure 2: Data Flow Templates
Figure 3: Create new Data Flow
All data modeling objects of the Data Flow Template are copied into the new Data Flow as place holders. From here you can either create the data modeling objects from scratch or reuse already existing data modeling objects.
Figur e 4: New Data Flow with place holders
At any point in time you can use the function Complete Data Flow to add already existing additional objects, such as DTPs, Transformations and InfoPackages. This is usually also necessary for SPO to complete the Data Flow with all objects related to the SPO.
Figure 5: Complete Data Flow
You can complete the Data Flow in an incremental way until it's finished. Don't forget to add any interesting or crucial support information using the documentation feature.
Figure 6: Incremental completion of Data Flow
SAP BW release 7.3 introduced a new modeling object called Data Flow. A Data Flow acts as a container for storing the data modeling objects of a data flow, e.g. InfoProviders, Transformations, DTPs, etc. It can also be used to incorporate documentation belonging to its data modeling objects. Furthermore, it's possible to define customized / tailor-made Data Flow Templates to facilitate standardization of data flow patterns in the context of your SAP BW implementation and architecture guidelines. Please refer to SAP Help for more information on Graphical Modeling, Data Flows and Data Flow Templates.
In this blog I would like to discuss standardizing data flow patterns using Data Flow Templates, creating new Data Flows based on such a Data Flow Template and the advantages of this approach.
Data Flow Templates
The purpose of Data Flow Template is standardization of data flow patterns. Every Data Flow should be based on a Data Flow Template. From an architecture point-of-view, any deviation from Data Flow Templates should be justified and motivated. It can potentially identify the need for an additional Data Flow Template, to be decided upon by the responsible person or team.Figure 1: Example of Data Flow Template
You can also store documentation. In the context of Data Flow Templates, you can find here modeling tips and procedural aspects.
Figure 2: Data Flow Templates
Data Flows
You create a new Data Flow in an appropriate InfoArea. Here you will see a blank canvas where you have to insert a Data Flow Template.Figure 3: Create new Data Flow
Figur e 4: New Data Flow with place holders
Figure 5: Complete Data Flow
Figure 6: Incremental completion of Data Flow
Conclusion
In this blog author presented a way to facilitating your (Enterprise) Data Warehouse Architecture by standardizing data flow patterns using Data Flow Templates. In his opinion it's easy to use but very powerful functionality. Author can highly recommend using Data Flow Templates in order to not only increase standardization of data flow patterns but also to provide gui ded implementation with documentation of necessary steps and naming convention hints. Furthermore, Data Flows can help reducing the need for a complex InfoArea and Application Component Hierarchy. Another benefit is the documentation feature to incorporate on-line documentation of your Data Flows. Last but not least, Data Flows offer a great help in collecting the right data modeling objects using the Transport Connection.Aug 21, 2014
Where to find information on SAP BW on HANA migrations
|
Aug 18, 2014
How to Generage a datasource from a Custom Report in ECC
How to Generage a datasource from a Custom Report in ECC
Via Content in SCN
When more analysis on a custom report in ECC system is required, users ask for a bw report that shows exactly the same data with the custom report in ECC. In standard cases, the rational behavior would be to search for business content if there is any corresponding content for the requirement. Most of the time, we can't find it in business content (That may be the reason why a custom report is written in ECC J). In such cases we have some alternatives to go with. In this blog I am going to discuss three alternatives, compare the advantages and explain the solution to the one which I mostly prefer.
When more analysis on a custom report in ECC system is required, users ask for a bw report that shows exactly the same data with the custom report in ECC. In standard cases, the rational behavior would be to search for business content if there is any corresponding content for the requirement. Most of the time, we can't find it in business content (That may be the reason why a custom report is written in ECC J). In such cases we have some alternatives to go with. In this blog I am going to discuss three alternatives, compare the advantages and explain the solution to the one which I mostly prefer.
The information I give does not include any detailed ABAP knowledge, but gives an understanding on how we can handle these types of requirements. I am not an ABAP developer, so, in this blog I will only give the sufficient ABAP code to make changes in necessary spots in your report and function modules.
The Alternative Solutions:
In this approach, we can write a function module that exactly behaves the same way as the program of the custom report. Then we create a datasource using function module. This approach is nothing different than creating a totally new datasource according to a new requirement. You can only use the logic in th e program. You can directly upload your infoprovider using this datasource.
With a minor change in the program, we can add some code to fill in a Z table. Then we can create a datasource with extraction from view. We use z table as the source. This is an easier way compared to the previous alternative. You don't need to write the whole logic once more. Everything is thought once. When a change request in the logic comes from the user, the change is implemented only in the program. As long as the fields of the custom report are not changed, there is no maintenance for change requests ( I am assuming full upload to infoprovider). Even if a change in fields arrives, the only thing we need to do would be replicating the datasource and changing the Z table.
Detailed Explanation for 3rd Approach:
For the detailed explanation, I got some help from my ABAP developer colleague, Gozde Candan. We have created a very simple program that gets the list of materials according to a material type selected in the selection screen. We also have created a transaction for this program. This is only for illustration. It does not matter how complicated the c ode is, you can reorganize the code in such a way I describe in this blog. We have written the program with a single select statement, so that it would be easier to show how we change it.
Suppose we have a transaction called ZMATLIST. This transaction gets the list of materials according to a material type selected.
To find the name of the program behind this transaction, we go to the system menu on top of the screen:
When we select status, a screen appears showing SAP data:
In the field "P ROGRAM", we see the name of the program that we make the changes so that the code inside can be called within a function module.
With the transaction code se38 we can view the code for this program:
For this program, we have defined a structure zmaterial:
This structure is created with TCODE: SE11. This part is important, because we will use this same structure for the datasource. If the design of the code does not include (most of the time it does, but in some cases it may not include) a structure like this, then it should be changed so that before it flows to the gui screens, an internal table defined by such a structure should be filled with the data .
Now we go on by editing this program. What we are going to do is adding a flag to the program to understand if it is being imported by a function module. In the function module, we are going to set this flag. So we will import the value of this flag from function module to this program. Reading the value of the flag, we are going to export the to the function module. That is; we are doing one import for the flag value (from function module) and one export for the data (to the function module).
The code in rectangles is added to the code.
REPORT zmateriallist.
TABLES:mara.
DATA:it_mara TYPE zmaterial OCCURS 0 WITH HEADER LINE.
*pflag is the name of the flag we define. You can give any name.
DATA:pflag(1).
*This part is the simple selection statement according to the parameter (material type) selected in the
*selection screen of the gui. The data is filled in an internal table called it_mara. For complicated z reports,
*this part can be much more longer. The idea here is filling in the internal table it_mara.
parameter:mtart TYPE mara-mtart.
SELECT * FROM mara INTO CORRESPONDING FIELDS OF TABLE it_mara WHERE mtart = mtart.
1. Creating a function module:
2. Using the program of the custom report to fill in a Z table:
3. The final approach I am going to give in detail is changing the report code so that we can call it from another function module. Then we use this function module to create the datasource. This is even better than the second approach. In this approach we don't need to create a Ztable. So we have some performance related gains. We don't spend a space in ECC for Ztable. We don't require the time to write into that table and also read from that table. When the function is called to upload an infoprovider, the code calls the report code to generate the data we require. Now let's go with the details. I will explain this approach with a sample report where we show a very small information from MARA table.
With the transaction code se38 we can view the code for this program:
The code in rectangles is added to the code.
TABLES:mara.
DATA:it_mara TYPE zmaterial OCCURS 0 WITH HEADER LINE.
*pflag is the name of the flag we define. You can give any name.
DATA:pflag(1).
*selection screen of the gui. The data is filled in an internal table called it_mara. For complicated z reports,
*this part can be much more longer. The idea here is filling in the internal table it_mara.
parameter:mtart TYPE mara-mtart.
*What we do with the below IMPORT statement is that, we get the value of pflag importing from the function
Memory id is a unique id, we can give any name. We will use
*module using memory id 'ZFLAGFROMBWFM'.
*this same id in the function module to export pflag.
IMPORT pflag FROM MEMORY ID 'ZFLAGFROMBWFM'.
IF pflag IS INITIAL.
*So any gui related code is written in this part.
LOOP AT it_mara.
WRITE:/ it_mara-matnr, it_mara-ersda, it_mara-ernam.
ENDLOOP.
ELSE.
*In this part, pflag is set from the function module as 'X'. Thus, we export the data from it_mara to the internal table defined in the function module with the memory id 'ZMATERIALLISTTOBWFM'. This unique memory is
*going to be used in the function module to import the material list to i_e_t_data defined in the function module.
EXPORT it_mara[] TO MEMORY ID 'ZMATERIALLISTTOBWFM'.
ENDIF.
That is all we do in the report code. Now, it is time to create a function module for our datasource. What we need is a function group where LRSAXD01 is included in the top. I will not explain in detail how to create a function module for bw. Though, here are the screenshots of the function module we have created:
Import tab:
Tables tab:
Exceptions:
And the source code is:
STATICS: s_s_if TYPE srsc_s_if_simple,
s_counter_datapakid TYPE sytabix,
i_e_t_data TYPE zmaterial OCCURS 0
WITH HEADER LINE.
DATA: ls_rsselect TYPE rsselect.
*We need to define pflag here, too.
DATA: pflag(1).
*This part is standart for all bw functions, lr_mtart is defined to enable
*the material type for selection. 'ZBW_MATLIST' is the name of the datasource
*we will define.
RANGES:lr_mtart FOR zmaterial-matnr.
IF i_initflag = sbiwa_c_flag_on.
CASE i_dsource.
WHEN 'ZBW_MATLIST'.
s_s_if-t_select[] = i_t_select[].
WHEN OTHERS.
log_write 'E' 'R3' '009' i_dsource ' '.
RAISE error_passed_to_mess_handler.
ENDCASE.
s_s_if-requnr = i_requnr.
s_s_if-dsource = i_dsource.
s_s_if-maxsize = i_maxsize.
APPEND LINES OF i_t_select TO s_s_if-t_select.
APPEND LINES OF< /span> i_t_fields TO s_s_if-t_fields.
s_counter_datapakid = 0.
ELSE.
IF s_counter_datapakid = 0.
REFRESH:lr_mtart.
LOOP AT s_s_if-t_select INTO ls_rsselect.
CASE ls_rsselect-fieldnm.
WHEN 'MTART'.
MOVE-CORRESPONDING ls_rsselect TO lr_mtart.
APPEND lr_mtart.
ENDCASE.
ENDLOOP.
*In this part, we do everything necessary to for loading data. As an initial
*step, we need to send the value of our flag to the report code so that it can
*export the data to this function. Remind that we use the same memory id in report code to import the value for pflag. With this EXPORT statement, in
*memory to a space called 'ZFLAGFROMBWFM', the value of pflag is written as
*'X'. The IMPORT statement has to be called from the report code with the same
*memory id, to get the value of pflag.
pflag = 'X'.
EXPORT pflag TO MEMORY ID 'ZFLAGFROMBWFM'.
*Now, the value of pflag is exported to the program ZMATERIALLIST. When we
*submit, the report code is called. We also need to send the required
*selections in this submit command. If no selection is required for BW data
*upload, then in this part, we can remove the assignment of material type. But
*in this case, we need to add some extra code to the selection statement in
*the report code.
SUBMIT zmateriallist WITH mtart = lr_mtart-low AND RETURN.
*And as the final step, we import it_mara from ZMATERIALLIST program to our
*internal table i_e_t_data with this unique memory id: 'ZMATERIALLISTTOBWFM'.
ENDIF.
IF i_e_t_data[] IS INITIAL.
RAISE </ span>no_more_data.
ENDIF.
DO i_maxsize TIMES.
s_counter_datapakid = s_counter_datapakid + 1.
READ TABLE i_e_t_data INDEX s_counter_datapakid.
IF sy-subrc NE 0.
CLEAR i_e_t_data[].
EXIT.
ELSE.
APPEND i_e_t_data TO e_t_data.
ENDIF.
ENDDO.
ENDIF.
As a result, this approach uses the same code for both ECC and BW reports, thus, helping prevent the repetitive software development. One more advantage is that, when a change request arrives from the users, it is only done in report code. No extra effort is spent for BW side.
Subscribe to:
Posts (Atom)