How do you connect to the remote server if you are working from the office for the client in remote place.

WAS web application server or ITS are generally used for this purpose. If you are sitting at your office with a server which is in the system and the other server is at the clients place you can generate IDOC, intermidiate documents which carry the data you want to transfer or the documents you want to transfer, these IDOC are interpretted by the system at the recieving end with the message class with which it is bound with. If you want to logon a system which is very distant..then remote login can be used this depends on the internet speed.

Explain about roll area , Dispatcher, ABAP-Processor.

Roll area is nothing but memory allocated by work process. It holds the information needed by R/3 about programs execution such as value of the variables.

Dispatcher :All the requests that come from presentation server will be directed first to dispatcher. Further dispatcher sends this requests to work process on FIFO(First In and First Out) basis. Dispatcher recieves the request from client and assigns the request to one of the work process.

Roll area: Each workprocess works in a particular memory that memory is known as Role Area, which consists of User context and session data. ABAP- Processor :is an interpretor which can execute logic

From Excel to ABAP – Is batch mode possible ?

DATA w_file TYPE string.
* Convert the file path into string
w_file = p_input.

* Internal Table should have same field sequence as EXL File.

CLEAR t_upload.
REFRESH t_upload.

* Call function to upload the data into internal table
CALL FUNCTION ‘GUI_UPLOAD’
EXPORTING
filename = w_file
filetype = ‘ASC’
has_field_separator = ‘X’
TABLES
data_tab = t_upload
EXCEPTIONS
file_open_error = 1
file_read_error = 2
no_batch = 3
gui_refuse_filetransfer = 4
invalid_type = 5
no_authority = 6
unknown_error = 7
bad_data_format = 8
header_not_allowed = 9
separator_not_allowed = 10
header_too_long = 11
unknown_dp_error = 12
access_denied = 13
dp_out_of_memory = 14
disk_full = 15
dp_timeout = 16
OTHERS = 17.
IF sy-subrc NE 0.
* MESSAGE ID sy-msgid TYPE sy-msgty NUMBER sy-msgno
* WITH sy-msgv1 sy-msgv2 sy-msgv3 sy-msgv4. ELSE.
* Delete the first row of heading from the uploaded table
DELETE t_upload INDEX 1.
ENDIF. ” IF sy-subrc EQ 0.

Administration

AL11 Display SAP Directories

BD54 Maintain Logical Systems

OSS1 Logon to Online Service System

SALE IMG Application Link Enabling

SARA Archive Management

SCC3 Copy Analysis Log

SCC4 Client Administration

SCC5 Client Delete

SCC7 Client Import Post-Processing

SCC8 Client Export

SCC9 Remote client copy

SCCL Local Client Copy

SCU0 Customizing Cross-System Viewer

SICK Installation Check

SM01 Lock Transactions

SM02 System Messages

SM04 User Overview

SM12 Display and Delete Locks

SM13 Display Update Records

SM14 Update Program Administration

SM21 System Log

SM35 Batch Input Monitoring

SM50 Work Process Overview

SM51 List of SAP Servers

SM56 Number Range Buffer

SM58 Asynchronous RFC Error Log

SM59 RFC Destinations (Display/Maintain)

SM66 System Wide Work Process Overview

SAINT SAP Add-on Installation Tool

SPAM SAP Patch Manager (SPAM)

SPAU Display modified DE objects

SPDD Display modified DDIC objects

ST11 Display Developer Traces

ST22 ABAP/4 Runtime Error Analysis

SU56 Analyze User Buffer Alert Monitoring

AL01 SAP Alert Monitor

AL02 Database alert monitor

AL04 Monitor call distribution

AL05 Monitor current workload

AL16 Local Alert Monitor for Operat.Syst.

AL18 Local File System Monitor

RZ20 CCMS Monitoring Configuration FILE Cross-Client File Names/Paths

RZ04 Maintain Operation Modes and Instances

RZ10 Maintenance of Profile Parameters

RZ11 Profile parameter maintenance

SE93 Maintain Transaction Codes

SM63 Display/Maintain Operating Mode Sets

SPRO Customizing: Initial Screen

SWU3 Consistency check: Customizing Database Administration

DB01 Analyze exclusive lockwaits

DB02 Analyze tables and indexes

DB12 DB Backup Monitor DB13 DBA Planning Calendar

DB15 Data Archiving: Database Tables Jobs

SM36 Define Background Job

SM37 Background Job Overview

SM39 Job Analysis

SM49 Execute External OS commands

SM62 Maintain Events

SM64 Release of an Event

SM65 Background Processing Analysis Tool

SM69 Maintain External OS Commands Monitoring

AL08 Current Active Users

OS01 LAN check with ping

RZ01 Job Scheduling Monitor

RZ03 Presentation, Control SAP Instances

ST01 System Trace

ST02 Setups/Tune Buffers

ST04 Select DB activities

ST05 Performance trace

ST06 Operating System Monitor

