DOUBTS ABOUT LOGICAL NAME IN SRM

[Former Member]

Hi all...

We have installed SRM Server 5.5 in our landscape, before, we had SRM 3. Now, we are in phase where we must assign logical name to SRM server and we have a doubt, we don´t if we use the same logical name we´ll get any issue with middleware (R3 and BW). We think that it´s possible that do this may cause inconsistencies because there are many references to old SRM, like RSBASIDOC table in BW system.

When we installed srm test server (we use another logical name) we have some integration problems with R3 test system, so that, we run BLDS in r3 to change old logical name to new logical name. Then everything works fine.

But we think it isn´t a good idea run bdls in productive system but we are not sure that if we use same logical name may cause us any problems with old references in middleware.

Thank very much all!

[Former Member · Accepted solution]

Hi

<b>Please see the links -></b>

Regards

- Atul

[Former Member]

Hello Diego,

if you run BLDS in a productive system you may get problems with your existing shopping documents. I'm not sure, but BLDS changes the customizing tables only.

As I understand it, the logical system name is the one and only identifier for SAP systems, therefore you should get no problems with middleware etc. if you name your new system identically to your old system. But you have to deactivate or deconnect your old system before you name the new system.

Maybe one of the experts here can verify this.

Hope that helps,

Karsten

[Former Member]

Hi

FYI... Transaction name is <b>BDLS</b> not 'BLDS'...

<b>Here is the detailed description on using BDLS Transaction -></b>

<u> Transaction <u>BDLS</u> <-> ( Tool: Conversion of Logical System Names )</u>

This program is used to convert a logical system name, which has already been defined or used in this system, to a new name. The program determines all the relevant tables and converts the corresponding entries.

Note:

Logical system names cannot be converted in productive systems. While the conversion program is running, no other activities can be performed in any part of the system, including communication with other systems.
All IDocs in the system must have been processed, because the logical system name could be a part of the IDoc data record. Logical system names within IDoc data records are not considered in conversion.
The conversion takes place in the current client. Sometimes, you also need to convert the logical system name in all partner systems. The tables for the definition of logical system names (TBDLS, TBDLST) receive preferential treatment. After you enter the system names, the system checks whether they have been defined. The old system name is not converted, and the new system name is entered in its place. Once the conversion process is complete, including in all partner systems, you then need to manually delete the old system name from all the tables.
Do not make any manual changes to the logical system names in the relevant tables. If you do, the application documents will no longer be found.
Note: Authorization

To execute the program, you need authorization for converting the logical system name (authorization object B_ALE_LSYS).
The following alternatives are available for converting the logical system names:

1. Convert client-specific and cross-client tables
Typical applications:
Changing the logical system name. This means changing the logical system name in all application tables of all partner systems.
Creating a new system by database copy. In this case, you need to give the new system a different name to the original system.
2. Convert client-specific tables
A typical application is converting the logical system name after client copy.
Choose the appropriate option for your application.

On the initial screen, enter the logical system name that you want to convert in the Old Logical System Name field. Enter the new logical system name in the New Logical System Name field.

It is advisable to start the test mode first. If you select the radio button Test Run, the system first analyzes all the relevant tables and determines the number of entries to be converted. These are displayed in a list. If the radio button Check Existence of New Names in Tables is selected, the system checks whether the new logical system name already exists in the application tables. If it does, a warning is displayed in the results list. Check the table in which the new logical system name is found, and determine whether you need to convert these entries. If you do not, terminate the conversion.

The conversion is also relevant for communication partners identified by partner number and partner type. If the partner number and logical system name are the same, these table entries are also converted.

The value in the field Number of Entries per Commit is only relevant for conversion. To improve performance, this value should be as large as possible, depending on the limits of the database roll area.

In the selection screen Tables for Conversion, you can select and exclude tables for conversion, and therefore target specific data in the database. Table T000, for assigning the client to the logical system, receives special treatment and cannot be excluded if you use Convert client-specific and cross-client tables. This table is converted last. 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 the converted tables can be found because they refer to the new logical system name, while application documents in tables that have not yet been converted are not found, because they still refer to the old logical system name. It is therefore advisable to convert all the tables in one step.

Check the conversion results. For example, the character * after the table name means that it is a cross-client table. If you choose Convert Client-Specific and Cross-Client Tables, the existing entries in the tables are replaced by new logical system names. If you do not want the entries to be replaced, choose Convert Client-Specific Tables, so that the old entries incross-client tables remain unchanged.

After the program has been successfully executed, a list is produced showing which tables and fields have been determined for conversion, and how many entries are relevant or have been converted. This process is recorded in the application log. To display the application logs, call the transaction SLG1 with the object CALE and the subobject LOGSYSNAME.

Note: Starting the conversion using background processing

The program RBDLSMAP can also be executed in background processing, by entering the appropriate values in the input fields. In this case, all security questions during the run are automatically answered with Yes.
Note: Performance

The value in the Number of Entries per Commit field is only relevant for the actual conversion (not for the test run). To improve performance, this value should be as large as possible, depending on the limits of the database roll area.
Depending on the size of the dataset in the system, this conversion can take a long time.
The test run for particular parameters is executed once. 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 a different client, or in the same client for different tables.
If you are sure that the new logical system name has not yet been used, you can deactivate the existence check in a test run.
If you definitely do not want to convert some tables, or you want to handle some objects individually, use transaction BDLSC to exclude these tables or define the objects. Note that defining these objects affects all clients, and so does the order in which the objects are to be handled.
Note: Restart capability

If the conversion process is terminated for any reason, it can be restarted, because the converted data is committed in tables or in sections of tables.
Note: Checking and changing the communication settings

Asynchronous communication: Partner profile
When a logical system name is converted, the partner name in the corresponding partner profile is also converted. The partner status in the partner profile is also changed to inactive.
After the 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.

Hope this will help.

Regards

- Atul