on 01-10-2014 9:18 AM
Hi all!
Scenario:
NW 7.01 SP10
SolMan 4.0 SP28
From time to time we are missing client entries in transaction SMSY under Product Systems/ERP/SAP ECC Server after the job LANDSCAPE_FETCH. This behavior is completly erratic. Affected systems are changing and the time period when it happens is not constantly.
What we find out is, that the affected systems have no entry in the table SMSY_SYST_CLIENT with "VERSION = ACTIVE". This entry was there before. But why was it be deleted by job LANDSCAPE_FETCH/program RSGET_SMSY?
Any help welcome!
Peter
Hello Peter,
Stop that job for test and try the following steps:
1.- Go to managed system and send the information to solman SLD trough RZ70
2.- On solman fo to SMSY and delete the system
3.- check if the system in updated correctly on SLD
3.- On solman go to SE38 and run the report SMSY_FETCH_SYSTEM_UPDATE
P.D: Solution Manager 4.0 is out of maintenance, be careful because you can send a support message to SAP for that product version of solman if you have a problem.
Regards,
Luis
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hola Lluis!
>Go to managed system and send the information to solman SLD trough RZ70
We can´t predict which system will be affected next!!! The system is changing from time to time.
> Solution Manager 4.0 is out of maintenance, be careful because you can send a support
I can or I can not???
Hasta luego!
Peter
Hola Lluis!
Que tal?
>you can use a test SLD with only that systems where you found that problem.
That is a good idea! But as I told you we can´t predict which system is affected.
>Sorry for the mistake, I try to write "CAN'T", sorry.
No problem!
>Have you solve the problem ?
No, I think! Until today everything is working fine. But we don´t know when it will happen again.
Hasta luego
Peter
Hola Peter,
I don't try to predict affected systems ,
Just take one that now, as you indicate before, currently don't have clients on SMSY_SYST_CLIENT and try to update that system again trough RZ70 from the managed system.
After that follow my steps on a previous answers (Jan 10, 2014 7:48 PM).
Regards,
Luis
Hi Peter,
Normally this will happen when the overwrite system data in the SMSY. ( smsy_setup t.code) .
Again rerun the LANDSCAPE_FETCH , it will update the details in the table.
Rg,
Karthik
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You may need to manually adjust the data in the SLD.
It's possible that the "Read Remote" is only updating the SMSY and not pushing this back to the SLD.
When a system's data changes, it updates the SLD which causes an update to SMSY, which might be overwriting your manual updates.
By putting the required clients in the SLD against the technical system, you might be able to stop them being removed from SMSY.
Hope that makes sense.
As I said, it's just a guess really. Not 100% sure on the actual process that goes on with regards to when data is updated in the SLD, but this could explain the randomness.
Regards.
Darryl
Hi Darryl!
>When a system's data changes, it updates the SLD which causes an update to SMSY, which might >be overwriting your manual updates
But the funny thing is:
1.) The data of the affected system has not changed.
2.) After one manuel update the job LANDSCAPE_FETCH was running fine for several days.
Regards
Peter
If you log into the SLD admin page: http://server:5xx00/sld as someone with SLD admin privs, then under Administration there's an option to view the log.
Hi Peter,
Delete the system in SLD , SMSY and again add the system in SLD and wait for job to add the system in SMSY. also check in smsy_setup.
Check in smsy data synchronize for SLD ( not RFC). if u not delete the system it will create new SID like SID00001. so better try the above process.
Rg,
Karthik
Are there any errors in the background job logs for LANDCSAPE_FETCH?
Thanks.
Darryl
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
84 | |
24 | |
11 | |
9 | |
7 | |
6 | |
5 | |
5 | |
5 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.