GRC
HR
SCM
CRM
BI


Blog

 

What's new with BW 7.3: Q&A with Dr. Berg (transcript)

by Kristine Erickson

November 21, 2011

Insider Learning Network recently held a web forum with Dr. Bjarne Berg of Comerit.   In this BI Forum on November 16, Dr. Berg took questions on  BW 7.3 upgrade options, changes that come with this new release, and how to prepare your data and hardware for the upgrade, and other topics.

For the full Q&A, you can view the questions and Dr. Berg’s responses in the BI Forum, or read excerpts from the transcript of the Q&A below.

The forum was moderated by Scott Wallask, editor of BI Expert and BusinessObjects Expert

Scott Wallask (moderator): Dr. Berg: Hi everyone, this is Scott Wallask, managing editor at BI Expert. Thanks for joining us in the BI Forum today – and a special thank you to all who have posted a question already. Wow, there are some great questions.

I’d like to welcome Dr. Bjarne Berg back to the BI Forum. Berg rocked at our Xcelsius Dashboards Bootcamp in Las Vegas a couple of weeks ago, and I’m excited to read his tips for upgrading to SAP NetWeaver BW 7.3.

p class="MsoNormal">Berg, the floor is yours...

[Editor’s note: Due to time constraints, there was not an opportunity to answer every question, but we did try to ensure that Berg addressed every BW 7.3 upgrade topic. We also invite all Insider Learning Network members to post your specific questions anytime in our Forums. - Kristine Erickson, Insider Learning Network].


CarlKepford:  Biggest question about 7.3 upgrade: BW isn't the most important part of our SAP landscape. Will upgrading BW before other components (ERP, portal, Solution Manager, RPM, adobe document server, SLD) break those components?  And sandbox, dev, and qas versions of most of the above?

Will transports and system copies work if different versions of NetWeaver in each?

Dr. Berg: Hi Carl,

There are few requirements for BW 7.3 for other systems. I.e. the old extractors still work on ERP/ECC and do not have to be upgraded. The SAP portal still works (no need for upgrade) and APO and IP still works fine.

The real challenge is the ‘other way’. For example, the BPC 10 upgrade requires BW 7.3 according to SAP. Also some system copy features and some of the new HANA features are relying on BW 7.3 (most works fine with 7.0).

To see the compatibility of all tools, technologies and software, look at the Product Availability Matrix (PAM) on the marketplace for each product.

Thanks,

Dr. Berg

p class="MsoNormal">JayRoble: p class="MsoNormal">1. BW 7.3 & BPC 7.5 upgrade. p class="MsoNormal">We are having issues upgrading our: BW 7.01 SP6 & BPC 7.0 SP09 to BW 7.30 SP4 & BPC 7.5 Add-on for BW 7.3 (CPMBPC 7.53) We have customer message open, but seems during the prepare stage it will not let you pick CPMBPC 7.53.

2. BWA query fails with error 6904, attribute $trex_udiv$ not defined

BW 7.3 or BW 7.01 & BWA 7.20 REV 14 & 15 Noticed these notes have been pulled & are not available, but this could be issues. This could be a lot of work if the fix is not available & you had to run this script everytime you rebuilt a BWA index.

Note 1641883: Reason and Prerequisites
You have BWA 7.20 revision 14 or 15. The virtual attribute $trex_udiv$ is missing in the f-tables.

Solution
This is a workaround. If your BWA 7.20 rev14/15 is attached to BW 7.30, apply note 1641692. AS long as note 1641692 is not available or you want to run the script to avoid reindxing of cubes, please follow the instructions below. Rerun the script when you index new cubes or reindex existing cubes. This is only necessary as long as you did not implement note 1641692. If your BWA 7.20 rev14/15 is attached to BW 7.0x please follow the instructions and rerun the script every time you index new cubes or reindex existing cubes. There will be a solution like in BW 7.30. I will update this note when that solution is available.

Instructions:
* download the attached script and rename its extension to 'py'.
* Open a console from the TREXAdminTool.
* Copy the script to the directory /usr/sap/$SID/exe/run/python_support and /usr/sap/$SID/TRX__/exe/python_support.
* Change directory to /usr/sap/$SID/TRX/exe/python_support. + BW 7.30
* Run the script "python addUdivAttributeForFTable.py --bw_dir_structure=1" + BW 7.0X
* Run the script "python addUdivAttributeForFTable.py" * restart your BWA

Note 1641692: Symptom
After upgrading SAP NetWeaver BW Accelerator (BWA) to Revision 14 or higher, errors occur during query execution. The error message reads:
"!Error reading the data of InfoProvider $X!
"!The following error 6.904 occurred in BIA server!"

Solution
After you implement the correction, execute the script of Note 1641883. Alternatively, you can rebuild the BWA index of the relevant InfoCubes in transaction RSDDB.
• SAP NetWeaver BW 7.30 Import Support Package 06

Dr. Berg: Hi Jay,

As you probably know, BPC 7.5 is supported on SAP BW 7.0 and 7.3. So the upgrade is possible (even though few have done it by now). The issue rather that BPC 10 is only supported on BW 7.3 (according to SAP). So I would work with SAP on the BPC7.5/BW 7.3 upgrade, but I have not seen any issues on that before.

The error message 6904 normally means that the attribute in the table was not available for indexing (FT). In BW 7.0 we used the workaround to add it by using the scripts in the python directory as outlined in the note 1641883. The drawback was that you had to do this for every new InfoCube and if new indexes were created (running the scripts require restart). I was unaware that notes were not available (1641883, 1641692). Those were the workaround I was going to suggest.  I would open a message to SAP and request support.

Thanks,

Dr. Berg

SwapnaTom: Can you please help with the following on BW7.3 upgrade?

