I am doing quite a bit with the web services, but have run into a few things that aren't clear in the documentation, mostly around filters.
The Webservice guide states the following for the filter operator:
Comparison operator (values such as
EQUALS, LIKE are admitted).
Is there a full list of what is supported anywhere? EQUALS and LIKE are great, but since the web interface can also do things like "not", "is null" and "contains", I'm assuming there is some way to specify those as well. The same question goes for the filterOperator were the documentation reads "(values such as AND, OR, NOT are admitted)". Are those the only ones?
Is there a way to specify case-independent searching? I have to interface with a database where someone decided to store names in all upper case, which is making it tough to match in the CMDB data I have imported from LDAP which has mixed case. It's easy enough for me to turn JOE SMITH into Joe Smith in my code, but names like O'MALLEY and SMITH-JONES are tricker and I would rather not have to deal with it if I can help it.
Unfortunately in the SOAP webservice you can only use at the moment only the AND / OR and EQUALS / LIKE operators.
CMDBuild Team
Previously Tecnoteca wrote:
Unfortunately in the SOAP webservice you can only use at the moment only the AND / OR and EQUALS / LIKE operators.
CMDBuild Team
Thanks for the reply. Is there a way to tell it to ignore case on the search? When searching for names I currently have to make sure they are capitalized since "JOHN SMITH" won't match "John Smith".
At this time, unfortunately, it is not possible.
We will consider your request for future CMDBuild versions.
We suggest you consider also the new CMDBuild REST webservice that we released last week and is described in the new webservice manual.
CMDBuild Team
Previously Tecnoteca wrote:
At this time, unfortunately, it is not possible.
We will consider your request for future CMDBuild versions.
We suggest you consider also the new CMDBuild REST webservice that we released last week and is described in the new webservice manual.
CMDBuild Team
I just upgraded to 2.3 yesterday, so I will have to take a look at what available in the REST interface.
The good news is that it looks like LIKE is case insensitive. The bad news is that it appears that it automatically wildcard anything I send it. So searching for "LIKE 'joe s'" will match "Joe Smith" as well as "Joe Schmo". I can at least work around that in my code.
Our engineers confirm to me that the operator applied in the REST webservice is equivalent to the SQL operator ILIKE.
CMDBuild Team
Previously Tecnoteca wrote:
Our engineers confirm to me that the operator applied in the REST webservice is equivalent to the SQL operator ILIKE.
CMDBuild Team
Tecnoteca,
Are there any examples available for using the REST interface? Some things are straight forward, I was able to authenticate and run simple queries. However, I can't get any of the string-type query parameters working.
For example, this works fine:
http://cmdbuild/cmdbuild/services/rest/v1/classes/Site/cards?limit=2
it returns two results as I would expect.
This on the other hand, causes a stack trace:
http://cmdbuild/cmdbuild/services/rest/v1/classes/Site/cards?sort=Code
and I have the same problem with the filter parameter. Is there a test suite that was used for the REST interface that can be published?
From my reading of the wadl, that should work...
<resource path="/classes/{classId}/cards/">
<param name="classId" style="template" type="xs:string"/>
<method name="GET">
<request>
<param name="filter" style="query" type="xs:string"/>
<param name="sort" style="query" type="xs:string"/>
<param name="limit" style="query" type="xs:int"/>
<param name="start" style="query" type="xs:int"/>
</request>
<response>
<representation mediaType="application/json" element="prefix1:responseMultiple"/>
</response>
</method>
...
You can find many examples in the CMDBuild Webservice Manual v. 2.3.
CMDBuild Team
The examples only seem to include non-parameterized queries as far as I could tell. I couldn't find a single example that included passing parameters to GET requests.
Doing it the "normal" way seems to work for integer parameters (ex.
/services/rest/v1/classes/Site/cards?limit=2
) but not for string parameters like filter or sort..
Previously Tecnoteca wrote:
You can find many examples in the CMDBuild Webservice Manual v. 2.3.
CMDBuild Team
Dear Dan Rich,
we are sorry, but Web Service Manual is missing some information. Talking about your issue about cards (and processes too) too, "sort" parameter requires this format:
sort:[{"property":"Foo","direction":"ASC"},...,{"property":"Bar","direction":"DESC"}]
where the property name is the attribute's name (not description).
Talking about "filter" parameter, it's a bit more complicated. Some examples:
# single attribute filter
filter:{"attribute":{
"simple":{
"attribute":"Code",
"operator":"contain",
"value":["foo"]
}
}}
# single attribute filter with logical operator
filter:{"attribute":{
"or":[{
"simple":{
"attribute":"Code",
"operator":"contain",
"value":["foo"]
}
},{
"simple":{
"attribute":"Code",
"operator":"contain",
"value":["bar"]
}}]
}}
# multiple attribute filter
filter:{"attribute":{
"and":[{
"simple":{
"attribute":"Code",
"operator":"contain",
"value":["foo"]
}
},{
"simple":{
"attribute":"Description",
"operator":"contain",
"value":["bar"]
}
}]
}}
Since manual will be updated with those information you can use this trick. Open CMDBuild with a web browser with debugging capabilities (Chrome/Chromium, Firefox + Firebug, etc) and create and advanced filter. If you look at the request, the filter parameter has the same format (ignore the "parameterType" attribute, is meaningless within this context).
Best regards.
-- CMDBuild Team
Previously Dan Rich wrote:
The examples only seem to include non-parameterized queries as far as I could tell. I couldn't find a single example that included passing parameters to GET requests.
Doing it the "normal" way seems to work for integer parameters (ex. /services/rest/v1/classes/Site/cards?limit=2
) but not for string parameters like filter or sort..
Previously Tecnoteca wrote:
You can find many examples in the CMDBuild Webservice Manual v. 2.3.
CMDBuild Team
Thanks, that's exactly what I was missing!
For anyone else who is going down this path, the filter and sort values need to be JSON strings. If you were going to use curl for example, you would use something like:
curl -g -H "Content-Type: application/json" -H 'CMDBuild-Authorization: authhash' 'http://cmdbuild/services/rest/v1/classes/PC/cards?limit=2&filter={"attribute":{"simple":{"attribute":"Code","operator":"contain","value":["myhost"]}}}'
That would return the card for the first two hosts with a Code containing "myhost". The "authhash" is the authentication hash you get from setting up a session via. /services/rest/v1/sessions/. You also need the -g flag to curl to keep it from globbing the URL and failing because of the nested braces.
Previously Tecnoteca wrote:
Dear Dan Rich,
we are sorry, but Web Service Manual is missing some information. Talking about your issue about cards (and processes too) too, "sort" parameter requires this format:
sort:[{"property":"Foo","direction":"ASC"},...,{"property":"Bar","direction":"DESC"}]
where the property name is the attribute's name (not description).
Talking about "filter" parameter, it's a bit more complicated. Some examples:
# single attribute filter
filter:{"attribute":{
"simple":{
"attribute":"Code",
"operator":"contain",
"value":["foo"]
}
}}
# single attribute filter with logical operator
filter:{"attribute":{
"or":[{
"simple":{
"attribute":"Code",
"operator":"contain",
"value":["foo"]
}
},{
"simple":{
"attribute":"Code",
"operator":"contain",
"value":["bar"]
}}]
}}
# multiple attribute filter
filter:{"attribute":{
"and":[{
"simple":{
"attribute":"Code",
"operator":"contain",
"value":["foo"]
}
},{
"simple":{
"attribute":"Description",
"operator":"contain",
"value":["bar"]
}
}]
}}
Since manual will be updated with those information you can use this trick. Open CMDBuild with a web browser with debugging capabilities (Chrome/Chromium, Firefox + Firebug, etc) and create and advanced filter. If you look at the request, the filter parameter has the same format (ignore the "parameterType" attribute, is meaningless within this context).
Best regards.
-- CMDBuild Team
Previously Dan Rich wrote:
The examples only seem to include non-parameterized queries as far as I could tell. I couldn't find a single example that included passing parameters to GET requests.
Doing it the "normal" way seems to work for integer parameters (ex. /services/rest/v1/classes/Site/cards?limit=2
) but not for string parameters like filter or sort..
Previously Tecnoteca wrote:
You can find many examples in the CMDBuild Webservice Manual v. 2.3.
CMDBuild Team