Overview of the migration process SAP BI

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

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:

  • All the new frontend features are only available with the new NW BI 7.0 component.
  • Objects created with the new 7.0 tools can no longer be edited with the 3.x BEx tools.
  • The 3.x BEx tools are delivered to support editing of existing scenarios.
  • The 3.x BEx tools are usable on the new SAP NW BI 7.0 server. Therefore, you will have two sets of components that you can use directly from the same context menu.
  • Conversion of 3.x objects is done on an “as needed” basis and no mass conversions are possible.
  • Except for queries, converted objects are stored as new objects. Old objects are never automatically deleted.
  • The recommendation is to make the change step by step, because further new features will only be made for the new tools.
  • Generally speaking, once an object is converted, you will not be able to open that object with the 3.x components. Therefore, it is a good idea to create a copy of the existing objects just to have a backup during the migration.

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:

  • All existing SAP BW 3.x queries can be edited with the SAP NW 7.0 BEx Query Designer without further manual adaptation. Therefore, you can open any BW 3.x reports in the Query Designer in the 7.0 version without any additional configuration.
  • After editing with the new tool, queries can no longer be edited with the SAP BW 3.x component, and this includes the 3.x BEx Query Designer.
  • Any queries created or adapted with the SAP NW 7.0 BEx Query Designer will appear in the Open dialog box of the SAP BW 3.x tool but can’t be opened or changed with the older version of the tools.
  • Query views that were created using the 3.x functionality will still run after a query has been changed with the new BEx Query Designer and will also be available in the BEx Web 7.0 frontend without any migration. Therefore, query views will move over to the new 7.0 NW BI frontend tools automatically.

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

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:

  • Role Menu Web item This Web item can be transported into the BI 7.0 environment, but this specific approach is not a best business practice.
  • Alert Monitor Web item This has been replaced by the Universal Worklist (UWL).
  • The List option for query views This option is still available but in the Consumer Patterns component (see Chapter "Getting a Fast Start with BI Patterns in the BEx Web Template" for a review of this component).

Other changes have been made within the overall process, but the preceding are the more popular Web items that have been changed or replaced. With these changes, some rework of existing Web templates may be necessary once they are migrated to the NW 7.0 version. Also, the JavaScript functions and enhancements made with the Table Interface component of the WAD in BW 3.x will need to be manually adapted. In the next section, we will review the differences that may occur while migrating the WAD templates, with a basic example of the XHTML that is generated upon migration. If the BW 3.x Web template contains items that are not supported in the new BI 7.0 routine, they are removed in the migration process and new version of that object with comments explaining the reason for the change and the omission of the old item from the new template are inserted. When the new template is saved, it is stored with a new internal name and status in the separate database table. This leaves the original version of the Web template intact so that it can be migrated again, if necessary. The new version of the Web template will not be useable from the BW 3.x WAD. Figure shows the different scenarios of the migration and maintenance of the BEx WAD.

Options for migration with the BEx Web Application Designer

Options for migration with the BEx Web Application Designer

The migration process for BEx WAD templates is very different from that for the BEx queries. You will use the migration tool in the NW 7.0 BEx WAD. This is an easy and quick approach to migrating existing WAD templates. Unfortunately, the migration tool will not convert some elements, such as JavaScript used to create tab pages in the older version or the BEx Web Designer API tables. These elements must be rebuilt using the standard delivered Web items in the BI 7.0 WAD. With this in mind, it may be an option in some cases, to rebuild the Web templates directly rather than rely on the migration tool. This probably is not going to be as intense a task as you might think, because many of the different objects that we had to build from scratch in 3.x are now standard delivered Web items in 7.0, such as the Tab Pages Web item and the command wizard option in BI 7.0.


All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd DMCA.com Protection Status

SAP BI Topics