The migration process from 3.x to 7.0 for the Web-based reports is fairly straight forward. As long as you follow the steps in sequence, all should go well. If you skip steps or perform them out of sequence, you may run into issues with the migration process. If we look at the overall question of “why” to migrate reports from 3.x to 7.0, we have to look to the business user for the answer. The decision to migrate is definitely more of a business one rather than a technical one. With the current version in BI, a company can have all the backend functionality up on the 7.0 version objects but keep all the frontend components on the 3.x version. It may decide, simply because everything is working well in 3.x, that there are no additional business requirements to move forward with the migration process for the reports
Companies that have implemented a version of BW prior to NetWeaver BI 7.0 and are evaluating whether to migrate have to consider both how they will implement the many new functions available and how existing objects will be migrated. The 7.0 components offer a ton of new functionality, and if a company wants to take advantage of these options, it has to migrate to the 7.0 frontend toolset. If you are experiencing too many gaps in reporting based on the functionality in 3.x, then migration to 7.0 is the way to go. If, on the other hand, you see that in some cases (for example, BEx workbooks) there is little or no gap between what the business user needs and what they currently have, then migration of these components would not be required. The great thing about the 7.0 platform is that it will support both versions of these reports at the same time, so you can migrate based on customer (business user) requirements and demands. You would just have to manage the process of accessing the reports and workbooks based on the version required to run them and avoid converting a report or workbook by mistake. The impact of the changes from 3.x to 7.0 to the reporting objects includes a complete change to the BEx Query Designer, queries, workbooks, Web templates, and additional new components such as the Information Broadcaster (new in the platform due to the fact that it is running against—Java rather than ABAP stack). Other objects, such as the use of structures in the queries and RKF and CKF functionality, have changed also.
With the BI 7.0 system, new tools and a new runtime process are available in the BEx Web Analyzer and BEx Analyzer. This critical change means that now the Web portion is running on the Java stack rather than on the ABAP stack. Figure shows this process.
Platform used by 3.x and BI 7.0 reporting
As you can see, the BEx Analyzer runs on the ABAP stack while the BEx Web Analyzer and all the new components run on the Java stack. This allows a distinct separation between the two sets of tools and offers the Web-based reports more flexibility and functionality. This also makes a change to the approach in terms of performance tuning and a different set of components to help with this effort. Within the BI 7.0 J2EE engine, a runtime layer is formed supporting the BEx Broadcaster, BEx Web, Integrated Planning, and Knowledge Management functions of the SAP Net Weaver 7.0 BI (2004S). Also, included in this architecture is the new Adobe Document service to support Web-based printing. With the NW BI 7.0 reporting component, new tools and a new runtime are available with all the frontend tools using the Web. At the same time, all the previous tools and the Web runtime from the BI 3.X are delivered in order to make sure that a step-by-step, business-driven transition is followed. It’s important to note the following so that you understand some of the distinct differences between the two options:
As mentioned, NW BI 7.0 is shipped complete with both the BEx tool set for NetWeaver BI 7.0 and the BEx toolset for BW 3.5. To support these two toolsets, two distinct runtimes are delivered with the NetWeaver BI 7.0 system. The new BI toolset offers many new and important features, and these tools are the only ones that can be used with the new frontend functionality in BI. These tools are all members of the Business Explorer family and include the BEx Query Designer, BEx Analyzer, BEx Web Application Designer, and BEx Report Designer.
NOTE: Since the BI system is delivered with both component reporting tools—3.x and 7.0—deactivating one of the two toolsets is an option. This will avoid any issues with opening a report in the incorrect frontend toolset and therefore possibly corrupting the report itself. Choosing this option requires some adjustments by your system support team.
Objects that have been created with the new toolset cannot be further maintained with the BW 3.x toolset. In this case, SAP needs to supply this component (3.x functionality to run BEx Reports) to support customers that continue to use and maintain their existing reporting objects. The actual migration process for a reporting object takes place when a BW 3.x reporting object is opened using the relevant new BI tool and then saved. The details of the migration process are specific to the type of reporting object to be migrated. A summary of some important information follows:
The BEx Query Designer is the solo tool in NW BI 7.0 that allows the creation and maintenance of query objects. The BI 7.0 version of the BEx Query Designer has been totally rewritten as a .NET Visual Basic application, complete with a redesigned user interface and numerous new features and capabilities.
The act of opening a BW 3.x query with the new BEx Query Designer and then saving that query will migrate it from the old version to the new BI version. Again, once this has occurred, it is no longer accessible by the BW 3.x BEx Query Designer. Interestingly, it will still be visible in the list of queries using the 3.x frontend component but will not be available to execute via this frontend.
Figure shows the possible scenarios with both BW 3.x and BI versions of queries. Each version of the query can be opened, maintained, and saved using the respective version of the BEx Query Designer. During the process of migration, the object—queries in this case—will be saved with the same internal name but with a different version and possibly in a different table. Table RSZCOMPDIR contains a listing of query objects, their internal names, and their content release level. You can find this table by using one of the SExx transaction codes in the system and normally the SE16 is available to most users. On a more detailed level, if you have a value of 100 or more in the Version field for a query, this indicates that the query has been migrated to the NW BI 7.0 version.
BEx Query Designer—scenarios for migration
Checking the Version field is a very easy approach to track and manage the migration of the queries. Several SAP Notes are available that address the scenarios for backing up your 3.x queries before migration, and I would suggest using this backup process more for the workbooks than for the queries. In terms of the WAD templates, this migration process is a bit different in nature but the requirement for a backup query is not as critical as it is for the workbooks. The migration of HTML and XHTML is more forgiving than the migration of VBA. Also note that if you are converting a reusable component such as a variable, restricted key figure, or calculated key figure, all queries that use this component can be maintained only with the new BEx Query Designer. This can be especially important when you are looking to manage and migrate the reports on an as-needed basis. If you don’t watch out for this, you may end up having to migrate all the reports prematurely.
As the preceding discussion indicates, the planning process for migration is important and critical to the business users. If you intend to restrict their access to either the new BI 7.0 toolset or the 3.x BW toolset, SAP Note 962530 will help you with this process. Basically, lock out everyone from using one or the other component so that no mistakes are made in the initial process. This will also be useful until everyone that is required to has had additional training on the new reporting components. Then, you can release the access as your company is rolling out the new frontend components and functionality.
In the case of the BEx Web Application Designer for NW BI 7.0, a complete redesign of the platform and the functionality has occurred. It has been redesigned as a .NET Visual Basic application and is delivered with numerous new features and functionality to enhance the Web-based reports in BI. Similar to the BEx Query Designer, SAP delivers a BW 3.x version to support the use and maintenance of existing BW 3.x Web applications. In the new version of the BEx WAD, additional Web items have been added and some of the 3.x Web items have been removed. This adjustment means that some rework of existing Web templates may be necessary when they are migrated to the NW 7.0 version. Following are some of the missing Web items that were popular to use:
Options for migration with the BEx Web Application Designer
SAP BI Related Interview Questions
|SAP BO Interview Questions||SAP ABAP Interview Questions|
|SAP BW Interview Questions||SAP BPC Interview Questions|
|SAP BODS Interview Questions||SAP BDC Interview Questions|
|SAP BW on HANA Interview Questions||Sap Bapi Interview Questions|
|Sap Business One Interview Questions|
Sap Bi Tutorial
Bex Web Analyzer Reporting Functionality
Getting A Fast Start With Bi Patterns In The Bex Web Template
Basics Of The Web Application Designer
Advanced Configuration Using The Web Application Designer
Advanced Functionality Of The Report Designer
Developing Effective Web Reports
Developing High-impact Dashboards
Migrating 3.x To 7.0 Bex Web Reports And The Wad
Integration Of Sap Businessobjects Components Into The Bi Environment
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.