So we’re going to discuss the technical architecture of a typical SAP system. Then

we’re going to move on to the landscape architecture and just discuss why we break

our landscape into multiple systems. Here we have a slide showing a three-tier

client server architecture of a typical SAP system. At the top we have the presentation

server. The presentation server is any input device that we can use to control an SAP system.

So here we are showing the SAP GUI. But we are not limited to just using the SAP GUI.

We can use a web browser, mobile device or any other form of input you can think of.

The presentation layer communicates with the application server. An application server

is the brains of an SAP system. This is where all the central processing gets done. You

can see here what’s showing the application server isn’t just one system in itself.

Your application server can be made up of multiple instances of the processing system.

Now the application server in turn communicates with the database layer of the three-tier

architecture. The database is kept on a separate server, a separate system in itself mainly

for performance reasons but also for security as well. It provides a separation and that’s

why we have got these three different layers in this whole SAP system.

The presentation server communicates with the application server. The application server

does all the processing. It makes calls to the database. Data is passed back to the application

server. More processing is done before the results and then sent to the presentation

server. Now, let’s quickly discuss a typical landscape

architecture. Now, I say typical but you’ll find that when you work with SAP, there is

no typical (in inverted comments), landscape architecture that most companies use. What

you do fine that is very common is you’ll find the development system, you’ll find

the testing system, and then you’ll find the production system.

Now, why do we have these three systems? Well, it’s fairly straightforward. All the development

work and initial unit testing that we do in our SAP work gets done on a development system.

This ensures we do not affect any of the system that is being used by the company. Once our

developments we think are good enough to be tested by maybe an external source or someone

else within your company whose role is to carry out testing, we move our developments

using what’s called a transport system to the next system, which in this case is the

testing system. On the testing system, normally no development is done at all. It’s just

use for testing what developments were carried out in the development system. If everything

works out and everything passes in the test system we then use a transport system again

to move our developments or our program changes into the production environment. When code

goes into the production environment, that’s when it’s turned on and that’s when it’s

used within the business itself. Now a landscape architecture is not separated

just for development purposes. Your company can have other reasons. That can be the quantity

of data that a normal production system holds. It can be too great to actually be used in

the development environment because normally your development system and your testing system

are not as large as a production system. You only want a subset of data to test on. There’s

also the security element that you need to look at. More often than not, companies do

not want developers to see live production data for data security issues. You know, you’ve

got employee data on the system, you’ve got sales data, and you don’t want people

who are not involved in those specific areas to actually see the live data. So normally,

your development and testing systems have a different set of data that they can develop

and test on. Now, I would say, the three systems we have

here are normally a minimum. You know, you normally have got your development system,

testing system, and the production system but it can increase to four systems. Maybe

you want a training system. Maybe you got multiple projects running at the same time.

So maybe you’ve got two different development systems, you could then add up two different

test systems, you know, and then maybe a consolidation system before it is passed to the production

environment. This is all dependent on the company that you're gonna be working at. But

one thing that is common is that each system that you do have in your landscape architecture

will have its own application server and its own database server. This then ensures we

have platform independence.