1) Is the authorization model changing with BW7.3?  ie we had analysis authorization in 7.0 which was different from 3.5 authorization. Is there yet another change?

2) Can we upgrade BW 7.0 SP 16 directly to BW 7.3 SP2 or should it be 2-step process?

3) Are 3.5 datasources still supported in BW7.3 or should we plan to migrate to 7.0 DS during the upgrade?

Danhaverly: We have v3.5 objects in a version 7 (non-unicode) upgraded system. Do these have to be converted to v 7.1 before upgrade?

Dr. Berg:  Hi,

When companies upgraded from BW version 3.5 to 7.0, security migration was optional and many did only a technical upgrade and kept the 'obsolete authorization' concept.  Actually, some companies did not do a security conversion in BW 7.0 since items such as 0TCTAUTHH did not migrate (manually reassigned for the hierarchies) and passwords became case sensitive. Now, SAP recommends migrating to the new concept before upgrading a 7.0 system. (Notes: 931898; 938871; 946724, 958665; 1001652).

However, in 7.3 you get a new security admin feature that allows you to make mass changes to authorizations instead of one-by-one. This can be done by cut-and-paste in a worklist, hierarchy nodes, and you can also add users to multiple analysis authorizations.

For those in need of migrating the security, SAP still has the ABAP migration tool in BW 7.0. It can be used in SA38 (RSEC_MIGRATION) and migration can occur before the 7.3 upgrade. The ‘new’ authorizations are building blocks of the 7.0/7.3 reporting concept and security contains both the data value and hierarchy restrictions. You can still build security in 7.0 and 7.3 using the “RSECADMIN” transaction

Also, the upgrade for you would be a one-step process with the new SP included.  The 3.5 data sources are still available. But it really is time to think about leaving update and transfer rules and go to DTPs instead.

p class="MsoNormal">JayRoble: Yes, there is a BW 7.3 migration step for Analysis Authorizations.

In BW 7.3, the 7.x new authorizations are now changed to TLOGO object (analytics security object) and can be transported to other systems.

If you have upgraded from SAP NetWeaver 7.0 to SAP NetWeaver 7.3 and already implemented the new analysis authorizations concept in SAP NetWeaver 7.0, you have to migrate these analysis authorizations from 7.0 to the transportable analysis authorizations. This does not involve a great deal of effort however.

Procedure
1.In SAP Easy Access, choose SAP Menu  Business Explorer  Manage Analysis Authorizations .
2.In the main menu under Extras, choose  Migrations  Migration: Release 7.0 -> Release 7.3  >Activate All & Delete Old.

The existing authorizations are migrated.

Dr. Berg: Hi Jay,

Thanks for adding this. You are absolutely correct. this is not a major task.

p class="MsoNormal">SidB: Will we have to rewrite our BEx 3.5 queries in BW 7.3 or can we still use them without change?

Dr. Berg: Hi SidB,

No real reason to hang back on the old BW 3.5 queries (technically possible). SAP has developed some really useful programs over the years to assist with the upgrade. For example, If you are still on 3.5 queries, or older versions (i.e. 3.1c, 3.0B), consider running the program RSR_GEN_DIRECT_ALL_QUERIES to regenerate all queries in the system into the new release.

For BeX query designer, users can still click ‘view as 3.5’ on the top menu if they are not ready to move to the ‘new’ Bex Query designer (have your cake and eat it to :-)….

p class="MsoNormal">Rodrigo Marques: We are currently analyzing and planning for upgrade from BW 7.0 EHP1 to 7.3.

1) We are running BW 7.0 EHP 1. We have some old data flows still following 3.x standards (Update Rules, etc). Is it mandatory to migrate them to 7.0 standards (transformations, DTPs ,etc) to perform upgrade from 7.0 to 7.3?

 2) Similar to above, we still have some remaining queries in 3.x (most are already 7.0), but 95% of our workbooks are still based on 3.x since we feel that Bex 3.x is faster and more stable than 7.0. Will 3.x workbooks and queries continue to work after we migrate our backend from 7.0 to 7.3? In other words, can we continue to use Bex 3.x as front-end with BW 7.3?

3) We are already using the new authorization concept from 7.0. In this case, can you highlight any new authorization objects that are required to keep current 7.0 functionality working, or they are just related to new functionality of 7.3?

4) The fact that IP in 7.3 will no longer use Java server, is this “transparent”? Or do we need to take any special step to “migrate” our existing IP objects based on Java to ABAP HTTP? Have you seen IP processes running after a 7.0 to 7.3 upgrade, any known issues?

5) Are there considerable changes in terms of SAPS requirement comparing BW 7.0 to 7.3?

6) We are currently running BIA 7.0. Are there any know issues, trips & tricks that you can share on upgrade to BIA 7.3? Can upgrade to BIA 7.3 be executed in advance while we are still running BW 7.0 EHP1? Are BW 7.0 and BIA 7.3 versions compatible?

Thanks in advance for your attention

Dr. Berg: Hi Rodrigo,

 1. Technically possible, but not recommended. NW BI 7.0 had a new transformation concept that replaced transfer and update rules, but not all companies have migrated. To do so now, convert the DataSources and the Persistent Staging Area to the new DTP process, (SAP Note 906789). To test the conversion of the DataSources can also run: RSSM_CREATE_REQDONE_FROM_SEL; RSSM_HASH_ENTRIES_CREATE for all requests; RSSTATMAN_CHECK_CONVERT_DTA;  RSSTATMAN_CHECK_CONVERT_PSA. (you can also hold off on this and do a ‘functional upgrade later. I believe now may be the time to do it right, so if you choose this, make sure it is actually done and not postponed as many did in the 7.0 upgrade)

2. See earlier answer to SidB

3.  Go to RSECADMIN and see the security objects. But it includes:

