How to migrate 'responsibility' level personalizations?

Hi all,
We have done a set of personalizations at responsibility level in our UAT instance.
We have no problem migrating the 'site' level personalization. We use the 'Functional Administrator' -> Import/Export utility.
But, We find that the responsibility level personalizations are stored under a folder hierarchy as below:
Eg:
Responsibility: XXRecruitment Manager
Responsibilty Key: XXRECRUIT_MAN
Responsibility ID: 50977
Personalization is exported in this folder:
/oracle/apps/per/irc/vacancy/webui/customizations/responsibility/50977/RectrDetsRN
It is stored under a folder '50977' corresponding to the responsibility id of the responsibility that we personalized.
Our problem is, the responsibility id's and responsibility key's are different in UAT and production instances:
Responsibility: XXRecruitment Manager 01
Responsibilty Key: XXRECRUIT_MAN_01
Responsibility ID: 50900
Now, how to migrate such personaliations? Our client have personalized atleast 25 pages at various responsibilty levels. Please suggest a suitable way to migrate these personalizations.
thanks in advance,
Hem

Hem,
We had the similar discussion in past once, but I guess the user didn't update the final results. As far as I think, 'Functional Administrator' -> Import/Export utility should be handling this scenario.
Did you try it atleast on one such responsibility level personalization?
--Shiv

Similar Messages

How to Migrate Row Level Security Configuration

Hi Guys,
Does anybody know how to migrate row level security configuration? I suppose PeopleSoft provided a data mover script, like securityexport.dms.
Thank you in advance,
Bob

Here are two options to achieve what you want.
A. You can do this by coding, that's if you are ready to. Are you? If yes then try the steps below:
1. create a security codes table. Say for example
001 - company a
002 - company b
2. create a security table that will list all users and which company they should have access to. You can also implement this by roles.
3. alter all tables in the application schema to add a security code column. This will be a foreign key reference to table created in 1 above.
4. update all data in the tables according to which company they belong to.
5. write a procedure or package that does a validity check whenever a user requests for data. This procedure/package determines which company data the user has access/rights to.
With this, you should be able to achieve what you want if you do not want to spend on VPD and FGAC. The problem comes where there are users who would have cross access to data from both companies. In this regard, then you have to modify your security table a little bit to handle this.
B. This option i will admit is not so clean. You can also achieve this by two different views for every table in the application schema. And on each of these views, create a private synonym for every user. For illustration purposes:
Table name = Employee.
Create a view employee_a on employee
create a view employee_b on employee
Let's say you have users x and y. X has access to employees of company a and y has access to employees of company b. You can now create private synonyms for each of these users as follows:
create synonym employee on employee_a in x schema.
create synonym employee on employee_b on y schema.
This i have not tried but believe should work.
Hope one of these options serve your purpose.

Exporting/importing Responsibility-level personalizations

Hello,
Suppose on one instance I have done some personalizations for responsibility A and I want to apply these personalizations on another instance, but there is no responsibility A on another instance, but instead its name is B.
Does export/import mechanism has support for this kind of requirement.
- Yora

Yora,
Does export/import mechanism has support for this kind of requirement.No, they don't have any functionality like this.
For much more information on this refer http://apps2fusion.com/apps/14-fwk/215-move-oa-framework-personalizations-from-one-environment-to-another
//Note Taken from Above Link -- Anil Passi
You have done responsibility level personaliation for OAF Pages, for this resp.
Issue:- When you extract the personalizations, the directory path of extracted personalizations will contain the responsibility_id
However, the same responsibility when created on TEST SYSTEM might be allocated a responsibility_id of 1088.
Hence, you referring to ***** in notes above, you will have to rename the directory from 1032 to 1088. This can be scripted too in Unix.
To overcome this issue:-If you wish to perform responsibility level personalizations against a custom responsibility, first create
this responsibility on production, and get this cloned to other environments. Alas, such forward planning rarely happens in projects.
Blame this on Oracle’ design. They could have easily used RESPONSIBILITY_KEY/APPLICATION_ID in the path, instead of using RESPONSIBILITY_ID. Regards,
Gyan

How to read responsibility level profile in forms personalization r12.1.3

All, I have one custom profile option at responsibility level. I am wondering if I can read that value in WHERE CLAUSE of a WHEN_VALIDATE_RECORD trigger?
I am trying to access responsibility level profile option using "${ps.up_prior_gl_period_allow.VALUE}". But, it doesn't seem to work.
However, I am able to read site level profile option using "${ps.up_prior_gl_period_allow.VALUE}".
Please help.

