Documentum REST API 7.3 - Search Results only include first value of repeating attributes

C Moro · 2021-02-09T17:03:14+00:00

There was an error rendering this rich post.

Hi all

we have Documentum 7.3 with the xPlore module and we are using the REST API, via the "/search" resource to perform searches against xPlore.

Having a query json as follows:

{

"types": [

"dm_document"

"columns": [

"r_object_type",

"r_creation_date",

"object_name",

"r_folder_id",

"repeating_attribute"

"expression-set": {

"expression-type": "expression-set",

"expressions": [

{

"expression-type": "property",

"name": "custom_property_1",

"operator": "EQUAL",

"value": "1",

"exact-match": true,

"case-sensitive": false,

"fuzzy": false,

"repeating": false

{

"expression-type": "property",

"name": "la_atr_deleted",

"operator": "EQUAL",

"value": "false",

"exact-match": true,

"case-sensitive": false,

"fuzzy": false,

"repeating": false

"operator": "AND"

}

And using the following url params in the search request: search?items-per-page=10&inline=true

I get the results of the query in the response, inside $.entries[*].content.properties.

The problem is that the "repeating_attribute" property value only returns the first value, not the whole list of values in said repeating attribute.

I've checked the OpenText Documentum Platform REST Services 7.3 Reference Guide document and I couldn't find anything that might resolve this issue.

What am I missing here? Could it be that something must be properly configured in xPlore for it to index all values for repeating attributes?

Thanks a lot in advance

Find more posts tagged with

Comments

DCTM_Guru

What am I missing here? Could it be that something must be properly configured in xPlore for it to index all values for repeating attributes?

- Verify that there are multiple values stored in the repeating attribute using DQL in Documentum Administrator. Assuming that is the case, what happens if you include keywords in your query (assuming you populate mult values for keywords)?

C Moro

Hi @DCTM_Guru Thanks for your reply.

- Verify that there are multiple values stored in the repeating attribute using DQL in Documentum Administrator.

Verified. I can see the multiple values checking the document via Documentum Administrator inteface. Using DQL i get several rows, one for each entry in the repeating attribute.

Assuming that is the case, what happens if you include keywords in your query (assuming you populate mult values for keywords)?

I have added a expression of type property to my query, for the repeating attribute. That repeating attribute has 2 values (checked using DQL). If I search by any of the 2 values, I only get the first value of said attribute in the search response.

The expression added to the query json:

{

"expression-type": "property",

"name": "repeating_attribute",

"operator": "EQUAL",

"value": "value1",

"exact-match": false,

"case-sensitive": false,

"fuzzy": false,

"repeating": true

}

If I use value1 for the query, I get value1 in the response. If I use value2 in the query, I also get value1 in the response. When I talk about the response, I mean under $.entries[*].content.properties

I would expect it to return an array of strings with the values, like so:

"repeating_attribute": ["value1","value2"]

but I get this instead:

"repeating_attribute": "value1"

Hope I did explain myself. Thanks again for your help.

C Moro

By the way @DCTM_Guru, just in case it's of any help, I have also tried the REST API resource /documents/{oid}Issuing a HTTP GET to the oid of the document, I get all its metadata, including the repeating attribute with all the values like so:

"repeating_attribute": ["value1","value2"]

Thanks

DCTM_Guru

Might be a bug with Search REST. I would submit a support ticket. Have you thought about using newer version of REST API?

C Moro

Hi again @DCTM_Guru. OK, understood.

I haven't thought about using a newer version actually, but I guess that would be difficult without certain info that it would actually fix the issue (it would mean an upgrade on server side if I'm not mistaken). Nevertheless, a support ticket might get us there.

Thanks very much again

DCTM_Guru

I would check the release notes for REST version (either 16.4 or 20.x). Since REST is just WAR, it should be backwards compatible for older content server versions.

C Moro

Oh OK, if I understand correctly, we could deploy a newer version of the REST API WAR without needing to upgrade the whole server side.

Thanks a lot for the tips!!

DCTM_Guru

Yes, check the release notes. Most of the Documentum clients are somewhat backwards compatible b/c upgrading server is more intensive than upgrading client.

Hicham Bahi

I would assume that the problem is on your side, since this is pretty basic functionality. I'm a bit puzzled by your request: you specify "types" as "dm_document" and then "repeating_attribute" in the list of attributes, but dm_document doesn't have such an attribute. Try specifying your custom type.

C Moro

Hi @bacham3. Thanks a lot for your suggestion.

We actually tried using our custom object type as "types" instead of "dm_document" and indeed, this way, the API returns multiple values in the repeating field!

Nevertheless, we also opened a support ticket, because using "dm_document" actually returned all custom attributes and values correctly (meaning using dm_document is correct IMHO, so it can be "generic" and apply to any object type), only repeating values are not populated correctly.

So thanks very much @bacham3!! Your suggestion allows us to workaround this issue until we get proper "official" guidance from support. When we get this I will come back and update this post as it might help somebody else in the future.

Kind Regards

Hicham Bahi

Good to know! When searching Documentum (and probably most other systems), the list of attributes is limited to the ones belonging to the type you are searching for. That's true for DQL and most Documentum clients. Therefore, don't expect a fix. If Documentum REST returns all of them, then fine, but in my opinion it's wrong to explicitly ask for an attribute that doesn't belong to the type (and even more wrong when in the WHERE clause).

C Moro

@bacham3 fair enough! My expectations for a fix are actually low ;) but I would like to have their "official" point of view on the subject.