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

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.

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

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

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

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

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

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.