Mapping of Logical Systems

Introduction

                  This is going to be a simple and clear cut understanding on “Clients and Logical systems & How to handle them in our landscapes”. I have seen many posts in SCN about various transport errors due to logical systems and clients. So, I have decided to make this simple blog which can explain you clearly.

We will start with definitions of Client and Logical Systems.

Client

         A Client is a subset of data in a SAP System. We can secure/deal our data with respect to various Clients in a System. Eg: 100, 200 etc..

         We basically have Clients in both ECC and BW landscapes.

What if both Client no.s are same? Eg : ECC Client is 100 and BW Client is also 100

That’s exactly is the need for Logical Systems in both landscapes. Why a logical system is required? Logical Systems can communicate/identify perfectly between the various systems by pointing to right system with the combination of Logical System and Client No.

Eg: We can connect our one BW system (100) with multiple clients of source system  like 100, 120, 300 etc..

Now we will see the definition of Logical System.

Logical System

                            A logical system is an application system in which the applications work together on a common data basis. In SAP terms, the logical system is a client. 

This means, we have to assign logical systems to Clients to make them to communicate correctly via RFC connection definitions in RSA1–>Source Systems. This has to be done in all your Dev, Qua and Prod systems.

This is what we have to do in SPRO

Coming to the key point of this blog

Why we have to convert our logical systems  during transport ?

                      I will give you an instance to make us understand clearly. Let’s say we have created a transport request in Dev BW system and the naming convention of TR is DBWK90001.

                      If we transport the same TR to Qua BW, it will return you an error saying that “Conversion of Logical System Names” has not been done. It basically checks for the source system reference in target systems. That’s the reason we have to define them like below. The same entries can be found in RSLOGSYSMAP table.

What has to be maintained in Dev BW System?

       If you try to create transport requests directly in Qua system, then the naming convention of TR will be like QBWKXXXXX. The reason Why I am saying this, when you define conversion definitions like above, your DBWK90001 gets imported into Qua by identifying its source system reference with respect to “logical system conversion definitions after the transport”. This will avoid our transport errors due to logical system issues. 🙂

     If you observe the above screen shot, you can see Original Source system as PBW and Target System as DBW and the same scenario for PEC and DEC.

How come original Source system as PBW and Target as DBW? 😕

     Because, The landscape here in my example is D–>Q and D–>P which is a quite standard landscape. My screen shot settings(in Dev) will help in case we want to do reverse transports from Prod to Dev.

What has to be maintained in Prod BW System?

Your original source system should be your Dev logical system and target should be Prod logical system. Because you want to transport from Dev to Prod.

Landscapes may vary from company to company. You have to define entries accordingly. Suppose if your landscape is D–>Q–>P, then your original Source system should be Qua Logical System and Target should be Prod Logical System.

What has to be maintained in Qua BW System?

The original source system should be Dev Logical system and target should be Qua Logical System.

Conclusion

               These are very basic settings to be done before starting our BW project. I have just shared my understanding about what is happening internally between the systems. Hope this will help all..

Thank you for reading my blog 🙂