Impact in portal for Upgrade ECC 5.0 SP04 to ECC 6.0

We are upgrading the ECC system from SAP_APPL 500 SP04(ECC 5.0) to SAP_APPL 600 EHP4 SP10(ECC 6.0) . I need to know what will be the impact on Portal 6.4 VErsion which is having ESS/MSS and BI integrated .

Hi GjEPCons ,
The Ess/mss application are standard some application webdynpro java and web dynpro abap so nothing happen upgrade one version to another version in backend and bi reports also but we can check the system object if case any thing happen ,
Ecc 5.0 and Ecc 6.0 nothing more change some features have add in Ecc 6.0 so we dont bother tome to upgrading .
Upgrade from ECC 5.0 to ECC 6.0
Hope this information help s to you
Thanks&Regards,
G.srinu

Similar Messages

Impact to Portal on upgrading the IE version from 6 to 8

Hi,
We are in a plan to upgrade our Internet Explorer version from 6 to 8.
Can anybody let me know what will be the impact on Enterprise Portal iviews (WD iviews, BSP, Standard iviews)
Regards,
Pradeep

Hi Pradeep,
The official support comes with SPS20 for IE8 on Windows XP Professional and with SPS21 on Windows 7. You will find information within the PAM - http://service.sap.com/pam
Also, check this thread for more details - IE 8 Compatibility with Portal 7.0
Regards,
Sen

Need useful documentation for upgrade of SAP 4.7C to ECC 5.O

Hi,
As my company is going for the upgrade to ECC 5.0, can you guys help me out by sending some useful documentation regarding the upgradation, as i never worked on upgradation project before.
Points will be rewarded for usefeul information.
Please send the documents to the following email id: [email protected]
Thanks,
Bobby

Hello Kumara,
First read the release notes of ECC 6.0 with respect to ur version (4.7c).
Observe changes in ECC 6.0 and make further changes in Blue print new release.
u can find the release notes at sap help and also at the screen.
If there any further requirements, u can collect the requirements that is billable
Regards,
Narendar Konakanchi

What is the impact of R/3 upgradation from 4.7 to ECC 6 on BI

Dear all,
Can any one tell me what will be the impact of R/3 Upgradation on BI... as we are shortly going to upgrade our R/3 from 4.7 to ECC 6.
Do we need to take any precautions in R/3 and aswell as BI
Please give the information...points will be given
Regards
venu