Have you tried using fnd_profile.get_specific()?

HOW TO MIGRATE DUNNING LEVEL & LAST DUNNED DATE FOR ALL OPEN LINE ITEMS

Hi,
We need to upload dunning level & last dunned date for all open items (to be done separately i.e. after all open items migrated) which is different for each and every line item so if we use mass upload (fbl5n) we have to do for each and every open line item which is not feasible as open line items in thousands..I tried LSMW also,problem is that for Batch input recording we need to run one complete cycle in sm30 but there is no maintenance dialog for BSEG & BSID table.. Please share your valuable Inputs how we can go ahead..
Thanks in advance

Hi Mark,
Thanks for your reply.
It is complete a Zcopy of a standard one, but we are facing one or two records are not updating correctly out of hundreds of customers in the worklist.

Personalize Page: How to add an item to Responsibility level

It seems not possible to add an item to a page on responsibility level through page personalization.
Therefore, I went Site level and it allows me to add an item. I was thinking I may hide (rendered=false) this item on site level and then personalize this item on the Responsibility level to show (rendered=true).
However, I'm not able to see this item on the Responsibility level. did I miss something?
Thanks

Open Newsstand. Tap on the "Store" button in the upper right. Any newspaper or magazine you download from the store will appear in Newsstand.

How to make personalaization at responsibility level

Hi All,
I Apologized, I have posted same thread in other place also so plz ignore that post.
I have number of responsibilities for internet procurement responsibility like internet procurement - 1200 , internet procurement - 1300 , internet procurement - 1250 , internet procurement - 1350 ,and so on...
Now I want add a link on the checkout : requisition information page only for some responsibilities.How can I do this?
When I am try to create a new item from personalization and want to select level then it only showing Site level and not others like responsibility level..
Thnaks,

1)Create Link Item on site level in requisition information page by personalization.
2)Go to internet procurement - 1200(Responsibility) -->requisition information page(Page).
3)Click on Personalize link of requisition information page.
4)Check newly created Link Field. Click on Yellow Pencil Icon in Personalize column.
5)Set Render Property False at Responsibility Level.
6)Click on Apply Button
Do Same For other responsibilities
Thanks,
Dilip

URGENT:Copying Personalizations from Site Level to Responsibility Level

Hi All,
We have created quite a many Personalizations at the Site level for our Instance. Now we release that if we have them created at the responsibility level we would have more flexibility.
Can any of you let me know in case , there is any way to move the personalizations created at the site level to Responsibility level?
Thanks,
Priya

Hi Mani / Anil,
Thanks for your responses.
I copied the site level personalization Tags from the site level xml document and put it in the Responsibility level document and removed those personalizations from site level as well and it is workign fine.
Just I have one more question to this. Going forward how do I create the items ( Create Personalized Items) at the Responsibility level.
B'coz when I create a Stack Layout Item , I can only create it at site level. But if I want this to be available only to some Resposinbilities and not to all then how do I do it?
Thanks,
Priya

Personalization at Responsibility Level

Hi ,
I am trying to personalize the display of "Worklist Notification" in Home page based on the responsibility of the user logged in . I have choosen the reqd. responsibility in the responsibility context chooser and did personalize the "Stack Layout: Notifications Worklist Function" at responsibility level. Everytime I login the context of the responsibility changes and my personalization does not work . If I manually go and change the responsibility context to the responsibility I want I am able to see the "Worklist Notification" list .
I would like to know if there is way I could make sure that the responsibility context does not change everytime a user logs in . Any replies will be greatly appreciated .
Thanks,
Chandu

Hi,
Sorry my mistake, if your responsibility is not the context it cannot pick up the XX_WORKLIST Permission from your Menu. You must use Functional Administrator Grants instead,
Try this:
delete your XX_WORKLIST function from the menu and from the system
1) Functional Administrator > Permissions
Create new permission:
XX_WORKLIST
2) Functional Administrator > Permission Sets
Create new permission set:
XX_WORKLIST_PS
- add the XX_WORKLIST permission
3) Functional Administrator > Create Grant
Name: XX_WORKLIST_GRANT
Grantee Type: Group of Users
Grantee: 'Your Responsibility' (e.g. System Administrator - FND_RESP|SYSADMIN|SYSTEM_ADMINISTRATOR|STANDARD)
Operating Unit: leave blank
Responsibility: leave blank
NEXT
Permission Set: XX_WORKLIST_PS
SAVE
- you will have now granted the XX_WORKLIST permission to any user with 'System Administrator'
4) Functional Administrator > Core Services > Caching Framework > Global Configuration > Clear Cache
Clear the Cache
Personalise your worklist (e.g. Row Layout: Home Content Row) at Site level with SPEL:
${oa.FunctionSecurity.XX_WORKLIST}
I have tested this in my 11.5.10 environment and it worked. All users with 'System Administrator' see the worklist, all others do not.
Regards,
Mike

