Fetching a Node by Full Path using OpenText Content Server REST API

NikolaM

Hello,

I am currently working with OpenText Content Server and using its REST API to interact with the nodes. I have a specific requirement where I need to fetch a node directly by its full path rather than by its ID.

Here are the details:

• I only have the name of the node and the full path to it.
• My files are structured within 12 nested folders, making it impractical to make separate API calls for each folder level.

For example, I have a path like /Folder1/Folder2/Folder3/.../Folder12/NodeName and I need to retrieve this specific node.

I've reviewed the API documentation and could not find a straightforward way to achieve this. The standard approach of navigating through each folder level with separate API calls is not feasible in my scenario due to the depth of the folder structure.

This functionality was available in the SOAP API that I am migrating away from. In the SOAP API, we could fetch a node directly by its full path, which greatly simplified operations in deeply nested folder structures.

Questions:

1. Is there a way to fetch a node directly by its full path using the Content Server REST API?
2. Are there any specific endpoints or query parameters that support this kind of operation?
3. If it is not directly supported, are there any recommended workarounds or best practices for efficiently retrieving a node by its path in such deeply nested structures?

Any guidance or suggestions would be greatly appreciated. Thank you!

appuq

OT introduced REST API so they can work on retiring others as they become more unpopular in the programming world so at this time I think one will have to do this.

1. REST API is very easy to implement server-side meaning it is trivial for an oscripter to add the missing call, perhaps send OT your work to see if they will look through it and introduce it in the product. So I would wait until you get an official answer from OT especially since you say it was available in SOAP.
2. Consider working with a more useful product like Answer Modules where creating an endpoint is also very trivial.
3. You could create a simple database function or code as in LR and call it via a WR. As you know every WR will act as a REST API…
4. Theoretically one could even implement a caching system where you kind of made some kind of algorithm keeping the breadcrumbs in memory. This is what Oscript does because when it knows a node has been fetched it is not reseeking that info. I say it but it could be very error-prone.
5. SOAP API will stay in the product until SAP creates or Update workspaces are migrated which I don't see for a good distant future.
6. I also don't know if Search API offers a direct method please use the search api or look in od forums if it can be done.

GregPetti

Hi,

If you use the WebReports approach, there is a subtag called NODEINFO with a feature called PATHTOID.

To use this you would pass the folder path to the subtag which would then return the ID of the last item. The only snag is that it expects the path elements to be delimited by colons, but that is easily remedied.

For example:

[LL_REPTAG_'Folder1:Folder2:Folder3:NodeName' NODEINFO:PATHTOID /]

If the path is being passed as a parameter (or with some other tag) you could do this:

[LL_REPTAG_&nodePath REPLACE:"/":":" NODEINFO:PATHTOID /]

As Appu mentioned, you can invoke any WebReport as a Rest Request as listed in the REST API documentation, e.g. /api/v1/nodes/{id}/output

https://knowledge.opentext.com/knowledge/llisapi.dll/Open/67789539

David Henshaw

@NikolaM

The others who've contributed here are wise and experienced people. Combined they have years of experience and have presented options.

I'm inclined to ask a two questions though….

Why do you only have the full folder/document path available to you?

e.g. suppose you have a path in Content Suite - Enterprise:Folder A:Folder B:Folder C:Document 1

An API to retrieve the document based on that path I agree would be "handy", but comes with some risk.

What would happen if someone decided to rename or restructure/move any point in the chain after you were given the path?

An API using the full path would likely result in one of two things:

At best, it would respond with "object not found", at worst if someone created a new object in the same path location you'd been given then you aren't assured of retrieving/updating the item you intended to update and may or may not know since the retrieve/update could in fact succeed.

Obviously one has to weigh up the probability of the above risks materialising - i.e. you might rightly say "but that will never happen in our system due to XYZ".

The above are why I tend to start with the IDs of objects in Content Suite - since:

A) They are imutable and never recycled.

B) Since the ID points to a single object, if you've got the ID depending on your requirements you might not need the full path (or can retrieve it using the ID).

All that aside, if the above is impractical and you only ever can be given as input the folder path, then what I would consider is doing (if possible based on your requirements) is initially making individual API calls to traverse the structure and retrieve the ID of each object in the path and cache a set of keypairs (object path, ID), such that in subsequent API calls you can use the cached path to recall the ID.

This way, you mitigate any change in the structure while the API calls are made.

NikolaM

Thank you for the thoughtful input on using paths versus IDs for document retrieval in OpenText Content Suite. The points raised about the potential risks of path-based retrieval—such as objects being renamed, moved, or replaced—are indeed valid concerns.

However, in our specific case, we manage hundreds of thousands, if not millions, of deals, each containing a set of documents. These documents are stored in a hierarchical structure that is 12 folders deep. Here's why path-based retrieval is necessary and practical for us:

1. Volume and Structure: Given the sheer volume and depth of our folder hierarchy, IDs alone aren't sufficient. We have well-defined paths for each deal's documents, making it easier to navigate and locate specific documents without needing to manage an extensive database of IDs.
2. Consistency and Stability: Our document structure is highly stable. Documents are rarely moved, and when they are updated or new documents are added, they remain within the same folder path. This stability minimizes the risks associated with path-based retrieval.
3. Frequent Updates, Infrequent Access: Each document might not be accessed frequently, but updates or additions to the deal folders are common. This dynamic nature means caching isn't as effective. Path-based retrieval ensures we always get the latest documents without relying on potentially outdated cached data.
4. Operational Efficiency: Retrieving documents using paths fits well with our operational workflows, where paths provide a logical and human-readable way to organize and locate documents. It aligns with our users' expectations and existing practices.

appuq

If your program can get a DB connection albeit read or a view or something I think you could make this work without elaborate coding and still use REST to do your thing. Also if you are not afraid to learn Oscript all you have to do is trace the SOAP call that does this and then create a REST endpoint. Obviously the "technical debt" blah blah may have to be convinced.I have never understood that because Oscript is yet another language

David Henshaw

@NikolaM No problem. We had a similar requirement recently and opted to use Business Workspaces. This way for each workspace we could be assured only one existed for the "business entity" (e.g. deal) and that within each there was a templated structure.

This meant we didn't need to concern ourselves with where the workspaces resided in the overall ECM folder structure - we could confidently just issue a "get me workspace X" and know we'd get the ID. That left us only having to worry about the sub-folder structure of the workspace.

GregPetti

Hi @NikolaM

Just in case you missed my previous post in the more strategic discussion about your approach and requirements, If you use a WebReport (called with a REST request) and pass it the file path, it has a built in "sub-tag" that automatically returns the DataId of the last element. I believe this is what you were trying to do, assuming you're still taking that approach.

Cheers

Greg Petti