SLD landscape Strategy

Hi All
Can anyone please point me to SLD installation/implementation strategy. Can SLD/Solution Mgr can be installed on the physical box.
Thanks you.

Hi Julio,
SLD is a concept introduced by SAP from its netweaver releases. Yes solution manager can be installed on a physical box.
For SLD implementation strategy please visit:
http://help.sap.com/bp_epv170/EP_US/Documentation/How-to/Configuration/Post_Install_SLD_NW_2004s.pdf
Please award points for helpful info.
Regards.
Ruchit.

Similar Messages

SLD Landscape Question

Hi
We are about to implement the SLD landscape for our PI systems.
From the documentation (SDN and HELP.SAP.COM), it is recommended to have all SLD Data Suppliers send to the PI Production SLD Bridge. The SLD data is then automatically forwarded to the DEV/QA SLD Bridge (Design Time SLD).
This is straight forward and I can see how to get the ABAP stack to look at the correct SLD Server.
However, when it comes to the JAVA stack, I can't see how to configure the SLD CLIENT of an instance in the design-time landscape to use the design-time SLD Server.
Version of Netweaver in 7.0.
Thanks
Doug

SAP Web AS (Java) 6.30/6.40 Start-up: JProbe's Direct Support
This feature is available starting with JProbe 5.2.2. For details of application server integration, refer to the JProbe documentation. Here, the single steps for the SAP application server are briefly described.
Step 1: Create an Integration for the instance to be profiled.
 Click Tools -> Application Server Integration.
 Choose SAP Application Server 6.30.
 Click Create.
 To fill out the columns, follow the help you get via tooltip.
 Specify whether server or dispatcher should be profiled.
Step 2: Create a Configuration.
 Click Tools -> Manage J2EE Configurations.
 Click Add.
 Fill in Configuration Name and Integration.
 Optionally, you could specify an application to be profiled; this is just used to help to set the correct filters for profiling. If you know which packages or classes should be profiled, you can leave these fields empty; otherwise, specify the directory where the application is deployed and the .ear or .war file in this directory.
Step 3: Create the J2EE Settings.
 Click Session -> New J2EE Settings.
 Specify the configuration.
 Specify the other options, especially set filters (optionally, you could use the application specified in the configuration for filtering).
Step 4: Use the Connection Manager.
 Different to "startup via jlaunch" below the Connection Manager has to be used.
 Click Tools -> Options -> Advanced Session; mark "Use Connection Manager."
Step 5: Check the property 'IDxxxxxx.JavaPath' in instance.properties in the directory /usr/sap/<SID>/JCxx/j2ee/cluster
 JProbe relies on the property to find Java home, but there are Web AS 6.30/6.40 SPs that do not have this property.
 If it is not included, add it for dispatcher or server (dependent on which one should be profiled)
 For example, add "ID8156650.JavaPath=C:/java/jdk1.4.2_06."
 Be aware that using the standard startup procedure instance.properties is overwritten, so you might repeat this step.
Step 6: Start the J2EE Engine with JProbe
 Start the database and the central instance (enqueue and message server).
 In JProbe click "Run" for the J2EE settings defined before.
 Dispatcher and server of the J2EE Engine will be started; the one specified in the Integration will be profiled.
SAP Web AS (Java) 6.30/6.40 Start-up: Using JProbe 5.2.x via JLaunch
Starting the Server via JLaunch
Detailed instructions how to start JLaunch can be found in the documentation of SAP Web AS (Java). Here we give only the minimal list of steps:
 1.
 Include the location of JLaunch in the PATH
 2.
 Go to base directory of dispatcher or server (depending on which one you want to start).
 jlaunch pf=c:\usr\sap\<SID>\SYS\profile\<SID>_JCxx_<Host>
 -nodename=IDxxxxxxx
 where "IDxxxxxxx" can be figured out from the "instance.properties" in directory "cluster."
