Additional Blogs by SAP
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
Introduction
Lately, I've had a lot of people ask how to roll out the new frontend tools. Initially, my recommendation was that it depends on the customer project and requirements. In general, after talking to a lot of customers, I realize the requirements are primarily the same as I was repeating myself a lot. Therefore, even though there are lots of options and ways to do this, here is what I find works well for a lot of customers. Given, a one-size-fits-all doesn't work, but in this case, I'm finding a one-size-fits most. Also, there is lots of good information available on this migration within the BI FAQs. Pay special attention to a presentation that is out there that discusses the migration options. Also, recently, we did a webinar on this topic. Here is the slide deck for the webinar: Migration Options. We'll have a podcast soon which we'll attach to this BLOG as well.

What are the ground rules?
There are three primary tools when converting. The BEx Query Designer, BEx Analyzer, and BEx Web Application Designer. Below are the ground rules for converting.

BEx Query Designer – SAP BW 3.x and SAP NetWeaver 2004s

  • All existing SAP BW 3.x queries can be edited with the SAP NetWeaver 2004s BEx Query Designer without further manual adaptation.
  • After editing with the SAP NetWeaver 2004s Query Designer, queries cannot be edited with the SAP BW 3.x BEx Query Designer anymore.
  • Queries created or adapted with the SAP NetWeaver 2004s BEx Query Designer will still appear in the Open Dialog of the SAP BW 3.x Query Designer, but they cannot be opened anymore
  • For those scenarios where customers do not want to use the SAP NetWeaver 2004s BEx Query Designer, SAP ships an SAP BW 3.x version of the BEx Query Designer in addition to the SAP NetWeaver 2004s version.
  • New capabilities are only implemented in the SAP NetWeaver 2004s BEx Query Designer
  • Query Views that were created before upgrade/migration will still run after a query has been changed with the SAP NetWeaver 2004s BEx Query Designer
  • In general query views do not need to be migrated


  • Figure 1 - BEx Query Designer Migration


    BEx Analyzer – SAP BW 3.x and SAP NetWeaver 2004s

  • Existing SAP BW 3.x queries and workbooks can be opened with the SAP NetWeaver 2004s BEx Analyzer
  • SAP BW 3.x workbooks are automatically upgraded on SAVE (not OPEN), workbooks with customer coding will be upgraded, but may not be complete and may require some manual work.
  • Manual adaptation might be necessary to ensure the proper behavior of the workbook. (e.g., customer Visual Basic has to be manually adapted). See this blog for more details: Migrating Advanced BEx Analyzer Workbooks - What VBA is Supported?.
  • After saving in the SAP NetWeaver 2004s BEx Query Analyzer, these new SAP NetWeaver 2004s workbooks can no longer be used in the SAP BW 3.x BEx Analyzer.
  • For those scenarios where customers do not want to use the SAP NetWeaver 2004s BEx Analyzer, SAP additionally ships a SAP BW 3.x version.
  • After migration to the SAP NetWeaver 2004s Workbook format, the BW 3.x version of a workbook is still available in the old SAP BW 3.x BEx Analyzer. Migration can be done as many times as need. BW 3.x workbooks are not deleted.
  • New capabilities are only implemented in the SAP NetWeaver 2004s BEx Analyzer
  • GIS functionality is only available via BEx Web (BEx Web Application Designer)
  • The SAP NetWeaver 2004s BEx Analyzer gives access to InfoProviders & queries but not to query views created with the new BEx Web Analyzer. On the other hand, query views created with the NetWeaver 2004s BEx Analyzer are available within the NW 2004s BEx Web Analyzer


  • Figure 2 - BEx Analyzer Migration


    BEx Web Application Designer – SAP BW 3.x and SAP NetWeaver 2004s

  • SAP ensures that existing customer scenarios continue to be able to be edited with the SAP BW 3.x BEx Web Application Designer that is shipped in SAP NetWeaver 2004s along with the new NW 2004s BEx Web Application Designer
  • In addition to many new items in the SAP NetWeaver 2004s BEx Web Application Designer some SAP BW 3.x items are not included any more (role menu web item, alert monitor, etc...).
  • A migration can be triggered if a SAP BW 3.x Web Application is opened and saved with the SAP NetWeaver 2004s BEx Web Application Designer
  • BW 3.x BEx Web applications in which certain customer-specific enhancements (e.g., Table Interface, custom Java-Script) were made cannot be automatically converted with the new 2004s BEx Web Application Desginer. Manual adaptation might be necessary to ensure the proper behavior of the web application.
  • After saving with the SAP NetWeaver 2004s BEx Web Application Designer, the migrated version of a web application can no longer be used in the SAP BW 3.x BEx Web Application Designer. Migrated versions will not appear in the open dialog of the old BW 3.x Web Application Designer.
  • After migration, the BW 3.x version of a web application is still available in the SAP BW 3.x BEx Web Application Designer. The old version will still appear in the open dialog of the BW 3.x Web Application Designer. Migration can be done as many times as need since old web applications are not deleted.
  • New capabilities are only implemented in the SAP NetWeaver 2004s Web Application Designer
  • Web templates for the new SAP NetWeaver 2004s BEx Web runtime can only be created with the new SAP NetWeaver 2004s BEx Web Application Designer.


  • Figure 3 - BEx Web Application Designer Migration


    BEx Broadcaster and Information Broadcasting; SAP BW 3.x and SAP NetWeaver 2004s
  • In SAP NetWeaver 2004s, the BEx Broadcaster is shipped in an SAP BW 3.x version and in a SAP NetWeaver 2004s version
  • The SAP BW 3.x version is started from the SAP BW 3.x BEx tools and/or the context menu of Web applications running on the SAP BW 3.x runtime
  • The SAP NetWeaver 2004s version is started from SAP NetWeaver 2004s BEx tools and/or context menu of Web applications running on the SAP NetWeaver 2004s runtime
  • Existing SAP BW 3.x broadcasting settings can still be maintained and processed with the SAP BW 3.x version of the BEx Broadcaster
  • If you use the SAP NetWeaver 2004s BEx Broadcaster, you can build settings on all queries in the system but you have to build them from scratch. You cannot use already existing SAP BW 3.x broadcasting settings for queries
  • If you use the SAP NetWeaver 2004s BEx Broadcaster, you can build settings on all Web applications that were built or converted with the SAP NetWeaver 2004s Web Application Designer. You cannot build settings on SAP BW 3.x BEx Web Applications.
  • If you use the new SAP NetWeaver 2004s BEx Broadcaster, SAP BW 3.x broadcasting settings for workbooks can be used as before. There are no changes.


  • Figure 4 - Migrating Broadcasting Settings