Authorization objects for the Data Warehousing Workbench:
S_RS_DS: For the DataSource or its sub objects (BI 7.x)
S_RS_ISNEW: For new InfoSources or their sub objects (NW BI 7.x)
S_RS_DTP: For the data transfer process and its sub objects
S_RS_TR: For transformation rules and their sub objects
S_RS_CTT: For currency translation types
S_RS_UOM: For quantity conversion types
S_RS_THJT: For key date derivation types
S_RS_PLENQ: Authorizations for maintaining or displaying the lock settings
S_RS_RST: Authorization object for the RS trace tool
S_RS_PC: For process chains
S_RS_OHDEST: Open Hub Destination
Authorization objects for the Business Explorer:
S_RS_DAS: For Data Access Services
S_RS_BTMP: For BEx Web templates
S_RS_BEXTX: Authorizations for the maintenance of BEx texts
Authorization objects for the Admin of analysis authorizations
S_RSEC: Authorization for assignment and administration of analysis authorizations
S_RS_AUTH: Authorization object to include analysis authorizations in roles
Changed Authorization Objects:
S_RS_ADMWB (Data Warehousing Workbench: Objects):
Sub objects:
CONT_ACT – Installing Business Content; USE_DND - Drag & Drop to InfoAreas and application components; CNG_RUN - Attribute change run 

4. There are still tasks to be performed for the IP ABAP/JAVA switch.  i.e. Java stack install/upgrade, setting up connectivity and testing. So, not a plug and play, but SAP has some wizards to help you with these tasks.

 5. I would always add more capacity if I can. There are many new interfaces, monitors and admin tools that benefit from this (if you have capacity constraints already). However, the real driver for HW changes would be if you do a unicode conversion.

Unicode conversions was strongly recommended by SAP in BW 7.0, but not required. Some decided against it due to the required additional disks, memory and processing power. Actually, if the system was MDMP companies had to convert. However, if their system was non-Unicode single code-page system a SCP non-Unicode is possible until SAP NW 7.0 EhP1 (SAP Note: 73606). Therefore many did not do the Unicode conversion. Now is the time to bite the ‘bullet‘and do it. Unicode is the standard. For example, BPC 10 on BW 7.3 requires Unicode (& 64-bit) and IBM’s NLS for BW 7.3 requires Unicode (DB2 v.9.7+). In addition, the PAM for JVM 6/Linux states ‘installation Unicode/64-bit only’). So, plan for the Unicode migration as part of the upgrade unless you have already done so in an earlier upgrade (i.e. v7.0).

If you do that, I would add 40-50% more disk, 20-30% more processing power and RAM as well…

p class="MsoNormal">
p class="MsoNormal">MartinOConnell: p class="MsoNormal">1) Are 3.5 update rules and transfer rules compatible with 7.3? We are running 7.0 (sp23) and plan on upgrading soon but have not migrated our 3.5 functionality to 7.0. p class="MsoNormal">2) We are planning on adding 2 additional blades to our BWA prior to upgrading BW from 7.0 to 7.3. Can the new blades have the 7.2 software installed and run successfully under BW 7.0 (with the existing blades running 7.0 software) or would we have to install the 7.0 software on the new blades until we upgrade BW? p class="MsoNormal">3) Is conversion to UNICODE required to upgrade to 7.3 BW/Portal? p class="MsoNormal">4) We run Oracle (11.2) - are there any issues with this running BW7.3?

Dr. Berg: Hi Martin,

1.  See earlier answer to SidB

2.  I would look at the product availability matrix (PAM) on the SAP Service Marketplace and see what is required for each version of the operating system, DB and hardware. To make it easier, and possibly save rework, I would though do this as part of the upgrade instead. Adding a couple of blades is not that big of a task and your hardware vendor would probably prefer to do a ‘one-time’ job instead of piecemeal.

3. See earlier answer to Rodrigo Marques

4. None that I know….

p class="MsoNormal">
p class="MsoNormal">José Mão-Cheia: Hi, From the infrastructure point of view what is the level of OS and database that SAP NetWeaver release 7.3 will support. I'm currently running:

SAP NetWeaver release 7.0 EHP 1

OS = SLES 11 SP1

Database = DB2

database size = 2.2TB.

Also what will be supported if I only use SAP HANA? Is this a feasible solution?

Dr. Berg: Hi Jose,

All items required are outlined in the product availability matrix and in the master install guide on SAP marketplace. There are detailed list of operating systems, databases, hardware and software compatibility listed there. Since it is updated frequently, I am not copying it over here. Just log-on and take a look at the ‘latest and greatest’ from SAP.

p class="MsoNormal">Dr. Berg: Re: Specific Database Support

Previously, SAP BW was database ‘agonistic’ and did not take advantage of all the database features used by the clients. This has changed somewhat in BW 7.3. Now there is new support for database features for Teradata and DB2.

For example, 7.3 can now run on top of the Teradata database and you have the ability to use BW-Accelerator on-top of Teradata. You can also use the SAP’s system to manage transports between your BW environments.

For DB2: 7.3 supports specific database features such as PSA, DSO and fact table compressions for reduced disk volume (integrates with DB2 storage management on DB2 v9.5). You also get support for MDC clustering in the DB Cockpit (available in v9.5.2. or higher and default for all DSO tables and PSA in version 9.7). In addition, you get much faster request deletion if MDC clustering is used and v9.7 even supports index compressions to reduce disk volume. You also get support for DB2’s database partitioning feature (DPF).

 So lot of great news to those using these types of databases.

pavel rais: Hello, We are planning to migrate from 3.5 to 7.3 and still not sure about the following:

1.Which of 3.5 BEx objects can still be used in 7.3 without migrating and which have to be migrated?

p class="MsoNormal">- Queries p class="MsoNormal">- Workbooks p class="MsoNormal">- WAD Template p class="MsoNormal">- Views

