Monday, 4 March 2013


SAP BASIS CLIENT COPY QUIZ ( Answers are given in brackets )

         1.   When a client is created? (A,B & D)
           A.     It has to be kept open        
           B.     It has no users except for a kernel built user
           C.     The new client will not be visible cross client        
           D.     It has no information 

         2.   Before creating a client the mode has to be changed from Display to
              Change in t-code SCC9? (A) 
           A.       False        
           B.      True
         3.   Which of the following answers is correct with relation to the t-code 
              SCCL?(A)
           A.     It has to be executed in the target client      
           B.      It is case sensitive
           C.     It has to be executed in the source
           D.     It shows all clients in the system

        4.   During local client copy, RFC connections must be created between 
             source and target clients? (B)   
           A.     True 
           B.     False        
         5.   During the client copy setup process which of the following has a 
              default value by default? (A) 
             A.     Target client     
           B.      Source system name
           C.     Source client       
           D.     Selected profile
         6.   Naming convention of a logical system is? (B)
           A.    CLNT(SID)(CLIENTNO)
           B.     (SID)CLNT(clientno) 
           C.     (clientno)(SID)CLNT
           D.     None of the above

         7.   Which of the following statements with relations to client copy are
              correct? (B & C)    
  A.           During client copy only user master records and authorization profiles
can be copied.
   B.           Before actual copy resource check and simulation can be done during test run. 
           C.     SCC4 can be used from any client         
           D.     SCCL can be used from any client   
 
          8.   During client copy? (B & C)
           A.      No one can login to source or target client
           B.     You can login to source client but objects cannot be changed 
                      in the source client   
             C.     No one can login to target client 
           D.     No one can login to source client

      9. BD54 and SALE can be used to? (A)
           A.     Create logical systems        
           B.      BD54 is used to create logical systems and SALE can be used to        
                    sell  Products.     
           C.     Create technical systems
           D.     Delete a client

10. To copy all client-specific data without changing documents, which of the    following profile has to be selected? (C)
           A.      SAP_CUST
           B.      SAP_USER
           C.       SAP_ALL
           D.     SAP_APPL

11. Which of the following commands can be used to check background jobs? (A)
           A.      SM37        
           B.     SE37
           C.     SM36
           D.     SA36

12. Which of the following are correct with relation to SAP instances and SAP clients?(C)
           A.     Both are same
           B.     Clients are made up of instances
             C.      We can login to the same client trough different instances     
           D.     Instances are made up of clients

13. A client in an SAP system is? (C)
           A.      A business partner
           B.      Workstation
           C.     Business entity 
           D.     A customer

    14. The t-code used to see the log after a client copy is? (B)
           A.     SCC1
           B.      SCC3        
           C.     SCC6
           D.     SCC9






SPDD and SPAU in Upgrade

Upgradation project are like
1. Technical Upgrade
2. Functional Upgrade
In technical project process steps like
1. System preparation and stack level patch upgrade – Basis Team
2. SPDD Phase – ABAP and Functional
3. Upgradation of the system – Basis Team
4. SPAU Phase – ABAP and Functional
5. DBACOCKPIT for indexing – ABAP TEAM
6. Issue resolution and error tracking – ABAP and Functional
7. Zprograms corrections – obsolete function modules and objects

SPDD Phase
This transaction code SPDD is the core step in an upgrade project. The system compares all the dictionary objects – data elements, database tables and structures of the latest system (say ECC) with the previous or the old system (Say 4.6c). These all elements are present under two nodes – with modification assistant and without modification assistant. Objects present under with modification assistant have the modification assistant ‘ON’ and we can see the modification logs. The objects in green color as shown below are the objects processed already and the ones in blue are the ones which still need to be processed.
Apart from the nodes – “With modification assistant ‘and ‘without modification assistant”
There is one more node sometimes – ‘Deleted objects’. This node contains objects which are deleted in the newer version of SAP and this node is to be left as it is.
 The objects under ‘With modification assistant’ and ‘Without modification assistant’ are to be processed by the ABAP team. The ABAP team clicks on the objects one by one – it takes us to the corresponding object – data element, structure or database table in the SE11 transaction code where we need to do the version comparison of the object.