Creating a JProbe Startup File
In order to start up JProbe via JLaunch, you need to create a start-up file (.jpl) with the JProbe launchpad as follows:
 1.
 Click Session -> New J2SE Settings
 2.
 Enter filters, triggers, ...
 3.
 In the Configuration main class and the classpath fields are mandatory; a dummy entry for main class is sufficient, for classpath you could use %CLASSPATH%
 4.
 Save the .jpl file
 5.
 Switch off the Connection Manager; in JProbe 5.2.x a Connection Manager is introduced, which does not work if a Java application is started from a C-framework; therefore use Tools -> Options -> Session -> Advanced to switch off the Connection Manager
 6.
 Change the .jpl file with a text editor
 Comment out the line starting with -jp_java
 Add the connection information and the snapshot directory information; related to the introduction of the Connection Manager this is not written when the .jpl file is saved in the launchpad
 o
 -jp_socket=<host for analysis>:<port> (e.g. localhost:4444)
 o
 -jp_snapshot_dir=<snapshot directory> (e.g. c:
Jprobe
snapshots)
Starting JProbe with the Server
Start JLaunch as above, but attach the following parameters to the JLaunch command line:
jlaunch pf=... -nodename=... -Xbootclasspath/a:JProbe-Base-Dir\lib\jpagent.jar
 -Xrunjprobeagent:-jp_input=.jpl-file
For the .jpl-file please, specify the complete path. If there are blanks in the file or directory names, use double quotes or the DOS notation (e.g. PROGRA~1). After starting JLaunch you can now attach the viewer to it (JProbe -> Program -> Attach to Remote/Running Session).
regards
chandra

SLD Landscape Best Practice recomendation

I am seeking advise on setting up SLD in my ever growing landscape.
I currently have a Master SLD on the same system as my NWDI system and a local SLD on my Solution manager 7.0 system that is updated from the master.
The Master SLD is shared by our ECC6 Duel Stack landscape and my BI 70 Duel stack portal landscape.
I have upcoming projects of implementing a PI 7.1 landscape, implementing CTS+ and a Solution Manager Enterprise upgrade all of which will be heavily dependent on SLD.
I have seen documentation that PI would like it's own local SLD.
My question is what would be the prefered SLD landscape and how to I get there. Any recomendations or best practices would be most appreciated.
Bill Stouffer
Basis Administrator.

Hi,
SLD that we have implemented in our landscape is like bleow:
1) All PI and Portal system has local SLD.
2) For all non- production system, we have one SLD and production system we have seperate SLD.
3) It means we are following 3 tier SLD landscape as resommended by SAP.
4) Main SLd lies on solman, for production we have seperate and non-production we have seperate. non production and production sld sent data to main sld that is on solman.
4) All systems except PI and portal send data to production and non-production sld. PI and portal systems first send data to local which in turns send to production and non-production sld.
5) So by this way you whole environment is secure as production sld is different.
So, i will recommend to have 3 tier SLD approach. One of the important thing is don't use cenrtal user to send data across SLD as one user lock will in turns be the fallback of whole environment. So, always make each system specific user for data transfer so that user lock of one system will not impact other.
If you need any other information please let me know.
Thanks
Sunny

Solution Manager Landscape Strategy

Hi Everyone
Can anyone please point me the document that talks
about Solutiom Manager landscape strategy. Is it recommend to
have Sandbox, Dev/QA/Prod instance of Solutiom Manager or we just need
one instance and connect all other system.
Thank you

I will add my two cents...
A three SM landscape strategy works pretty good:
#1 - Sandbox Solman - no satellite system connectivity; open access; used for the purposes of testing patches and exploring solman functionality - mostly for basis' purposes.
#2 - 'Development' Solman - only satellite systems that are NOT on the path to production would be connected here - such as a sandbox. This solman system would be used for configuration of solman itself [example, your solman team would configure solman functionality here]. It is also a good practice environment for PM's because it would have a small landscape attached to it [your sandboxes, remember]? Migrations start here for solman functionality...
#3 - 'Production' Solman - ALL path to production satellite systems connected here, except your sandboxes [which were connected to #2 remember?]. This system also serves as a target system for migrations that came from #2 [for solman functionality itself], This is the main solman box that most users will access for project management, blueprinting, config, charm, and so forth.
This type of landscape satisfies ITIL requirements as changes made to solman itself are migrated from #2 to #3; changes are not made directly in the prod box.
Hope this helps,
Jen

