We are converting extended lapi to extended CWS in our project to customize existing feature ,now cws looking for SDO objects. I m looking for good sample for custom sdo wiht some custom things. please help me out.
i already refered below link but that is not suffient
https://knowledge.opentext.com/knowledge/llisapi.dll?func=ll&objId=45500683&objAction=browse&viewType=1
Extended LAPI is basically Oscript. When you actually look in LAPI you will see after the Dispatcher has received the request it does validations,however when all said and one it will actually do what the client programmer says to do. If OT is not providing you what extended LAPI does I would first put my hat as a client programmer making sure I play nice to my integrations so I would write at least in a straw man the parameters to the call.
Then with that info you have the HelloWorld Oscript as well as the .NET and Java for you to work with what OT showed.In very simple terms what the client code does is send to livelink just like lapi did,albeit in this case OT will use the mechanisms .NET gives(the .svc) and java gives(for Tomcat the jar).The Oscript part will be more easier for a true oScripter the making of libraries is basically a mundane /chore with plenty of errors and I wish they had a good flow doc on this step does this.
I have been able to at least develop the .net part with the free Visual Studio.Never attempted this in CSIDE . I never attempted to do the java part as the customer did not need it and not being a active client dev I just had it when I saw success with the .NET part.
Extended LAPI is probably in use by many OpenText products so there might be an official version.Also OT does allow old lapi to be called in newer server versions,they just don't want people getting comfortable on it.I recently installed extended lapi to make EScan work and immediately noticed that the old lapi oscript libraries were back into play albeit probably not available on the lapi port.It is most likely that OT wants new programming constructs in play in the new world so "weaning" if you will.
I would not expect a person never having done anything in Oscript before to know the intricacies of OT code and I am in no way saying this to discourage you but I would redesign this in REST as that I think has more chances of surviving than the SOAP libraries which the link you put is asking you to do.
Whether you like it or not whether .NET/Jar it will have something in Oscript and the framework language(or both ?)
REST keeps you sane because I would assume it would constrain yourself to Oscript and some javascript libraries.
BTW I made a mistake unintended in my reply
Content Server Private Bridge Module 16.0.0 module\apicore_16_0_0\ 16.0.0 module\apicore_16_0_0\
when a OScripter looks he will see the old LAPI code in that OSpace.My guess is Extended LAPI is similar.
