SERVERS

[Former Member]

Hai,

Could u plz clearly explain me about the servers?

In Dev server we customize the things and where & how can we save the customization?

How can we transport the data from Dev to Testing

Could u plz explain me clearly

Thanks in advance

[Former Member · Accepted solution]

Please award points for useful answers.

Thanks

[Former Member · Accepted solution]

Really it helped me a lot,Thankq very much

[Former Member]

One more point. Your question is referring to servers - I think you are confusing terms server and system.

Server is not SAP system. SAP system is very scalable if you want you can have one SAP system (most probably PRD system) on many servers. SAP system composes from some basic elements:

Note: Again I am going to simplify so please pardon me for omitting some specialties.

1.) database - you can have dedicated server (or even two servers in cluster) just and only for database

2.) central instance - central instance is set of services and processes you need for SAP to function - this is (along with database) most important part of SAP system - without it, SAP will not work (again it can be installed on cluster if you want)

3.) application server(s) - usually one or more additional servers that have dedicated services and processes to serve the users; application server is cooperating with central instance and without it cannot function

Now you can see that one SAP system can in fact be on more than one server. This allows you to improve performance by buying more servers rather that upgrading the current one.

Opposite thing is that you can have more SAP systems installed on one server (usually DEV and QUA can be on one server - depending on size and parameters of the server).

[Former Member]

I am not sure if my explanation will be "too simple". But here it is:

In every SAP system landscape you usually have three types of system: DEV (development), QUA (quality) and PRD (production).

Note: You can have less or more - depending on you actual needs.

The schema of these three types is following:

DEV -> QUA <-> PRD

DEV: In development system you can do everything you want. Developers can have full rights and do whatever they need to do. Here you have only testing data - small sets of "some" data entered to see "some" result. Problem of this system is that you cannot see real environment results performed on real data (meaning real types of data and real amounts of data).

PRD: Production system is absolutely crucial for the customer. They need it to live. Without it they cannot effectively work. Problem is this system is that customer will not let you to test any report on this system, risking corruption or lost of data.

QUA: That is why quality (or testing, preproduction, etc.) systems are existing. These systems are between development and production. These systems are designed to test finished programs on real data before sending them to the production system. To have latest production data you are doing operation called system refresh. This operation is practically deleting of your QUA SAP system and restoring it from the backup of production PRD SAP system (including post-refresh operations like renaming database, change of SID, BDLS, etc.)

To move the programs (and customization and other stuff) from DEV to QUA and from QUA to PRD you are using TMS (Transport Management System).

Every change you made on DEV system can be recorded into TO (transport order). After you are satisfied with the status of the programs/customizations you can release the TO and it will be written to a disk into files (two files will be generated - data file and cofile). These files will be written into the shared directory (usually /usr/sap/trans). This directory is accessed by all SAP system in landscape.

After the releasing of the TO in the DEV system you can add it to the transport queue in the QUA system (and on PRD system as well). Common practice is that developers have no rights to use TMS - so they cannot import their programs into the QUA, etc..

Another common practice is that QUA and PRD systems are locked against any change so the only possible changes can be made through the DEV --> QUA --> PRD way. This is big advantage, because you ALWAYS have QUA in sync with PRD and it can never happen that something that works in QUA perfectly will not work in PRD.

When doing this configuration I suggest you study settings in client definition (transaction scc4). Also you need properly configured TMS system (transaction stms) including shared directory for transport files on OS level.

This is just basic overview and it includes a lot of simplifications.

If you want to really understand TMS I suggest you read <a href="http://help.sap.com/saphelp_erp2005vp/helpdata/en/14/94fc3f8fc2c542e10000000a1550b0/frameset.htm">Change and Transport System</a> documentation.

[Former Member]

Hi,

In the logical context, a server can be a SAP System with one or multiple SAP and database instances spanning over one or multiple physical machines.

Customization is normally carried out by the relevant BPXs through the Implementation Guide (IMG) - Transaction Code : SPRO.

While Customization, changes are automatically recorded in the form of change requests which can be transferred to 'Testing' through TMS.

Surfing Whizzy