CIM Modle in SLD landscape

Hi all,
I read few blogs before CIM/CR content update, when I see in my SLD landscape I do not see CIM model, I can only see CR content,
my requirement is to update both CIM and CR, since I do not find CIM model I got confused..
can anyone clarify...

Hi Gaurav and Arun,
thanks for the reply, now I got CIM and CR content version,
I read note 669669, this is really helpful.
CIM update is straight forward, latest version can be deployed, CR content I have to check how many sequences to import.
thanks,

SLD Landscape Design Question

After reading the Planning Guide - System Landscape Directory, I am left with a question.
The Setup:
Standard three system landscape
ECC 6.0 Ehp5 on NW 7.02ECC Instances: DE1, QE1, PE1
PI 7.31
PI Instances: DP1, QP1, PP1
PI Business Systems: DE1CLNT100, QE1CLNT100, PE1CLNT100
Each PI Instance has a local SLD
Management LandscapeSolution Manager 7.1 on NW 7.02
SolMan Instance: SP1
Local SLD
LMDB
Reading through the Planning Guide, the recommendation (pg. 45, picture below) seems to be to have all systems self-report to PP1. That is, without synchronization, only PP1 knows about any systems because they all report to PP1 and do not report in to their local SLDs. The data is then sent back to DP1 & QP1 via bridge forwarding. Business Systems are manually entered into their respective local SLDs, but then have to be manually exported/imported from DP1 --> QP1 --> PP1. Once it's all gathered into PP1 again, all data is pushed to SolMan's SLD on SP1 via a unidirectional content synchronization.
If I read this correctly, then all SLD's will end up "knowing" all systems and business systems: e.g. the sld of DP1 will have entries for QP1 and PP1 and for business systems QE1CLNT100 and PECLNT100.
Earlier in the guide, I gathered that there was value in not having all of the data in Development in that there is then clear separation between non-production SLDs and production SLDs. The above recommended setup seems to go against this idea of separation. Plus, it requires a significant amount of manual upkeep.
As an alternative (pictured below), what if each environment only reported to it's local SLD (DE1 --> DP1, QE1--> QP1, PE1--PP1). (Note that in the picture the SLD is drawn separate, but I've heard that most customers run their local SLD on PI, so the SLD depicted in each environment actually runs on the PI system in this scenario.) Further, what if the SLD's then synchronized sequentially in a full unidirectional content sync fashion. (DP1 does a full uni-directional Content Sync to QP1, QP1 does a full uni-directional Content Sync to PP1, and PP1 does a full uni-directional Content Sync to SP1.)
DP1 would only know about it's own systems. QP1 would know about it's own plus DP1 (which it needs). PP1 and SP1 would both have full visibility into all systems. Furthermore, the manually entered business systems would also be automatically synchronized and the whold manual export/import process could be avoided or a manual export/import could be implemented between Q and Production for safety with an automatic bridge forward of Data Supplier data.
Are there downsides to the second scenario that I am not seeing? Please comment!
Best regards,
--Tom

Although the guide states that Dev systems only needs to know about other systems in the DEV environment and QAS systems only needs to know about systems in the DEV and QAS environments and only PRD needs to know all systems, I am finding that I can't get the groups set up correctly when the DEV environment has no visibility to the QAS environment.
It seems that the recommended structure (where all systems are known in all environments) will facilitate the correct setup of the PI transports. So far, that is the biggest arguement I've been able to find against the second approach outlined above. Using full sync all the way through is also not an option if you're doing any development as any changes in the DEV system automatically flow through to PRD almost instantly. Using automatic bridge forwarding and import/export might be a usable alternative, but the recommended approach from page 41 of the planning guide does seem to have the best of all worlds.

Landscape Strategy for SM1 & SM2

