[REST API] How to search devices in Spectrum in a specific landscape AND with the POST method

[yann.mornet]

Dear community,

 

I want to search for a bulk of devices. I am only interested in devices having FOO in their Model_Name and only located in the specific landscape 0x5000000.

My XML is:

<?xml version="1.0" encoding="UTF-8"?>
<rs:model-request throttlesize="10000" 
 xmlns:rs="http://www.ca.com/spectrum/restful/schema/request"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://www.ca.com/spectrum/restful/schema/request ../../../xsd/Request.xsd ">
 <rs:target-models>
 <rs:models-search>
 <rs:search-criteria xmlns="http://www.ca.com/spectrum/restful/schema/filter">
 <devices-only-search />
 <filtered-models>
<has-substring-ignore-case>
<attribute id="0x1006e">
 <value>FOO</value>
 </attribute>
 </has-substring-ignore-case>
</filtered-models>
 </rs:search-criteria>
 </rs:models-search>
 </rs:target-models>
 <rs:requested-attribute id="0x1000a" /> <!-- Condition -->
 <rs:requested-attribute id="0x1006e" /> <!-- Model_Name -->
 <rs:requested-attribute id="0x11564" /> <!-- Notes -->
 <rs:requested-attribute id="0x12d7f" /> <!-- Network_Address -->
 <rs:requested-attribute id="0x129e7" /> <!-- TopologyModelNameString -->
</rs:model-request>

URL is

http://<OC>:<PORT>/spectrum/restful/models?landscapeid=0x5000000 

 

 

But it does not work. The response gives devices in other landscapes than 0x5000000.

Moreover if I try the same request with HTTPS, the request is rejected by Spectrum unless I remove the landscapeid criteria in the URL.

 

How is it possible to run the search on a specific landscape ?

I mean run the search should be run on a specific landscape and not the others. The goal is not to request the whole infrastructure and filter the list with a criteria on Model_Handle which starts with 0x50. Eek.

 

BR

Yann

[Christopher Scollin]

I don't believe the POST models URL accepts the landscapeid paramter in the URL. What you could do is exactly what you said in your post. In your models search criteria you could do something like the following along with the model name filter.

 

      <attribute-filter>

            <and>

                <greater-than-or-equals>

                    <attribute id="AttributeID.MODEL_HANDLE">

                        <value>0x500000</value>

                    </attribute>

                </greater-than-or-equals>

                <less-than>

                    <attribute id="AttributeID.MODEL_HANDLE">

                        <value>0x600000</value>

                    </attribute>

                </less-than>

            </and>

        </attribute-filter>

 

Then also add the model name filter. 

[yann.mornet]

The only "optimized" way I found to limit the landscape to a specific one is to restrict the Spectrum User to this very landscape.

Yet, this is not a solution which can be appliable in all circumstances.

Otherwise I am afraid I will have to test the Model Handle like you said.

[Frank Tonjes]

I've found that requests for info from specific landscapes still end up being sent out to each individual landscapes. Even if you specify you want only landscape 0x100000 and you have 20 landscapes in your domain, it will go ask each landscape. This isn't really ideal. We have some landscapes that are on customer locations and while the links are OK every REST API call will now take as long as the slowest landscape. I'm sure there is some room for improvement. ie. when the Oneclick receives the request it could see what landscapes are in the criteria and then only query the ones needed. If it is a mass request then obviously send it to all landscapes. I've noticed that the ihProcessed jumps on all landscapes when doing REST API calls.

 

Even if you specify show me attributes for model handle 0x100000 you still had to specify the upper and lower model handle range (as suggested by scoch03) but I raised that as a bug and think that might be fixed in the latest release (not yet been able to test as migrating in the next 2 months only!).  

[yann.mornet]

Thank you for your feedback. We also have landscapes on remote locations here and I wanted to optimize my queries to avoid any unnecessary load and WAN reponse times. Glad to know you have raised a bug on this issue!