How to get profile options & values at user & responsibility level by SQL?

Experts, How to get profile options and values at user and responsibility level using SQL?

SELECT
po.profile_option_name as name
, po.user_profile_option_name
, decode(to_char(pov.level_id),'10001','SITE','10002','APP','10003','RESP','10005','SERVER','10006','ORG','10004','USER', '???') as "LEVEL"
, decode(to_char(pov.level_id),'10001','','10002', app.application_short_name,'10003', rsp.responsibility_key,'10005', svr.node_name,'10006', org.name,'10004', usr.user_name,'???') as context
, pov.profile_option_value as value
FROM
fnd_profile_options_vl po
, fnd_profile_option_values pov
, fnd_user usr
, fnd_application app
, fnd_responsibility rsp
, fnd_nodes svr
, hr_operating_units org
WHERE 1=1
AND pov.application_id = po.application_id
AND pov.profile_option_id = po.profile_option_id
AND usr.user_id (+) = pov.level_value
AND rsp.application_id (+) = pov.level_value_application_id
AND rsp.responsibility_id (+) = pov.level_value
AND app.application_id (+) = pov.level_value
AND svr.node_id (+) = pov.level_value
and org.organization_id (+) = pov.level_value
ORDER BY 1, pov.level_id, 5
You'll need to apps initialize your SQL session before running this ...
Regards,
Jon

How to migrate the Objects from 3.1c to BI7

Hi,
We are in Functional Upgradation.
How to Migrate the Objects( Infocubes,DSO,Datasources,Rules...etc...) from 3.1C to BI 7.0
Please help me to doing this....
regards,
anil

BW Upgrade tasks (BW 3.1C to BI 7.0)
Prepare Phase:
Task     How-To     Who
Review BI 7.0 feature lists     Review BI 7.0 feature lists for possible inclusion in developments.     Basis/BW
Obtain the BI 7.0 upgrade guide     Download the upgrade guide from http://service.sap.com/inst-guides -> SAP NetWeaver -> Upgrade
     Basis/BW
Review all upgrade SAP notes     In addition to the upgrade guide, check, download, and review all SAP notes for your upgrade
     BI 7.0 Upgrade notes
     SAP Web Application Server 6.40 upgrade notes
     OS and DB specific upgrade notes
     SAP BW Add-on upgrade notes
(e.g. SAP SEM, ST-PI, etc)
     Plug-In upgrade SAP notes
     Other notes identified in above notes and/or upgrade guides.
     Basis/BW
Check DB and OS requirements for the target SAP BW release     Check DB version/patch level and OS version/patch level required for upgrade
     First check the most current information from the SAP BW homepage http://Service.sap.com/BW -> <SAP BW release> -> Availability
     Additionally, the u201CPlatformsu201D link will take you to the main DB/OS page for BI 7.0 and SAP Web AS 6.40.
     Note: In some cases there are differing requirements for SAP BW 3.0B/SAP BW 3.1 Content and BI 7.0
     Basis
Check SAP BW Add-on upgrade requirements     Do you have SAP BW add-ons installed that require additional handling (e.g. SAP SEM, Enterprise Portal Plug-in, etc)?
     SAP SEM (SAP BW based components) requires SAP SEM 4.0 which is part of the mySAP ERP 2004 suite.
     WP-PI release must be at 6.00 before the upgrade begins. As mentioned before this add-on is merged with PI_Basis after the upgrade.
     Basis
Check SAP BW upgrade requirements          Minimum Support Package and kernel levels for upgrade
     SAP BW Frontend requirements for new SAPGUI, SAP BW BEx Frontend and SAP BW Web applications.
     Source system Plug-In requirements     Basis
Check compatibility requirements with 3rd party software          3rd Party Reporting tools (example: Crystal)
     ETL Tools (example: Ascential, DataStage, etc)
     Scheduling tools (example. Control-M, Maestro, etc)
     Monitoring tools (example: HP OpenView, Patrol, etc)
     Other OS or DB related tools     Basis