Hello all,
I am new to Solution Manager (and SAP in general) so I came here to seek for your opinions.
I have SM1 and SM2 installed in one box. SM1 serves as our playground (sandbox) and SM2 serves as the semi-prod.
SM1 is in Solution Manager 7.0 EHP1 SPS 20 while SM2 is still in Solution Manager 7.0 SPS 16.
Currently, I have 11 other systems as follows:
- ECC 6.0 (1st and 2nd instances)
- PI (with SAP NetWeaver 7.1)
- XI (with Netweaver 04)
- EP with NW 7.0 (1st and 2nnd instances)
- BI with SAP NetWeaver 2004s (1st and 2nnd instances)
- SRM 7.0 EHP1 SPS 03
- APO (SCM 5.00) (1st and 2nd instances)
all 1st instances are treated as dev systems while 2nd instances are treated as semi-prod systems
How can I go about the Landscape stategy for the two? That is, which systems to connect to SM1 and which sdystems to Connect to SM2?
i was thinking of the following concepts:
1st option:
#1   SM1 (dev't) - only satellite systems that are NOT on the path to production would be connected here - such as a sandbox. This solman system would be used for configuration of solman itself example, your solman team would configure solman functionality here. It is also a good practice environment for PM's because it would have a small landscape attached to it your sandboxes, remember? Migrations start here for solman functionality...
#2   SM2 (semi-prod) - ALL path to production satellite systems are connected here, except your sandboxes which were connected to SM1. This system also serves as a target system for migrations that came from the dev system (SM1) for solman functionality itself. This is the main solman box that most users will access for project management, blueprinting, config, charm, and so forth.
can this be possible?
2nd option:
#1   Sandbox Solman - no satellite system connectivity; open access; used for the purposes of testing patches and exploring solman functionality - mostly for basis' purposes.
#2   'Development' Solman - only satellite systems that are NOT on the path to production would be connected here - such as a sandbox. This solman system would be used for configuration of solman itself example, your solman team would configure solman functionality here. It is also a good practice environment for PM's because it would have a small landscape attached to it your sandboxes, remember? Migrations start here for solman functionality...
#3   'Production' Solman - ALL path to production satellite systems connected here, except your sandboxes which were connected to #2 remember?. This system also serves as a target system for migrations that came from #2 for solman functionality itself, This is the main solman box that most users will access for project management, blueprinting, config, charm, and so forth.
for the 2nd option, I will have to install a new SolMan system to have a three landscape.
please advise.
your insights will be very much appreciated.
thank you.
charisse

Hello Charisse,
I am not sure you are understanding the use of Solution Manager to manage your system landscape.
Typically one Solution Manager will manage the entire system landscape, and systems of all types, PRD, QAS, DEV, SANDBOX, TRAINING, etc.
You can still have DEV and TEST and Sandbox Solution Manager systems, but they would be for those functions, developing, testing, learning and would not be managing your system landscape as that would be the role of a production Solution Manager system, normally.
You should start here - https://websmp207.sap-ag.de/solutionmanager, then also navigate to the "Media Library" where you will find a collection of Presentations, Articles and Brochures, Documentation, Technical Papers and How-To's.
Of course you will find the Knowledge Transfer Ramp-up Kits very helpful - http://service.sap.com/rkt-solman
And also the help library is often quite useful - http://help.sap.com - select the Solution Manager product and then select the applicable version.
You should find these resources quite helpful in determining a strategy for your system landscape and grow your Solution Manager knowledge.
Regards,
Paul

Query on Global Rollout Landscape Strategy

