SAP Basis Sample Interview Questions

Sample SAP Basis (System Administration) Interview Questions with Answers

SAP Basis (System Administration) interview questions can cover a very wide range.

Here is a sample of questions that a typical Basis Consultant can be expected to face.

Q1. How do you check if your system is a Unicode system?

We are planning to transport Objects between two SAP systems, one of which is Unicode and the other without Unicode.

Is it possible to do this? What are some of the issues I may face?

Answer;

There are a few ways to check if your system is Unicode.

On the SAP system
When logged on to the SAP system, click System -> Status

At OS level
Logon to OS level with SIDADM userid and run disp+work. In the output, you will see if the system is Unicode.

To answer the second part of the questions; While it is possible to transport objects between a Unicode and a non Unicode SAP system, the process has to be approached with caution.

A general prerequisite for this type of transport is that the R3trans belonging to the system is used during both the import and export processes.

There are generally two classes of problems:

Technical transport problems (that is, the transport fails) and

Logical transport problems (the transport works, but the transported data does not fit in the target system).

Transports from Unicode systems to non-Unicode systems

a) Technical transport problems

o        ‘Exotic’ languages
Exotic languages are those for which a character is used within SAP that does not appear in the Latin 1 character set. An example is Azerbaijani (AZ), which is represented internally with the character 0xB89A.

Entries of language-dependent tables in such languages cannot be imported into ASCII systems. To ensure this, an R3trans version should always be used to import Unicode exports into ASCII systems.

o        Report texts in Japanese or Chinese
Japanese and Chinese texts are displayed in ASCII with double-byte code pages. Depending on the available size of the target fields, the system may truncate texts during the conversion from Unicode to ASCII.

o        “Exotic” characters in table keys.
Here, “duplicate key” errors may occur during the import.

o        Warnings with non-printable characters.
During an ASCII import, some characters cannot be mapped to meaningful ASCII characters.  When this is the case, the log displays corresponding messages and these messages may also contain non-printable characters.

b) Logical transport problems

o        Language-dependent character conversion
Texts that contain non-Latin1 characters require a special character conversion. This happens automatically for language-dependent data if the R3trans transport program can recognize the language dependency (for example, for tables with a language field in the key).

o        Special characters during the transport of Unicode to ASCII.
In general, you cannot retain special characters when transporting from Unicode to ASCII if the target code page does not contain a corresponding character. These characters are mapped to ‘#’, and in this case, a warning is issued in the import log.

o        Transport of Customizing objects with address data
Problems may occur during the transport from a non-Unicode system to a Unicode system, between two Unicode systems, and during the transport from a Unicode system to a non-Unicode system.

o        Transport of screens from Unicode systems
Transporting screens in the 3.1 or 4.0 format from Unicode systems may result in defective screen source codes, depending on the operating system used.

o        Transport of texts (R3TR TEXT) and forms (R3TR FORM)
These objects may be unreadable after a transport.

2. Transports from non-Unicode systems to Unicode systems

a) Technical transport problems
o        Up to now, there are no known technical transport problems.

b) Logical transport problems

o        Language-dependent character conversion
Texts that contain non-Latin1 characters require a special character conversion. This happens automatically for language-dependent data if the R3trans transport program can recognize the language dependency (for example, for tables with a language field in the key).

o        Transport of Customizing objects with address data
Problems may occur during the transport from a non-Unicode system to a Unicode system, between two Unicode systems, and during the transport from a Unicode system to a non-Unicode system.

Q2. In addition to outputting SAPscript forms or Smart Forms to a printer, we also need to send them as a PDF attachment to an email.

How can we do this?

Answer;

For SAPscript forms, from within your application print program, you need to call the SAPscript function module OPEN_FORM with the parameter DEVICE = ‘MAIL”.

To send a Smart Form as an email PDF attachment, when calling the function module of the Smart Form from your application print program, you need to set CONTROL_PARAMETERS-DEVICE = ‘MAIL’ and the corresponding mail parameters.

In this way the OTF data is transferred to the SAPCONNECT interface and the PDF conversion is done there.

The device type used in the PDF conversion process is defined for each language in transaction SCOT as follows: SCOT -> Settings -> ‘Device type for Format Conversion’

Q3. We have tried to setup Single Sign-On with SAP logon tickets in Application Server
ABAP and an error is displayed in the trace of transaction SM50.

What kind of errors might you see and how would you fix them?

Answer;

While setting up Single Sign-On, you may see some of the following errors;

1. Invalid certificate
This error means that the signature of the SAP logon ticket cannot be checked. The reason for this error is often because
o        the certificate that is used is no longer valid.
o        the certificate that is used is not yet valid.

In the system that issues the ticket, check the validity of the certificate that is used. If necessary, create a new certificate which conforms to the above criteria.

2. An entry is missing from the access control list (ACS)
The ACL is client specific and must be maintained in the client in which you intend to use the SAP logon ticket. In the accepting system, use transaction STRUSTSSO2 to check whether the ACL is maintained in the corresponding client.

3. There is an obsolete entry in the ACL
When an entry is added to the ACL, the serial number of the certificate is also added. If you have created a new certificate in the system that issues the ticket and its serial number is different from the serial number used previously, you must update the entry in the ACL also.

4. The certificate does not exist in the certificate list
This error means that the certificate of the issuing system cannot be found. The reason for this error is often because
o        the certificate of the issuing system is not in the certificate list of the system Personal Security Environment (PSE) in the accepting system.
o        there is an obsolete certificate of the issuing system in the certificate list of the accepting system (for example, after the regeneration of a key pair in the issuing system).
o        the accepting system is configured so that a different PSE is used to verify the logon ticket which the certificate of the accepting system does not contain.

