Now we are going to look at each of the items that we need to migrate. In this section, we will work through the mechanics of completing the migration process. The different components that we need to deal with are the standard business content (SBC) to support the BI 7.0 objects, the WAD library, Web reports, the WAD templates and finally the variants. (Migrating variants tends to get the most attention from business users, which is understandable; if I were a business user who created numerous personal variants over years of using these reports, I would be very interested in making sure that I didn’t have to redo all of my work.) These are the different migration activities and in the next section we will organize them into the appropriate step-by-step process so that the complete migration process will be successful. Each of these processes is fairly straightforward and can be done via a step-by-step approach. The BEx workbooks can be a bit tricky and challenging, but we will not go through the migration process for BEx workbooks because it’s more of a BEx Analyzer issue than a BEx Web Analyzer issue.
1.Standard Business Content for Migration
Your initial focus should be on making sure that all of the standard business content (SBC) that needs to be migrated is activated. This is not that hard, and if you’re used to activation of the SBC within BW, you will be able to very quickly collect these objects and then activate them. The following illustrations show some of this content in the display process within the SBC activation process. You can find the majority of the required SBC under the header BEx Web Template—and of course this is the 7.0 version, not the 3.x version, which is clearly marked on the SBC activation screen. To access these, go to the Administration Workbench and use the button on the left side of the screen BI Content. Then using the option for Object Types you can see the Web Templates and Items for both the 3.x and 7.0 versions.
Most of the required templates are listed together in the area of the 0ANALYSIS_PATTERN template. This, of course, is the root template for many different items, but as you can see, several other templates are necessary. Several of these templates are actually a part of 0ANALYSIS_PATTERN, such as 0ANALYSIS_PATTERN_EXPORT, which offers the format for the Export process in the standard Web template. There is one minor trick to this process and it’s something that you would immediately find out once you execute your WAD templates, since you would get either a warning or an error, but it’s available in the SBC area and needs to be activated. Under the 3.x templates, you will find the final 7.0 template required. That is the template that controls some components of the Information Broadcaster. So, you have to expand Web Template (Format SAP BW 3.x) to get this one. The illustration shows the actual template required—0BROADCASTING_TEMPLATE70. Now, if you are not using the Information Broadcaster, you do not need this template, but depending on what you are accessing, you may run into a warning that this specific template is not active. So, activate it here and be done with all of the SBC at once.
Migrating the WAD library items is another small but important task, because if you go through this process and don’t migrate these items initially, you will immediately get error messages as you attempt to migrate the Web reports. You may or may not have used this component, but it’s always good to check and make sure that everything you need has been migrated. If the functionality available in the WAD library has not been used, then nothing further needs to be done in this section. The following illustration shows the WAD library, which is a part of 3.x WAD and therefore has not been seen before.
As you might know, the 3.x version of the Web reports did have a WAD library but the 7.0 version of the WAD doesn’t have a “library.” What it does have is a component called Reusable Web Items, and that is where the library objects are migrated to during this process. They are very similar in functionality and usability. So we would be migrating from the library to the Reusable Items. We will see that each component in the WAD has its very own approach to migration and its own toolset that is used to migrate. In this case, we will use an ABAP program to execute the migration. Using the program RSZW_ITEM_MIGRATION_3X_TO_70, we can move the library items to the Reusable Items list. The following illustration shows the program component after we use transaction code SE38 and insert this program into the execution field.
As you can see, this program allows us to migrate selectively based on filters, including by specific items, libraries, and roles, or by the All Items option. The bottom section of this program is important—identifying the behavior of the roles that are possibly assigned to these library items. You can realign the templates to different roles, ignore the role assignment, keep all role assignments, and other approaches. We normally want to see that everything is positioned as it was in the older version, so the second radio button, Keep All Role Assignments, is normally what you will see selected. I have not come across any issues with this step in the process and it has been fairly straightforward each time. Even if you choose to migrate all items, you shouldn’t run into any errors or concerns.
Migrating Web reports is also fairly straightforward. The only issue that you may come across during the migration of the Web reports or queries is that you forgot to migrate one of them. This process is different from what you just did for the WAD library and the SBC activation. To migrate the Web reports, you have to use the Query Designer. There is no specific program or component, just the Query Designer for BI 7.0. All you need to do is open the 3.x query within the Query Designer 7.0 component and it will immediately migrate when you save it. So, let’s take a look at the process in the system.
The following illustration shows the creation of a query in the 3.x Query Designer. As you can see, the process is not too complex, and the process is the same no matter what level of complexity a query may be.
The next illustration shows the process for saving this query—the technical name YCUST_REPT_3X_Q001 has been assigned to it for identification purposes.
Now we go to the 7.0 Query Designer and access this same query. The next illustration shows that we can see the same query with in the 7.0 Query Designer even though we created it in 3.x.
Now we will open it in the 7.0 Query Designer and review the information. The next illustration shows the query within the 7.0 Query Designer. As you can see, the system realigns the characteristics and key figures in the appropriate fields, since the 3.x and 7.0 versions are quite different.
We now execute the query and confirm that the format is correct and the query actually does work in the newer environment.
We then save the query within the new environment, as shown next.
Now let’s test the same query in the 3.x environment. As mentioned, this query will not be available in the older environment once it’s opened and saved in the newer environment. This is shown in the illustration that follows. A notice is displayed in the older environment confirming that the query is actually a 7.0 version now.
Now we turn our attention to the WAD templates. With the WAD templates, we encounter another approach to the migration process. In this case, we have a migration wizard, shown next, to help us through the steps.
As you can see, this process has four steps, and this is where you will find out if all the previous steps have been completed correctly. If any have not been completed, you will get either a warning or an error at this step. You access this migration wizard via Tools | Migration Tool.
For purposes of demonstration, I’ve created a basic WAD template in the 3.x version of the component. You can see that this is 3.x because it has the item library, which 7.0 doesn’t have.
Now we’ll step back into the 7.0 WAD to demonstrate the migration process. Before we start, we need to look and make sure we don’t see the 3.x WAD template in the list of the 7.0 WAD templates. The following illustrations show the process of logging onto the 7.0 WAD and then doing a search for the 3.x version template within the 7.0 environment.
Go to the Open button in the top toolbar and click it to access the search dialog box. A search on the technical name of the WAD template returned no objects.
Now, we will start the migration process for these WAD templates. Accessing the migration wizard and then doing the same search for the WAD template, the template from the 3.x environment shows up, as shown next.
We executed the first step and the report is inserted into the migration wizard to be processed. As indicated by the Change button, in the first step, we could have gone into the WAD template and made a change to the template before the migration process if we wanted to adjust the description or some other parameters within the WAD template. Once we are through with Step 1, we can then execute Step 2. In this step, we identify whether we would like the system to generate the XML and all the other components of the WAD template, such as the graphics, different style sheets, and XHTML conversion.
The conversion is executed in Step 3. If the template is successfully migrated, it will create its own URL and XSLT to use during the execution of the report. This is shown in the following illustration.
After the migration wizard is done with its job, we should be able to see the converted BI 7.0 template. The next illustration shows the end result. All components are identified and the template looks like it has been successfully migrated.
As you can see in the next illustration, the data provider came along with the template. If the query had not been migrated first, then during the migration process, you would have gotten an error or, at the very least, a warning.
The result of executing the new report is shown in this illustration. As you can see, this report would need a little work or customization to make it look consistent and user friendly.
Let’s also look at the XHTML that has been converted.The next illustration shows the format of the report before the conversion. Notice that the XHTML looks more like ABAP. If you look closely at the XHTML screen for the converted 3.x template and look down to the sixth row, you will see a prompt to call the ABAP process to access the CSS style sheet for the report background. It’s the line with the CSS template that is different. As we know now the CSS style sheet is not used for the standard background. Now with the BI 7.0 we use the themes that are managed in the BI Portal for this task. During the conversion process, the wizard handles many different styles and formats and tries to convert all of them.
In this case, we see that the XHTML has not fully taken advantage of the ABAP programs that are used now and were not available a couple of years ago.
The next illustration shows the same Web item using just the 7.0 Web template. Notice that the whole approach to executing the XHTML is different. This is not to say that the migration process will not work for you, but you may find that the execution will be affected a bit. In this case, the CSS template is not there but a prompt to another location in the Web application is being executed.
The next illustration shows what we can produce with a few very minor changes to the font sizes in the standard parameters for the Analysis Web item.
After this step, it would be very important to review and execute as many of the WAD templates as possible to test the newly converted queries.
After finishing the previous steps, you are, for all intents and purposes, finished with the basic migration process. However, in most cases, you still need to migrate the variants, which are closely related to reporting. Business users create variants to make it much easier to access specific information based on the values that are saved. Migrating these variants sometimes is a critical piece of the migration process, so you need to understand how to do it.
Currently within NW BI 7.0 SPS08 and SPS09 there is no existing functionality that enables you to migrate query variants to and from the NW BI 7.0 runtime and the SAP BW 3.x runtime in NW BI 7.0. In order to fully understand how BEx query variants work, you need to understand the different places that variants can live within NW BI 7.0. Upon execution of a complete upgrade to NW BI 7.0 from SAP BW 3.x your query variants are still technically stored as ABAP variants and therefore reside with in the VARI table. A program was delivered by NW BI 7.0 that enables you to migrate these variants into a separate data store, RSR_VARIANT_XPRA. This separate data store is technically the RSRVARIANT table.This newer SAP BW 3.x query variant data store exists only within the SAP 7.0 BI environment and is where query variants for the SAP BW 3.x runtime are stored.
In terms of variants and the creation of them, we have to be on a specific SP to have both the BEx Analyzer and the BEx Web Analyzer variants available. To have both the ability to use and create the local and global variants for both components we need to be on SPS12. The query variants that are created within this new runtime are stored technically in the RSRPARAMETRIZA table as personalization settings.
NOTE: To be able to create both local and global variants within the two different toolsets—BEx Web Analyzer and BEx Analyzer—you should be on at least SPS12. On a lower SPS than this, you will be able to create both local and global variants on the BEx Analyzer but only the local variant on the BEx Web Analyzer.
So to recap, there are three different data stores available in NW BI 7.0:
A. SAP BW 3.x Runtime = VARI
B. SAP BW 3.x Runtime within NW BI 7.0 = RSRVARIANT
C. NW BI 7.0 Runtime = RSRPARAMETRIZA
In order to migrate variants from tables for A to tables for B you can utilize the ABAP program RSR_VARIANT_XPRA. In order to migrate query variants from data store B to data store C or vice versa you will utilize another migration program. You need to initially import the transport available that has this specific migration component included. Make sure you review the process within your system so that you do not write over existing programs within your system. Once you are done importing the SBC transport with the programs installed, you then go to transaction code SE38 or SA38 and run the program Z_MIGRATE_VARIANTS. Once you have executed this program.
This program allows you to migrate from and to 3.x and 7.0. It also offers filtering so that you don’t have to migrate all the variants if you don’t want to. After you execute this program, you will see that the variants desired are now available in the RSRPARAMETRIZA table and available for 7.0 reports.
But let’s step back just a bit and review this variant situation. If you migrate all the variants, then you won’t have them available for any 3.x reports that may be left. So, you need to make sure that these reports are the ones that are affected and none of the variants are being used in any other capacity, such as a global variant on a process chain. If you look at the tables for both the 3.x and the 7.0 variants, you will see a big difference in the storage of these two sets of values. The illustrations that follow show the process of accessing the 3.x variant table RSRVARIANT to see the list of variant values that are available. Remember, the variants saved for the 3.x version are set up in an ABAP format. Therefore, these variants are coming more from the BEx Analyzer side than from the BEx Web Analyzer.
The next display is for the 7.0 variant table RSRPARAMETRIZA. You can see that this is very similar, but in the follow-up illustrations you will see that the values are stored in XHTML rather than in ABAP format. This allows the BEx Web Analyzer to create the variants—both global and local.
Let’s look at a very basic variant that is created. From the Web side, you can now create a variant so that your business users can be responsible for this process, and you will probably only allow them to create local variants—variants that they set up for themselves and that can’t be used by anybody else. If you decide to allow global variants, once these variants are available, they are available for all business users.
Start by creating a variant from the Web. The following illustration shows the variable screen used to create the variant.
Once you fill in the values in the variable screen, click Save As to save the variant using the Save Variant dialog box, shown next.
The Save As User Variant check box is checked by default. If you leave that turned on, you will create a local variant. If you deactivate that parameter, your screen will change a bit and allow you to enter a technical name for the variant, as shown next. This variant will then be a global variant.
If you leave the box checked to create a local variant, all you need to do is enter a description into the field, as shown in the illustration.
If we go into the RSRPARMETRIZA table we see that it is storing the one variant created by me as indicated in the following illustration.
If you look at that one variant and how it is stored, you will notice that a technical name has been assigned to it, as shown in the following illustration. The system automatically assigns this technical name, and it’s more of an encrypted number than a true technical name. Also notice that the values of the variant are stored in an XHTML string rather than an ABAP field. This allows the creation of these variants on the Web as well. So, during the migration process, the older version variants are switched from an ABAP format into an XHTML format.
If you step over into the BEx Analyzer, you can also use the same variants created in the BEx Web Analyzer, as shown in the following illustration.
If you create a global variant and fill in the Technical Name field, you still get an assignment into the RSRPARMETRIZA table, but it will look just a bit different. The next two illustrations show the creation of the global variant and the table with the different variants that are available for display. You can identify the two types of variants by looking at the User-Specific column on the far right of the screen. This field contains an X if the variant is user-specific and therefore a local variant. If the field is not checked, the variant is a global variant and available to all users of this query. Also notice that the technical name of the variant is quite a bit different. The global variant has a true technical name, whereas the local variant has the longer, system-generated technical name. There are a number of differences between the local and global variants, but one important difference is that global variants can be used in scheduling processes, such as background job runs and Information Broadcaster settings, whereas the local variants, due to the nonconforming technical name, can’t be used in scheduling processes because you can’t assign them to the job.
Now that we have worked our way through the system migration process, we can look at combining everything together to set up a project timeline and detailed steps.
6.Steps in the Migration Process
We have discussed and reviewed all the components that are involved in the migration process specific to the WAD templates and BEx Web reports. Now let’s take a look at the process based on a step-by-step approach. The tables in this section list the sequence of steps involved in the different phases of a migration project. Before you perform any of these activities, remember to activate the required standard business content objects so that you don’t have to worry about it during the rest of the migration.
The first phase is the migration of the queries. You need to take care of this first so that once the WAD templates are migrated, they can link up directly to the appropriate queries. Table lists the general steps involved.
Steps in the Migration of BEx Web Queries
The next objects to be migrated are the Web Application Designer templates. Table gives an outline of all the specific activities
Steps in the Migration of WAD Templates
Because the technologies that support the 3.x and 7.0 WAD templates, respectively, are completely separate but support the same template in both 3.x and 7.0 the WAD templates can be migrated multiple times.
The process of migrating BEx workbooks is outlined in Table. We haven’t worked through a detailed analysis of the migration strategy for workbooks in this chapter, but this step-by-step process will give you some ideas and topics to discuss and review before you start the migration process with your BEx workbooks. It is important to review the extent that complex programming was done in the BEx Workbook such as VBA and complex macros.
Steps in the Migration of BEx Workbooks
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.