ST10 Table call statistics

ST03 Performance, SAP Statistics, Workload

ST07 Application monitor

STAT Local transaction statistics

STUN Performance Monitoring (not available in R/3 4.6x)

Points to consider when Sizing

This sizing questionnaire is designed to collect enough information to allow us to configure and characterize an appropriate SAP Business Information Warehouse (SAP BW) landscape.

1. Customer Information-This includes customer contact information, in case the sizing engineer needs further input to process the sizing. Here we also ask about the number, version and software of OLTP source systems as well as certain operational issues important to the overall system design.

2. Landscape Configuration
     and  DW Design Planning-This section covers all information around the planned system and DW landscape as well as the Data Model design.

3. User Activity and Workload-There are three basic components to size for a SAP BW system:  number of users/processes, query mix and quantity of data stored in the DW.  This section will gather the information necessary to perform this process.

4. Data Quantity-In this section we ask for the amount of data you have planned to store in your DW and the data model you have planned to use.

5. Technical Requirements-Here we gather information regarding certain technical requirements, such as clustering or backup technology, that may influence the sizing of the system.

Before any sizing begins, a conference call between the SAP customer and various SAP technology partners (sizing partners) is very helpful – by determining the answers to the following questions, the sizing engineers greatly improve their chances of architecting a mySAP solution “right” the first time, and thus avoid or minimize subsequent and time-consuming re-sizings. The sizing engineer should ask the following:

• Why are you implementing SAP?

(business reasons will impact HA and other considerations)

• Are you interested in a low cost/maximum value solution?

(price sensitivity will drive platforms)

• Is overall performance/response time the driving factor behind the configuration?

(max performing disk subsystem/RAID configuration, more application servers)

• Is overall availability of the system critical or simply ‘important’ – how many nines of availability are you looking for?

(HA and DR considerations)

• Does your company anticipate growing/shrinking via acquisitions/mergers/divestitures soon?

(impacts role/potential for scalability in the solution, or the ability to easily redeploy assets if no longer needed)

• Are you biased towards one OS over another (i.e. W2K or a specific version of UNIX)?

• Are you biased towards a particular database/RDBMS? (Oracle, SQL Server, DB2, etc)?

• Are you biased towards a particular hardware vendor (HP, IBM, other)?
• Do you want the ‘latest and greatest’ hardware? (technology perspective – hot plug RAM or PCI, support for the fastest processors with the most cache, platforms that support the most RAM, 64 bit architectures, etc) Why?

• Do you want the ‘latest and greatest’ database release? Why?

(risk vs potential for improved performance or latest HA options)

• Do you want the ‘latest and greatest’ OS release? Why?

(risk vs potential for improved performance or latest HA options)

• What level of expertise do you have in regards to implementing and supporting SAP?

(will drive specifying a solution stack with which the company is familiar)

• Do you understand the role, or need, a ‘Technical Sandbox’ specified for your SAP system landscape?

• What about a ‘Training’ system earmarked for end-users? Other specialty systems?

• Will you want to provide Internet browser-based access to the system to be sized?

• Will you be implementing another mySAP.com component shortly after this system?

(might drive adoption of platforms with a longer life cycle)

• Who has been selected as your systems integration partner (SI) and functional partner?

(may drive platform, based on their expertise or core competencies)

• Who is your hardware reseller, or are you buying direct?

(indicated price-sensitivity and to some extent partners, and therefore competencies)

• Are there any vertical industry solutions expected to be implemented as part of your mySAP solution? Which ones?

(this drives core sizing in terms of CPU, RAM, and disk requirements)

• What do you perceive to be the greatest risk in implementing this SAP system?

• Will you be stress-testing the proposed solution prior to Go-Live? Why/why not?

(drives “super-sizing” of, or building additional overall capacity into, the solution)

SAP Server Pre-Installation Checklist (HW and OS only)

Verify Basic Data Center Infrastructure Installation

1. Ensure that all server/disk subsystem racks are physically installed.

2. Ensure that all servers/disk shelves are physically installed.

3. Verify that all PCI and other controller cards occupy a “standard” PCI or other slot in each server (for example, all public NICs should reside in slot x, and all HBAs for external SAN connections should reside in y and z).

4. Ensure that all SAN disks are physically installed.

5. Ensure that all SAN cabinets are cabled to SAN Switches, and all SAN Switches are cabled to redundant HBAs in each Database or other SAN-attached server.

6. Ensure SAN disks are to be carved into volumes consistent with your SAP Competency Center’s recommendations.

7. Ensure that all servers are cabled via 10BaseT CAT5 to redundant network switches (as dictated by the solution sizing or HW requirements).

8. Verify that the public and private (and cluster interconnect, if applicable) network connections are clearly labeled and ready.

9. Verify that all HOSTNAMES and IP addresses (including management appliance or similar IP addresses) have been determined and documented in advance of actually installing OS’s.

General Power and HA Power Requirements

1. All racks should be configured with redundant PDU’s.

