Skip to Content
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
    image

    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
    image

    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
    image

    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
    image

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)…

To report this post you need to login first.

50 Comments

You must be Logged on to comment or reply to a post.

  1. Pankaj Gupta
    Hello Prakash

    This is too good. You have clarified some of my questions, but some more questions will follow.

    Thanks for putting this together.

    Pankaj Gupta

    (0) 
      1. Girish Savadi
        Prakash,

        I need to provide some recomendation to a client about the upgrade from 3.5 to 7.0.
        Could you explain a strategy to handle the activities concurrently going on in 3.5 development and activities for upgrade to 7.0 ?
        How do we handle these two at the same time ?

        Regds
        Girish

        (0) 
  2. Tomiko Hachiya
    I saw the new security roles you mentioned above, but have an additional question.  If we use batch processing of reports, will we be able to use our R/3 authorizations to restrict views of a pre-run NetWeaver 2004s report?  For instance, I would run a complete headcount report and users would only see the data for which they had access – so there would be only one query/report to be accessed by all (but would show different results for each user).  I believe that in BW 3.5 this was not possible, as authorization was determined at query runtime, but I heard that this will be possible with NetWeaver 2004s.  Is this true?
    (0) 
    1. Prakash Darji Post author
      This is talking specifically about SAP NetWeaver 2004s BI authorization, not R/3 reports. If you have HR authorization in R/3 and need to implement that in SAP NetWeaver 2004s BI, then you can use the content extractors to load the datastores in BI and generate authorizations from this for your BI reports…
      (0) 
  3. Tarun Chhichhia
    Hi Prakash,

    Very timely Blog, cleared all the doubts, we just had finished out technical upgrade so..thanks extremely useful.

    One question remains, you mention Query Variants are not converted, and will be covered in later packages., Do you have any information on that, when the conversion of query variants will be covered, or any way to copy the Query variants from 3.5 to Nw4s.

    thanks,

    Tarun

    (0) 
    1. Prakash Darji Post author
      Currently, there is an issue with query variants that we’re working with development on. As this is resolved, there will be another blog in the next few days. When that is out, I’ll add a link to it that describes the process for query variants…
      (0) 
  4. Tarun Chhichhia
    HI Prakash,

    Very timely blog for us just completed techncial Upgrade this clarifies lots of doubts…

    One question for now though about Query Variants,we found that all the Variants are gone after the technical upgrade in our Sandbox environment…Any resolution on this one…

    thanks,

    Tarun

    (0) 
    1. Prakash Darji Post author
      The variants issue is still being worked on. Just to make sure you’re aware. Variants will work great in the BW 3.x runtime and will be available for your BW 3.x queries and the such. The issue I am referring to is specific to variants in the 2004s runtime. If you don’t see your variants in your BW 3.x runtime, make sure you run program RSR_VARIANT_XPRA
      (0) 
  5. Dave Pazuchanics
    How can I force the 3.x BEx analyzer to run from RRMX when both BW and BI components are installed?  I know of the setting in the Global Options of the 04s Analyzer, but I’d like to set it through a registry setting at the time of installation.
    (0) 
  6. Geert Vandenbroucke
    Dear,

    I succeeded to connect a portal 2004S SP9 to BI 2004S SP9. When I want to publish a query thru th web application designer. The portal is always using the 3.x view instead of the bi view. Do you know how to solve this?

    Thanks

    (0) 
  7. Peter Loo
    Prakash:
    Great article!
    We are considering the upgrading to BI without the BI Java stack.
    1.Will all the existing 3.0b queries, workbooks, report agent still work?
    2.0 When we eventually want to install BI Jav, does UNICO conversion have to preceed the BI Java installation?

    Thanks, Peter
    (0) 
  8. Peter Loo
    Prakash:
    Great article!
    We are considering the upgrading to BI without the BI Java stack.
    1.Will all the existing 3.0b queries, workbooks, report agent still work?
    2.0 When we eventually want to install BI Jav, does UNICO conversion have to preceed the BI Java installation?

    Thanks, Peter
    (0) 
    1. Prakash Darji Post author
      1. Yes, BW 3.0B queries and Workbooks will still work. Your reporting agent settings may work but reporting agent is going out of support so I suggest migrating those settings to information broadcasting.
      2. Unicode conversion does not have to proceed BI-JAVA install. All java installs are Unicode based…
      (0) 
  9. Dinesh Mukundu Mohan
    To retain the 3.5 Bex Browser,the Macros attached to the 3.5 Workbooks and make use of the 2004s Integerated Planning as well, is it a good idea to convert only the 3.5 Queries to 2004s Queries and access them via BEX Browser ??

    Advantage of converting all the queries to 2004s is that we can use Integerated planning and later on decide to convert the 3.5 Workbooks to 2004s Workbooks. We can still retain BEx Browser for the time being.

    Disadvantage is that the query attached to the 3.5 workbook can be edited only with 2004s Query Designer.

    Thanks & Rgds
    Dinesh

    (0) 
    1. Prakash Darji Post author
      You cannot use integrated planning in a BW 3.5 workbok. It must be a 2004s workbook. BW 3.5 doesn’t support the api commands to transfer and save values.
      (0) 
      1. Dinesh Mukundu Mohan
        Thanks for your reply.

        If we are using Web Report for Integerated planning, we would need only 2004s query. Correct me if i am wrong. Will be developing Web reports based on the 2004s query.

        Will not be using 3.5 Workbook for Integerated Planning.

        (0) 
  10. THAO NGUYEN
    Prakash,
    We are using what you wrote as our guide. Thanks for putting it together. One question we have, you mentioned:
    Phase 4 – Analysis Authorizations – Implementing Analysis Authorizations is a pre-requisite to using the 2004s frontend tools.

    Why is analysis authorization a prerequisite to 20004S front-end tools?  We don’t understand why it would be so please help us with this question.  Thanks again.

    (0) 
    1. Prakash Darji Post author
      Because that is what SAP supports. If you have an authorization problem while using the new tools, and you haven’t implemented Analysis Authorizations, SAP will say implement analysis authorizations to fix your problem.

      Also, from a technical perspective there are new things in the tools such as integrated planning which have different activities (change data) in analysis authorization.

      (0) 
  11. Peter Garner
    Hi Prakash,

    We are upgrading our BI system to 2004s from 3.5, but have not installed the BI java usage type yet because the decision was made to isolate the end users to the change.  When changing to the portal runtime, does ALL end user content need to be changed or will existing reports/queries look like 3.5 until we re-save them as the 2004s version?

    Thanks

    Peter

    (0) 
    1. Prakash Darji Post author
      This is covered in the blog above (see especially the publishing strategies subsection). There aren’t many reasons why you would want to re-save them.
      (0) 
  12. THAO NGUYEN
    Prakash,
    I lost all my query variants after upgrading to NW04S.  I executed RSR_VARIANT_XPRA and the report log showed all the variants got converted successfully.  Also, over 12000 records got added to table RSRVARIANT.  However, my queries still show no variants. Are there other steps I need to do after running RSR_VARIANT_XPRA or is there a bug with this program?  I am on SP9.  Thanks in advance for your help with this question.
    (0) 
    1. Prakash Darji Post author
      After upgrade, the variants will be in the BW 3.x runtime, not the 04s runtime. There is a conversion utility that is posted in a how-to guide written by scott cairncross on SDN and there will be a program coming in future support packages to run this.
      (0) 
  13. THAO NGUYEN
    Prakash,
    I lost all my query variants after upgrading to NW04S.  I executed RSR_VARIANT_XPRA and the report log showed all the variants got converted successfully.  Also, over 12000 records got added to table RSRVARIANT.  However, my queries still show no variants. Are there other steps I need to do after running RSR_VARIANT_XPRA or is there a bug with this program?  I am on SP9.  Thanks in advance for your help with this question.
    (0) 
  14. THAO NGUYEN
    Prakash,
    I really appreciate you getting back to my questions.  In your reply, you mentioned that there is “conversion utility that is posted in a how-to guide written by scott cairncross on SDN”.  I couldn’t find this how-to guide.  Is it out yet?
    (0) 
    1. Prakash Darji Post author
      Hey Thao,

      Scott never released a how-to guide because this was rolled into the product as a program. The details are in the release notes. This became available with SPS11.

      Cheers,
      Prakash

      (0) 
  15. André Jansen
    Hi,

    We are busy with the upgrade from BW 3.1 to SAP NetWeaver 2004s. I can not refresh queries within a workbook, though if I go to queries and run the quries there they refresh. Does anybody know how I can fix this?

    Regards,
    Mbali

    (0) 
      1. André Jansen
        Hi Prokash,

        No that is what I’m saying doesn’t work, but if I open each query separately via queries not workbooks and refresh them, it works fine. This is only a problem when I use the new gui, with the old qui the workbooks refreshes fine. I will log a customer message.

        Thanks

        (0) 
  16. Nabil Succar
    Hello
    We are starting a new BI 7.0 NW instalation and we have some question about this new version:
    1. What Plug-Ins version do we need in R3 to work with BW NW. I read some notes that recomend add-on 3. Is that correct?
    2. Once replicated the source system and all datasources are transfered like 3.x can we reverse it to trasfer it again like new version 7.0?… for example if we upgrade the PI in R3

    Kind regards for your assistance

    (0) 
  17. Witalij Rudnicki
    Whatr about 3.x webtemplate bookmarks? What is impact on them with:
    – doing technical upgrade only?
    – doing webtemplate conversion?

    As well druing run-time will 3.x webtemplate open query that was accidentaly converted to 7.0 or will webtemplate fail?

    Thank you
    Vitaliy

    (0) 
  18. Donald Gosnell
    Prakash,
    I am aware of the ways in which you can restrict users from using the new tools, but I am curious to the recommended approach for restricting user access to the old 3.x BEx tools. You mention in the proposed migration process that the old BEx Query Designer and BEx Analyzer would be ‘removed’ from the end user’s and power users’ PCs. Please elaborate as to the best process for doing that. Also, does the same approach work for the 3.x BEx Web Application Designer?
    (0) 
    1. Prakash Darji Post author
      Hey Don,

      Hope all is well. See OSS Note: 962530 – How to Restrict access to the new 2004s Query Designer

      This controls who has access to the new query designer. Typically, in the approach I mentioned above, you would run the SAP Client Install via a script to remove or add the frontend tools to the user’s machines such that they only have one set of tools (either the new ones or the old ones)…

      (0) 
  19. Witalij Rudnicki
    Hi Prakash,

    I know you are not in BI FrontEnd anymore, but may be still could help.

    We found that after BW technical upgrade (Phase 2 in your weblog) from 3.5 to 7.0 icons that represent hierarchies’ expanded and collapsed nodes have changed in 3.x webtemplates (these running on ABAP). E.g. now collapsed icon is s_b_right.gif and before upgrade system used s_b_right_35.gif.

    Icons are white now (they were black before upgrade) and are bigger now (16×15 pix versus 12×12 pix in *35.gif).

    We absolutely need to keep using old (12×12 px) icons after the technical upgrade, because new ones are breaking report’s layout (this webtemplate uses modified table class to draw pixel-precise layout, but now is adjusting lines to accommodate bigger icons, which are causing a mess)!

    Have someone gone through the same problem? How can we force 3.5 webtemplates to use “old” hierarchy icons in BI 7.0?

    Will appreciate your help!
    -Vitaliy

    (0) 
  20. Sini Kumar
    Hi Prakash,

    Can you please let us know if we need to install Visual J# 2.0 for SAP GUI 7.10?
    OSS note# 1013139 (pre-requisite for 7.10 FrontEnd) it did not mention about Visual J#.

    I was assuming for all Stack > 8 , Visual J# is required, is that a true statement?

    Thanks.
    -Sini

    (0) 
  21. priya Reddy
    Hello Prakash ,
        i would like to know if there is any problem in BI 7.0 query varaiable texts as we migrated from from 3.0 to bi 7.0 for some of the query varaiables which are having texts are not displaying in BI 7.0 . your help will be greatly appreciated.
    Thanks
    Priya
    (0) 
  22. Nigel K
    Great Blog !

    I do have a question about the query componenets (i.e. RKF, CKF, Query Infobjects).

    We are currently performing a technical upgrade from BW 3.5 to BI 7.0 .
    After the upgrade we will continue to use the 3.5 Query designer for the existing queries but use 7.0 Query Designer to develop new queries(potentially re-using some of the older 3.5 query components).

    I know that the migration of “Queries” will happen when we open the BW 3.5 queries in BI 7 Query Designer and Save them.

    What happens to the 3.5 query components in that new migrated 7.0 Query (i.e. Restricted KF, CKF, Query Infobjects ) ?
    Will those be migrated to 7.0 query components ?

    If that happens will the existing BW 3.5 queries using those newly  migrated query 7.0 components cause the 3.5 query to break ?

    Thanks in advance !

    (0) 
    1. Prakash Darji Post author
      The 3.5 query components will get converted to 7.0 components (RKF, CKF, etc…). This will break the 3.5 queries. If you wanted to co-exist the tools, then you would have to have seaprate RKY and CKF for 3.5 and 7.0…. I typically tell people not to try the co-existence strategy…
      (0) 
  23. Bob Dunsford
    We are upgrading our Frontend tools from BW3.5 to BI 7.0.  Our Finance users have created a large number of workbooks that use only MS Excel formatting.  When we open these workbooks in BI 7.0 to covert them, the Excel formatting is overridden by the BI formatting.  I found that we can uncheck Apply Formatting in the analysis grid properties.  The problem is that the MS Excel formatting is wiped out as soon as I switch to design mode.

    How can I set the default properties for the analysis grid to have the Apply Formatting unchecked?  This way we can retain the Excel formatting from our existing workbooks.

    (0) 

Leave a Reply