Dear All,
I need some information about Global Rollout.I am working in SAP BASIS.I need to finalize the system landscape.The query is,what would be our approach to implement the global template using solution manager:
1. Separate Implementation at two different sites(Location1 and Location2) with two sets of servers (DEV,QAS & PRD) with common solution manager between both the location where the solution manager will be working as a common server between (DEV1 & DEV2,QAS1 & QAS2,PRD1 & PRD2 respectively),so that the global template package can be transported from Location1 to Location2 by using Solution Manager.
So Total no of servers will be 7 (two sets of DEV,QAS,PRD & 1 solution manager).
2. Implementation with only one set of server (DEV,QAS,PRD) and solution manager at Location1. And only one Production server at Location2 so that the developed global template is common between both the location by solution manager.After developing local components at different clients (for different locations) at DEV,testing at QAS and transporting to PRD1,the global template is transported to PRD2.
So Total no of servers will be only 5 ( one set of DEV,QAS & 2 PRD,one solution manager)
Please guide.I need your help so that can finalize this asap.
Waiting for your reply,
Thanks & Regards,
Sandipan

Hi Sandipan,
Always a pleasure to hear Global Rollout use
First, I will comment on the number of Solution Manager instances.
If there is no particular need for two separate instances of Solution Manager and the different Geographies/ Businesses involved are happy to share 'content' from same Solution Manager instance, you just need one Solution Manager.
With Global Template Rollout based out of one Solution Manager instance, things can be a lot more simpler. For example,
- you don't have to think about 'transporting' templates from source SolMan instance to target SolMan instance to provide periodic updates; they become available 'perpetually' for all Implementation Projects within the single instance
- you don't have to activate 'Change Requests' to capture the structure and content assignments in the project. Often, people find this to be very time consuming
Please go through SAP Note 603336, if you haven't done already. This is very important to read.
As regards the number of DEV, QAS, PRD you must have for Satellite Systems, it's entirely dependent on the way your programme requirements are. I would believe PRD to one, though the other boxes in between could vary as per needs.
As for SolMan, you need to have just one instance running to cover Template Project and all Rollouts based on that.
Best regards,
Srini

SLD Naming strategy

I have different application that sends files into FTP in different folders.
Do I need to create one business/techical system in SLD with generic name like FILE_SYSTEM? This system will have several channell in ID.
Or I need to create each business/techical system for each applicatiuon in SLD.
What are your suggestions?

Hi Sergey,
both is possible. One more alternative is only to create a business service without SLD entries. If you have a good reason to reduce number of directory objects use only one system with more channels; if you prefer a extendable solution (X-Path routing) use more systems with only one channel.
Regards,
Udo

Central SLD Configuration

Dears,
Recently we installed PI DEV and PI QAS server.At time of configuration we choose local SLD option for configuration.
But now we are getting requirement to configure central SLD.
So please confirm which strategy is good between them and if it is central SLD,Please suggest the
procedure to change local SLD configuration to central SLD.
Shivam

Hi Shivam
The SLD planning guide provided previously is the key source to plan, implement and run an SLD landscape
However what it may not deal with specifically is changing an existing SLD landscape to accomodate a local PI specific
SLD and a new Central SLD for Solution Manager (or other purposes)
Some things to consider when selecting Sync options
1) 1 Dual purpose SLD is not recommended - a central SLD might have different administration requirements than a PI specific SLD
2) Where possible do not change established import or export lines in either SLD
3) Keep all SLDs involved in the sync at the same J2EE version, SP landscape and CIM model/content
As the PI SLD can be productive critical - full consideration has to be given to this SLD as you can
still maintain systems manually in a central SLD manually - or indeed in Solution Manager itself (both manually and automatically via RFC) - therefore I would recommend a unidirectional sync from local PI SLD to Central SLD of PI landscape data only - either manually or automatically or indeed explore any available options to have data suppliers update both SLDs (there was some options similiar to this in older SLD versions - but I am not completely familiar with the latest SLD builds)
I would not however encourage full sync or CIM based sync as there maybe established CIM import lines on either SLD nor would I specifically encourage the Central SLD to influence data on the Local existing PI SLD
Best wishes
Stuart

SLD - Logical System Management

Hi,
We are implementing XI and we have the problem with SLD logical system management. The problem is that we use the same Logical system name (Ex. PRDclnt350) for all the systems to avoid running lengthy BDLS process when we hook our R3 systems to their respective BW systems.
Can you please suggest how we take care of this in XI -SLD landscape as it requires unique logical system names for each Business System when maintaining in SLD.
Can we have multiple SLDs and will it take care of the issue. If so can we take one of them as the master SLD and the rest as slave SLDs. What would be the best practices for synchronizing them. Any help in this regard is greatly appreciated.
Thanks and regards..
Haritha

