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

[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.