SAP Library - Find your answers

Brief Description About SAP Basis Implementation

Please give a brief description about implementation process carried out.

There is no standard Implementation process, it purely depends on which methodology person have adopted for implementation. I will give you broad view of implementation project... I am just starting from sizing of the servers ...

1. Identify the no of users and type of users

2. Design the technical system landscape of servers

3. Do the sizing based on users, documents created.

4. Convert your sizing requirement in to Hardware requiremnet

5. Consider the backup procedure also

6. Then start with the setup of development landscape

7. Define client strategy, transport strategy, User management.

8. Fix the support package levels.

9. Tune the system for performence

10. set up the QA systems

11. Define client copy strategy

12. Setup the PROD systems

13. Apply for Pre Golive report

14. Monitor system of db load

Please give a brief description about implementation process carried out.

There is no standard Implementation process, it purely depends on which methodology person have adopted for implementation. I will give you broad view of implementation project... I am just starting from sizing of the servers ...

1. Identify the no of users and type of users

2. Design the technical system landscape of servers

3. Do the sizing based on users, documents created.

4. Convert your sizing requirement in to Hardware requiremnet

5. Consider the backup procedure also

6. Then start with the setup of development landscape

7. Define client strategy, transport strategy, User management.

8. Fix the support package levels.

9. Tune the system for performence

10. set up the QA systems

11. Define client copy strategy

12. Setup the PROD systems

13. Apply for Pre Golive report

14. Monitor system of db load

The basis for the Zero Administration Memory Management under Windows NT is the dynamic Extended Memory. This technique provides you with a nearly unlimited memory resource. Initially, the extended memory is set to the size of the profile parameter phys_memsize ([PM]). If the user requires more memory, Extended Memory extends itself in steps from "[PM] / 2" up to the set limits in the profile parameter em/max_size_MB , or until the address space in the NT page file is used up. By setting the default value for em/max_size_MB to 2000 MB, the size of the NT page file represents the actual limit for extending the Extended Memory. The profile parameter phys_memsize determines how much of the total main memory is used by R/3. The parameter is entered according to the input at installation. The default value for phys_memsize is the size of the main memory [MM].

The memory allocation strategy for a non-dialog work process was changed as of Release 4.0B. Through the previous allocation sequence, the extended memory was protected to the benefit of the heap memory. This is no longer necessary when using the dynamic Extended Memory, and the allocation sequence of the batch work processes is identical to the sequence of the dialog work processes (see Allocating Memory for User Contexts). Another beneficial side effect is that you can avoid the PRIV mode (see Private Memory) for background work processes and thereby the expensive restarting of work processes.

Sequence of allocating memory for non-dialog work processes:

1. Roll memory until the limit
ztta/roll_first
2. Extended memory until the limit
min {em/address_space_MB, ztta/roll_extension}
3. Roll memory until the limit
ztta/roll_area
4. Heap memory until the limit
abap/heap_area_nondia

The basis for zero administration memory management is a sufficiently large NT page file. The previous recommendation

NT page file = 3 to 4 times the main memory size

still remains.

All relevant memory management parameters are set with an optimal default value so that all manual configurations are unnecessary.

See also: Memory Management under Windows NT

The Implementation Roadmap consists of the following five phases, as we have
previously seen within ASAP:


• Phase 1: Project Preparation. In this initial phase, you plan your implementation
project and make all the preparatory steps, including setting the objectives for the
project, determining the scope, defining the project plan, project team members
and establishing the activities and sequence for the implementation activities.

• Phase 2: Business Blueprint. The purpose of this phase is to determine the project
scope and create the Business Blueprint. The Business Blueprint documents
business process requirements and additional goals for your implementation.


• Phase 3: Realization. The purpose of this phase is to configure and test the
business processes defined in the Business Blueprint phase and create customerspecific
end-user documentation and training materials.

• Phase 4: Final Preparation. The purpose of this phase is to prepare and conduct
end-user training and perform a final test of the SAP system before going live.
You also prepare and execute data conversion from legacy systems to the
production system. You should also resolve all open issues.

• Phase 5: Go Live and Support. The purpose of this phase is to move the SAP
system to a live production environment, establish a help desk support
organization for end users, and optimize the system performance and technical
environment as far as possible. In this phase, you also plan follow-up training and
define an upgrade strategy to continually improve the SAP system.

AS/400 architecture uses a single level storage architecture (single storage principle) to implement the R/3 Extended Memory model. For this memory architecture, the main memory and the disk from the system are handled as an one address space.

Even if a large address space is assigned as an R/3 memory unit, the single level storage architecture and the dynamic memory allocation of the AS/400 operating system enable unused memory pages to be transferred, and to be available for use by other requests. Furthermore, you do not have to copy data to or from the context of the R/3 work process.

AS/400 memory pools are assigned subsystems. The resource needs of an R/3 instance are handled within a subsystem. The entire memory available for an instance is the allocated memory for the corresponding subsystem with the description R3_, where represents the number of the R/3 instance. R/3 jobs compete for resources with other jobs assigned to the same memory pool. The AS/400 subsystem description defines the size of the memory assigned to the instance.

Implementing R/3 Extended Memory on AS/400 has the following effects:

• Roll area Unlike other platforms, user contexts are not swapped in or out of work processes using copying. Instead the roll area is implemented in the same way as the R/3 Extended Memory. Under AS/400, a roll-in is reached by setting pointers for the user roll memory.

The implementation enables the roll area setting to be at a higher value (max. 16 MB) so that the roll extension area in the R/3 Extended Memory model is not required. The memory from the roll area is dynamically allocated up to 16 MB according to the requirements of the executed dialog steps. If you require additional memory, extended memory is allocated as planned in the R/3 memory model.

Since no data is copied during the swapping, the corresponding system profile parameters are not used. You must set these parameters (rdisp/ROLL_MAXFS and rdisp/ROLL_SHM) to 0 (null).

• R/3 Paging AS/400 does not differentiate between the paging cache (R/3 system profile parameter rdisp/PG_SHM) and the paging file (R/3 system profile parameter rdisp/PG_MAXFS). The entire paging file is buffered. For this reason, the settings for rdisp/PG_SHM and rdisp/PG_MAXFS are identical.
• Shared Memory Pools You do not have to define or manage any shared memory pools (defined with the parameters ipc/shm_psize in the system profile). This means, you do not have to allocate the logical shared memory segments to the new shared memory pools.

The parameter ipc/shm_psize is ignored on AS/400.