2. Is it possible to do upgrade from 3.5 to 7.3 in one step or is it mandatory to go through 7.0? (In case if we do not plan to migrate analysis authorization)

Dr. Berg: Hi Pavel,

The WAD (assuming JSP and not BSP) should work fine. No major changes to that product. 

For queries I recommend conversion (see earlier answer to SidB). Query views (7.0) works fine also.

For workbooks, I would carefully examine each of them before making a determination. There is often complex logic added to these that can break. So, be careful… I recommend to my clients that you go from 3.5 to 7.0 and do the security conversion; query conversion; Unicode conversion and then to 7.3. The 7.0 ‘stop-over’ modularizes the upgrade and should not add much to the overall timelines.

BTW: 3.5 went out of mainstream support in October 2010 :-)


magdalena zarek: Hello, We are looking at an upgrade from 3.x to 7.3 and we are not sure about the following issues:

p class="MsoNormal">- Is our first step on 7.0 or it is possible to make a direct upgrade to 7.3? p class="MsoNormal">- If the upgrade has to be done in two steps, is the migration to the new authorization concept required in 7.0 or is possible in 7.3? p class="MsoNormal">- Any compatible issue concerns related to source system? p class="MsoNormal">- Will BEX queries and workbooks work without any fail in 7.3? p class="MsoNormal">- Any obsolete objects or no longer valid in BI 7.3, but exist in BW 3.0? p class="MsoNormal">- And what about the object in 2.0 still existing on a 3.0 server: what do we have to do in order to go to the 7.3?

Dr. Berg: Hi Magdalena,

The stop-over on BW 7.0 is the right path for a 3.5 upgrade.

For the authorization concepts see my earlier answer to SidB.  But the short story again is that:

When companies upgraded from BW version 3.5 to 7.0, security migration was optional and many did only a technical upgrade and kept the 'obsolete authorization' concept.  Actually, some companies did not do a security conversion in BW 7.0 since items such as 0TCTAUTHH did not migrate (manually reassigned for the hierarchies) and passwords became case sensitive. Now, SAP recommends migrating to the new concept before upgrading a 7.0 system. (Notes: 931898; 938871; 946724, 958665; 1001652).

However, in 7.3 you get a new security admin feature that allows you to make mass changes to authorizations instead of one-by-one. This can be done by cut-and-paste in a worklist, hierarchy nodes, and you can also add users to multiple analysis authorizations.

For those in need of migrating the security, SAP still has the ABAP migration tool in BW 7.0. It can be used in SA38 (RSEC_MIGRATION) and migration can occur before the 7.3 upgrade. The ‘new’ authorizations are building blocks of the 7.0/7.3 reporting concept and security contains both the data value and hierarchy restrictions. You can still build security in 7.0 and 7.3 using the “RSECADMIN” transaction

Before I start I normally reduce the overall size of BW.  I do this by cleaning the PSA, delete log-files and objects not needed (i.e. DSOs and InfoCubes), empty aggregates etc. before I launch the upgrade front-end that take me through all the steps of the NW 7.3 upgrade.

While the upgrade interface is simplified, there is still a need to thoroughly understand how to setup connectivity, hardware and shadow systems. But, SAP has a great step-by-step 'wizard' tool to help with the upgrade. Then you should plan the maintenance. This includes:

1. Stop all Daemon Process - RSRDA

2. Remove all temporary database objects - SAP_DROP_TMPTABLES

3. Run the upgrade check - RSUPGRCHECK

4. If you copied your system from Prod, check the storage - SECSTORE

5. Make sure all objects and programs has a library entry - TLIBG

6. Create an XML file for the new stack in Sol. Mgr

So, just make sure that all objects are in the TLIBG library and they will be 'shielded' during the upgrade.

p class="MsoNormal">
p class="MsoNormal">magdalena zarek: Is it possible to go directly from BW 3.0b non Unicode to BW 7.3 unicode?

Dr. Berg: Hi Magdalena,

The short story is: Unicode conversions was strongly recommended by SAP in BW 7.0, but not required. Some decided against it due to the required additional disks, memory and processing power. Actually, if the system was MDMP companies had to convert. However, if their system was non-Unicode single code-page system a SCP non-Unicode is possible until SAP NW 7.0 EhP1 (SAP Note: 73606). Therefore many did not do the Unicode conversion. Now is the time to bite the ‘bullet ‘ and do it. Unicode is the standard. For example, BPC 10 on BW 7.3 requires Unicode (& 64-bit) and IBM’s NLS for BW 7.3 requires Unicode (DB2 v.9.7+). In addition, the PAM for JVM 6/Linux states ‘installation Unicode/64-bit only’).

So, plan for the Unicode migration as part of the upgrade unless you have already done so in an earlier upgrade (i.e. v7.0).



Anil Patel: We are currently on release 7.01 support pack 8 and planning to upgrade to 7.3. Here are the questions we have for the upgrade:

1. What will be compatibility of SEM with BW 7.3? We are on release SEM 6.04.

2. What is the future of BEx Excel Analyzer and BEx Query designer? Do we need to start moving towards Business Objects?

3. Which 3.5 objects will not supported and has to be migrated after or during upgrade?

4. What kind of migration tool are available in BW 7.3 during and after upgrade?

5. Which area we need to concentrate our testing on?


Dr. Berg: Hi Anil,