Click on Utilities → Versions Version Management. There it shows all the versions of the object. The topmost or the latest version is of the Latest SAP Version and the versions below are the previous or modified versions. Now, we need to compare the Latest SAP version with the previous versions. Click on the check boxes of the two versions to compare and then click on the ‘compare’ button. We have to choose two and only two versions in order to compare them. In the comparison, it shows the differences in the two versions. We can click the Delta Comparison to see the delta differences between the two versions of the object. Now, after seeing the comparison, the ABAPER has to decide whether he wants to keep the Latest SAP version (ECC) of the object. (Reset to Original) or he wants to keep the changes made or modifications made (Adapt Modification) in the previous system (4.6c).

Example: say a table MEDA is there in SPDD. When we click on it and go to the version comparison, suppose it shows that 2 new fields are added in the Latest SAP version (ECC), when compared to the older version (4.6c).The ABAPER has to analyze the pros and corns of this objects – If he resets the table to original in SPDD, the 2 new fields would be added in the table MEDA. If he Adapts modification, whenever any transaction or any program tries to store or read any value from the two new fields, it might give a short dump. So in this case, it is better to go for ‘Reset to original’.
Considering another example, if say a data element say PRODH1 was of length say char7 in the previous versions where it had been modified by the user from char5 to char7 by the user for their business requirement, and again in the Latest SAP version, its char5, then it is better to adopt modification since in some transactions the user might be storing char7 values instead of char5. So if we reset the object to original, it might give dumps whenever char7 length value gets stored in any field using PRODH1 data element.

SPAU Phase
The SPAU transaction contains the objects – Programs, Reports, Screens, Messages, Notes, Function Modules etc. which have difference in the Latest SAP request and the previous ones. This SPAU phase can be done either just after SPDD or after the Up gradation of the system by the Basis team. The same way we need to compare the objects in ‘Version Management’ and decide weather to ‘Reset to Original’ or ‘Adapt Modification’. The ‘Adapt Modification is however slightly different for codes – Function modules, reports etc. In adapt modification, the SPAU gives us the empty space to write our code – by having a reference to the code in previous request, we can decide and write the code with some corrections when required. This is in the case of objects present in ‘Without Modification Assistant’. In case of ‘With modification Assistant’, it opens a the program code in grey mode and we can insert or delete or modify code by pressing corresponding buttons in a similar way we do to modify any SAP standard code by using the access key. The objects present in SPAU do not require any access key for a period of around 15-20 days after which SAP automatically locks those codes and after this locking, if we want to change or delete any code in SPAU objects, we would require an access key. So it is a good practice to finish the SPAU phase in 10-15 days time. In SPAU also, only one request is to be made for all objects as a best practice.

SAP R/3 System Parameters Review
This overview describes how security and controls can be implemented through system parameters. System parameters are used to maintain configuration over the operation of the SAP system. System parameters may define key settings for the whole system on which SAP runs, individual hosts systems (e.g. configuration for only one of many application servers) or the instances that are running on these servers. The majority of system parameters ensure that SAP operates effectively on the customer's preferred hardware, operating system and database platforms. System parameters also control how SAP operates and provides system wide control over some aspects of Security. System parameters are set using transaction RZ10. To make the parameters globally effective set them in the default profile, DEFAULT.PFL. To make them instance-specific, you must set them in the profiles of each application server in your R/3 System. System parameters can be reviewed with transaction TU02 or from the standard SAP report RSPARAM using transaction SA38.

Incorrect Logon, Default Clients and Default Start Menus
. Login/fails_to_session_end (default value - 3)
Defines the number of times a user can enter an incorrect password before the system terminates the logon attempt

. Login/fails_to_user_lock (default value - 12)
The number of times a user can enter an incorrect password before the system locks the user. If the system locks, an entry is written to the system log, and the lock is released at midnight.