Hi All,
We opened an OSS note with SAP regarding this. Please see the question we asked and the response we got from them regarding the SLD maintenance:
Hi,
We are on BW 3.5 and SAP ERP 5.0. We are implementing XI now. So we
need to configure SLD and register our Business systems. The problem is
we have the concept of using the same logical system for all our SAP
systems, say WRPCLNT750, when we are hooking our systems to their
respective BW systems. And in SLD, we have problem becuase of this, as
it recommends to have unique logical system name for each Business
System being registered.
We want to mention some points in here about our landscape and some of
the recommendations we got from SAP regarding this. Ours is a very big
warehouse system and in order to avoid the lengthy "BDLS" runs, SAP
recommended using the same Logical System name for all the SAP systems.
Hence we are using the same logical system name for our systems.
So now coming to our problem, can you please tell us what would be the
best practice that needs to be followed now for SLD Business System
registration. How can we overcome the hurdle of NOT having a unique
logical system name for our systems in central System Landscape
Directory.
Please let us know the solution as early as possible.
Thanks and regards..
Haritha.
The Response:
Hello Haritha
I have found some pass cases with the same question that you have,
however, the replies from developer are as below.
Logical systems cannot be duplicated within the SLD, that means one
Business System per Logical System name, both need to be unique, the SLDis working a designed here.
I would suggest you rename one of the copies of the productive system
to solve this.
My apology that I couldn't provide you a better answer for this.
Thanks & Best Regards
Andy Lam
Active Global Support - SolMan & Technology
Kindly, please let me know your suggestions.
Thanks and regards..
Haritha.

Accessing SLD through web services

is it possible to call the SLD via web services to pull out system element data (i.e. different data types like SAP system, application system, database, so forth)? if not are there other APIs to the SLD (like a Java API or C/C++) which could be used by non-SAP programs to get at SLD landscape data?
thanks ín advance / matthew

Hi,
it is possible to access SLD via WS and also there is some API available but I have not done this myself.
this link might be helpfull:
http://help.sap.com/saphelp_nw70/helpdata/en/c9/dc37520bdf4b48bb8f6d4329f073d5/frameset.htm
greetings Georgi

Name server not updated in development configuration after change of SLD

Hi Guys
Hope you can help me with this one.
We have moved our SLD from one server to another.
After this we changed the name server in NWDI and in NWDS.
In NWDS i removed the development configuration and reimported it, but when I do this, a popup box shows the details of the development configuration and the name server is still the old SLD server. This means that when I start the NWDS I get an error saying that the name server host is unreachable.
Where do I change this?
I found out that the name server is setup in the .confdef file under .dtc\0 in the field called name-server-url. If I change this manually in the file, it works. But if I remove the development configuration and reimport it again, I am taken back to the old name server again.
It seems as if something has to be changed in NWDI, but I can't figure out what.
Can anybody help?
Cheers,
Jacob Vennervald

Hi Jacob,
I would proceed as follows: 
- login to your new SLD 
- go to the technical systems in the landscape area of the SLD 
- in the filter drop down select AS JAVA 
- check if your NWDI has reported to this SLD in the last 12 or 24 hours, you can check this on the "last update" column 
- if your system has reported to this sld the last few hours this is good if not go to the step "change J2ee to new sld" i will descirbe later. 
- remember the name of the system here. it is like sid on dbhostname. 
- got to sld administration (link on top) choose content maintenace in administration 
- in the subset filter select "All with instances" as class set SAP AS JAVA Cluster 
- you should find your system there. click on it. 
- in the new screen find a link in the middle top <nr> associated instances -> click it 
- in the next screen you will see the relationship of the technical system to the rest of the sld data. 
- there should be a topic called "hosted application server" 
- the should be an entry like: system landscape directory: sld on sid on server -> click it 
- here you will see the data for this hosted system. You can find the cim/url definig the SLD you will find the roles. Landscape and name server should assigend and so on here you can chage the SLD url. 
You can although proceed as follows. This as well requieres you nwdi to report and use this sld in j2ee see below if not. 
- on sld startscreen choose landscapes in the landscapes part of sld 
- select landscape type nwdi systems 
- if there is no landscape you can create one 
- in the landscape ypu can assinge systems. The sld should be availabel to choose. 
- once in the landscape you can view the system and you can change the CIM Server url and the roles there aswell its just another view on the content. 
 