Hi
Please Refer this as this vll give u the Pros and Cons for upgrade.
Refer
http://wiki.ittoolbox.com/index.php/Upgrade_BW_to_Netweaver_2004s_from_v3.0B
This Wiki contains Rob Moore's ( BW Manager, Edwards Limited) teams experiences in upgrading Business Warehouse System from 3.0B to BW 7.0.
Contents
1 Upgrading from BW 3.0B to BW 7.0 (Netweaver 2004s)
2 Introduction
3 Overview & Scope
4 Drivers
5 Environment
6 Resource & Timescales
7 High Level Plan
8 Summary Task List
8.1 #Support Pack Hike
8.2 #Plug-in installation
8.3 #PREPARE process
8.4 #Dbase upgrades
8.5 #System Upgrade
9 Lessons Learnt
10 Issues & Fixes
10.1 Unfixed Issues
10.2 Fixed Issues
11 Regression Testing Process
11.1 Introduction
11.2 Set up
11.3 Actions
11.4 Security
12 Transport Freeze
13 Web Applications
13.1 Dashboards
13.2 Internet Graphics Server (IGS)
14 Detailed Task Lists
14.1 Support Pack Hike (detail)
14.2 Plug-in installation (detail)
14.3 Dbase upgrades (detail)
14.4 PREPARE Process (detail)
14.5 System Upgrade (detail)
Upgrading from BW 3.0B to BW 7.0 (Netweaver 2004s)
Introduction
This Wiki contains my teams experiences in upgrading our Business Warehouse System from 3.0B to BW 7.0.
Hopefully it will be useful to anyone else who's about to embark on this. If there's anything I've missed or got wrong, then please feel free to edit it or contact me and I'll try to explain.
Rob Moore - BW Manager, Edwards Limited.
Overview & Scope
This was to be a technical upgrade of BW only. The new BW 7.0 web functionality & tool suite which requires the Java stack rather than the ABAP stack was out of scope. We had heard that the latter was where most of the problems with the upgrade lay. Our plan is to wait for this part of BW 7.0 to become more stable. Also it has a big front end change and the business didn't have sufficient resource to cope with that much change management.
Drivers
3.0B at the end of its maintenance
Opportunities to do better reporting
Options to utilise BI Accelerator
Environment
Our R/3 system was at 4.6C and was not going to be upgraded. We have APO at version SCM4.0.
Our BW system is approximately 300 GB, with 125 global users. It was at version 3.0B SP 18
We have Development, Acceptance and Production environments.
Resource & Timescales
The Project ran for 3.5 months from Feb to May 2007. We used the following resources. The percentages are the approx. amount of their time spent on the project.
Project Manager * 1 70%
BW technical team * 3 50%
ABAP coder * 1 10%
SAP Systems Development expert * 1 20%
Basis * 1 25%
High Level Plan
These are the basic areas. We planned to complete this process for each environment in turn, learning our lessons at each stage and incorporating into revised plans for the next environment. However we did the Support Packs and Plug-Ins in quick succession on all environments to keep our full transport path open as long as possible.
Upgrade BW to the minimum support pack.
Install R/3 Plug-ins PI 2004.1
Run PREPARE on BW
Dbase upgrades (Database & SAP Kernel upgrade)
System Upgrade
Summary Task List
This list contains all the basic tasks that we performed. A more detailed check list is shown below for each of the headings.
#Support Pack Hike
We moved only to the minimum acceptable SP as this seemed most likely to avoid any problems with the 3.0B system prior to the upgrade.
Apply OSS 780710 & 485741
Run Baseline for Regression tests
Full Backup
Apply SP's (we were at SP18, going to SP20)
SPAU list review
Regression testing
#Plug-in installation
Apply SAP note 684844
Import and patch Basis plugin PI 2004.1
SPAU list review
#PREPARE process
BW Pre-Prepare tasks
BW - Inconsistent Data fix
Run PREPARE
Review of results
Any showstoppers from PREPARE?
#Dbase upgrades
Database Upgrade (FixPak)
SAP Kernel Upgrade
#System Upgrade
Reverse Transport of Queries
Reconnect DAB & SAB to AAE
Run Baseline for Regression tests
Full Backup
Run the Upgrade
SPAU list review
Regression testing
Lessons Learnt
Testing is all! We picked up on a lot of issues, but would have picked up more if we'd had a full copy of our production environment to test over.
Our approach of doing a full upgrade on each environment before moving to the next one paid dividends in giving us experience of issues and timescales.
Write everything down as you go, so that by the time you get to upgrading production you've got a complete list of what to do.
We succeeded because we had people on our team who had enough experience in Basis and BW to be able to troubleshoot issues and not just read the manual.
The SAP upgrade guide is pretty good, if you can understand what they're on about...
Remember the users! The fact that the loads have been successful doesn't count for anything unless the users can see the data in Excel! There's a tendency to get caught up in the technology and forget that it's all just a means to an end.
Issues & Fixes
I've listed the main issues that we encountered. I have not listed the various issues where Transfer rules became Inactive, DataSources needed replication or we had to reinstall some minor Business Content.
Unfixed Issues
We could not fix these issues, seems like SP 13 will help.
Cant delete individual request from ODS
After PREPARE had been run, if we had a load failure and needed to set an ODS request to Red and delete it, we found that we could not. We raised an OSS with SAP but although they tried hard we couldn't get round it. We reset the PREPARE and still the issue persisted. Ultimately we just lived with the problem for a week until we upgraded production.
Error when trying to save query to itself
Any query with a re-usable structure cannot be saved (more thsan once!)
OSS 975510 fixed the issue in Dev and Acc, but NOT in Production! SP 13 may solve this once it's released.
Warning message when running some queries post-upgrade
Time of calculation Before Aggregation is obsolete. Not a big issue so we haven't fixed this one yet!
Process Chain Scheduling Timing error
Process chains get scheduled for the NEXT day sometimes and has to be manually reset.
See OSS 1016317. Implement SP13 to fix this. We will live with it for now .
Fixed Issues
Duplicate Fiscal Period values in Query
If you open up a drop down box ("Select Filter Value") for Fiscal Year/Period to filter your query, you are presented with duplicate entries for Month & Year.
Due to Fiscal Year Period InfoObject taking data from Master Data not InfoProvider. Thus it picks up all available periods not just Z2.
Auto-Emails being delayed
Emails coming from BW from process chains are delayed 2 hours on BW before being released
Due to userids that send these emails (e.g. ALEREMOTE) being registered on a diffferent timeazone (i.e. CET) from the BW system (i.e. GMT)
Pgm_Not_Found short dump
Whenever a query is run via RRMX or RSRT
Call transaction RS_PERS_ACTIVATE to Activate History and Personalisation
Characteristics not found
When running a query the warning message Characteristic does not exist is displayed for the following: 0TCAACTVT, 0TCAIPROV, 0TCAVALID
We activated the three characteristics listed and the warnings stopped. NO need to make them authorisation-relevant at this stage.(also did 0TCAKYFNM)
System generated Z pgms have disappeared
Post-upgrade the system Z-pgms ceased to exist
Discovered in Development so we compared with pre-upgraded Production and then recreated them or copying them from production.
Conversion issues with some Infoobjects
Data fails to Activate in the ODS targets
For the InfoObjects in question, set the flag so as not to convert the Internal values for these infoobjects
InfoObject has Conversion routine that fails, causing load to fail
The routine prefixes numeric PO Numbers with 0s. SD loads were failing as it was not able to convert the numbers. Presumably the cause of the failure was the running of the Pre-Prepare RSMCNVEXIT pgm.
Check the Tick box in the Update rule to do the conversion prior to loading rather than the other way round.
Requests fail to Activate on numeric data
Request loads OK (different from above issue) but fails to Activate
Forced conversion within the update rules using Alpha routine. Deleted Request and reloaded from PSA.
Database views missing after pre-PREPARE work
Views got deleted from database, although not from data dictionary
Recreated the views in the database using SE14.
Workbook role assignations lost
We lost a few thousand workbook assignments when we transported the role they were attached to into Production
The workbooks did not exist in Development, thus they all went AWOL. We wrote an ABAP program to re-assign them in production
Regression Testing Process
Introduction
We were limited to what we could do here. We didn't have a sandbox environment available. Nor did we have the opportunity to have a replica of our production data to test with, due to lack of disk space in Acceptance and lack of sufficient Basis resource.
Set up
We manually replicated our production process chains into test. We didn't have any legacy InfoPackages to worry about. We asked our super-users for a list of their "Top 10" most important queries and did a reverse transport of the queries from Production back into test (as we do not generally have a dev/acc/prodn process for managing queries, and they are mostly created solely in prodn). We made sure every application was represented. In retrospect we should have done some Workbooks as well, although that didn't give us any problems.
Actions
Prior to the various changes we loaded data via the Process chains and ran the example queries to give ourselves a baseline of data to test against. After the change we ran the same queries again and compared the results against the baseline. We tried to keep R/3 test environments as static as possible during this, although it wasn't always the case & we often had to explain away small changes in the results. After upgrading BW Development we connected it to Acceptance R/3, so that we had pre-upgrade (BW Acceptance) and post-upgrade (BW Development) both taking data from the same place so we could compare and contrast results on both BW systems. We did the same thing once BW Acceptance had been upgrading by connecting it (carefully!) to Production R/3. To get round the lack of disk space we tested by Application and deleted the data once that Application had been signed off. Once we got to System test we involved super-users to sign off some of the testing.
Security
We chose to implement the new security schema rather than choosing the option to stick with old. For us, with a relatively small number of users we felt we could get away with this & if it all went wrong, just temporarily give users a higher level role than they needed. Our security roles are not complex: we have end user, power-user and InfoProvider roles for each BW application, together with some common default roles for all. In the event we simply modified the default "Reports" role that all our users are assigned, transported it and it all went smoothly. Apart from the fact that everyone's workbooks are assigned to this role and so we "lost" them all !
Transport Freeze
Once you've upgraded Development you've lost your transport path. We planned around this as best we could and when absolutely necessary, developed directly in Acceptance or Production, applying those changes back to Development once the project was complete. Depending on what other BW projects you have running this may or may not cause you pain!
Web Applications
Dashboards
We had various dashboards designed via Web Application Designer. All these continued to function on the upgraded system. However there were various formatting changes that occurred e.g. Bar graphs were changed to line graphs, text formats on axes changed etc. SAP provides an upgrade path for moving your Web applications by running various functions. However we took the view that we would simply re-format our dashboards manually, as we didn't have very many to do. Plus the external IGS (see below) powered all our environments and needs upgrading separately as part of the SAP method. Thus we couldn't have tested the SAP path in Development without risking Production. Sticking with manual mods was a lower risk approach for us. We did find we had to re-activate some templates from BC to get some of the reports to continue to work.
Internet Graphics Server (IGS)
We had an external IGS server with v3.0B. Post-upgrade the IGS becomes part of the internal architecture of BW and thge external server is redundant. We found no issues with this; after the upgrade BW simply stops using the external IGS and no separate config was needed.
Detailed Task Lists
Support Pack Hike (detail)
Apply OSS 780710 & 485741
Communicate outage to users
Warning msg on screen
Stop the jobs which extract data into delta queues
Clear the delta queues by loading into BW
Check RSA7 in PAE that delta queues are now empty
Run Baseline for Regression tests
Stop Delta queues
Lock Out users
Full Backup
Apply SP's
Upgrade the SAP kernel from 620 to 640
SPAU list review
Apply OSS Notes 768007 & 861890
Unlock Test users (inc. RFC id's on R/3)
Regression testing
Regression sign-off
Remove warning msg
Unlock users
User communication
Plug-in installation (detail)
Communicate outage to users
Warning msg on screen
Apply SAP note 684844
Lock out users
Full Backup
Empty CRM queues
Import and patch Basis plugin PI 2004.1
SPAU list review
Apply OSS 853130
Switch back on flag in TBE11 (app. BC-MID)
Remove warning msg
Unlock users
User communication
Dbase upgrades
Dbase upgrades (detail)
Communicate outage to users
Warning msg on screen
Run Baseline for Regression tests
Stop the Data extract jobs
Full Backup
Lock Out users
Apply FixPak13SAP to DB2 database
Upgrade the SAP kernel from 620 to 640
Apply OSS 725746 - prevents RSRV short dump
Unlock Test users (inc. RFC id's on R/3)
Regression testing
Regression sign-off
Remove warning msg
Unlock users
User communication
PREPARE Process (detail)
Pre-PREPARE Process
RSDG_ODSO_ACTIVATE
Repair Info objects and recreate the views
Communicate outage to users
Warning msg on screen
Run Baseline for Regression tests
Stop the Data extract jobs
Lock Out users
Full Backup
Run RSMDCNVEXIT Using BSSUPPORT ID
If there conversion process runs longer delay the regular backup
Re-run Baselines and sign off
If there conversion process Fails repeat the steps on Sunday after the regular backup
BW work
Back up customer-specific entries in EDIFCT (note 865142)
Activate all ODS objects
Execute report RSUPGRCHECK with flag "ODS objects" (note 861890)
Check Inconsistent InfoObjects - Upgr Guide 4.4; OSS 46272; Convert Data Classes of InfoCubes - Upgr Guide 4.3
Execute report SAP_FACTVIEWS_RECREATE (note 563201)
Make sure Delta queues are empty (RSA7)
Basis Work
Full Backup of BW
Lock users
Unlock id's RFC id's and designated test users
Confirm backup complete OK
Apply OSS 447341 Convert Inconsistent Characteristic Values - Upgr Guide 4.5
Confirm OK to PREPARE
Run PREPARE
Review of results
System Upgrade (detail)
Communicate outage to users
Process errors from PREPARE
Check disk space availability for PAB
Warning msg on screen
Reverse Transport Queries from PAB to SAB & DAB
Change BW to R/3 connection
Get backup put on hold, for Ops to release later
Ensure Saturday night backup is cancelled
Final run of PREPARE
Run Baseline for Regression tests
Clear Delta Queues
Delete Local Transports
Remove process chains from schedule
Lock Out users (with some exceptions)
Confirm to Ops and Angie that we're ready
Full Backup
Incremental backup of Unix files
UPGRADE "START"
Back up kernel
Unpack latest 700 kernel to upgrade directory
Check ids required for upgrade are unlocked
Check no outstanding updates
Turn off DB2 archiving
Open up the client for changes
Stop saposcol, & delete from exe directory
Run the Upgrade
Execute the saproot.sh script
Perform the database-specific actions
Perform follow-up activities for the SAP kernel
Reimport additional programs
Import Support Packages
Call transaction SGEN to generate ABAP loads
Transport Management System (TMS)
Handover to BW Team
SPAU list review
Apply OSS Notes from SPAU
Process Function Module XXL_FULL_API (part of SPAU)
Restore table EDIFCT (if required)
Transport Fixes from our BW Issue list
Convert the chart settings - manually
Perform activities in the Authorization Area
Activate hierarchy versions
Update the where-used list
Execute the conversion program for the product master
Transport New roles to PAB
Unlock selected users
Regression testing
Regression sign-off
Go / No Go decision
Restore if required
Remove warning msg
Tell Ops that the CR is now complete
Lock down PAB
Unlock users
User communication
Perform the follow-up activities for SAP Solution Manager
Reschedule background jobs
Reschedule weekly backup on Ctrl-M
Drinks all round.
Vendors mentioned: dBase
Hope this helps.

Requirements for upgradation from 4.7 to ECC 6.0

Hi Guru's,
Can anybody explain what are the steps required for upgradation from 4.7 to ECC 6.0, technically and functionally. If any body have documents regarding the same, please share.Full marks will be awarded.thanx in advance....

Hi
You have to aware of all related program like BDC's , Screens related errors and all dictionary related problems.
Some function modules may become obsolete, and some screens will change
abnd some new fields will be added in the new versions etc.
Also take care of SPAU and SPDD tcodes.
You should be able to know about Unicode concept in sap.
chk this
http://www.thespot4sap.com/upgrade_guide_v2.pdf#search=%22upGRADE%20STEPS%20-%20SAP%22
also chk these 2 notes in service.sap.com
Technical Upgrade is only a version upgrade without any functionality changes.
The objects that are needed to be upgraded are:
Includes
Function Groups / Function Modules
Programs / Reports
OSS Notes
SAP Repository Objects
SAP Data Dictionary Objects
Domains, Data Elements
Tables, Structures and Views
Module Pools, Sub Routine pools
BDC Programs
Print Programs
SAP Scripts, Screens
User Exits
You can refer to the below links for more information on technical upgrade:
https://www.sdn.sap.com/irj/sdn/wiki?path=/display/profile/2007/05/07/upgradeFROMR3TOmySAPERP-PARTII&
https://wiki.sdn.sap.com/wiki/display/profile/UPGRADEFROMR3TOmySAPERP-PARTIII
http://help.sap.com/saphelp_nw2004s/helpdata/en/60/d6ba7bceda11d1953a0000e82de14a/content.htm
http://help.sap.com/saphelp_nw04/helpdata/en/2e/6d66647d9011d396b60000e82de14a/content.htm
https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/5ac31178-0701-0010-469a-b4d7fa2721ca
Reward points if useful
Regards
Anji

Implementing SAP EP as a Central Portal for mulitple R/3 ECC Backends

Hello
We are trying to implement an Incident / Occurrence Management Solution for a Company with 6 different subsidiaries who run their own SAP ECC Backends which are geographically located in different parts of the country.
The idea is to implement a central SAP Enterprise Portal for these different subsidiaries and we would like to know if anyone has done anything similar before. So the idea is that anyone from these 6 different geographically locations can log an incident on the central portal and the data will be then updated on their own divisional ECC Backend.
Currently the SAP ECC Backends are based on ERP2005.
The Company itself has an Central Active Directory solution in place and single sign on could be used for authentication. All the subsidiaries already use the central Active Directory for authentication.
Could anyone please let us know whether they have done something similar or have any reasons why this cannot be done and some potential issues that could arise for implementing a solution like this.
Some potential issues could be:
System aliasing
Network connectivity, bandwidth, availability issues
Patch alignment etc
Would there be other issues that one would consider?
Thank you kindly.

Hi,
I dont see any issues with such a landscape. You can have content for each of this location based of the systems they access.
As u have said bandwidth, network issues and roles assignment would be concerns as they would be in a single ecc backend connected portal
Regards
Jayesh

OSS notes relevant for FI/CO for upgrade from 4.7 to ECC 6.0

Hello,
I need the list of the applicable OSS notes relevant for the FI/CO module for upgrade from 4.7 to ECC 6.0
Thanks
Sid

Hi,
Please visit the following links:
http://service.sap.com/erp
http://solutionbrowser.erp.sap.fmpmedia.com/ (Functional prespective)
http://service.sap.com/instguides --> mySAP Business Suite Applications --> mySAP ERP --> mySAP ERP 2005 --> Upgrade
http://help.sap.com/printdocu/core/Print46c/en/data/pdf/LOVC/LOVC.pdf
For Functionality Differences pls refer to the below site -
http://solutionbrowser.erp.sap.fmpmedia.com/
After opening the site, please select the Source Release Version which is 4.6 b Then Select the Target Release Version which is "mySAP ERP 2005" or ECC 6.0
Select the Solution Area like Financials, Human Capital Management, Sales....
Select module like MM, PP, SD, QM.....
Click on Search
Then it displays the Release Version and the Delta Functionality. which can be downloaded to a word document if required.
and also check the release notes of ECC 6.0 in service.sap.com.
Hope this helps you.
Please assign points if it useful.
Regards
Ravinagh Boni

Does for upgrade from ecc 5.0 to ecc 6.0 we have to pay money for that

Hi All
Does for upgrade from ecc 5.0 to ecc 6.0 we have to pay money to SAP for that.

hi,
asking or teling ?
I think you need not as long as you are with official support . However please contact sap official support in you region

Hardware Rqmts for Upgrade 4.6C to ECC 6.0

We are replacing hardware and need round estimates of % increase to be expected for DASD, MEMORY, and PROCESSOR after upgrade from 4.6C ASCII to ECC 6.0 Unicode.
I thought I saw a thread on that in this forum but cannot find.
TIA,
Margie Teppo
Perrigo Company

Hi Peter,
> And for unicode additionally 30% CPU, 50% RAM and Disk 10-20%:
The first 2 are the official SAP figures for all platforms. The third is for iSeries. My experience, is for the third: 5-10%
The first 2:
CPU: +20-25% (as the DB server was on Unicode before already)
Memory: +25% (or less, as the most part of memory is used in the DB is this is on Unicode already)
but especially the CPU point is still true and pretty high with about 25%, because most of the CPU is taken in the appl server and that was pure ascii before.
Regards
Volker Gueldenpfennig, consolut.gmbh
http://www.consolut.de - http://www.4soi.de - http://www.easymarketplace.de

Features and Functionalities of ECC 6.0 for upgrade from 4.7 to ECC 6.0

Hi All,
Can you let me know the features and functionalities of ECC 6.0 as we are planning to go for upgrade from 4.7 to ECC 6.0...
Cheers
Prasanna

And you can see the PAM for your architecture.....
Do you want to use the JAVA instance?
Change from no-unicode to unicode?
Do you have MDMP?
Regards,
Alfredo.

Using Portal for streamlining transaction entry

Hello All
We have a client who would like to speak to a company that has used the portal as a "frontend" to transactional entry in ECC. This client is has a resource issue and has found that the transactions in ECC are far greater than their legacy system. If you have a cleint who has imploented such an approach and could speak to lessons learned, etc.. please let me know.
Thanks
Steve
<u>Notes from Customer:</u>
Issue:
The implementation of SAP has inundated the plants with a large number of transactions they did not have to perform previously. No resources have been added to help support this additional day to day transaction load.
Applications:
Active Ingredients Processing, PP, QM, SD
Primary Transactions:
Plan Production (MD01, MD04, MD06), Post Production (COR1/CORK & MFBF), Results recording (QE51n), Post Goods Issue & Post Goods Receipt (MIGO), Create PO & STO to Purchase Raw Mtls (ME21n), Create Deliveries (VL02n), ), Clear Backlog (COGI & MF47). Custom transactions for the following: MIGO 309 & 311 (ZMIGO), Expected Shipments (ZMM003) & Expected Receipts (ZMM004), Delivery Status (ZMM007), Goods Movement Report (ZPP001).
Background:
Prior to SAP production personnel had very few system transactions they were responsible for. Many plants had outmoded computers and poor network connections. The PC skill level varied tremendously from e-mail only capability to superuser. Each plant had their own manual process for tracking inventory, production planning, production recording, shipping, etc. Raw mtl ordering was done via phone call releases against blanket orders. Customer Orders simply showed up on the fax machine and were dealt with as time permitted. Any changes were communicated via phone or refax of change order. The only system data entry was the PGI of shipments which required only 4 or 5 pieces of information. This was done on a daily basis with relative ease since negative inventory was allowed.
Description:
The advent of SAP brought an upgrade to the hardware, software, network connections, and required a large increase in the average PC skill level. In addition, the plants have taken on a huge transaction burden compared to pre-SAP and are struggling to perform all of their required daily tasks (run plants and produce & ship product) and in addition execute all of the required transactions. The larger plants have bigger staffs and can better distribute and absorb some of this load, but the smaller plants have been hit the hardest.

Hi Nilesh,
Depending on the Scenario you need to decide what BAPI you will use. what solution are you excepting?
Regards
Shital

BI 7.0: Source System upgrade from R/3 Enterprise to ECC 6.0

Background:
I am relatively new to BW team and will be going through my 1st source system upgrade.
We currently have BI 7.0 SPS 17 connected to source system R/3 Enterprise EP1.
We are upgrading to the source system to ECC 6.0.
In Development and QA Environments:
we will have access to both old (R/3 Enterpirse) and the new (ECC 6.0) source systems.
We have a opportunity to compare the BW Objects, data flow and data loading from
both source systems.
In Production, however, we will just upgrade over 3 days downtime.
One Question that comes to mind in this regard...
What sort of things, we should be checking for before and after upgrade in Dev/QA and in Prod environments and what tools are available that can help the analysis and validation process ?
Some of the suggestions that were given to me include following points.
Before Upgrade:
1 Check data, taking pre images of it for testing with post upgrade.
2. Perform proper analysis of Source system related BW objects.
- A complete listing of actively used Datasources,.. etc.
3. Make delta queues empty,
Make sure that all existing deltas are loaded into BW.The last request delta must not deliver any data and must be green in the monitor.
4. Stop Process chains from BI (remove from schedule) and collection runs from R/3 side
After Upgrade:
1 After the OLTP upgrade, refer to note 458305 and other notes that are relevant to the actual upgrade
(depending on the R/3 system release / R/3 plug-in to BI plug-in compatibility).
2. Check logical system connections. Transactions SMQS, RSMO and SM59, If no access, then we can use Program RSRFCPIN_NEW for RFC Test.
3. Check and/or Activate control parameters for data transfer. SBIW ---> General Settings --->
Maintain Control Parameters for Data Transfer
http://help.sap.com/saphelp_nw70/helpdata/EN/51/85d6cf842825469a51b9a666442339/frameset.htm
4. Check for Changes to extract structures in LBWE Customizing Cockpit
- OSS Notes 328181, 396647, 380078 and 762951
5. Check if all the required transfer structures are active. See OSS Note 324520 for mass activation.
7. Check if all Source system related BW Objects are active - Transfer rules, Communication rules, update rules,DTPs,..etc.
Below is a link for some useful programs in this regard.
https://www.sdn.sap.com/irj/scn/wiki?path=/pages/viewpage.action&pageid=35458
6. Test all important datasources using RSA3 and check for OLTP Datasources changes .
As soon as BW notices that the time stamp at the DataSource in the OLTP is newer than the one in the transfer structure, it requests replication of the DataSource and activation of the transfer structure. Transfer the relevant DataSources only if required, and transfer only the ones that have changed (RSA5 -> Delta).
7. Create Data flow objects (trnasfer rules, infopackages, trnasformations, DTPs) for the Replicate
new/changed datasources,if needed.
8. Check all CMOD enhancements.
If we are using a customer exit with the extractor in the OLTP, see Note 393492.
7. Check for unicode (all custom programs or Function Modules for DataSources)
5. Check all the queues in RSA7, start delta runs and test data consistency.
For delta problems:In the BW system, start the 'RSSM_OLTP_INIT_DELTA_UPDATE' program for the DataSource and the source (OLTP) system for which the init selections are then transferred from BW into the ROOSPRMSC and ROOSPRMSF tables in the source system so that the delta can continue.
9. Take back up of data posted during upgrade for contingency planing.
10. Run the entire set of process chains once if possible and let it pick up no data or the usual master data.
Since we have lot of experts in this forum, who have probably gone through such scenario many times, i wanted to request you to Please Please advise if i have stated anything incorrectly or if i am missing additional steps, OSS Notes, important details...

Thanks Rav for your detailed post and very helpful contribution by posting all the information you had regarding the upgrade.
We have similar scenario -
We are upgrading our source system from 4.7 to ECC 6.0. We have our BI system with BI 7.0 at support pack 19 (SAPKW70019).
Our strategy in ECC deployment ->
In development we copied our old DEV 4.7 system DXX to new ECC system DXY (new system ID).
In production we are going to use same system PRXX upgraded from 4.7 to ECC.
Now we are in testing phase of ECC with all interfaces like BI in Dev.
My questions are below ->
How can we change/transfer mapping of all our datasources in Dev BW system BID to new ECC dev system DXY (Eg. Logical system LOGDXY0040) from Old dev system DXX (Eg. Logical system LOGDXX0040). We donot want to create new datasources or change all transfer rules/Infosources for old BW3.x solutions on our BI.
Also in new ECC sourcesystem copy we see all datasources in Red in RSA7 transaction. Do we need to initialize again all the datasources from our BW BID system.
Is there any easy way for above scenario ?
Please let me know if you have any further helpful information during your ECC 6.0 upgrade connecting to BI 7.0 system.
I have found some other links which have some pieces of information regarding the topic -
Upgrade R/3 4.6C to ECC 6.0 already in BI 7.0
http://sap.ittoolbox.com/groups/technical-functional/sap-bw/sap-r3-migration-and-sap-bw-version-1744205
BI 7.0: Source System upgrade from R/3 Enterprise to ECC 6.0
Re: ECC 6.0 Upgrade
Re: Impact of ECC 6.0 upgrade on BI/BW Environment.
ECC 5.0 to ECC 6.0 upgrade
Thanks
Prasanth

Is there a central note available yet for Upgrading to NW 7 EHP 5?

Hi all,
I'm trying to find out if there is a central note available for upgrading to NW 7 EHP5.
I have note 1299009 which is the central note for upgrading to NW 7 EHP 2 but I'm trying to find one for EHP 5 specifically (if it exists at all).
The reason I'm keen to find this is because note 1299009 refers to downloading various software patches and fixes before starting your upgrade and it tells you the versons of the files you need, but it is specific to EHP2 and its not at all obvious which files to use if you are going to EHP 5 (or does it even matter?).
For example, you need to download the latest patch for SAPup. The oss note mentione for EHP 2 to use the 7.02 version. Logically it would follow that there might be a 7.05 one for EHP5? No there isn't, you just get 7.00, 7.01, 7.02, 7.10, 7.11 and 7.30 - how do you know which to use for EHP 5? (or is it just 7.02 still?). The current version of SAPup that comes on the DVD is 7.00/3. Hopefully you can see why I am confused.
The same is true for the correction needed for the upgrade package. The suggested one in the note refers to FIX_ NW02.UPG. On OSS the availble ones are the same as above (nothing with a 5!).
Any help appreciated.
Regards
Claire
Edited by: Claire Richards on Dec 15, 2011 12:23 PM

Dear Claire,
Let me clarify your doubts here.
There is no EHP5 for NW 7.0 yet. Its EHP5 for ECC 6.0 which brings in NW 7.00 EHP2 along.
ECC 6.0 uses NW 7.0 architecture and also note that NetWeaver 7.0 is also available as a independent product.
Now if you are having NW 7.0 as your product version then you need to apply EHP2 of NW on it to be on 702 release.
But if you are having ECC 6.0 as your product version then you need to apply EHP5 of ECC on it to be on 702 release which would also make 605 release for all other application components.
For ECC 6.0 EHP5 kindly refer the following SAP Notes:
1302772 - Central Note - SAP Enhancement Package Installer 7.00
1298878 - Installation of SAP Enhancement Package 5 on SAP ERP 6.0
I hope i could clarify your doubts.
Regards,
Abhishek

9.0.2.6 Portal Repository Upgrade Patch problems.

We got some problem with Portal when tryed to apply
9.0.2.6 Upgrade. Could anybody give advice on this issue:
Initial configuration:
Solaris8, Portal 9.0.2.2.14, Oracle 9iAS R2 v.9.0.2.0, RDBMS 9.0.1.3. The infrastructure and midtier work on different SPARC-servers.
Accordingly upgrade procedure we succesfully applied:
a) Infrastructure: 9.0.1.4 Patchset for Oracle RDBMS server, 9.0.2.2 Patchset for OID, Oracle 9iAS SSO-server
migration to 9.0.2.5, 9.0.2.2 Patchset for 9iAS Core.
b) 9.0.1.4 Patchset for Oracle RDBMS server, 9.0.2.2 Patchset for OID, Oracle 9iAS SSO-server migration to 9.0.2.5, 9.0.2.2 Patchset for 9iAS Core, Portal 9.0.2.6
patch.
After this we needed to make just one last step:
Portal 9.0.2.6 Repository Upgrade Patch (2981297) for
changing Portal's repository schemes. It worked but
like a result we got the next errors after patch upgrade
was done:
a) "The following invalid non-Portal objects exist in the Portal Schema: INDEX ABC (the name of portal object), PACKAGE BODY WWMON_REP_REPOSITORY, PACKAGE BODY WWMON_REP_REPOSIT_DTL, PLS-00103: Encountered the symbol "," when expecting one of the following: (-+case mod not null <an identifier>,...) The symbol "null" was substituted for "," to continue.)" See upgtmp/nonportal.log
b) "ERROR: 1 invalid objects remain; ERROR: Failed while updating the new portlet IDS..."
c) "ERROR: ORA-01407: cannot update ("PORTAL"."WWSBR_URL$"."URL") to NULL.
d) Two package body of packages at PORTAL scheme became invalid: WWMON_REP_REPOSITORY, WWMON_REP_REPOSIT_DTL. About 20 package body of packages at PORTAL_DEMO became invalid (It seems like initial portlet ID's disappeared
and except of pportlet_id there is nothing:
Example:
inital statement at body:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
PORTAL.wwpro_api_invalidation.invalidate_cache(
p_provider_id => p_provider_id,
p_portletid => 1065753336,
p_instance_id => p_reference_path,
p_subscriber_id => PORTAL.wwctx_api.get_subscriber_id ,
p_user => PORTAL.wwctx_api.get_user);
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
after upgrade repository patch:
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
PORTAL.wwpro_api_invalidation.invalidate_cache(
p_provider_id => p_provider_id,
p_portletid => ,
p_instance_id => p_reference_path,
p_subscriber_id => PORTAL.wwctx_api.get_subscriber_id ,
p_user => PORTAL.wwctx_api.get_user);
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Like a result after 9.0.2.6 Portal Repository Upgrade Patch application we lost the possibility to edit user's
profiles at Portal and other nesessary features. It seems
like some portlet ID's just dissapeared from Portal scheme. Could anybody had the same problem with Portal Upgrade 9.0.2.6? Quite possible that we missed some important element at during upgrade but ,really, we didn't wait so unlucky result. Advice something, please...
Regards. Igor.

Igor,
Since you've encountered undocumented errors, your repository upgrade has failed. You'll want to leave the repository as is for troublshooting, if at all possible, and log a TAR with support if you haven't already. They'll ask you to upload your upgrade log file and your upgrade tmp directory.
Regards

Connection SEM 4.0 and BW 3.5, after upgrade R/3 4.6C to ECC 6.0

Hello experts,
Currenctly my customer has the following systems:
BW 3.5 with software component SEM 4.0
R/3 4.6C without software component SEM
ECC 6.0 with software component SEM 6.0 (Development system, I cannot connect the BW system to this one!)
Next week my customer is going to upgrade R/3 4.6C to ECC 6.0 (Test system).
I have to investigate if this upgrade does not influence the communication between SEM 4.0 and BW 3.5, if I connect BW 3.5 to ECC 6.0.
According to the blog: /people/karen.comer/blog/2006/12/19/confused-about-business-planning-releases-between-sap-sem-and-sap-netweaver-bi
SAP SEM is an add-On on top of SAP BW / SAP NetWeaver BI.
This blog also states that:
SEM 4.0 should work with BW 3.5
SEM 6.0 should work with Netweaver 2004s (BW 7.0)
Now I have the situation that software component SEM 4.0 is installed in BW 3.5, and SEM 6.0 is integrated in ECC 6.0 because it is part of Netweaver 2004s.
Does anyone know if the upgrade to ECC 6.0 has influence to the connection between BW 3.5 and SEM 4.0??
Tnx for your help!
G.

>
Markus Taxacher wrote:
>Is the only possible way to migrate the BW 3.5 to ERP/ECC 6.0?
> Whats the easiest way for upgrading to 6.0?
>
> Best regards,
> Markus
Hi, you cannot use BW3.5 you must have BI7 (not ECC6!) to install BCS 6 - BCS sits on BI (formerly known as BW).
It doesn't matter what version of source system you have, you can still collect data from ERP 4.6, you don't necessarily need ECC6.

Impact in portal for Upgrade ECC 5.0 SP04 to ECC 6.0

Similar Messages

Maybe you are looking for