Here are some answers on the upgrade tool (your question #4):

The ASU provide a list of pre- and post upgrade tasks. Last time I looked I found 26 pre-processing manual tasks in the list and 28 manual post processing tasks. However, these are well organized and there is also support for documentation of each task. Team members can consolidate their comments, test results and outcomes. This can reduce the number of emails and everyone can see what has been done and see results in one place.

In step-2 of the ASU upgrade interface, you select you system files. First you must select the update option for your system and the stack you want to update (make sure you are connected). Then you select the target system you want to upgrade to (NW 7.3) and all files for the operating system and database you have. Finally, you select the files for the ‘to-be’ stack.  There are some different files required for each type of database, operating system and stacks. Make sure you collect the right versions.

 In step-3 you download the XML upgrade file generated and you use this for the next steps in the upgrade process.

This is very much an automated process. with some manual checks. SAP has developed some really useful programs over the years to assist with the upgrade. For example, If you are still on 3.5 queries, or older versions (i.e. 3.1c, 3.0B), consider running the program RSR_GEN_DIRECT_ALL_QUERIES to regenerate all queries in the system into the 7.x release.

NW BI 7.0 had a new transformation concept that replaced transfer and update rules, but not all companies have migrated. To do so now, convert the DataSources and the Persistent Staging Area to the new DTP process, (SAP Note 906789). To test the conversion of the DataSources can also run: RSSM_CREATE_REQDONE_FROM_SEL; RSSM_HASH_ENTRIES_CREATE for all requests; RSSTATMAN_CHECK_CONVERT_DTA;  RSSTATMAN_CHECK_CONVERT_PSA. (you can also hold off on this and do a ‘functional upgrade later. I believe now may be the time to do it right, so if you choose this, make sure it is actually done and not postponed as many did in the 7.0 upgrade)

If you are upgrading from an old BW system and is going through BW 7.0 to upgrade to 7.3, redefine the BI Statistics, (notes 934848 & 964418). Also, use SM37 in production to find any other jobs that are scheduled, and make sure they are also tested.

Finally, if some of your InfoSets becomes inactive, you can still use the program RSQ_ISET_MASS_OPERATIONS to activate all InfoSets (available since BW 7.0)

So lots of help is available.

JayRoble: 1. Is there a list of any new security Authorizations?

2. Do you know if anyone has the BW cockpit working in BW 7.3? We never really got it working or useful in BW 7.01.

Dr. Berg: Hi Jay,

There are lots of new cockpits and monitors in BW 7.3 and they seem to work fine. For example:

- You get monitors where you can see database usage and object sizes (i.e. InfoCubes, DSOs) and query usage statistics are more visible (similar to RSRT, RSRV, RSTT).

- In addition, you get easier access to see the use of BWA and sizes and you can monitor for the actual use of OLAP/MDX Cache and hit ratios.

- In addition, you may selectively delete internal statistics in RSDDSTATWHM by date through the updated RSDDSTAT_DATA_DELETE ABAP program and there is even a new MDX editor for coding and syntax assistance.

- Also, there are monitors to see DEAMON update information (i.e. RDA capacity status, usage), and a new performance monitoring workbench for performance trends. For most companies the new process chain monitoring (transaction: RSPCM) with error and active chain monitoring, user specific displays, and performance threshold monitoring (i.e. for SLAs) is a great new feature in BW.

Actually, I believe some companies will upgrade just to get access to monitor performance in an easier way than through Early Watch reports in Solution Manager (BTW: Solution Manager has also been updated to take advantage of these new monitors).

So, I am not sure why your BW cockpit did not work in 7.0, but in 7.3 I have not seen any issues with this.

 Dr. Berg: Re: Semantic Partitioned Objects (SPO) support in BW 7.3

When data stores and InfoCubes are allowed to grow over time the data load and query performance suffers.   I believe that objects should be physically partitioned when the numbers of records exceed 100 million. However, this may be different depending on the size of your hardware and the type of database you use. In BW 7.3 we get an option to create a Semantic Partitioned Object (SPO) through wizards.  You can partition based on fields such as calendar year, region, country etc.

 SPO Wizards can create Data Transfer Processes (DTP), transformations, filters for each data store and a process chain automatically. When a SPO is created, a reference structure keeps track of the partitions.  You can place the structure in the MultiProvider for querying.

p class="MsoNormal"> 

Anil Patel: We have BW 7.01 and BPC 7.5 SP6. What is the upgrade path to BW 7.3?

Dr. Berg: Hi Anil,

I would concentrate testing on queries/workbooks (if converted). DTP's (if converted), workbooks is high priority if converted from 3.5 queries to 7.x. I would also check security if you are still on old authorization concepts. 

From a logic standpoint I would run two set of process chain runs and also reconcile data between planning functions such as SEM/IP/BPC/APO etc.

 


Andrei Grechko: Hi, We are currently running:

- SAP NetWeaver BW 7.02 EHP 2 (SAPKW70209 SAP BW)

- ECC 6.0 Ehp5

I have 2 questions:

1. We are using SAP ECC 6.0 (Ehp5) system to extract all the data into SAP BW. Do we need to upgrade our ECC/R3 transaction system, or can we just proceed with the BW upgrade?

2. We are using SAP Enterprise Portal for all reporting and analytics functionality, including BI-IP. While we upgrade BW to 7.3, do we also need to upgrade SAP Portal? If portal needs to be upgraded as well, then to which level?

Thanks so much for your answers.

Dr. Berg: Hi Andrei,

No, the plugins do not need to be upgraded unless you have really old PI's. The same is true for the portal (unless you are using really, really old versions). However, if you can, there is nothing wrong with upgrading these as well (if you have the bandwith).

p class="MsoNormal">AndyBates: We use the BEx Browser to present our web template reports to our users (about 200 reports). p class="MsoNormal">We have been led to believe by multiple consultants that the BEx Browser is a) Not supported (don't know what this means) b) doesn't work c) going away (don't know what this means either) or d) will probably work but nobody uses it.

We are running BW 3.5 and want to ugprade to 7.3 next year, but losing the BEx Browser is a show-stopper for us. We have been told that we will have to implement SAP Enterprise Portal to replicate the BEx Browser functionality, but that has a dollar and personnel cost that we cannot afford.

Would you please explain how the BEx Browser does or does not work with 7.3 and advise on what our next steps should be. Telling us to install the SAP EP (as we keep hearing from multiple consultants) is not an option.

Dr. Berg: Hi Andy,

Sorry, but BexBrowser support was discontinued with 3.5 end of mainstream support in March 2010. It died together with 'ad-hoq query designer' and BEx Download scheduler.  More information is available here. [Editor's note: Please log in to view the presentation "Best Practices for Your SAP NetWeaver Business Intelligence 7.x Upgrade" in the BI section of the Member-Only Resources.] 


harancibia: Is it possible to keep some datasources in the 3.5 version after the upgrade to BI 7.3?

Today we are running on BW NW 7.01 emulating some datasources in the 3.5 version. We want to know if we would upgrade them or we can work in that version until activate another datasource in the 7.3 version.

Dr. Berg: Hi Harancibia,

Technically possible, but I recommended that you do it now. For example, NW BI 7.0 had a new transformation concept that replaced transfer and update rules, but not all companies have migrated. To do so now, convert the DataSources and the Persistent Staging Area to the new DTP process, (SAP Note 906789). To test the conversion of the DataSources can also run:

RSSM_CREATE_REQDONE_FROM_SEL;
RSSM_HASH_ENTRIES_CREATE for all requests;
RSSTATMAN_CHECK_CONVERT_DTA; 
RSSTATMAN_CHECK_CONVERT_PSA.

You can also hold off on this and do a ‘functional’ upgrade later. I believe now may be the time to do it right, so if you choose this, make sure it is actually done and not postponed as many did in the 7.0 upgrade.

SAPinsider (Murty): We are at version NW 7.0 SP17 and planning to upgrade to NW 7.3.The purpose of this upgrade is as below:

1. We want to set the platform to install Business Objects tools and be able to integrate with existing BW queries without having to set up BICS. Will we able to do so?

2. We assume after this upgrade we may be able to work with WebI/Xcelcius directly sittng on top of BW queries without having to set up Universe. Is this a valid assumption?

3. How do we check in our system in the current version (NW 7.0) whether we are already on Analysis Authorizations or not? Is there any transaction/table where we can verify?

Thanks,

Murty.

Dr. Berg: Hi Murty,

Most of this is answered in the earlier posts [e.g., to Rodrigo Marques]. But for BOBJ tools, you can always create OLAP universes (based on MDX) and pick up the queries in BI 4.0.

However, just be aware of the fact that BICS connectors are 'native' and typically much faster. Also, with BICS you can connect to both the query and the underlying InfoProvider.

p class="MsoNormal">substring re: SAPinsider (Murty) post: p class="MsoNormal">“2. We assume after this upgrade we may be able to work with WebI/Xcelcius directly sittng on top of BW queries without having to set up Universe. Is this a valid assumption?”

It is a valid assumption providing that BW is your only data source. Otherwise, you might need to create multi-source universes.

Dr. Berg: Yes, you can use Multi-Source universes and link the BW data with non-BW data. The issue is that you lose access to time dependent masterdata; hierarchies; RKF; CKF; Variables, Exceptions; Conditions; structures and non-cumulative key figures. Currency and unit conversions also have to be added. So technically feasible, if you can live with these limitations.

p class="MsoNormal">Dr. Berg: Re: Data load options in 7.3

There are several new data load options in &.3. Now you can create generic delta extraction for the Universal Data (UD) & Database Connect (DB) options, as well as for flat files.  In addition you can the new DataSource adapter “Web Service Pull” to load data from external web services. You can even create generic WebServices delta loads, and load the new data straight into the staging area of BW 7.3.

While web services do not support hierarchies yet, there is now integration of hierarchies into the standard process flow such as transformation and DTPs, as well as being able to load hierarchies from flat file using a new DataSource.

Another great change is that when you use delta loads, the first time BW 7.3 automatically defines it an “init load” after that it automatically switches to “delta” as the InfoPackage mode (there is no need to define it anymore).

Combined with the new activation options in 7.3, these may be the core reason why you want to consider the upgrade earlier than later in 2011.

p class="MsoNormal">  p class="MsoNormal">Dr. Berg: Re: Faster data loads in BW 7.3

7.3 is a quantum leap in better data load features. For example, during activation, BW 7.0 had to lookup in the NIRV table to see if the object already exists. This could be a slow process. We had some basic tools to assist us in tuning this. We could buffer the number ranges to compare the data load with records in-memory. This speeds up data activation.

However, in BW 7.3 the data activation is changed from single lookups to package fetch of the active table, resulting in faster activation and less locks on the lookup tables. The new method may result in 15-30% faster data activation (I have seen 20-40% in our lab tests).

Also, in 7.3 for data transformations the option ‘Read from DataStore’ for a faster data look-up is also available. In addition, the use of navigational attributes as sources in Masterdata transformations reduce overhead for lookups. Combined, this may lead to an additional 10-20% improvement. Finally, you now can use the 7.3 initial load runtime option “Insert only” and the “Unique data records only” to prevent all look-ups during activation.

 Overall, great new features that may improve you dataloads significantly…

Marc Lavoie: Can we consider a BW 7.01 SPS5 to BW 7.3 as a pure technical upgrade by not putting the new functionalities day one to minimize testing effort -- In fact, considering this upgrade a pure technology step forward to put in place the technological foundation to better support future market and business Analytics trends?

To evaluate effort to deliver this upgrade, is it realistic to estimate effort for BW queries and loads similar than Support pack stack upgrade project? This is assuming that estimated effort for basis and testing team will be higher if other components (Portal, CE or Solman ) are also upgraded.

p class="MsoNormal">AnneMoreau: Hi,  My question is the same as Marc Lavoie.

Dr. Berg: Yes, you can treat it as a 'pure' technical upgrade and roll out the functionality gradually.

Just be aware that most of the new 7.3 functionality is targeted to developers and admins (i.e. ETL interface, load activations, wizards, LSA templates, monitors, SPO etc.) You can certainly plan on using this gradually, but I would plan for at least a couple of (2-3 hours) workshops with the developers to show them how they will be impacted and what the new tools are.

In terms of effort, this is a bit larger than applying an SP and I would treat it as an upgrade project (4-8 weeks incl. testing for a 'pure' technical upgrade). The functional upgrade would then follow when you are ready and you can start remodeling DSOs, partition ICs and take advantage of DTP and the new data activations over the next few months (not required, but there are great performance benefits here)....


MartinOConnell: Hi, The upgrade from 3.4 to 7.0 was a very smooth process. Is the upgrade from 7.0 to 7.3 similar?

Or are there any known problems that we need to be aware of to factor into our plans - particularly if we are a site still using some update rules/transfer rules, are not UNICODE, and don't want to do either of these conversions prior to upgrading?

Dr. Berg: Hi Martin, The 7.3 has been an extensive upgrade, but not that difficult.

Actually the 7.0 was bigger if you did the DTP, Security and unicode conversions as well as the java stack.

There are new options though. A major decision is: Are you going to minimize the system down-time, or doing a low resource upgrade? The trade-off is between using more system resources, or more downtime.

In the 'standard' upgrade, we create a shadow system, while the BW system is still operating. We turn off any archiving to make sure we do not miss any data, and do our system backup right before the downtime starts. Therefore we can do much of the upgrade before the downtime (shorten the outage).

In a very high system resource upgrade, we also use a shadow system, but imports are much faster and we can keep archiving on (may create large logs), but downtime starts earlier. Most companies should use the standard upgrade method, unless their system is very small or have limited resources. For those, the shadow system is created during the downtime.

The short story is that a ‘high system resource ‘ upgrade  - locks the system in the REPACHK2 phase; the ‘Standard system resource’ upgrade locks the system in the REPACHK2 phase (step 5/6) and a ‘low system resource’ upgrade locks the system in the LOCKEU_PRE phase (see note 851449 for more option details).

Assuming you did a standard resource upgrade, in the ASU step-5, while, technically you have not yet locked the system, configuration changes to process chains, info packages & queries are no longer possible after this step. The real lock-down of the BW system takes place when the pre-processing step is complete. After this the system is unavailable for users.

However, there are many steps between these steps. I believe the best timing may be to complete all tasks from step 1 through 5 before Friday's 5pm when you may be able to bring the system down. I recommend also doing another backup before you proceed to step 6.

If you are set against the unicode conversion and want to stay away from the DTPs, you can make it work. But you will have significant problems 'living' in the SAP landsacpe  long-term.  For example: For example, BPC 10 on BW 7.3 requires Unicode (& 64-bit) and IBM’s NLS for BW 7.3 requires Unicode (DB2 v.9.7+). In addition, the PAM for JVM 6/Linux states ‘installation Unicode/64-bit only’). So technically possible, but not reccomended.

Anil Patel: We have BW 7.01 and BPC 7.5 SP6. What is upgrade path to BW 7.3?

Dr. Berg: Hi Anil, You can stay on BPC 7.5 and to to BW 7.3; or you can upgrade to 7.3 and then BPC 10. You cannot do a BPC 10 and stay on BW 7.0 (not supported by SAP).

MartinOConnell:  Are there any special considerations that need to be taken into account for IP work developed under 7.0 when upgrading?

Dr. Berg: Hi Martin,

A major consideration is whether you want to stay with IP on Java, or move to the new ABAP stack for IP.  If you do, there are some install and connection work as part of the 7.3 upgrade. I reccommend going with the ABAP stack (faster) if you have testers available during the upgrade.

Dr. Berg

p class="MsoNormal"> 

Aleeza: Dr. Berg, We have read that mainstream maintenance has been extended to 2020 for the SAP Business Suite.  In order to qualify for this extension, do we need to upgrade from Netweaver 7.0 to 7.3?

Thanks in advance.

Dr. Berg: Hi Aleeza,

I have not seen this maintenance note for Business Suite and cannot tell what is required. I would ask my SAP account executive.

Dr. Berg

p class="MsoNormal">Aleeza: Dr. Berg,

The information can be found on the SAP Service Marketplace.  Here’s a link to the PDFs. Thank you.


AnneMoreau:  Considering a BW 7.0 EnhP1 to be upgraded to BW7.3, with BIA, Portal, Java potal upgrade as well.

And to try to understand your statement to Anil that we just should test, would you please advise how long HL would take a Development, Acceptance and Production Upgrade for the DW?

Dr. Berg: Hi Anne,

We normally plan for a 6-12 weeks upgrade of all environments. It depends a bit on the testing required for missing critical applications (APO/BPC/SEM/IP etc.), the number of boxes (i.e. additional training, development, technical sandboxes etc). as well as any conversions included in the upgrade (security, DTP, PSA, unicode etc). However, 6 - 12 weeks, with most being around 8 weeks is normal for a 4 box environment.

Dr. Berg: Re: Upgrade path

If you are also installing new hardware, you get a lot of flexibility and less project risk (amazing, is it not? :-). When I have this option, I first copy the ‘old’ BW 7.0 development box to the new hardware.

Second, I upgrade the new sandbox in a controlled manner and document all activities. I want to create a repeatable process, so no ad-hoc activities are allowed. The benefit of doing this is that it is also a test run for upgrading the development box (!), thereby reducing the upgrade risk. In addition, after the upgrade we also have a refreshed sandbox environment. Just, remember, extra time has to be set aside for notes research and unforeseen issues. 

Then I freeze all development activities. Normally the work in the 7.0 dev box is transported to QA for testing and the dev box is locked. I copy the box to the new hardware, and using the upgrade ‘script’ and all steps collected and written during the sandbox upgrade, I upgrade the new development box. This is intended to be a structured approach that is repeatable. The benefit is that the outage of the development box occurred after the sandbox upgrade and the development outage is minimized.

This is also the second time we have upgraded the development box, so any issues should be well known. The developers participate in in-depth testing of the new 7.3 dev. box.

For the QA Box, I copy production environment to the new ‘to-be’ development box after all testing in the QA has been completed and all the object has been transported to the production system. Notice that no copies of Sandbox, nor QA is made. Instead we get to upgrade the development box and the production box 'twice'.  This is a significant risk mitigation strategy, but it does require that transports and client dependent objects are switched back on the new Sandbox and QA systems (manual steps).

The benefit of doing this is that this approach turns the QA upgrade into a real 'dress rehearsal' for the production box upgrade. Also, since we are switching the hardware, the r isk to the upgrade in minimal (BW 7.0 prod is not taken off-line until after the upgrade).

I am now ready for the Production box and the ‘cutover’ weekend.  The best timing is to start the production box on Thursday evening after the BW system has completed data loads. A full backup is taken. I communicate that the system is unavailable on Friday and is completely expect to have it upgraded by Saturday 6am (the users are told that the system will be unavailable the whole weekend, since I also have to plan for restore time in case everything goes wrong). A major consideration is the time it takes for Unicode conversion, unless already done. I plan for having basis and technical people working the night from Thursday to Friday and possibly to Saturday, depending how long the upgrade takes.

The system verification takes place by testers on Saturday between 6 am and noon. A complete data load is executed by manually running the process chains and data is also validated.

A restore decision is made at 3 pm on Saturday:  If the system does not pass the validation, the system is restored from backup and will be ready by Monday 8am.  If the system passes validation, the process chains are scheduled and run at normal scheduled times and data is validated once more before declaring success...


Dr. Berg: Re: New BI Workspaces in 7.3

7.3 also introduces the term “BW Workspace”. In short, this is dedicated area in BW where new models can be created based on central BW and local data (cvs files, text etc.). The BW workspaces may be controlled by IT and used by business departments to react faster to new requirements.

BTW: the workspaces can even be given their own BWA access ‘areas’, and there is even a new Workspace Designer tool that you can give to the business units. It is GUI based on have many wizards to do basic functions (step-by-step).

Just be careful to who you give access (can create ‘wild-west’ in you BW system if the business people who do the work are not properly trained or managed).

 

MartinOConnell: Are there any special considerations that need to be taken into account for IP work developed under 7.0 when upgrading?

Dr. Berg: Hi Martin,

A major consideration is wheter you want to stay with IP on Java, or move to the new ABAP stack for IP.  If you do, there are some install and connection work as part of the 7.3 upgrade. I reccoemend going with the ABAP stack (faster) if you have testers available during the upgrade.

The IP for 7.3 was redeveloped in ABAP HTTP (Java no longer required) so plan for a switch during the upgrade.


Dr. Berg: Re: Splitting the stacks during the BW 7.3 upgrade

NW Java 7.3 is now included, and it is suggested that ABAP and Java Stack is split if not already done so. A tool to split the stack is available in EhP2 (in SAPInst) and in SAPInst in ABAP 7.30.

This gives better scalability (multiple hardware servers). However, ‘double stack’ upgrades are still possible. Also, the java server is not used for IP after BW 7.30 (re-developed in ABAP HTTP).

When you finish the upgrade, you can also automatically create connections between Java-ABAP for EP/IP or front-end Java using CTC (see SAP notes: 983156, 1178800 for instructions).  The short story, is that you should consider splitting the Javastack from the ABAP/ BW as part of the 7.3 upgrade unless you have already done so.

 

Dr. Berg: Re: New HybridProviders in BW 7.3

There is a new "HybridProvider" in 7.3. The core idea is to link the historical data inside BWA with real-time data. Currently, there are two ways of implementing a hybrid provider. It can be based on a DSO or a Virtual InfoCube.

 If you base it on a DSO, then ‘real-time’ data is in the DSO and historical data in the BWA based InfoCube (the DSO use real-time data acquisition (RDA) to load data). BW automatically creates a process chain for the HybridProvder's data flow and the process chain is executed for every closed request. This solution provides for really fast queries, but delta logic has to be custom designed

If you base it on a Virtual cube, the data is read in real-time from ECC, while historical data is read from BWA. The difference depends on how often BWA is loaded. Basic non-complex data logic can be applied and DTP is permitted if you do not filter the data set. Just be sure that you take into account that virtual cubes with many users may place high-stress on the ERP system.

So great features that both speeds up query execution and also gets access to ‘near-time’ and ‘real-time’ data. I believe this may be a great option for people in finance that is looking at faster close cycles and near-time reporting, or executives who simply cannot wait for end-of-nigh data loads :-)

Scott Wallask: Thank you again to Dr. Berg for his help with today’s BI Forum.

For more advice, check Dr. Berg’s regular blog on Insider Learning Network covering BI and SAP BusinessObjects, including thoughts from his recent sessions at SAPinsider’s Reporting & Analytics conference and the ongoing Xcelsius Dashboards Bootcamp seminar.  Members of Insider Learning Network can also access one of Dr. Berg’s sessions on BI and BWA in the Member-Only Resources section on their homepage. 

Another excellent resource is BI Expert, which offers in-depth articles and tutorials about BI and BusinessObjects topics, related technology, and best practices.

And of course, the BI Forum archives past Q&As from Dr. Berg and ot

Did you find this blog helpful? Get access to the latest updates and resources from SAPinsider with a free subscription.

Get the SAPinsider subscription now »»

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