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

NikolaM · 2024-07-15T21:31:21+00:00

There was an error rendering this rich post.

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:

Is there a way to fetch a node directly by its full path using the Content Server REST API?
Are there any specific endpoints or query parameters that support this kind of operation?
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!

Find more posts tagged with

Comments

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.

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.
Consider working with a more useful product like Answer Modules where creating an endpoint is also very trivial.
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…
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.
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.
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:

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.
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.
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.
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

GARZARELLAS

Hi @GregPetti ,

we have developed the solution you proposed, but we need to obtain the ID of a node contained in a BWS. The solution you proposed doesn't work in this case, as it doesn't reach the nodes inside a BWS, do you have any solution? Thank you

Regards,

Simone

appuq

if you have a workspace ID like this 123456

then select * from DTREE where OWNERID= <123456> //all nodes in a workpace will share the same ownerid try negative if positive does not work. This is a fundamental of the Content Server database

Once you have this correct introduce any filter that you need to get the node you want

GARZARELLAS

Hello @appuq,

we are not using DB, we have a Web Report with the tag:

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

Replacing 'nodePath' with a path containing a BWS, the call fails.

appuq

are you getting something like this? the call in my system only works for non BWS objects

My Input

[LL_REPTAG_'Enterprise:Asset Management:Assets:ASSET - BEDFORD - 11400 - Boiler- 50,000 Lb/Hr/ Gas Fired/ Water Tube' NODEINFO:PATHTOID /]

if you know Oscript(or have the will for it) look at Greg Petti's easy way of extending tags.While it is oscript the example introduces the user to create something even without a huge knowledge of Oscipt.Or you can hire a developer freelancer.Or use Aanser Modules or something better at this

Run WebReport: CHUMMA

* NODEINFO: Error retrieving DAPINODE for ASSET - BEDFORD - 11400 - Boiler- 50,000 Lb/Hr/ Gas Fired/ Water Tube *

appuq

BTW I was not saying use a dB tool and create a connection you would use a supported approach.

No organization will refuse to create a Live Report(LR) against the CS application if the solution far outweighs it and LR is a fully audited piece of application software.
In your case it looks like the idea to use a WR tag is not going anywhere until OT parses the workspaces object(or as I said you needed to write what the gap is)
The WR is just a wrapper to the LR in this case so if the LR works you have a method to get what you want from a REST API call.

I will stop here .

Alessio Villa

As Appu mentioned earlier, if you have ModuleSuite installed, you can achieve your goal very quickly. Simply create a content script under 'ContentScriptVolume:CSServices' and write the following line of code:

return docman.getNodeByPath(docman.getEnterpriseWS(), params.path).content.content

This instruction leverages out-of-the-box APIs to retrieve the node from the Enterprise volume based on the provided path and returns the corresponding document for the user to download.

Assuming the script is named retrieveNode, you can easily invoke it by calling the following custom API: /amcsapi/retrieveNode?path=<path>, where <path> is the path to your resource (e.g., 'Folder1:Folder2:BWS3:Folder4:Resource.png'). This approach works with regular folders, business workspaces, or any other container objects.

Since you can customize the API as needed, you could enhance it by adding checks for node existence and permission verification. If you're more interested in node attributes rather than the document itself, you could return a JSON object containing the node's information. In cases where the node doesn't exist or the user lacks the necessary permissions, you could return an appropriate message instead, to properly handle errors.

You can also reuse the same script to implement multiple APIs, as distinct Groovy closures, all exposed under a common mapping. For instance, /amcsapi/retrieveNode/enterprise?path=<path> and /amcsapi/retrieveNode/personal?path=<path> could be used to distinguish between enterprise nodes and personal workspace nodes. Additionally, you can handle different HTTP methods (GET, POST, PUT, DELETE, etc.) to manage operations such as creation, updates, deletion, and more for each node.

Essentially, you have the freedom to implement the logic you prefer using simple Groovy code, while leveraging hundreds of out-of-the-box APIs provided by ModuleSuite to perform common actions quickly and efficiently.