How do you roll it out?
In general, I think a phased approach is best. That being said, I typically will only use one version of a tool at a time. Here's what I find works best.

  • Phase 1 - Design your landscape - One of the first things you need to do is design your landscape. Within SAP NetWeaver 2004s BI, the ABAP and JAVA stacks have a one-to-one relationship between BI and Portal. Also, the concept of abstraction has been introduced with the Federated Portal Landscape. See this BLOG on federated portal: To Federate or Not to Federate... That is the question?. In addition, to deciding about your federated portal strategy, you will also need to decide the location of your SLD. When you use integrated planning, or Java Webdynpro, JCO connections reside in the SLD. Content is then built within this system using those JCO connections, so it's generally a good idea to have your SLD strategy in place as part of your landscape design. Ultimately, you should have a landscape diagram before starting your technical upgrade.
  • Phase 2 - Technical Upgrade - Do a strict technical upgrade. Do not implement ANY new functionality. Don't roll out the 2004s Web Analyzer or any new features of the toolset (Do not pass GO... Do not collect $200). If you're currently using the NetWeaver Portal, you can still use that for report deployment. If not, you should still use role menu web item from the SAP BW 3.x Web Application Designer to deploy web reports in this phase. Also, do not rollout any 2004s BI Frontend tools via SAPGUI in this phase. The users should only have the BW 3.x tools available in this phase. Also, in this phase, you will need to go into transaction SPRO and change the authorization concept back to the "Obsolete BW 3.x authorization concept." The technical upgrade changes this to analysis authorizations by default, but you have not implemented analysis authorizations in phase 1. In this phase make sure you configure BEx Web which is a post-upgrade step. See this e-learning class for details about setting up BEx Web that Tobias Kauffman presented: Setting up BEx Web.
  • Phase 3 - Activate Technical Content and Administrator Cockpit - After the technical upgrade, the table RSDDSTAT will no longer be populated with statistics information. This old technical content becomes obsolete. You should active the new technical content cubes for BI (0TCT*). More information coming soon on this!
  • Phase 4 - Analysis Authorizations - Implementing Analysis Authorizations is a pre-requisite to using the 2004s frontend tools. Therefore, directly after your technical upgrade should be implementing analysis authorizations. You may find the obsolete authorization concept still works for the new tools (in most cases), but this is not supported as stated in OSS Note 923176. Before you use the new tools, you should implement analysis authorizations. As for implementing this, you have 2 options. The first is to use the migration tool. The second option is to build the analysis authorizations from scratch. When building from scratch, you do have options to generate authorizations by loading your authorization information into Datastores (see link to e-learning below). You will find that the new analysis authorization makes a lot more sense and will ease maintenance a lot. Therefore, approaching this wholistically is a good idea. If you decide to build this from scratch, it will also allow you to clean up your BI security models. Also, in this phase use the SAP BW 3.x Frontend Tools only. Do NOT roll out the new SAP NetWeaver 2004s frontend tools yet. If you need details about analysis authorizations, see this e-learning class Marc Bernard did on analysis authorizations: An Expert Guide to Analysis Authorizations.
  • Phase 5 - Portal Roles and KM Folders - When you start using the new tools, Portal Roles and KM Folders are key to deploying reporting. Therefore, in this stage, you should migrate BI Roles to Portal Roles. Here it is very important to setup security for publishing to portal roles. If you have not been using portal roles in the past, this will require some training and change management. Definitely review this blog I put together on publishing strategies at: SAP NetWeaver 2004s BI - Define your Publishing Strategy Part 1. Also, in this phase roll out the new SAP NetWeaver 2004s BEx Web Analyzer. Now your users have their much wanted "Drag and Drop" functionality and PDF Printing! Keep in mind the the "BW 3.x Role Menu Web Item" does not exist in the SAP NetWeaver 2004s BI Runtime. Any new queries created with the new 2004s runtime will not show up in the BW 3.x role menu web item. Existing BW 3.x queries will show up in the Role Menu Web Item. The role menu functionality has been replaced with the Open Dialog in the new SAP NetWeaver 2004s BEx Web Analyzer. Also, keep in mind that a role upload functionality is available to upload BI Roles to Portal roles. For rules of how the objects map in this role upload, see the online help at: Object Conversion in Portal. Details are available on the role upload process in the online help at: Upload ABAP roles to Portal Roles! Also, for posssible options of already defined publishing strategies, see this blog: SAP NetWeaver 2004s BI - Define your Publishing Strategy Part 2
  • Phase 6 - The 2004s Tools Rollout - This is it, the moment you and your end users have been waiting for. The rollout of the SAP NetWeaver 2004s Query Designer and SAP NetWeaver 2004s BEx Analyzer. Here, you roll out the new SAPGUI with just the 2004s Query Designer and 2004s BEx Analyzer to your enduser, power user community, and IT community (NOTE: you may not need to rollout the Query Designer to end users if they aren't using it). In addition, you will remove the BW 3.x Query Designer and BW 3.x BEx Analyzer from your end users and power users machines. This is what we call the old switcharoo... Therefore, your users aren't confused by having multiple versions of the tools. This is a big bang approach but will keep things simplest for most people. When your users open up their workbooks, they will look the same after migration (they may get a popup saying this has been changed to SAP NetWeaver 2004s version the first time they do this). There will be training needed for the 2004s BEx Query Designer because that looks different. When your users save their BW 3.x queries or workbooks, they will be saving them in the SAP NetWeaver 2004s version. For details on issues with migration of workbooks with visual basic, see this blog: Migrating Advanced BEx Analyzer Workbooks - What VBA is Supported?. Since nobody is running the old BW 3.x tools after this switch, there is no impact to the reporting or having to deal with people not being able to open reports. Inthis phase, do not roll out the new SAP NetWeaver 2004s BEx Web Application Designer or Report Designer to your power users. Users will access workbooks through the BEx Analyzer or through transaction RRMX. The BEx Browser should not be used anymore. In this phase, you haven't published workbooks to the Knowledge Management or the NetWeaver Portal yet. There is no need to convert existing BW 3.x queries or BW 3.x workbooks to SAP NetWeaver 2004s versions as this will automatically happen when a user opens and saves these onjects in the new SAP NetWeaver 2004s frontend tools. When the users save these objects, they will be in the SAP NetWeaver 2004s version, so anything that is being used will be converted. Keep in mind that you do not need to migrate your SAP BW 3.x queries or workbooks in development to the SAP NetWeaver 2004s version and transport them. If you make changes, this will happen over time, but there is no explicit reason (other than using new functionality) to spend time migrating these objects. If you have problems installing the new SAP NetWeaver 2004s BI Addon Frontend, please see this blog: Troubleshoot the SAP NetWeaver 2004s BI Frontend Installation
  • Phase 7 - New Reporting Security - Setup security on S_RS_BTMP and S_RS_EREL. These are the authorization objects which allow control for the new Report Designer and new SAP NetWeaver 2004s BEx Web Application Designer. Specify naming conventions to separate out what is built adhoc in production and what is built in development. Then roll out new SAP NetWeaver 2004s Web Application Designer and SAP NetWeaver 2004s Report Designer to your users. If you need to run the BW 3.x Web Application Designer in parallel to the 2004s Web Application Designer, this is not a problem. Both tools provide different technology, XHTML vs HTML, so they both can be used in parallel. The BW 3.x Web Application Designer is the only BW 3.x tool you will be running as of this phase. For details on reporting security, check out this BLOG: SAP NetWeaver 2004s BI Authorizations for Reporting.
  • Phase 8 - Migrate Web Templates/Move Workbooks - In this phase, you should migrate the SAP BW 3.x web templates to SAP NetWeaver 2004s web templates where-ever applicable. NOTE: This may not be needed for all web templates, especially those using table interface. For details about the table interface and it's support, see OSS Note: 931395. Templates using the table interface should NOT be migrated. They should be kept on the BW 3.x runtime. Optionally in this phase, you can migrate your BEx Workbook to the portal as described in the portal help: BEx Analyzer Workbook as iView in the Portal. If you want to save the BEx Workbook to KM, see this procedure in the online help here: BEx Workbook as Precalculated Document
  • Phase 9 - Broadcasting Security and Migration - Now you have all the tools and you've migrated most of your objects. You're well on your way. You can start thinking about using some of the new SAP NetWeaver 2004s features that are integrated tightly within the new runtime. The first thing I would look at in this stage is information broadcasting (if you haven't already implemented it from BW 3.5). You should first implement security on authorization object S_RS_BCS. This will allow you control over broadcasting so people don't get "carried away" with scheduling reports. Pushing out reports should be part of your reporting strategy, so this is definitely worth considering. In this stage, do not roll out scheduling to end users. Do this only with power users, or directly from IT. Also, you can migrate broadcast settings in this phase if needed, but this isn't required.
  • Phase 10 - Roll out Broadcasting - Roll out information broadcasting to a larger community. Make sure you pay special attention to OSS Notes 936112 (see pdf in this note) and 973713.
  • Phase 11 - Set up web service proxy - One of the key benefits to using Visual Composer is that you can consume external web services. Before you can start however, you need to make sure you setup the web service proxy. This blog shows you how to do that: External Web Service Proxy Configuration for Visual Composer
  • Phase 12 - Visual Composer - If you have not already started using Visual Composer, definitely explore using this cool new tool! If you need help setting up your source system connections for Visual Composer, see the details in this How-to Guide: How to Resolve Visual Composer Issues. Also, keep in mind you can integrate Visual Composer and SAP NetWeaver 2004s BEx Web Application Designer components using this how to guide: Integrating UI Elements

Why do it this way?
The reason I'm saying to do it this way is because it minimizes complications. You aren't confusing your users by asking them to use multiple tools at the same time. You aren't worried about backwards compatibilities or accidental migrations because you are using the new tools. Therefore, this approach simplifies the migration path to the new tools. You don't have to worry about converting back to the old version or wondering which user is using which version of the tool. This is especially important for customers who have lots of queries and workbooks. Also, to have small highly defined projects allows the development team to focus on short term projects that can add immediate benefit to the organization.

What are your user communities?
One major thing you should take into consideration is that the vast majority of users will NOT be using design tools. All they do is execute workbooks or web templates. Therefore, there is a minimal impact to your the majority of your users. They don't care about the new SAP NetWeaver 2004s versions of the BEx Query Designer or BEx Web Application Designer. All that matters for them is a switch to the new SAP NetWeaver 2004s BEx Analyzer when they need to use new workbook functionality. If the old icon is gone and the new icon shows up, this will be minimal impact to them as well, other than they have lots more functionality 🙂

One of the other big considerations is whether or not you allow any power users to build "adhoc" queries in production using the BEx Query Designer. If you do, the approach I suggested above helps minimize impact as you're only allowing one version of the tool at any given point in time. If you do not allow this, then a hybrid approach where you have both versions will still work as everything is being built in Development in a controlled environment. In this scenario, you would need both the 3.x and 2004s tools to support the BW 3.x queries (for production support) and the SAP NetWeaver 2004s queries for new development. In that case, there would not be a cutover.


Is the Report Designer an end-user tool?
This depends on your scenario. I'm sure there will be users in the financial community within your organization that would benefit from using this tool for formatted Income Statements. There is a security object S_RS_EREL that allows you to control access to building formatted reports, so it can be used by end users in production if needed, but this alldepends on your requirements.

Some other relevant information

Summary
In general, the new tools offer lots of benefits. Sure, there may be things you used to do in BW 3.x that are different or not yet available in SAP NetWeaver 2004s BI, but the new runtime is wicked cool. It solves a lot of challenges we had in BW 3.x, and I definitely view it as important to make sure this migration goes smoothly. Therefore, I hope this will help!

Special Thanks...
Special Thanks must be given to all the people who helped out with this: Marc Bernard, Tobias Kaufmann, Bryan Katis, Scott Cairncross, Ron Silberstein, Derek Johnson, as well as many other SDN community members who have been asking questions about this on the SDN forums. Also, special thanks to the customers I worked with on this strategy (you know who you are)...

50 Comments