How to Create a Custom API in OpenText Content Server ?

Wagar · 2025-02-20T12:48:30+00:00

There was an error rendering this rich post.

I am working with OpenText Content Server and looking for a way to create a custom API to extend its functionality. I need to expose some custom endpoints to interact with Content Server data programmatically.

Could anyone guide me on:

The best approach to creating a custom API inside Content Server.
Whether WebReports, OScript, or REST API extensions are the recommended way to do this.
Any documentation, examples, or best practices for implementing and deploying a custom API.

I appreciate any help or pointers.

Thanks in advance!

Find more posts tagged with

API

Content Server

Note:

If there are Accepted Answers, those will be shown by default. You can switch to 'All Replies' by selecting the tab below.

Accepted answers

All comments

appuq

The Oscript classes that you take or the book they give you actually walk you through this. I was able to do that for my company for a product we developed. I also have been working(not recently) in Oscript all my life so all those idiosyncracies of the tool I ignore.

If there is a gap in the product that you badly want to implement then Oscript is the preferred source.

If for example OT has created a pretty onerous way of calling things and you may want to make some efficiency by chaining a few or finding it out by some custom SQL and exposing it then a WR/LR will come to your rescue because every WR can be made to spit out JSOn or appear to be an endpoint. These kinds may be useful if the server on which OTCS is controlled won't allow deployment of your custom script-developed REST endpoint. If you have answermodules it is also very easy to develop your own api and you get the power of groovy/java

Reiner Merz used to be a teacher with OT learning. Of late he has been chronicling his work on linkedin

https://www.linkedin.com/pulse/extending-rest-api-reiner-merz-ga72e/?trackingId=%2BGpBDoAb%2FXS8fKlSpHwMSQ%3D%3D

I just looked at it and this is kind of how one does it but if you are new to Oscript I would get myself accustomed to CSIDE and a server you can play with and lots of backups

While technically OSCRIPT WR Custom tags are very easy to develop and are not considered as evil as a custom module in OT cloud scenarios so that may be a good one to pursue as well.

GregPetti

We make pretty massive use of WebReports to create custom REST requests (though in many cases we just use conventional URLs to make the request rather than an actual REST syntax). We have a product we built called the Application Analyzer that uses a VUE client and is entirely built this way because many (most) of backend functionality we needed was unique. Even for cases where there was a corresponding REST request available, the WebReport allows us to tailor the response (as well as the DB activity) to exactly what we need - making it very efficient. We have a few different approaches to rendering the JSON for this.

LIteral - we explicitly put the JSON syntax in the WebReport, managing quotes, commas etc. and putting ESCAPEJSON sub-tags where a string could return unfriendly characters. The can be difficult to manage commas, opening closing brackets etc. so we have a custom sub-tag that allows conditions to be setup for when a character is included.
Using existing OScript structures like ASSOCs, and Lists, or creating them using available sub-tags (WebReports has an ASSOCACTION sub-tag and we have an extension to make LIST building easier). Any Script structure can be converted to JSON with the TOJSON sub-tag.
Using a custom sub-tag we have in our sub-tag suite called RB_JSONBUILD. This manages all of the syntax and escaping automatically, but is less readable than the literal approach. On the other hand it is more flexible than using the OScript approach.
Using the INSERTJSON tag that comes with WebReports. This has a fixed structure and format but will render data from a data source among other things, and it can expand the available fields in various custom ways. We tend not to use this as we like to have some control over the JSON schema.

The sub-tag suite i mentioned is part of a product offering but we periodically offer it on a promotional (free) basis (subject to some limitations). info@ravenblackts.com

Greg Petti