5. Receiver data is incorrect
For the SAP assertion ticket, the receiver data must match the current system data. Therefore, you must check the entries in the issuing system.

6. No digital signature could be generated
To issue a digital signature, the system requires a PSE. The PSE is stored on the file system of the application server and additional meta information about the file is saved in the database. If you now change the file directly at file system level, inconsistencies may occur.  In particular, when the system issues an SAP logon ticket that is digitally signed by the application server, the trace displays the following additional entry:

N *** ERROR => Ticket creation failed with rc = 1441801. [ssoxxkrn.c 704

To correct this problem, proceed as follows:
– Call transaction STRUST
– Double-click the entry “System PSE”
– From the menu, select “PSE > Save as.. .”
– Select the option “System PSE”
– Confirm the dialogs that follow

=> As a result, the PSE is saved again in the file system and the database tables are
cleaned up.

Q4   When would you recommend that a company uses Virtual Host Names instead of physical host names when installing an SAP system.

How would you do this installation?

Answer;

Using virtual host names might be useful when you want to quickly move SAP servers or complete server landscapes to other new hardware without having to perform a reinstallation or complicated reconfiguration.

Another reason might be the naming convention for DNS names specified in the security policy of your company – if, for example, an application must run with a unique virtual host name.

Before you install your SAP system using a virtual host name, you must first prepare your operating system and check whether it is configured properly for using virtual host names.

1.        Define a new DNS A-record for each virtual host name.

Example for a DNS A-record: 10.67.4.28  enterprise

We do not recommend using DNS CNAMES.

2.        Make sure that the reverse DNS lookup for this new name works properly.

3.        Add the IP address to the network card configuration.

4.        Check whether the IP address was successfully bound by opening a command prompt and entering the ipconfig command.

5.        Check whether the reverse DNS lookup works correctly with the nslookup command (for example, nslookup <ip-of-enterprise>).

6.        Check whether the local IPv4 address is returned with the ping command (for example, ping –a enterprise).

7.        Check whether the reverse DNS lookup works correctly with the nslookup command (for example, nslookup <ip-of-enterprise>).

8.        To use the virtual hostname enterprise, configure the Windows operating system as follows:
a.        Add the value DisableStrictNameChecking to the registry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters

b.        Add a value DisableStrictNameChecking of type DWORD set to 1.

c.        To apply the changes, either reboot your system or restart the Windows Server service without rebooting.

d.        Add the value BackConnectionHostnames:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

e.        Add the new multi-string value BackConnectionHostNames. Enter the fully qualified domain name (FQDN) (in our example: enterprise.wdf.sap.corp) and the short name.

To use virtual host names, you do not have to change the local hosts file: %windir% \system32\drivers\etc\hosts.

However, you can use a virtual host name that only works locally to allow the operating system to “find itself” using a virtual name.

Then add the name to the local hosts file.

9.        Check whether the virtual host names work properly in Windows.

If they do not work properly, you get an Access denied error. In this case, correct the registry keys and values.

Use the following options to perform the checks:
o        Enter the command: net view \\virtualhostname
If you get the message Access denied, either the registry keys are not correctly set, or you have to reboot your Windows operating system.
o        Use the net view \\virtualhostname command from other servers.
If you get the error A duplicate name exists on the network, the key DisableStrictNameChecking is not correctly set.
o        Use the SAP MMC and connect to computer virtualhostname:
Open the SAP MMC.
Select File –> Add/remove Snap-in …
Select Computer Management and choose Add.
Click OK.

To install your system using a Virtual Host Name, you must;

1.        Start SAPinst from a command prompt and execute the following case-sensitive
command: SAPINST_USE_HOSTNAME=<virtualname>

2.        Proceed as described in the installation guide.

After the installation has finished successfully, your system is available in the SAP MMC. The system uses the virtual host name.

In our example, the host name is PWDF1000 and the virtual host name is ENTERPRISE.

Q5  Our production Database size is less than 100 GB and daily backups are possible.

Can you advice what our database backup strategy should look like and how should faulty backups be treated?

Answer;

SAP data is stored in a relational database. A data backup consists of database files and SAP files such as programs, log files, and so on, which are stored centrally under /usr/sap/… .

You use operating system tools to back up this directory tree, which is part of the hierarchical file system. As this data generally only changes when profile parameters are modified or after an upgrade, you only need to perform a backup in such cases.

Since it is generally very dynamic, SAP data requires a comprehensive security strategy.

The size of the database is less than 100 GB and daily backups are possible.

If the SAP System does not have to be available after 18:00, you can perform the backup offline.

Alternatively, you can perform the backup at a time when the transaction load is low. A full backup of the data (without log redo information) fits onto two tapes, if DLT techniques are used.

To be able to deal with a faulty backup, several generations of backups have to be available.

Therefore, for this example, the retention period is set to 28 days and consequently 27 backup generations are available in the event of database failure.

The tape pool ought to contain several reserve tapes, shown as “+ x” in the above graphic. The additional tapes – I recommend approximately 30% of the required number – are intended as a reserve in case the amount of data to be backed up greatly increases or an extra unplanned backup becomes necessary.

Using a separate tape pool, you also need to back up the redo log information generated during the day, which is temporarily stored on a separate large disk until the tape backup.

As this data is necessary to recover a database after restoring a data backup, never set the retention period for the redo log tapes to less than the retention period for the data backup tapes. Particularly in the case of an online backup, it is best to always back up redo logs directly after the data backup.

Without redo log information the online backup is worthless.

As the redo log information is much more dynamic than the database data, even more reserve tapes are required.

I recommend you to back up the redo logs twice for extra security, so that you need 2 x (52 + x) tapes in the redo log tape pool.

More Interview Questions? Have a look at:

110 SAP Basis Interview Questions with Answers & Explanations – eBook