you can although check: 
- open name reservation from develpoment part of start screen 
- here you should find a button about enabling or disabling the sld for nwdi usege. this should be of course enabled... 
 
"change J2ee to new sld" Ok and here what to do or to check if you are not sure if your NWDI uses/reports to the new sld. 
- Go to the nwdi server an open Visual admin i asume you are running a 7.0 Di if not let me knoe i can although tell you for CE. 
- ok in VA. select on of your server nodes->services->SLD data supplier. 
- an overview page will show up. 
- select the http settings tab in the lower middle. 
- https settings will tell the j2ee where to report to. Verify the data and change if needed. use the lightinigbolt button on top to transfer data to the sld. have a little patiance if your data is not shown immediately in your sld,. it may take 1-2 minutes until it is shown in the gui. 
- switch to cim client generation tab. those paraemters will tell your j2ee from what sld to read data from. It is important to understand that you may report to one sld but to read from antioher. depending on your sld landscape. The CIm CLient should use the same Sld as your NWDI uses in CMS setting. 
- if all is setup. do a cim client test. 
 
Allright. This is all I know on how the NWDI is integrated in SLD. Hope you can resolve your problem wiht this steps.
 
Have a good time 
Jan

SLD to SMSY synchronization - Which product version do we have to choose ?

Hello,
We do have a CPP system running on SAP ECC 6.0 version.
1. In SLD, we do have the list of all "Software Components" used in CDP.
We do not have the "PRODUCT VERSION" of the managed system.
2. With job SAP_SLD_DATA_COLLECT (RZ70), all data are sent from CDP (managed system) to SLD.
3. With LANDSCAPE FETCH job, all data are synchronized between SLD and SMSY.
Now, how can we choose the right "PRODUCT VERSION" to set in SMSY ?
As far as there is not "PRODUCT VERSION" defined in SLD, do we have to set manually a PRODUCT in SMSY ?
Is there any guide or OSS Notes which describe, step by step, the full workflow process synchronization
from (1) Managed System to (2) SLD to (3) SMSY ?
Thanks
Best regards
PC

Hi,
As I have observed, when the data sync happens between SLD and SM system, the product versions are also assigned.
Sometimes, the product assigned through SLD sync may not be correct or may be irrelevant to your scenario,
In that case, you should always manually edit and assign the correct product version in SMSY, to avoid any conflicts arising in further setup of EWA, SMD setup etc.
For ECC 6.0, you can goto SMSY>systems>search for SAP ECC-->your system CPP/CDP should already be present under SAP ECC through SLD landscape fetch job.
Select that system, and in the header data tab u can see the Installed product versions.
There you can always change the relevant products for your systems.
Hope this helps.

PI and SLD Transports using CTS+

HI all,
We have a three system PI landscape (DEV.QAS.PRD)
There is a two system separate SLD landscape (DEV/QAS & PRD SLD) - this is also serving PI, NWDI, Portal, & solution manager has its own SLD.
CTS+ has been configured to transport all PI objects in a PI Domain controller.
In trying to integrate SLD to PI domain controller, the SLD transport is created, we can see it in the transport organizer but after releasing the SLD transport , it does not show up in the SLD source system defined in the domain controller? Any ideas why?
The transport content is in /usr/sap/trans/data at the file system level.
Regards, Neeta

I do not think CTS+ support SLD content transport. You have to use manual export/import mechanism from with in the SLDs.
VJ

SLD landscape Strategy

Similar Messages

Maybe you are looking for