Phase Switch To Successfully Tested Not Working In Urgent Change

[barry_keating]

We have updated our Solution Manager development system to SPS08 from SPS03. Our development system has 4 clients (100, 801, 802 & 803). The 8xx clients mimics a CHARM landscape. I have gone through SOLMAN_SETUP for capabilities we have installed. This is basically CHARM and nothing else. When testing Urgent Changes, we cannot switch to the “Successfully Tested” phase. When passing to test, the transport is imported into the 802 client successfully but with a return code 4 error stating the source system is the same as the target system. This was not a problem previously.

We get the following error message: “Details: No import into test system has taken place yet”. I am assuming the problem is with the return code 4 from the transport import. Is there a config where we can set a tolerance level to disregard return code 4s.

Also, please guide me if my assumptions above were incorrect.

[raquel_pereiradacunha · Accepted solution]

Hi,

it's strange that you did not have return code = 4 when transporting to a client of the same system before, because I always had this rc when testing ChaRM with 3 or 4 clients in the same system. This is not because of ChaRM, but it's how the import works. I never had rc = 0.. But please note that rc=4 is not an error, it's just a warning and as you are testing using the same system, you can just ignore.

Regarding the message "Details: No import into test system has taken place yet", I have faced this many times and I hate it. If you run a Recheck, does it delete the error and understand that the import finished? Sometimes it's because the import takes longer and the program finishes without getting the return of the import. If it's very common that the imports in your system takes long time, there is a parameter CHECK_NTIMES_SOCM that you can insert in the users profile that can change how long the system waits for the import to finish. This parameter by default is 5, which means that the system will wait for 5 x 5 seconds before it returns. If you increase this parameter, the delay will be longer ( 5 x the paramater) and it may stop the error message in case the reason was a very long import time. But the higher is the parameter number, the longer you will wait looking at the Web UI until it finishes... And you should not set this parameter to more than 20 according to SAP to avoid very bad performance or even a time-out dump.

It also happened to me that the cause of this message was a problem in SMSY. The domain controller of the systems was not saved in SMSY (you have this field there for every system) and the program was getting lost because it was looking for the systems in the track based on the domain controller found in SMSY and as nothing was found it was not connecting via RFC to the managed system to get the result of the import.

Regards,

Raquel

[barry_keating · Accepted solution]

Thanks Raquel, your response got me looking into my situation and your suggestion on parameter CHECK_NTIMES_SOCM has helped me with another problem

Here is some more information on my situation.

·         I created separate development & productions systems with their own transport domains and CHARM infrastructure. Development had a client 801/802/803 landscape and the production system was linked to ECC & BW

·         Each had their own /usr/sap/trans folders

·         I added the development system to the production transport domain so I could have 1 source of transport files for consistency and to ease the migration of changes

·         My thought was all I needed to worry about was the transport domains. As it turns out the transport domain is part of the system definition in SMSY/LMDB. I had wanted to keep the development & production Solution Managers segregated when it came to SMSY/LMDB

My error described in my earlier post occurred when the urgent correction was checking the status of the import by using the wrong transport domain from the LMDB. I was able to correct the transport domain but the development Solution Manager project does not know about the production system. Thus the project is inconsistent and cannot be used.

Has anyone been able to accomplish what I am trying. In short I am trying to share a transport domain and keep everything else separate.

Thanks,

Barry