Check new component requirements for BI 7.0          If SAP BW web reports were developed in SAP BW 2.x, a windows version of IGS 6.40 (Internet Graphics Service) is required for conversion and future rendering of web graphics (i.e. Charts and GIS Maps).
The IGS chart migration will also be required after the SAP BW web report conversion.
     If you used or activated any SAP BW Web Applications in SAP BW 3.x, or if you have used charts in SAP BW 2.x web reports, you will need a windows version of IGS 6.40 (Internet Graphics Service) to execute the IGS chart migration after the upgrade.
     If ESRI GIS software is in use, a different version of ESRI software maybe required for BI 7.0. (ArcView 8.2?).
     If you plan to use Information Broadcasting, please review the requirement for additional infrastructure components such as EP, KMC, Workbook pre-calculation service, and Web AS connectivity to your mail servers.
Detailed information is available in the SAP NetWeaver u201904 master planning guide (http://service.sap.com/instguides -> SAP NetWeaver).
     Basis
Test and distribute new SAP BW Frontend
          Install and test the new BI 7.0 Frontend (including the new version of SAPGUI for Windows if applicable).
     A detailed FAQ on the new BI 7.0 Frontend is available on the SAP service marketplace alias BWFAQ (http://service.sap.com/BWFAQ).
     After successful testing, the new SAPGUI for Windows and SAP BW Frontend can be distributed to the BW teams and end users.
     Basis
Alpha Conversion:
Ensure that your InfoObject data is consistent from a u201Cconversionu201D perspective (Alpha Converter tool)      Check that you have executed the Alpha Converter tool to check the consistency of your InfoObject definitions and data for InfoObjects that utilize the ALPHA, NUMCV and GJAHR conversion exits.
Note: The Alpha conversion is not part of the SAP BW upgrade itself, but the upgrade simply checks to ensure you have successfully executed the check tool.
Transaction RSMDCNVEXIT
Check the system status:
     u201CAll Characteristics Have Correct Internal Valuesu201D: The Alpha converter has been successful executed. The upgrade preparation can continue.
     u201CNo Check yet/Inconsistent Internal Vales existu201D:
The Alpha converter check has not been executed.
     u201CCharacteristics have Inconsistent Internal Valuesu201D:
The Alpha converter tool check has been executed and data problems have been detected. The InfoObject and data must be processed before the upgrade can be started.
     BW
Upgrade SAP Note updates     Check for newer versions of your SAP notes for the Upgrade.
Tip: The SAP service marketplace offers an option to subscribe to OSS notes so you can be notified of changes when you log on.
     Basis/BW
Confirm SAP BW support package, kernel and DB/OS configuration     Analyze current Support Package and DB/OS/Kernel configurations in your SAP BW landscape in relation to the SAP BW 3.x upgrade requirements.
     Apply necessary support packages, kernel patches, and DB and OS patches to meet upgrade requirements
     Basis
Alignment of SAP BW objects within your SAP BW system landscape     Check and, where required, re-align SAP BW Objects and developments in your SAP BW system landscape (Development, Quality Assurance and Production).
SAP BW Object differences can impact the quality of testing in the Development and Test environment and can lead to change management issues.
     This check is to minimize risk and ensure productive objects are being tested prior to the Production upgrade.
Where alignment issues exist and realignment is not possible, alternative testing plans should be devised.
     Basis/BW
Confirm all developments are deployed.     Ensure that all SAP BW developments are deployed or they are to be re-developed/tested after the upgrade.
     In the DEV system, all SAP BW development transports should be released (i.e. transport created and released) and imported to all downstream systems (i.e. QAS and PRD systems).
For SAP BW developments not already collected in the transport collector, a decision must be made:
Deploy the developments or wait until the upgrade has completed to deploy.
o     Development to be deployed should be collected, released, and imported into the QAS and PRD systems.
o     Developments that should be deployed after the upgrade should be re-tested/re-developed after the upgrade.
     In the QAS or PRD systems, ensure that all SAP BW development transports have been imported prior to the upgrade.
     BW
Implement BI 7.0 Business Explorer Frontend     Install, evaluate, test and distribute the new BI 7.0 Business Explorer Frontend.
     Basis/BW
Pre-upgrade Process:
Download required BI 7.0 support package Stack for inclusion in the upgrade     Determine the equivalent support package level of the source SAP BW release and the target SAP BW release.
     There is a minimum requirement that you upgrade to at least the equivalent support package level on the target SAP BW release so that you do not lose functionality, corrections, and data.
     It is recommended to upgrade to the latest version of all support packages during the upgrade via the upgradeu2019s support package binding functionality.
     BI 7.0 Support Packages are delivered via SAP NetWeaver u201904 Support Package stacks (SP-Stacks). It is not recommended to partially apply some of the SP-Stacksu2019 individual support packages. You should apply all of the SP-Stacks support packages at once.
For more information on the SP-Stacks and SAP NetWeaver SP-Stacks, please see the SAP service marketplace alias SP-Stacks (http://service.sap.com/sp-stacks)
     You should also review, download, and bind in support packages for all add-on components that are installed on SAP BW and will be upgraded during the SAP BW upgrade (e.g. SEM-BW, ST-PI, etc)
     Basis
Apply latest Support Package tool patch     Apply latest SPAM patch before executing PREPARE     Basis
Validate the SAP BW (ABAP) Data Dictionary and the Database Data Dictionary for consistency     Check Database consistency
     Transaction DB02:
o     Execute ABAP SAP_UPDATE_DBDIFF and re-execute DB02 check. This gives a truer view of the SAP BW objects in DB02.
o     Check missing database objects (indices, tables, etc)
o     Missing indices may identify erred data loads or process problems
Tip: Missing indices on InfoCubes can be restored by RSRV or ABAP SAP_INFOCUBE_INDEXES_REPAIR
Note: check for running data loads before executing a repair!
o     Check DDIC/DB consistency
     Verify database objects and consistency
(e.g. SAPDBA check for offline data files)
     BW
Remove unnecessary SAP BW temporary database objects     Delete all SAP BW temporary database objects:
     Execute routine housekeeping ABAP SAP_DROP_TMPTABLES.
     This reduces the numbers of database objects that need to be copied during the upgrade.
     Note: take care not to delete objects that are in use as this will cause queries, compressions, etc to terminate.
     BW
Validate your SAP BW Objects for correctness prior to your upgrade     Using the SAP BW Analysis Tool (transaction RSRV), perform extensive tests on all important SAP BW Objects to ensure their correctness prior to the upgrade.
Note: this test should be repeatable so you can re-validate after the upgrade!
     Ensure that any inconsistencies are identified and corrected
     RSRV has a number of extensive tests and if all checks are executed will consume a large amount of time. Multiple tests can be performed in parallel.
     Tip: Some corrections in development can be deployed to other systems via transport in advance of the next upgrade.
     BW
Ensure DB Statistics are up to date prior to the upgrade          Check DB statistics for all tables.
Tables without statistics, especially system tables, can seriously impact upgrade runtimes.
     Check DB statistics for missing Indexes for InfoCubes and Aggregates
o     User transaction RSRV to check      BW
Check SAP BW Support Package status     Check the status of all support packages (via transaction SPAM)
     Ensure the Support Package queue is empty
     Confirm all applied Support Packages     Basis
Check all u2018Repairsu2019     Check for unreleased repair transports
     Release all unreleased transports
In your QAS and PRD system, check if all repair transports have been imported (i.e. systems are aligned)
     Import missing repair transports into down stream systems. This will avoid differing message and/or errors during the upgrade.
     BW
Check InfoObject status          Check for revised (modified) InfoObjects that have not been activated.
All InfoObjects should be active or saved (not activate):
o     Check all inactive InfoObjects:
Transaction RSD1 (Edit InfoObjects),
click on u201CAll InfoObjectsu201D radio button and click the u201CDisplayu201D button.
Modified InfoObjects are denoted by yellow triangles!
o     Determine if revision should be activated or removed.
     'Reorgu2019 or u2018Repairu2019 all InfoObjects
This checks and repairs any discrepancies in the InfoObject definition and structures. It is common to have obsolete DDIC and table entries for InfoObjects after multiple upgrades and definition changes. These obsolete entries normally do not effect normal SAP BW operations.
     Transaction RSD1 (Edit InfoObjects), Select u201CExecute Repairu201D or u201CExecute Reorgu201D Use expert mode for selective executions.
     BW
All ODS data loads must be activated.          Activate all inactivated ODS Object requests.
All ODS u2018Mu2019 tables must be emptied prior to the upgrade as a new activate process is implemented
o     Inactivated ODS request can be located via the Admin workbench -> u2018Monitoringu201D button -> u2018ODS Status Overviewu201D
     BW
All Transfer and Update rules should be active          Check for inactive Update and Transfer Rules
o     All update rules and transfer rules should be active or deleted.
o     Look into the table RSUPDINFO for update rules and search for the version "not equal" to "A". Likewise use the table RSTS for Transfer rules/structure.     BW
All InfoCubes should be active          Check for inactive InfoCubes and Aggregates (Aggregates are InfoCubes too!)
o     All InfoCubes should be activated or deleted.
o     Execute ABAP RSUPGRCHECK to locate any inactive InfoCubes. See SAP note 449160.
     BW
All Web Report objects should be consistent prior the upgrade.          Check the consistency of your SAP BW web objects (web reports, web templates, URLs, roles, etc). All objects should be consistent prior to web object conversion after the upgrade. It is recommended to ensure consistency before the upgrade.
o     For Original release SAP BW 3.x:
A SAP BW web reporting objects check can be executed via a new check in RSRV. This is provided via a SAP BW support package.
Please see SAP note 484519 for details.
     BW
Backup your system before starting PREPARE     Before execution PREPARE, perform a full database backup (including File system). Ensure you can recover to the point in time before PREPARE was executed.
     Database admin
Address any instructions/errors generated by PREPARE          Address any issues listed in log files Checks. Log generated by PREPARE.
o     Repeat PREPARE until all checks are successful.     Basis
Complete any Logistic V3 data extractions and suspend V3 collection processes          Extract and empty Logistics V3 extractor queues on SAP R/3 source systems.
o     The V3 extraction delta queues must be emptied prior to the upgrade to avoid any possible data loss. V3 collector jobs should be suspended for the duration of the upgrade.
They can be rescheduled after re-activation of the source systems upon completion of the upgrade.
     Note: If you perform any data loads after executing PREPARE, re-check the status of all delta queues in SAP BW and the source systems(s).
     BW
Complete any data mart data extractions and suspend any data mart extractors          Load and Empty all Data mart Delta Queues in SAP BW. (e.g. for all export DataSources)
o     The SAP BW Service SAPI, which is used for internal and u2018BW to BWu2019 data mart extraction, is upgraded during the SAP BW upgrade. Therefore, the delta queues must be emptied prior to the upgrade to avoid any possibility of data loss.
     Note: If you perform any data loads after executing PREPARE, re-check the status of all delta queues in SAP BW and the source systems(s).
     BW
Check that your customer defined data class definitions conform to SAP standards          Check all customer created Data classes used by SAP BW Objects (i.e. InfoCubes, ODS Objects, Aggregates, InfoObjects, and PSAs) to ensure they conform to SAP standards.
o     Check your data class definitions as detailed in SAP Notes 46272 and 500252.
o     Incorrect data classes could create activation errors during the upgrade.
     BW
Remove unnecessary SAP BW temporary database objects     Delete all SAP BW temporary database objects:
     Execute routine housekeeping ABAP SAP_DROP_TMPTABLES.
For more information see SAP note 308533 (2.x) and 449891 (3.x).
     This reduces the numbers of database objects that need to be copied during the upgrade.
     Note: take care not to delete objects that are in use as this will cause queries, compressions, etc to terminate.
     Basis/BW
Backups!     Before executing the upgrade, ensure that you have a backup strategy in place so you can return to the point where loading was completed and the upgrade started.
Ensuring you can return to a consistent point in time (without having to handle rollback or repeats of data loads) is key to having a successful fallback plan.
     Database Admin
Before Execution:
All SAP BW administration tasks should have ceased          Cease all SAP BW administration tasks such as Object maintenance, query/web template maintenance, data loads, transports, etc at the beginning of the upgrade.
The Administrators Workbench and the Data Dictionary are locked in the early phases of the upgrade.
     Reminder: Users can execute queries until the time that the upgrade determines that the SAP BW System should be closed*
- timing depends on the type of upgrade selected
     Basis/Admin
Remove unnecessary SAP BW temporary database objects     Repeat the deletion of all SAP BW temporary database objects after you have stopped using the SAP BW Admin workbench*
     Execute routine housekeeping ABAP SAP_DROP_TMPTABLES.
For more information see SAP note 308533 (2.x) and 449891 (3.x).
- timing depends on the type of upgrade selected
     BW
Check system parameters     Check OS, DB, and Instance profile parameters.
     Check System Instance parameters for new BI 7.0 specific parameters. See SAP note 192658 for details
     Check for any DB specific parameters for BI 7.0
     Check for any new OS parameters     Basis
Check Database archiving mode     Turn database archive log mode back on if it was disabled during the upgrade!
     Database Admin
After Execution:
Check the systemu2019s installation consistency     Execute Transaction SICK to check installation consistency
     BW
Check the system logs     Perform a technical systems check.
     Example: Check system and all dispatcher logs (inc. ICM logs)
     Basis
Apply latest executable binaries     Apply the latest 6.40 Basis Kernel for all executables
     Tip: use the SAP NetWeaver u201904 SP-Stack selection tool to find all binaries. (http://service.sap.com/swdc)
     Basis
Review BI 7.0 Support Packages for follow-up actions.          Review SAP Notes for all SAP BW Support packages applied during (bound into the upgrade) and applied after the upgrade:
o      Search for Note with the keyword u201CBWu201D, u201CSAPBWNEWSu201D, and u201C<BW release>u201D
o     Follow any required instructions identified in the SAP Notes
     Basis
Apply latest patches          Apply the latest SPAM patch
     Apply any required support packages that were not bound into the upgrade.
     Basis
Apply additional BI 7.0 Support Packages
(if required)          SAP recommends that customer remain current on SAP Support Packages.
     Review SAP Notes for all SAP BW Support packages applied in previous task.
o      Search for Notes with the keyword u201CBWu201D, u201CSAPBWNEWSu201D, and u201C<BW release>u201D
o     Follow any required instructions identified in the SAP Notes
     Basis
Resolve any modified SAP delivered Role issues      If SAP delivered Roles were modified, then these modifications may incorrectly appear in the upgrade modification adjustment tool (SPAU).
     Review and implement SAP note 569128 as required     Basis
Configuring Information Broadcasting EP/KMC Connections
     If you plan to use the EP integration functionality of Information broadcasting (Broadcast to the EPu2019s PCD, Broadcast to KMC, or Broadcast to Collaboration Rooms):
     Ensure the SAP EP is at the same SP-Stack level as your SAP BW system.
     Follow the online help documentation to configure and connect the SAP BW system and the SAP EP system. (http://help.sap.com).
     For broadcasting to KMC, ensure that KM has the u2018BEx Portfoliou2019 content available.
     Basis
Re-check SAP BW Object and consistency     Execute RSRV to check SAP BW Object consistency
     Repeat tests that we executed prior to the upgrade.
     Validate results      BW
Check InfoCube views for consistency     Check consistency of InfoCube fact table views
     It is possible that fact table view /BIC/V<InfoCube>F is missing if a number of SAP BW upgrades have been performed before. See SAP Note 525988 for instructions for the check and repair program.
     BW
Perform SAP BW Plug-in (SAPI) upgrade follow-up tasks          If required, Re-activate the SAP BW u201CMyselfu201D source system in SAP BW.
     The SAP BW internal plug-in (SAPI), which is used for internal data mart extraction and u2018BW to BWu2019 communication, is upgraded during the SAP BW upgrade. The source system is de-activated to prevent extractions and loading during the upgrade.
     It may be required to replicate export DataSources and reactivate transfer structures/rules for internal data loads (i.e. ODS Object to InfoCube objects).
o     Tip: It is advised to do this step for all export DataSources to avoid possible errors during execution of InfoPackages
     Check that all other Source Systems are active.
o     Activate as required.     Basis/BW
Check SAP BW Personalization is implemented     (SAP BW 2.X upgrades will have performed this in the previous task).
Validate that personalization has been activated in your SAP BW system.
Note: It has been observed that in some cases, BEx Personalization has to be re-activated after an upgrade from SAP BW 3.x to BI 7.0. It is advised to check the status of personalization after the upgrade.
     Enter the IMG (transaction SPRO), select SAP Business Warehouse -> Reporting relevant settings -> General Reporting Settings -> Activate Personalization in BEx
Check the status of the Personalization settings. All entries should be active u2013 highlighted by an unchecked check box.
     To activate highlighted Personalization, click Execute.     BW
For SAP BW 2.0B/2.1C -> BI 7.0 Upgrades:
Convert ODS secondary indexes to new standard     For SAP BW 2.0B/2.1C -> BI 7.0 Upgrades:
Convert any customer created ODS Object secondary indexes to the new ODS Object index maintenance process.
     Re-create all indexes in the ODS Object definition screen in transaction RSA1.
     ODS indexes must conform to the new naming convention
     BW
Converting IGS chart settings
     Convert you existing IGS chart settings (converts IGS chart settings from BLOB to new XML storage format)
     Ensure you have the latest SAP Web AS 6.40 IGS (stand alone windows version) installed and working
o      Test via transaction RSRT
     Execute the conversion process as directed the BI 7.0 upgrade guide.
     Note: This step is required for all BI 7.0 upgrades     Basis
Backup your SAP BW system     Perform a full database backup (including the File system)
Remember to adjust your backup scripts to include new components such as the J2EE engine, pre-calculation service, etc.
     Database Admin

Function level personalizations

Hi,
I want to know how can we export the function level personalizations from one instance and import them to any other instance. This is very urgent. Please let me know as soon as possible.
Thanks and Regards,
Sandhya

If you are on 11.5.10 CU2 then you can use the import/export option in the Functional Administrator responsibility. If you are on CU1 or earlier versions then you need to use XMLImporter and XMLExporter commands in the middle tier to get it. If you have a jdev on your local then you can use th import.bat and export.bat from the jdev/bin folder to do that.
Example for XMLImporter and XMLExporter can be found in the personalization guide.

Admin Level Personalization to create seeded views failing

Hi,
I have a custom page, let me call it customPG.xml.
When I log in and access that page, there is a button that enables me to create user-level views for a table, and it works.
To create table view that is visible to all users, I go to functional admin and create seeded user views for the same table. For some reason, when I create a blank view from admin level personalization, it appears in the user screen views dropdown, but when the view is selected, no data shows up in the table.
When I duplicate this view at the user level, I can see the data in the table.
any reason why this is happening?
how can i overcome this?
thanks

Anand,
Thank you for the response.
I tried both Functional Admin and SYSADMIN and neither worked. What worked was - when on the personalizae page - select option 'Complete View' instead of the 'Simple View', then all 'Create Item' icons becone enabled!
Well - wonders never stop!
Regards
Anatoliy

Modify view object at responsibility level

Hello,
One of our business requirements is to change the drop-down values for several list of values based on the responsibility the user is logged in with. For example when creating a new application, the LOV 'Country' needs to list certain countries under the responsibility A and other countries under the responsibility B.
In order to accomodate this requirement, I have created an extension to the VO oracle.apps.igs.utilities.server.countriesVO that can be found on the create application page. I have tried two different approaches:
Approach 1:
I have modified the SQL code and used the import utility jpximport to enable the substitution and everything works fine EXCEPT that the substitution is done at the site level, not the responsibility level. There are no options to enable the substitution at the responsibility level.
I tried changing the MDS repository. After initial substitution, the query
BEGIN jdr_utils.printDocument('/oracle/apps/igs/utilities/server/customizations/site/0/CountriesVO'); END;
returns the XML for personalization (substitution). I deleted that entry using
BEGIN jdr_utils.deleteDocument('/oracle/apps/igs/utilities/server/customizations/site/0/CountriesVO'); END;
and used the import utility to import the XML at the responsibility level. the query
BEGIN jdr_utils.printDocument('/oracle/apps/igs/utilities/server/customizations/responsibility/23331/CountriesVO'); END;
returns the correct XML but the extension doesnt appear on the screen.
Do you know what I am missing and if it is possible to enable substitutions at the responsibility level (not site level) at all?
Approach 2:
I am still implementing the View Object extension but I am modifying the SQL code to handle the responsibility:
Original SQL Code:
SELECT territory_short_name,territory_code
FROM fnd_territories_vl
Updated SQL Code:
SELECT territory_short_name,territory_code
FROM fnd_territories_vl
WHERE fnd_global.resp_name <> 'A' OR fnd_global.resp_name IS NULL
UNION ALL
SELECT description as territory_short_name,territory_code
FROM fnd_territories_vl
WHERE fnd_global.resp_name = 'B'
ORDER BY 1
I used the import utility jpximport to enable the substitution and everything works fine EXCEPT that the View Object gets cached and the SQL statement is only executed the first time the object is called. If I clear the cache and I log in using the responsibility A then the countries are correctly displayed. If I login using the responsibility B then the countries for responsibility A are displayed. Same occurs if I clear the cache, login using responsibility B first then switch to responsibility A. Countries for responsibility B are always displayed.
We need to find a way for the SQL to be re-executed every time this object is called. This object should not be cached. Is that possible at all?
Thank you for your help
Benoit

Substitution of VO & AM will can be done only at site level. However controller extension can be personalized/substituted at any level, which includes responsibility level also.
Thanks,
--Anil
http://oracleanil.blogspot.com/

Make all the forms at a user level or responsibility level to be read only

Hi,
Please suggest me to make all the forms at a user level or responsibility level to be read only. So that when a particular user logs in, he gets all the form in read only mode or at a particular responsibility all the forms are read only so that we can attach this responsibility to the user for the same purpose.
Any ideas will be highly appreciated.

check this blog,
http://www.oracleappshub.com/11i/oracleapps-responsibility-vs-sap-functions/
Re: How to change OM responsibility as read-only in oracle applications 11i
read only responsibility-user

How to migrate 'responsibility' level personalizations?

Similar Messages

Maybe you are looking for