Keep in mind that the BI 7.0 upgraded system allows configuration running in the 3.x method of modeling (with InfoSources, transfer rules, and update rules). This means that any existing configuration in the 3.x system will continue to work in the BI 7.0 system. For this reason many projects opt for a technical upgrade, moving the configuration to the new release, but the data model does not take advantage of the new loading methodology, java functions, etc. This allows for a quicker and less risky upgrade because there are less changes to the application.
Listed are some of the typical challenges in the 3.x to BI 7.0 projects. This list includes some of the common issues I or some colleagues have experienced during upgrade projects, this list is not exclusive, but does help to highlight some of the areas that are particularly challenging.
There are a lot of SAP Notes. This release is a very extensive and complex release, this leaves a potential for substantial software issues. SAP is releasing a large number of SAP notes for each support stack. The team needs to keep the system updated as often as possible. Regression testing needs to be planned after each support stack upgrade.
The Java analysis queries need to be planned properly. The Java analysis queries can sometimes gather huge volumes of data, depending on their design. In some cases this can monopolize the Java server causing performance issues for everyone. This can be compensated for by good user training and intelligent query design. The query design element forces the user to utilize jump queries in order to get detailed data. This can keep the users from running very large queries and taking a large volume of the Java server.
Common access tools either go away or are no longer supported. Those projects that use the 3.x BEx Browser and/or the Web menu item is not included in the current version of BI 7.0. This may mean that the upgrade requires a new way for the users to launch queries to be developed. This can pose a rather difficult change management issue
SAP no longer supports the 3.x method of authorizations. It is highly recommended that quickly after the upgrade, project teams migrate the authorization security to the BI 7.0 Analysis Authorization security functionality. This can involve a rather large effort depending on the complexity the 3.x security model. In most cases this should be managed as a separate project because of the effort involved.
The security migration tool does not always convert everything. SAP has provided a tool to convert existing 3.x security to the BI 7.0 model. This program is RSEC_MIGRATION. It does not always convert all security; most customers report that it is converting about 80-85% of security. This means some of the migration needs to happen manually. All security requires a regression test to ensure the migration was successful.
Regression Testing for Analysis Authorizations are time consuming u2013 The only way to really understand any issues that may result from the transition from the 3.x authorizations is to fully regression test. This is a rather labor-intensive process involving creating many userids and manually testing the BI functionality to verify that the authorizations are set up correctly.
Integration with the Portal is much more vital in the BI 7.0 release. There are many more touch points between the BI application team and the Portals team. The BI team needs to determine what strategy is to be used for publishing queries to the portal, the portal team needs to develop a clear strategy in conjunction with the BI and ECC or R/3 transactional teams to provide clear content to the end user. In the 3.x version, the SAP Enterprise Portal (EP) was not as tightly integrated with BI, in the BI 7.0 version the integration is more dramatic.
A federated or BI portal strategy needs to be developed. If the project team plans to use the EP functionality to provide the end user access point for BI, there are several important decisions that need to be made by the portal team. The portal can be run either from the BI system or from a centralized 'federated' portal. There are advantages to each approach. There are several whitepapers that detail this decision on the SAP developer network site (SDN) at www.sdn.sap.com.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.