We are about to refresh the Development system with a copy of Production. What tables do I need to export from Development prior to the refresh, and later re-import, to ensure that Profile Generator is able to maintain the activity groups created in Development?
These tables for profile generator stuff:
(from top include for PFCG)
000010 function-pool rhum.
000020
000030 tables: hrv1220, hrp1001, hrp1000.
000040 tables: pchdy, pphdx, p1000,
000050 pt1220, t77fc, t77fd.
000060 tables: *objec, objec, *p1000.
000070 tables: pdrhum, t77aw, t777o.
000080 tables: xu213.
000090 tables: t777e, usr05, tprprof.
and you may need to do the same with menu tables - I'm not sure which ones
(from top include from SSM1)
000010 function-pool smnu. "MESSAGE-ID ...
000020 *
000030 tables: indx, tstct, dsyax,
000040 smenca_new, smen_obnew, smen_conew,
000050 smenusenew, smenentnew,
000060 smen_dates, ssm_stat, ssm_start, ssm_langu,
000070 smensapt, smencust, smenentt,
000080 smensapnew, smencusnew,
000090 smenselect, t002t,
000100 ssm_rele, smenintnew, smenintt.
--------------------------------------------------------------------------------
user masters: USR01 to 09, UST04,
profiles: USR10, USR11, UST10S, UST10C,
authorisations: USR12, USR13, UST12.
password exceptions USR40.
History tables(may not be applicable but FYI): users:
USH02, USH04,
profiles: USH10, auths USH12.
Activity groups are stored in table PLOGI along with loads
of other object types. the activity groups are object type T.
You could export the table data with a manual transport
request via SE01, using R3TR TABU and specify the keys to use for all objects
of type T(ie all activity groups). Remember to include all clients in the
selection.
OR, if you are using the client copy functions to refresh you DEV from PROD, then you could use the RSCCEXCT (see OSS note 70290) to list all these tables and exclude them from the copy, hence the corresponding original DEV tables should not be overwritten in DEV.
I suggest you export a transport request with with all these tables from DEV just in case, so you can re-import them again if it goes pear shaped.
If you choose to re-import the tables from transport requests, you might want to run the sync tool in the target client (DEV) afterwards - i.e. run function module SUSR_SYNC_USER_TABLES, or run SU30, just to check for any links or inconsistencies.
Also, if you are re-importing user masters too, run RSSODELT and RSSOUSER to recreate all SAPOffice mailboxes and link them to the new user IDs in the target client.
I would also use RHMOVE30 and create a transport of your activity groups. To be safe test import the activity groups to QAS prior to refreshing DEV with PRD. Then once you have completed the refresh import the transport you created.
Remember to run SUPC after you import to regenerate the profiles.
