SID remains in SLD as WAS Java entry even when Java Stack is deleted

[Former Member]

Hi there,

Can somebody help me with next strange behaviour in the SLD.

Some SID's in our Landscape Components (tc SMSY) on Solution Manager has as Data Source 'SLD'.

These SID's comes from the SLD and are feeded by RZ70 for the ABAP part and by the SLD Data Supplier for the JAVA stack.

The SLD Data Supplier service is set up by the Virtual Administrator.

Now, we have systems in the SMSY with an sidname like <SID>_NABP.

These kind of entries has then SLD as datasource.

The problem is that I don't want these entries in the SMSY beacuse ther is no JAVA stack anymore.

The Java stack is removed completely.

I removed the WAS Java entry in SLD.

But, this enty in SLD is reset after a while.

So, when I remove the entry in SMSY on SolMan and in the SLD WAS JAVA, still the component is recreated in SMSY with datasourrce coming from SLD.

The data in SMSY is empty (no instance, no database). Only the SID and hostename is available.

What i believe is that something triggers the SLD Data Supplier but I can not reach it because JAVA and so Visual Administrator included is removed from the system.

Maybe, if somebody can tell me how SLD is feeded for the JAVA stack, I could find the solution.

I really hope that somebody can help me out.

Thanks

Paul Van Daele

Edited by: Paul Van Daele on Sep 9, 2009 11:06 AM

[stuart_campbell · Accepted solution]

Hi Paul

Thats great news

Although not obligatory, please feel free to add rewards points if you felt this information was useful

Best wishes

Stuart

[stuart_campbell]

Hi Paul

As per Seans additional thread - it may be possible the problem is in Solution Manager - some other definition or condition in SMSY or landscape fetch is keeping the entry alive

I also found note 1279177 which maybe of interest

Best wishes

Stuart

[Former Member]

Hi Stuart,

Thanks for the answer.

Note 1279177 was really the solution.

Thanks a lot

Kind Regards

Paul

[Former Member]

Those <SID>_NABP ("non-ABAP", i.e., Java) can certainly be hard to get rid of. It's like a zombie: you think it's gone, but it keeps coming back! What's happening is that it can't recognize that the system is loading from SLD matches one that already appears in SMSY.

Note 1301106 can help sometimes: tcode SOLMAN_WORKCENTER > Root Cause Analysis > System Conflict Resolution.

Failing that, the only thing that I have found to work is to carefully compare the SID and _NABP entries, and then copy the key value that makes _NABP look like it's a different system into the SID entry: most often that is the message server name. Then, next time it reloads, it sees that it has a system with that message server (for example), and won't create a new one. You may need to right-click on the SID entry and set its data source to manual to be able to edit the message server field.

Another possible key field is the database (under the Header Data tab): assign it the value of <SID>.

A more complicated problem is where the erroneous entries are instead for ABAP stacks, and look like <SID>000001. Those have System and Type defined (under the Selection of Main Instances tab) but for a product I never installed (e.g., Mobile Infrastructure). By assigning System and Type on my existing instances, those _00001 systems were no longer created.

[stuart_campbell]

Hi Paul

This is indeed unusual

As Solution Manager gets the data from SLD - I have to believe the problem lies with SLD

Is the SLD obtaining data from another SLD or Central SLD via export/import track or automatic forwarding - it could be this is where the entry is coming from

I guess also check data supplier connections between the WAS JAVA server and SLD server to see if there

is a data supplier update occuring - this would require someone from BASIS team or with network experience to

identify

Hope this helps

Stuart