. Login/failed_user_auto_unlock (default value - 1)
Unlocks users who are locked by logging on incorrectly. The locks remain if the parameter value is 0.

. Login/system_client
This parameter specifies the default client. This client is automatically filled in on the system logon screen. Users can enter a different client

. Login/ext_security
Since release 3.0E, external security tools such as Kerberos or Secude have managed R/3 System access. If this parameter is set, an additional identification can be specified for each user (in user maintenance) where users log on to their security system. To activate, set the value to X.

. rdisp/gui_auto_logout (default value - 0)
Maximum time allowed between input from the GUI before the frontend is automatically logged out. The value is set in seconds and the value of zero is used when this facility is not active.

. Start_menu
This parameter specifies the default start menu for all users and can be overwritten with the user-specific start menu (transaction SU50). The default is S000, and this value can be set to any other area menu code.

Password Security
System profile parameters define the minimum length of a password and the frequency with which users must change passwords.

. Login/min_password_lng
Minimum password length. The minimum is three characters and the maximum eight characters.

. Login/password_expiration_time
Number of days after which a password must be changed. The parameter allows users to keep their passwords without time limit and leaves the value set to the default, 0.

Note:  To prevent use of a certain password, enter it in table USR40. Maintain this table with transaction SM30. In USR40, you may also generically specify prohibited passwords.

There are two wild-card characters:
- ? means a single character
- * means a sequence of any combination characters of any length
Examples:
  - 123* in table USR40 prohibits any password that begins with the sequence 123.
 - *123* prohibits any password that contains the sequence 123.
- AB?  Prohibits passwords that begin with AB and have an additional character, such as ABA, ABB, and ABC

Securing SAP* user master record
login/no_automatic_user_sapstar
By default SAP is installed with a user master record SAP*. This user has the profile SAP_ALL with access to all transactions and programs in SAP. By default if this user master record is deleted then SAP allows logon using SAP* and a password of 'PASS'. Although the user master record does not exist, SAP grants unrestricted system access privileges to SAP*. By setting this parameter value to '1' this 'backdoor' access is blocked in the event the SAP* user master record is deleted. Prior to version 4.0 this parameter was login/no_automatic_user_sap*.

Tracing Authorizations
. Auth/check_value_write_on (default value - 0)
Authorization failures can be evaluated immediately they occur by running transaction SU53. This functionality is only active if the parameter is set to a value greater than zero in the system profile parameter.

. Auth/authorization_trace (version 4.0B onwards - default value - 'N')
When the parameter is set, any authorization checks performed are validated against existing entries in table USOBX. If the table does not contain the transaction/authorization object combination, then a new entry is added to the SAP reference table (i.e. USOBT not USOBT_C). Due to significant performance issues, SAP does not recommend this parameter being set in customer systems.

. Auth/test_mode (version 4.0B onwards - default value 'N')
When activated every authority check starts report RSUSR400. However SAP recommends not activating this parameter as the system is paralyzed if syntax errors occur in running the report and it has a significant performance impact.

Authority Check De-activation
. Auth/no_check_on_sucode (version 3.0E to version 3.1H - default value 'N'), Auth/no_check_on_tcode (version 4.0 onwards - default value - 'N')
From release 3.0E, the system checks on object S_TCODE. In upgrades from versions prior to 3.0E to set this flag to 'Y' to ensure that old profiles operate in the new system. By default, the function is inactive.
The flag should not normally be switched on because of the degradation in security that results.

. Auth/no_check_in_some_cases (version 3.0F onwards -default value depends on release)
This parameter needs to be set to 'Y' for installation of the profile generator. It defines the use of table USOBT in the authority checks undertaken and allows authority checks to be disabled in individual transactions. Whilst SAP recommends switching off unnecessary authority checks, the full impact of this should be considered carefully.