2. All servers, disk subsystems, and network equipment should be installed with redundant power supplies.

3. Each power supply should be connected to different PDU’s.

4. Each PDU should be connected to a separate UPS (preferred) or power source.

5. Ensure that all power is laid out as required, L6-30P for servers and L6-20P for SAN/Disk subsystems (verify specifics with your hardware partner).

Update HW configuration (as required)

1. Perform all firmware (FW) upgrades prior to configuring any drives at a hardware level – upgrade all array controller(s), drives, and system boards to versions/release levels approved by the hardware vendor and your SAP Competency Center.

2. Assume 4+ drives are installed in each server – typically, 1 drive is mirrored to another, for two mirror-sets total. Check with your SAP Competency Center or solution sizing for specifics.

3. Carve the local disks. Start the Array Configuration Utility or equivalent to verify configuration of local server drives

4. Create 2 arrays, 1st drive mirrored to 2nd, 3rd drive mirrored to 4th.

5. Ensure that a hot spare is set up, if room is available for another drive.

6. Unless specific testing has been performed that indicates another configuration is better, go with all array controller default values. For example, ensure that read/write cache is set to 50/50.

7. Create 1 logical drive per array (do not create more than one logical drive per array unless directed to do so per the sizing).

Update OS (assumes W2KAS/SPx currently installed)

1. Verify that the base W2KAS OS load has been performed, and that the currently supported service packs/patches have been applied)

2. Choose a SAP system name consistent with your naming standards. The NAME must NOT exceed 13 characters in most cases (SAP limitations), though this varies. Since other applications are still limited to 8 characters, the best way to go is to choose a name that does not exceed 8 characters but still manages to reflect the role of the server.

3. Create the admin/installation user (i.e. r3padm, verify the name with the SAP Basis team) – MUST BE lowercase – and give this user domain admin (or admin) rights – note that ALL SAP installations, updates, and administration activities need to be performed with this user ID.

4. Ensure that all LOCAL drives are formatted for NTFS (explorer, select root, file, properties, general tab), 64kb recommended for log and data files, 4kb or 8kb recommended for all others.

5. For INTERNAL drives only (to be used for OS and pagefile), depending on the physical drive size, you may wish to create 2, 3, or more drives on each physical array. For example, with 18 GB drives, 3 drives of about 6GB is common. Be consistent across all servers.

6. Label all disk drive volumes, i.e. – C: OS, D: UTIL, E: PAGE1, F: PAGE2, G: PAGE3, H: PAGE4, Z: CDROM, or equivalent (as per standards)

7. Set the TEMP environment variable (control panel, system) – used by R3setup.bat or other installation processes, which will be executed later by the SAP Basis team.

8. Create the C:\TEMP directory if it doesn’t exist already.

9. Perform Pagefile sizing – 4x physical RAM, 10 GB max OK unless directed otherwise (may wish to round up just to be consistent).

10. Configure pagefiles via Control Panel, System) – suggest 4095 MB on drives C:, E:, F: – refer to the standard Pagefile sizing developed for customer’s EA environment.

11. Modify the default ‘Server’ service property – change it to ‘Maximize Throughput for Network Applications’ (this changes how memory/cache is allocated, and is set via network & connection places, properties, pick connection, properties, file and print sharing, properties)

12. Grant ‘everyone’ permissions to root/all subdirectories of all logical drives

13. Ensure your hardware specific driver-overlays are up to date, and approved by the hardware vendor’s SAP Competency Center. For example, it’s common to load special network, array, and management drivers that replace the default W2K drivers.

14. Load the SNMP service (W2K) if not loaded already- note that service packs and other updates/patches may need to be reapplied.

15. Load any solution stack management agents not already loaded, as directed by the SAP Basis team.

16. Check the W2K Event Viewer for issues

17. Check the Management Console for issues

18. Select a 3-character SID (system ID), consistent with Customer’s EA naming standards.

19. Set up an alias for SAPTRANSHOST in the HOSTS file – edit C:\WINNT\SYSTEM32\DRIVERS\ETC, and add an entry for SAPTRANSHOST to point to the particular system’s central instance.

20. Verify that Internet Explorer is at version 5.x.

21. OPTIONAL – after the ENTIRE SAP INSTALLATION, go back to Control Panel, System, Performance, and change ‘foreground’ to ‘background’ – this ensures that a locally logged-on user does not rob the logged-in SAP R/3 clients of their otherwise entitled memory/processor cycles. You may also wish to load any array configuration or management utilities locally on the server, too, to facilitate future change control/troubleshooting.

Prepare for the DB and R/3 installation

1. Read through the pertinent INSTALLATION guide (InstGuide – print it, make it easy on yourself!) and the standard SAP product guide (may be found on CD with the installation kit)

2. Request that the SAP Basis team obtain any pertinent SAP Notes – see the InstGuide for a list of pertinent notes, and read these – they may impact the basic setup of the server/infrastructure.