 allsoftware.sites
Rating: 58
Member since: 2009-02-19
Feeds: 3
Bookmarks
Categories
|
Preview: All SAP BASIS
All SAP BASISMessage Class,Networking,Tables,Transaction Codes,EMail, Interview Questions,OSS,Printing and Fax,SAP,Performance Tuning,Solution Manager,Statistics ,System Audit, Transports and Upgrade,Users Profiles and Password,SAP RouterUpdated: 2009-10-17T06:40:18.577+05:30
background job failed because of authorization 2009-03-11T12:25:39.093+05:30 We have a job which runs OK in foreground but when defined in background.It failed and the log said it is an authorization problem. Unlike a foreground job which we can always run SU53 after the execution to get which auth is needed, the log of the background job didn't tell more detail other than "it is an auth problem". Pls help us with this. is there a way to find out what is the exactly reason after a background job failed because of authorization? thanks. Answer: Several solutions: 1) Copy the batch user to a dialogue user, then logon and run the job. You will then have your error online and maybe the SU53 you are looking for. 2) Check S_PROGRAM value for the batch user. Maje sure the batch user has activity BTCSUBMIT for the program auth group. Have you checked the job log in SM37?? You can usually drill-down to see some type of error. Common errors are S_PROGRAM and S_DATASET authotizations' missing. Answer: You can also run an authorization trace from ST01 for the "job step executor" (the background user) -- not the batch job scheduler, unless if they're run by the same people. Also -- make sure you run ST01 on the exact application server the batch job is running to capture the trace. Answer: Tried to run the job online, it went through w/o problem. Tried it in background again, failed with same authorization problem. Does this make sense for you guys? Should running online and running in background have the same authorization check? 
Background Jobs 2009-03-11T12:25:13.349+05:30 What is the general practice for running Background jobs? Under the individual's user ID or one generic ID which has wide authorisations?If it is run under the individual ID, then how is it handled when the person leaves the company?What are the pro's and con's of running it under one generic ID?Thank youJaynick_________________SAP Rules!!!Answer:We make sure that all background jobs are scheduled against a background user. This way we ensure that there is sufficient access to complete the job without having to give the individual users the same level of access. At the same time we can lock leavers and inactive users without being concerned of jobs falling overTo do this, you need to make sure that only a limited number of people can schedule batchjobs against the background ID. If not, you risk people obtaining access they should not have.You can also ensure that the jobs won't have a negative performance impact on the system, as they will be scheduled with the right parameters.Hope it helpsAnswer:If you currently allow users to create background jobs, checking for jobs scheduled for a particular ID should be a standard part of user decomissioning.Answer:Thanks Henrik! Any other input from SAP fans as to what the general practice out in the world is?JaynickAnswer:I have a question about this also. I understood that a Basis admin could schedule background jobs to run under the userid of a system user, so that the system user (non dialog) could be granted broad authorizations, and not the dialog user, and also no maintenance is required if basis admin leaves the company.I know that there are a few things that will require that the basis admin who schedules the background job to run under the auths of the system user id, also have the authorizations in his/her role also, or they will not be allowed to schedule it to run under the system id, even if the system id has the auths. Which is an understandable security measure. But these are only for a few things like os command and program execution considered critical, and not like broad business applications which the admin would not have in his admin role, and yet there is no problem scheduling jobs under the system id which does process business application jobs.I have been told by some that they needed to create a generic dialog user like "JOBSCHEDULER" and use it to schedule jobs. I don't understand why they need to do this. Can anyone tell me why there would be a technical problem if they simply used their own id to schedule these jobs to run under the authorizations of the system id set up for this purpose?_________________Gary MorrisSAP Security Analyst/Developergarymorris@sapsecurity.netAnswer:Hi Gary,Do you mean that the job admin is a generic account? That makes the connection between the dialog user ID and the name of the background user in which the job step is running even more obscure...The belief that SOD conflicts between dialog users with S_BTCH_NAM = 'BATCHUSER' and the authorizations of 'BATCHUSER' itself is bad enough!If you mean the job steps running in the name of the generic account as a dialog user, I have observed some OSS notes on a related topic which you can find with a search on 'call transaction' (I was looking for something else). Some programs may call a transaction screen which is not a parameter transaction and requires dialog interaction - at least that is what I understood the notes to be describing.If I find an example again, I will post it.NoddyAnswer:There are two types of background jobs:1. Repetative Production scheduled jobs to support a business process.2. Adhoc reporting in background to keep the dialog processes free for "real" work. ( transaction processing)The repetative Production jobs should be formalized with a standard naming convention for the job name and scheduled by the Batch administrator at the appropriate time, generally on a basis person's id not a generic one as there is no accountability on a geeric ID. The batch admin will need sufficient access to create the job, not run the report if in[...]
background jobs via background users 2009-03-11T12:24:44.092+05:30 I need some opinions about following issue:We have some jobs who have to be done every day. So, these jobs are planned every morning. The jobs are backgroundjobs and [b]one[/b] system user runs [b]all the jobs[/b]. Therefore, this system user has a SAP_ALL. A system user can't login on a normal basis but I don't feel well with the SAP_ALL. I have the idea to split this user in several system users, with a big profile of the module which need some background jobs. (HR-user for HR-backgroundjobs, FI-user for FI-backgroundjobs,...) Is this realistic or is there an other solution? Maybe our situation at this moment isn't so bad as I think??? Can someone help me? Thanks in advance! Bart Answer: It's perfectly feasible to split them by function or module. For non-sensitive stuff I generally have a user e.g. FIBATCH with auths to cover what's needed. It takes a bit more work to set up but helps keep things arranged in an orderly manner. Answer: I’ve been through audits in the past where they have been satisfied with the background user having SAP_ALL as long as you have tightly controlled who can actually schedule jobs etc against that ID. Answer: I’ve been through audits in the past where they have been satisfied with the background user having SAP_ALL as long as you have tightly controlled who can actually schedule jobs etc against that ID. Its all about risk. System users can also be used as communications users and there are some tricks that could allow someone to abuse a systems user in an RFC call. (They involve a kind of password hack). If you restrict the authority of the systems user you can diminish the opportunity for abuse. You also have to be very restrictive about authority for S_BTCH_NAM. _________________ bwSecurity Answer: I’ve been through audits in the past where they have been satisfied with the background user having SAP_ALL as long as you have tightly controlled who can actually schedule jobs etc against that ID. When I perform audits I prefer not to see the ID with SAP_ALL - as there are plenty of ways it can be misused if the required restrictions are not in place. If you do want to use one user, at least use a chopped down version of SAP_ALL with some of the more sensitive auths removed or very tightly controlled to grant what specifically is used. 
Background Processing VS Batch processing 2009-03-11T12:24:02.942+05:30 Can someone tell me what the difference between backgroud processing and batch processing is. Also does the access to this function be limited.I have a requrinment where they want everyone to have access to batch processing and just wanted to know how i should be handling this request. Please help Answer: You have to get clarification from the requester. Most often Batch and background mean the same. There is a SAP useage which means Batch Data Communication ( BDC) that is sometimes refered to as Batch but most often refered to as BDC. Batch anf Background is controlles with S_BTCH_JOB and BDC is S_BDC_MONI. You need clarification fromt he requester. Answer: And if the user also has S_BTCH_ADM = Y and S_BTCH_NAM = DDIC (or *), then they can schedule the jobs, release, delete etc (as per S_BTCH_JOB actions permitted), but.. in the name of and with the authorizations of the other user names. You can check with SUIM reports who can use your user account (for example) without having to know your password. The myth that one cannot logon with a batch user is therefore true, because you don't need to logon with it... Cheers, Bob Answer: There is no myth about "loggin on to a Batch id" it does logon to run the batch job it just cannot be used in DIALOG mode. S_BTCH_NAM allows you to run a batch job using that users' access be it DDIC ( which should not have SAP_ALL) or any other id BATCH or DIALOG. Answer: There is no myth about "loggin on to a Batch id" it does logon to run the batch job it just cannot be used in DIALOG mode. S_BTCH_NAM allows you to run a batch job using that users' access be it DDIC ( which should not have SAP_ALL) or any other id BATCH or DIALOG. It does logon, but unlike Communication users, the password is not critical for this login so you can change it. Like Communication users, one does not have to know what the password is... just access to see that someone once did and left it behind in the system. For Communication users one does not need to know the password either, but changing it, would make the access to the user more difficult. 
Deleting a scheduled Background job in SAP 2009-03-11T12:23:09.357+05:30 To delete a job:Go to Transaction SM37. Select a job (or jobs) from the Select Background Jobs screen. In the Job Overview, mark the job or jobs you want to delete by checking the box to the left of the job name. Choose Job --> Delete. Deleting Jobs That Have Dependent Jobs: If you delete a job that must be processed before another job can be started, the dependent job can no longer be started. The system will inform you of any such existing dependent, or successor, jobs. You'll then need to either reschedule or delete the dependent job. If you try to release a job whose predecessor job was deleted, the system sets the status of the job to Planned. To start this job, you must release it and specify the start conditions. 
Schedule Manager 2009-03-11T12:22:36.804+05:30 Automate your routinue task with Schedule Manager. It facilitate the definition, scheduling, execution, and review of tasks that are executed on a regular basis, such as period-end closing. SCMA - Schedule Manager 
how you can assign a Background work process as a Class A Background Work process 2009-03-11T12:22:15.425+05:30 Go to transaction code rz04 then button Operation Modes / Instances. Then select the Operation mode and double click on it. Then you will see a window with no of Background work process. In the field named Class A increase the no to 1 (use the + button to increase that). Default value is zero. Then click on the save button to save the configuration
How To Delete a Scheduled Job in sap 2009-03-11T12:21:46.816+05:30 I am working in production support and have been asked to stop a scheduled jobs. The job will run on the first of next month and I need to stop it from running. To delete a job: Go to Transaction SM37. Select a job (or jobs) from the Select Background Jobs screen. In the Job Overview, mark the job or jobs you want to delete by checking the box to the left of the job name. Choose Job --> Delete. Deleting Jobs That Have Dependent Jobs: If you delete a job that must be processed before another job can be started, the dependent job can no longer be started. The system will inform you of any such existing dependent, or successor, jobs. You'll then need to either reschedule or delete the dependent job. If you try to release a job whose predecessor job was deleted, the system sets the status of the job to Planned. To start this job, you must release it and specify the start conditions. 
Checking your program Background Job Status 2009-03-11T12:21:10.168+05:30 Checking your job status with SM50 (processor type BTC) is more accurate then SM37. SAP updates the tables TBTCO wheneveryour background jobs status change. If SAP is shutdown, the currentjobs might not be update ontime to the table. (e.g. a background job wasshown as Active (SM37), in fact it real status should be Cancelled. The type of work process:
Availability Check on Quotation 2009-03-11T12:20:40.154+05:30 SAP standard does not do an availability check on the quotation, as it is not a definite order, usually just a pricing quote. When it is converted to an order, the first availability check is carried out, as well as credit checks. The system will check stock in the plant, plus what is contained in the availability checking rule (scope of check) eg: can add POs for replenishment, purchase reqs, different planned orders, and subtract sales orders, deliveries etc already created against that material in that plant (and possibly Storage location). If there is enough stock in the plant/SLoc, the system will give you a confirmed date, or give you a date based on the production time or purchasing time from the material master. The date the system proposes is based on the customer's requested delivery date. SAP first backward schedules looking at the required delivery date, less transportation time, less transportation lead time, less pick and pack time, less production/purchase time if applicable. If the date it calculates is equal or later than today’s date, then it will confirm the customer’s required date. If it falls in the past, SAP will then forward schedule for today’s date, plus the times listed above to get the date when the customer can actually have it. ATP is the single most complex part of the SD module, depending upon how PP and MRP is set up. MRP works semi-separately, depending on how it is set up. Basically, MRP looks at the demand on the plant, and if it the stock does not meet expected sales orders and deliveries, it will create a purchase requisition (outside purchase) or requirement or planned order (for production) to cover the shortfall. When MRP is started, it will turn the PR into a PO or the requirement into a production order. 
SD material Determination based on availability check 2009-03-11T12:20:17.389+05:30 For SD material Determination you can create a Substitution reason and on the Strategy field, the following info. is available: Product selection in the background is performed on the basis of the availability check. We want to have the material determination only in case on material shortage. We expect the Substitution reason to give us this functionallity. It does not hovever take the availabilty into account before substitution. We thought the worse case is to create a ABAP which is linked to the "requirement" field in the Procedure (OV13). Has anyone had the same requirement? Is this a bug or just incorrectly documented? I also encountered this abnormally recently using material determination. In order to combat the problem, the first product substitution should be for the original material. I've illustrated this below: Original Product: ABC In order to perform product substitution ONLY in the case of ATP failure for product ABC, structure the Material Determination record as follows: Material Entered: ABC Substitutes: ABC There seems to be a devaition at availability check and or on a conceptual note still. Availability check can be configured both at requiremnt class and at the schedule line categories level. Whilst the availabilty check at the requirement class level via global and mandatory configuration the schedule line catgry availability check deals with the order. It is mandatory that the reqmnt class is flagged off for avlblty check and the schdelu line cat need not be. The following are the mandatory for Availability check to happen-- 1. Must be swithced on at the requirment class level and at the schedule line level. 2. Reqmnt type must exist by which a requiremnt class can be found 3. There must exist a plant and is defined 4.Checking group must be defined in Material Master records(it controls whthr the system is to create individual or collective reqmnt) A combination of checking gropup and checking rule will determine the scope of availbaility check. 
Creating Multiple Materials in Material Determination 2009-03-11T12:19:55.370+05:30 Material Determination is used to swap one material for another.It is possible to get a list of materials for substituiton,but remember you can substitue only one material from the list. This can be done through substituiton reason T Code [OVRQ] Go To VB11 to create Material Determination (taking into consideration that all the previous steps for material determiantion i.e. maintaining condition types,maintaining procedures for material determination and assigning procedures to sales doc. types have been done) Create one material determination,dont forget to give the Subst reason on top and also on the line. Click the Variants Icon on top left-Sreen opens Specify different materials you want to swap with the material you have enterd Note that the subst reason is already copied on the screen Remember materials should be of the same sales area,atleast Divisions should be same
Backward and Forward Scheduling 2009-03-11T12:19:08.762+05:30 Backward scheduling is the calculation of deadline dates: the arrival time at the customer site is calculated as the earliest possible goods receipt time at the customers unloading point on the requested delivery date. All four of the delivery and transportation scheduling lead times are subtracted from the customer's requested delivery date to determine if this date can be met. The transit time, loading time, and pick/pack time are subtracted from the customer’s requested delivery date to calculate the required material availability date. The system calculates backward scheduling as follows: Requested delivery date minus transit time = Goods issue date By default, the system will calculate delivery dates the closest day, taking into consideration the working days of the shipping point and a rounding profile. In this case the system assumes a 24 hour work day and lead times can be entered in days up to 2 decimal points. This is referred to as daily scheduling. Precise scheduling calculated down to the day, hour and minute is supported. This allows the scheduling of a delivery within a single day. It is activated by maintaining the working hours for a particular shipping point. Backward scheduling is always carried out first. If the material availability date or transportation scheduling date is calculated to be in the past, the system must then use forward scheduling. Forward scheduling is also done if no product is available on the material availability date calculated by backward scheduling. The system does an availability check to determine the first possible date when product will be available. This new material availability date forms the starting point for scheduling the remaining activities. The loading time, pick/pack time, transit time, and transportation lead time are added to the new material availability date to calculate the confirmed delivery date.
SAP Authorization Concept 2009-03-11T12:18:43.624+05:30 The SAP authorization concept is based upon the logical relationship between a user ID and the range of system authorizations with which it can be associated. The architecture of the authorization system is based upon the utilization of several individuals but related logical components: Profiles, Objects, Fields, and Authorizations. The user ID refers exclusively to profiles. Each profile grants a set of specific system access authorizations to user. Figure 2 illustrates the hierarchical authorization concept in SAP. Figure 2 Composite profiles refer to the various employee roles available in the corporation (for instance: Purchasing / Receiving Clerk or Accounts Agent). As the name suggests, composite profiles may contain multiple user IDs necessary to perform all the business operations associated with a particular role. A composite profile may encapsulate another composite profile(s). In practice, a model composite profile should be recognized for each possible role in the organization, which may be used to produce hybrid composite profiles. The over-existence of the hybrids can defy the very purpose of composite profiles and they should be created only when specific needs arise. User ids allow access to SAP applications. Each user must have a corresponding profile specifically assigned. In many situations, multiple composite profiles can be assigned to a user ID, depending on the role(s) an individual user is responsible for, in the business processes. Authorizations are the key building blocks of SAP security. Authorization is the process of assigning values to fields present in authorization objects. In SAP, access to all system functionality is achieved through a complex array of authorizations. Sometimes users find that they lack the necessary authorizations to perform a certain function in the system, in which case the message: "You are not authorized..." is displayed at the bottom of the screen. An authorization process may ask for second associated authorization process which in turn asks for third and so on. For example, the task of paying a vendor invoice may require 10 different authorizations. 
SAP’s TCODE checks with the authorization tool 2009-03-11T12:18:09.776+05:30 What are the checks that the SAP authorization tool performs when a TCODE is executed in order to ensure authorization of that user? EXPERT RESPONSE When initiating a transaction, a system program performs a series of checks to ensure the user is authorized. 1. The program checks whether the transaction code exists in table TSTC. 2. The program checks whether the transaction code is locked by the administrator (transaction code SM01). 3. The program checks whether the user has the authority to start the transaction. Authorization object S_TCODE (transaction start) contains the authorization field TCD (transaction code). The user must have the appropriate authorization for the transaction code to be started (for example, FK01, Create Vendor). 4. The program checks whether an authorization object is assigned to the transaction code. If this is the case, the program checks whether the user has an authorization for this authorization object. The transaction code/authorization object assignment is stored in table TSTCA. 5. The system performs authorization checks in the ABAP program using the ABAP statement AUTHORITY-CHECK. 
Listing TCODE transactions used to view what users are logged in to SAP 2009-03-11T12:17:50.357+05:30 I want to get a list of all transactions used per user in a specific time period. Basically I’m looking for a list of all users logged in SAP and the details of the tcodes they used. Is there any standard report or tcode available to view this info? EXPERT RESPONSE There is no standard transaction. The information is available for configurable time periods using transaction ST05N but it is not organized to readily provide a report of users and transactions. Also the information available summarizes a user’s use of a transaction. There will be one entry (with count data) per user per time period. Daily, weekly and monthly summaries can be created and they are stored for configurable durations. It is also possible to configure audit logging via SM19 and read the log files via SM20. This will provide more detail but it also introduces new file management issues and requires a change to system settings. 
Authorization Check 2009-03-11T12:17:28.994+05:30 The following actions are subject to authorization checks that are performed Starting SAP transactions (authorization object S_TCODE) The authorization objects S_TCODE, S_PROGRAM, S_RFC, and S_TABU_DIS Authorization Check: 
SAP BASIS (BC) Authorization Concepts 2009-03-11T12:16:58.516+05:30 SAP Authorization Concept The SAP authorization concept is based upon the logical relationship between a user ID and the range of system authorizations with which it can be associated. The architecture of the authorization system is based upon the utilization of several individuals but related logical components: Profiles, Objects, Fields, and Authorizations. The user ID refers exclusively to profiles. Each profile grants a set of specific system access authorizations to user. Composite Profiles Composite profiles refer to the various employee roles available in the corporation (for instance: Purchasing / Receiving Clerk or Accounts Agent). As the name suggests, composite profiles may contain multiple user IDs necessary to perform all the business operations associated with a particular role. A composite profile may encapsulate another composite profile(s). In practice, a model composite profile should be recognized for each possible role in the organization, which may be used to produce hybrid composite profiles. The over-existence of the hybrids can defy the very purpose of composite profiles and they should be created only when specific needs arise. User Ids User ids allow access to SAP applications. Each user must have a corresponding profile specifically assigned. In many situations, multiple composite profiles can be assigned to a user ID, depending on the role(s) an individual user is responsible for, in the business processes. Authorizations Authorizations are the key building blocks of SAP security. Authorization is the process of assigning values to fields present in authorization objects. In SAP, access to all system functionality is achieved through a complex array of authorizations. Sometimes users find that they lack the necessary authorizations to perform a certain function in the system, in which case the message: “You are not authorized…” is displayed at the bottom of the screen. An authorization process may ask for second associated authorization process which in turn asks for third and so on. For example, the task of paying a vendor invoice may require 10 different authorizations. 
Unlocking a blocked admin user ID in an Oracle DB 2009-03-11T12:16:34.403+05:30 My admin user ID has been locked out. Is there a table I can update in Oracle to reset the flag and enable myself to log in? EXPERT RESPONSE Select all entries of table USR02 where ‘UFLAG’=128. These users are locked by reason of incorrect logons. ‘UFLAG’=64 will give you the users that are blocked by Administrator. Set ‘UFLAG’ to 0, to unlock your account. 
How to Check Missing Authorisation for User 2009-03-11T12:15:44.261+05:30 How to check the missing authorisation for the user not having the option "/nsu53 ?"You can use the following procedures to determine which authorizations a user requires to carry out a transaction: You can use Trace function, ST01, you can trace the user activity and from the log you can see the authorization missing. Start an authorization trace using the ST01 transaction and carry out the transaction with a user who has full authorizations. On the basis of the trace, you can see which authorizations were checked. This procedure generally works well. However, sometimes the result is very surprising because certain programs can and do ignore some authorization checks by using preliminary checks and buffered results. In such cases, these methods are not very effective. You can recognize these cases because certain fields of the corresponding programs are specified with * or DUMMY at some point of the authorization check. Analyzing authorization problems in an unknown program The most frequently used method to analyze authorization problems in an unknown program involves you setting the Debugger breakpoints to the AUTHORITY-CHECK and MESSAGE commands. Then execute the program and analyze its behavior. Determining all the authorizations a user has for an authorization object When troubleshooting, it is often helpful to find out all the authorizations a specified user has for a specific authorization object. A simple method of reading these authorizations as raw data from the user master record is to execute the GET_AUTH_VALUES function module in the SUSR function group. Use the SE37 transaction or SE80 in test mode to do so. The result table is not formatted for output, but is very compact and easy to understand for authorization experts. Analyzing an authorization problem that occurs for only one user It is often the case that a certain authorization problem occurs for only one specific user. This kind of authorization problem generally affects users with no Debugging authorization. If you want to assign a user Debugging authorization without changing the HR authorizations, you can add the S_A.DEVELOP authorization profile (if available) to the user’s authorization profiles. In production systems, note that changes such as these to authorizations enable users (with relevant knowledge of the development environment) to access any system data easily (especially in other clients). 
SAP Profile Generator tables 2009-03-11T12:15:18.996+05:30 ---Original Message-----Subject: Profile Generator tables?From: Paul EllisWe 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? - moreFrom: Mike O'Carrolloh, and maybe these tables for profile genrator stuff......(from top include for PFCG)000010 function-pool rhum.000020000030 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/UKuser 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 MarquardtI would use RHMOVE30 and create a transport of your activity groups. To be[...]
Query About Tcode PFCG 2009-03-11T12:14:52.400+05:30 1. How to check the name of all users who has been authorised to use a particular transaction? I am trying to find through SUIM, but failing to find the name or total number of users of a particular t-code say SPRO.2. I know that a particular transaction say SPRO is available in a particular role and I want to remove that t-code from that role. But I am unable to find that node through PFCG. If I am using the search for a t-code inside menu tab after putting the edit mode it is not coming in PFCG, but through SUIM its existence is coming in that role. That particular role contains a lot of t-code and reports, say about 2000. 1. Goto SUIM and select USER node, then select USERS BY COMPLEX SELECTION CRITERIA node then execute BY TRANSACTION AUTHORIZATION report then give the Tran. code and it will return you the number of users having that trans with relevatn details. Follows these steps :- - Go to SUIM . - Choose Roles --> By Transaction assignment. - Enter Transaction : "SPRO" - Choose execute. - Double click on a role in which you want to remove "SPRO" authorisation. - Click on pen mark to change into change mode. - Go to tab "Authorization" - Choose change authorization data. - Choose Utilities --> Technical names on . - Choose --> cross application authorization objects--> - Expand the selection for Object "s_tcode" , under the corresponding profile look the values maintained for "TCD" and remove value "SPRO" from the list to eliminate the authorization. - Don't forget to regenerate profiles. 2. You should able to find this via menu tab otherwise try to do this in authorization tab --> change authorization data by search. 
How To Compare The Roles 2009-03-11T12:14:27.177+05:30 How to compare the roles where created or defined in two different systems?For role comparision both the roles must be in the same system, in same client Transaction code SUIM -> Comparision-> Roles If the roles are in different system, then tranport the role into one of the system and do comparision. If no transport connection defined then, you can use the upload and download option in the PFCG Steps for Role Comparing: 1. Run the t-code SUIM 2. Go To Comparison and select the option of roles 3. Click on Across systems option it will give option to select the sys name under Remote Comparison there enter the SYS ID between which system you want to do comparison and put the role name in compare role section then execute it will give you the result. 4. If there is any difference b/wn the t-codes it will b in red colour otherwisein yellow. 
Creating New User With Authorizations 2009-03-11T12:14:04.570+05:30 I want to create new user for SAP module. I am having user id as sap* (someone has said that this is super user id); when I login with this id and go to IMG for configurations. A message is displayed that I am not authorised to change the details with sap* user.What is the procedure for creating new user which have all features define under SAP* user and which could allow me to make the configruations. Creating new user with superuser authorizations. 1. Goto SU01 -- username : sapuser |-->Create. 2. In default settings, give :Mr first name : sap lastname : user 3. Goto next tab, give initial password :1234 repeat password : 1234 4. Goto profiles. type- sap_all (say enter) sap_new (say enter) Then save.... See the message in status bar, (user created successfully) 5. Login with the new user. change the password. now this user contains all superuser authorizations. 
Introduction on Authorizations 2009-03-11T12:13:37.455+05:30
 |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
http://allsapbasis.blogspot.com/rss.xml
Privacy policy - Sitemap - Press - Terms of Service - Copyright information - Contact Us - About Us - Feedage
Website Design by: JMVMedia.com - Florida Search Engine Optimization
Language Detection Powered by