. Auth/object_disabling_active (default value -'N')
Whilst_no_check_in_some_cases allows authority checks to be switched off in for individual transactions, this parameter allows checks on individual objects to be switched off globally within SAP. It is recommended that this parameter is not set.

Number of Authorizations in User Buffers
. Auth/auth_number_in_userbuffer
When a user logs onto SAP, the authorizations contained in the user's profiles are copied to a user buffer in memory. The maximum number of authorizations copied is set by this parameter. The size of the buffer must always exceed the maximum number of authorizations as authorization checks are made only against those in the buffer.
The default value is 800, but this can be set to between 1-2000. Refer to OSS notes 84209 and 75908 for more detailed information regarding changes to the size of the user buffer.
Transaction SU56 shows the contents of the user's user buffer and a total for all the authorizations in a user master record.

Table, ABAP and RFC system parameters
. Rec/client (default value - 'N')
The parameter switches automatic table logging on. Images of the table before and after are logged rather than just changes and so consideration to which tables are to be logged and log volumes must be made before using this as part of a control solution.

. Auth/rfc_authority_check (default value - '1')
The parameter determines how object S_RFC is checked during RFC calls. The object has three fields, activity, the name of the function being called and the function group in which the function resides. The parameter defines whether S_RFC object is checked and if so, whether the function group field is included in the validation.
Value = 0, no check against S_RFC
Value = 1, check active but no check for SRFC-FUGR
Value = 2, check active and check against SRFC-FUGR

. Auth/system_access_check_off (default value - '0' - check remains active)
This parameter inactivates the automatic authorization check for particular ABAP/4 language elements (file operations, CPIC calls, and calls to kernel functions). This parameter ensures the downward compatibility of the R/3 kernel.

Useful Transactions
TU02 →Shows current parameters for all hosts and gives a history of changes to parameters
RZ10 →Maintain system parameters
RZ11 → View single system parameters and their functional area.
SU56 →Shows all authorizations a user has in their user master record and the total number. This is useful to identify apparent authorization failures caused by user buffer overflow.

Useful Reports
RSPARAM displays all system parameters set and applicable to the system and instance in which it is run.
From version 4.0 the RSUSR003 report also shows the settings for some of the critical password parameters. The report also shows identifies whether SAP*, DDIC or CPIC have insecure passwords by comparing value of the encrypted password field with the encrypted values of the standard shipped passwords. It also shows whether the SAP* user master record is absent from any clients.

SAP Background Job Scheduling



SAP Background Job Scheduling
There are two ways to define and scheduling Background jobs, which are as follows:
1. Using transaction SM36.
2. Using Job Scheduling Wizard. (For this, we need to start Transaction SM36, and then either select Goto @ Wizard version or simply use the button for Job Wizard)
Note: first approach is best option for the users having knowledge in background job scheduling, while second approach is for the users unfamiliar with SAP Background job scheduling.
Procedure:
  1.       Enter SM36 in OK Code field or we need to choose CCMS Jobs Definition.
  2.       Now we need to assign a job name to enter it in the Job Name Field
  3.       Then, we have to set Job's Priority or 'Job Class'.
              o    High Priority: Class A
              o    Medium Priority: Class B
              o    Low Priority: Class C
   4.       Then provide Target Server Field to indicate to use system load balancing.
        o    For the system to use system load balancing to automatically select the most
              efficient application server to use at the moment, so we will leave this field empty . 
        o    Enter a specific target server to use a particular application server to run the job.
   5.       We need specify email address using Spool list recipient button so that spool request
              generated by this job to be sent to somebody's email.  
   6.       Now in start condition, we can specify when to start the job and completing the  
             appropriate selections. To make job repeated or periodic, we need to check the box at the
             bottom of screen.

   7.       In this step, we define the job's steps by choosing Step, and then specify the ABAP
             program, external command, or external program to be used for each step.

   8.       Now all we have to do is to save the fully defined job to submit it to background job
             processing.
   9.       To modify, reschedule or to manipulate a job after scheduled for first time, we need to
              manage these from the Job Overview.