If you've ever worked for a company, who has outsourced hosting to a partner, you might also have - for various reasons - had the pleasure of migrating from one hosting partner to another.
In such a migration the new hosting partner is eager to cleanup any relations to the old hosting partner, which makes a lot of sense. (New hostnames, IP-ranges, services etc.)
But sometimes the new hosting partner unintentionally deletes things from your system, which then causes log-files or applications to report on missing configuration.
Above case I experienced recently with a SAP System Landscape (SLD) - it started complaining about a missing HTTP destination, when doing sync to remote SLDs. But how to solve this?
Looking into the SLD configured for Synchronization, the list comes up empty:
So why is it still complaining?
#12 07/19/2018 08:45:27.063 [SLD Notification Thread-0] ERROR com.sap.sld.misc.DestinationServiceUtil: Could not get HTTP destination {0} from destination service
Thrown:
com.sap.security.core.server.destinations.api.DestinationException: [com.sap.ASJ.dest.sv0707] Application or service sap.com/com.sap.lcr tried to access destination SLD_SyncDest1 of type HTTP which does not currently exist in the destination service. You can create destinations in the NWA under Configuration Management-Infrastructure-Destinations.
at com.sap.security.core.server.destinations.service.DestinationServiceImpl.getDestination(DestinationServiceImpl.java:430)
at com.sap.sld.misc.DestinationServiceUtil.getHTTPDestination(DestinationServiceUtil.java:125)
at com.sap.sld.admin.SldAdminContentSync.getSyncInfos(SldAdminContentSync.java:244)
at com.sap.sld.contentsync.NotificationRunner.run(NotificationRunner.java:90)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:836)
Turns out that instead of deleting the configuration for synchronization of remote SLD in SLD Sync, the new hosting partner deleted the connection in NWA Destinations. So internally the local SLD still thinks it needs to sync data to the remote SLD.
To solve the problem I recreated the HTTP destination 'SLD_SyncDest1' (as reported in above log) with dummy information, which then allowed for the SLD Synchronization configuration to display the remote SLD of the old hosting partner. It also made it possible for me to delete the configuration for remote SLD from SLD Sync, effectively instructing the local SLD to not synchronize to remote SLD anymore. And as an added bonus the NWA Destination I recreated also got deleted successfully.
Ahhh, it's oh so quite in the logs for SLD now.