SAP Library - Find your answers

---Original Message-----
Subject: Profile Generator tables?
From: Paul Ellis

We maintain profiles in a Development system using Profile Generator, but only transport the authorisation profile and not the activity group to Staging/Production.

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?

Thanks in advance.

Paul Ellis

-----Reply Message-----
Subject: Re: Profile Generator tables? - more
From: Mike O'Carroll

oh, and maybe these tables for profile genrator 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.

--------------------------------------------------------------------------------

Regards,
Mike O'Carroll

-----Reply Message-----
Subject: Re: Profile Generator tables? (Document link: Michael O'Carroll)
From: Michael O'Carroll/UK

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.
In 3.x I don't think the activity group names involve client number or SID, but I've heard some differences in 4.6 - Guy Holchester has sent many notes to the list about it - have a look at the archives, but I think as long as you aren't copying between different versions (eg from Prod 4.6 to Dev 3.x, or vice versa) then it should be OK.

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 - ie run function module SUSR_SYNC_USER_TABLES, or run SU30, just to check for any dodgy 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.

hope this helps.
cheers,
Mike

-----Reply Message-----
Subject: Re: Profile Generator tables?
From: Kenneth Marquardt

I would 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. For more info on this look at the Authorization is made easy guide available online on page 11-6 release 4.0b.

Remember to run SUPC after you import to regenerate the profiles.

-----End of Reply Message-----

SAP Profile Generator tables

-----Original Message-----
Subject: Profile Generator tables?
From: Paul Ellis

We maintain profiles in a Development system using Profile Generator, but only transport the authorisation profile and not the activity group to Staging/Production.

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?

Thanks in advance.

Paul Ellis

-----Reply Message-----
Subject: Re: Profile Generator tables? - more
From: Mike O'Carroll

oh, and maybe these tables for profile genrator 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.

--------------------------------------------------------------------------------

Regards,
Mike O'Carroll

-----Reply Message-----
Subject: Re: Profile Generator tables? (Document link: Michael O'Carroll)
From: Michael O'Carroll/UK

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.
In 3.x I don't think the activity group names involve client number or SID, but I've heard some differences in 4.6 - Guy Holchester has sent many notes to the list about it - have a look at the archives, but I think as long as you aren't copying between different versions (eg from Prod 4.6 to Dev 3.x, or vice versa) then it should be OK.

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 - ie run function module SUSR_SYNC_USER_TABLES, or run SU30, just to check for any dodgy 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.

hope this helps.
cheers,
Mike

-----Reply Message-----
Subject: Re: Profile Generator tables?
From: Kenneth Marquardt

I would 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. For more info on this look at the Authorization is made easy guide available online on page 11-6 release 4.0b.

Remember to run SUPC after you import to regenerate the profiles.

Question: Hi,
We normally use Role(PFCG) and authorization profiles are generated automatically .
I need to create Authorization profile in 3.1h .Both simple and Composite.

Can anyone guide me how to do?
Is it through su02? what has to be added in Object ? and in Authorization?

Thanks.

Answer:
You create and modify Authorization roles in SU02. The values assigned to each authorization object must be determined by members of each business unit. Either that or you asign no values to any of the parameters and let the users test each transaction assigned to the role and determine the different org levels and parameters through testing. It is a long process however if the business cannot help you define the roles it is the only other way to do it.

Answer:
And I assume you will need to create custom authorisations as well. That is done through SU03.

An overview of the memory management parameters will be shown in the following sections.

A description of the parameter always follows the unit in which it is specified, the default value and a proposed value. The default value usually is based on a minimal value, therefore for very small R/3 installations (see Application Servers with Up to 15 Users), the proposed value is based on a midsize to large installation (see Application Servers with Up to 50 Users and Application Servers with Over 50 Users).

The specified default values and proposed values are based on UNIX systems; under Windows NT, the parameter setting is explained in the unit Parameter Overview for Windows NT.

abap/heaplimit: Work Process Startup

ztta/roll_extension: Extended Memory Limit

abap/heap_area_dia: Heap Memory Limit for Dialog Work Processes

abap/heap_area_nondia: Heap Memory Limit for Non-Dialog Work Processes

abap/heap_area_total: Heap Memory Limit

em/initial_size_MB: Extended Memory Pool Size

rdisp/ROLL_SHM: Roll Buffer Size

rdisp/ROLL_MAXFS: Maximum Roll File Size

rdisp/PG_SHM: Paging Buffer Size

rdisp/PG_MAXFS: Maximum Size of the R/3 Paging File

ztta/roll_area: Roll Area

ztta/roll_first: Initial Allocation Size from the Roll Area

em/blocksize_KB: Segment Size for the Extended Memory

em/stat_log_size_MB: Statistics - User Context Size

em/stat_log_timeout: Statistics - User Context Size

These are important categories of system parameters. You can access and change them using RZ11.


To display you can use report RSPFPAR which can be run thorough SA38. Not

all parameters can be changed Using RZ10 (profile maintainance)

you can change parameters that are dynamically switchable and they are

activated immediately.



ES/* : Related to extended memory settings

INSTANCE* : Identify an instance or server

ABAP/* : Related to program execution, including heap settings

AUTH/* : Related to authorization

DBS/
EM/* : General system related settings

ENQUE/* : Settings for the enqueue WP (or standalone ENQ server)

GW/* : SAP Gateway related settings

ICF/* & ICM/* : Settings for the Internet control framework and ICM

LOGIN/* : Controls the logon environment (such a multiple sessions etc)

MS/* : Message server related settings

RDISP/* : Controls the dispatcher & dispatcher controlled processes

STAT/* : Statistics collector related parameters

SCSA/* : Shared common system area parameters

ZTTA/* : Extended memory related parameters

Role and profile go hand in hand. Profile is bought in by a role. Role is used as a template, where you can add T-codes, reports, URL's.

Profile is one which gives the user authorization. When you create a role, a profile is automatically created.

Keyword: BASIS
Title : CCMS Configuration & Profile Maintenance

Main System Profile Parameters for Updates

rdisp/vbname: Specifies the name of the update server that is to process the updates if load balancing is deactivated ( rdisp/vb_dispatching = 0 ).

In the standard system, this parameter specifies the name of an update server (set when the update server is created). If rdisp/vb_dispatching is set to 0, the updates are only processed by the server in rdisp/vbname.

rdisp/vb_delete_after_execution:Determines whether update records are deleted automatically after they have been processed successfully.

In the standard system, this is set to 1 (automatic deletion activated).

If set to 2, automatic deletion is deactivated. This value can be used to set the update and database performance. In this case, the report rsm13002 with the parameter DELETE = X should run in the background at least once a day to prevent the update tables from becoming excessively large. See also the section entitled Structure link Background Processing in the CCMS documentation.

rdisp/max_vb_server: Maximum number of update servers permitted in the SAP System. Default = 50 servers.

rdisp/vb_included_server:List of the SAP update servers, which are to be used to process updates in accordance with the load balancing principle. No updates are assigned to update servers that do not appear in the list.

This parameter is empty in the standard system. This means that all active update servers are taken into consideration for the load balancing mechanism. This is generally speaking the optimum value.

rdisp/vbdelete:Specifies the number of days after which the update records are deleted. The parameter is set to 50 days in the standard system.

Once this interval has expired, an update record is deleted irrespective of its status (processed, not processed, error etc.).

If set to 0, automatic deletion is deactivated. This value should only be set temporarily, and only if an incorrect update record is to be kept for further analysis.

Keyword: BASIS
Title : J2EE Engine - Profile Parameters