Conversion of Logical Systems (as of NetWeaver 6.20)
As of NetWeaver 6.20, SAP provides the option to convert logical systems using a new transaction that is more transparent and easier to use. Transaction BDLS has been used for this purpose until now. This transaction remains unchanged, and is enhanced by the new transaction BDLSS. In contrast to BDLS, in BDLSS logical systems can also be converted remotely in all partner systems.
Before you begin the processing, note the following points:
· It is not possible to convert logical system names in a productive system.
· While the conversion program is running, no other activities can be executed in the affected systems, including communication with other systems.
· All IDocs in the system must be processed, because the logical system name could be contained in the IDoc data record. Logical system names in IDoc data records are not taken into account in conversion.
· First perform the conversion in the current logical system (current client). Normally, the logical system name is then also converted in all partner systems. The tables for the definition of logical system names (TBDLS, TBDLST) receive special treatment in the current system. After you have entered the system names, the system checks whether they have already been defined. The old system name is not changed in conversion. Instead, you add the new system name, and when the conversion process is complete, including in all partner systems, manually delete the old system name from the tables. For the current system, SAP recommends that you carry out conversion for client-specific tables as well as cross-client tables. For all other systems, only the conversion for client-specific tables is recommended.
· Do not manually change the logical system names in the relevant tables. If you do, the application documents will not be found, or will only partially be found.
· Users of this program have the authorization object B_ALE_SYS in their user profile. SAP recommends that only the ALE system administrator is given this authorization.
· Before starting the conversion in the partner systems, you have converted the logical system in the current client.
1. Enter the transaction code BDLSS
2. The initial screen of the transaction provides an overview. This overview displays all communication partners for the current system, who are defined in the ALE distribution models, and for whom the partner type 'LS' (logical system) is maintained in the partner profiles.
3. If the RFC destination determined for this system can be accessed, the Technical Info column displays the system ID and the client. You can also start conversion in the partner system remotely from here.
4. In the dialog box for the Set Parameters function, enter the logical system name that you want to convert in the Old Logical System Name field. Enter the new name in the New Logical System Name field. If a conversion has been carried out for the current system and the log is still available, the appropriate values are entered for these two parameters.
5. To set further parameters, choose the relevant tab page, for example, the parameter Number of Entries per Commit Work. The default value is 1000000 for Oracle databases and 100000 for other databases. This value is only relevant for conversion. To improve performance, this value should be as large as possible, as long as the database roll area is sufficient. If necessary, you can also adjust this value to suit the relevant system.
6. After you have set the parameters, you can start the conversion process remotely for each system. The following options are available for converting logical system names:
Convert Client-Specific and Cross-Client Tables
· Renaming the logical system name, therefore changing the logical system name in all application tables of all partner systems.
· Creating a new system by database copy. In this case, call the new system a different name to the original system.
Convert Client-Specific Tables
· A typical application is the conversion of the logical system name after client copy:
1. Choose the appropriate option for your application.
2. The conversion process can be carried out online or in background processing (default). In background processing, a batch job is planned in the corresponding system and started immediately.
3. You first need to start the conversion in the test run. If the radio button Test Run is selected, the system first analyzes all relevant tables, and then determines the number of entries to be converted. The result of the test run is saved in the database and recorded in a log, which can be displayed as a list. If the parameter Check Existence of New Names in Tables in Test Run is activated during the test run, the system checks whether the new logical system name already exists in the application tables. If it does, a warning is displayed in the log for these tables. Check the tables that contain this logical system name, and determine whether these entries need to be converted. If you do not want to convert these entries, do not start the actual conversion.
4. The conversion also affects tables for communication partners, which are identified by partner number and partner type. If the partner number and the logical system name are the same, these table entries are also converted.
5. In some applications, you may only want to select and convert specific data from the database table. To do this, you can select or exclude the tables to be converted by entering the objects in the Tables for Conversion selection screen in Set Parameters. Table T000, for assigning the client to the logical system, receives special treatment and cannot be excluded. This table is checked and converted at the start of the conversion process. Note that if only one table is converted, the definition of the client for the logical system is also converted, if this assignment is defined in the current client. This means that the application documents in converted tables are found, because they refer to the new system names, while application documents in tables that have not yet been converted are not found, because they still refer to the old logical system names. It is therefore advisable to convert all tables in one step.
6. Check the conversion logs to see whether the conversion process was successful. Check the results of the conversion. For example, a * character at the end of the table name indicates a cross-client table. If you use Convert Client-Dependent and Cross-Client Tables, the existing entries in these tables are replaced by the new logical system names. If you do not want to replace these entries, choose Convert Client-Specific Tables, so the old entries in cross-client tables are retained.
7. After the conversion process has been successfully completed, the system generates a conversion log. This shows which tables and fields have been determined for the conversion, and how many entries are relevant or have been converted.
· The value in the Number of Entries per Commit Work field is only relevant for the actual conversion (not for the test run). To improve performance, this value should be as large as possible, as long as the database roll area is sufficient.
· Depending on the size of the dataset in the system, the conversion process can last a long time.
· The test run for certain parameters is executed once, and the result of the test run is used for the actual conversion. To improve performance, you can execute the program for the actual conversion at the same time. This parallel processing can take place in different clients, or in the same client for different tables.
· If you are sure that the new logical system name has not already been used, you can deactivate the parameter Check Existence of New Names in Tables in Test Run.
· If you definitely do not want to convert same tables, or you want to handle some objects individually, use transaction BDLSC to exclude these tables or include the objects. Note that defining objects in this way affects all clients. Also note the order in which the objects are to be handled. There is a predefined programming interface for this.
· If the conversion process is terminated for any reason, it can be restarted, because the converted data is committed as a table or in sections within a table.
Checking and Changing the Communication Settings
· Asynchronous communication: Partner profile
logical system name is converted, the partner name is also converted in the
corresponding partner profile, and the partner status in the partner profile
is set to inactive.
After conversion, check the partner profile (port and RFC destination). Change these if necessary, and activate the changed partner profile.
· Synchronous communication: RFC destination
After the logical system name has been converted, check the RFC destination for synchronous communication, and change it if necessary.
Was this page helpful to you?
Do you have any additional feedback?
The following content is not part of SAP product documentation. For more information, see the following disclaimer .