Here we are going to discuss the technical architecture of a typical SAP system. Then we’re going to move on to the landscape architecture and point out why we break our landscape into multiple systems.
Three-Tier Client Server Architecture of a Typical SAP System
The image below and to the right shows 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.
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. The application server is the brains of an SAP system. This is where all the central processing gets done.
You can see in the image the application server isn’t just one system in itself. The application server is made up of multiple instances of the processing system.
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 these three different layers in this complete 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.
Typical SAP Landscape Architecture
Now, let’s move on to look at a typical landscape architecture. Now, I say typical but you’ll find that when you work with SAP, there is no “typical” landscape architecture that most companies use. What you do find that is very common is a development system, a testing system, and then you’ll find the production system.
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 initial developments are complete to the point where we think they are good enough to be tested by 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 in our SAP landscape. In this case it is the testing system. On the testing system, normally no development is done at all. It’s just used for testing what developments were carried out in the development system.
If everything works out and all the testing activities are completed successfully, we then use a transport system again to move our developments of our program changes into the production environment.
When the ABAP code goes into the production environment, that is when it is used within by the business itself.
Why Separate The Systems In Our SAP Landscape?
An SAP system landscape is not separated into multiple systems just for development purposes. Your company can have other reasons:
- The quantity of data that a normal production system holds 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 may 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. For example, you have employee data on the system or 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.
It is worth mentioning that the three systems we have modeled here are normally a minimum. You normally have a development system, testing system, and the production system but it you may need to increase to four systems. Maybe you want a training system. Maybe you got multiple projects running at the same time. This may mean you need two different development systems. You could then have two different test systems followed by a consolidation system before it is passed to the production environment.
This is all dependent on the company that you work for, 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.