****************************************** ***START UPDATE 10/3/2016*****************
LAPI and its client installer has become very hard to find. Moreover clients written in LAPI in say Java/.NET will only work if your Livelink a.k.a Content Server is of version less than CS16.Readers who are new to LL programming is encouraged to read this to the approach and not to the exact lines of the code.What I mean is when you used to program in LAPI you were basically passing parameters to discrete calls by modelling it based on the webgui of livelink .SOAP based webservices called CWS is also the same,so if you do not try to do the task in the webgui and try to understand the business rules you will almost have no success in CWS too. OT is notorious for not putting fully functioning use cases and a walk through,so whenever possible I write code assuming the user has not worked in Livelink for X number of years and try to educate you all. Livelink,Content Server,Enterprise Server all of this has been Livelink’s marketing brand name changes over the years.CS i sused in many of the integrations like AGA, XECM, RMLINK and you know you are programming against livelink if you see a link that looks like this http(s)://somefriendlyURL/livelink.exe|cs.exe|llisapi.dll|cs.dll|livelink.In many places SAP/ SP /Exchange will be configured to talk to Archive Server and then they will use Livelink to read into archive server and turn that into LL objects for better presentment/RM and other aspects. The AGA product is moving away from LAPI(not sure totally or not) to REST API in LL.
Many people seem to have understood my post about LAPI
The AGA (Sharepoint to Livelink Integration) product is the only officially supported OT product that seems to use old lapi binaries.Most of us have moved away for using it although when you are in a time crunch you can still use it.If you still want to use lapi make sure you are writing client code in java which takes care of most inconsistencies regarding 64/vs 32 bit J# problems.If you are a modern day .net buff see how old lapi can be run in new .net ways.
Back to CWS/EWS- Livelink is branded Content Server so it is no surprise that its API reflects that.The binaries that make up the wsdl is delivered without any additional installation in the same file path as the livelink server is installed.So if you run your livelink in a IIS webserver,you just “expose” the code from OT into a application.If you run your livelink in a Tomcat server then just dump the war file and TC will do the magic.The Web.Config in both he deployments make sure where it can talk to.For e.g in a livelink install if you see the Web.Config say localhost & 2099 when you call the beautiful code form your client it sends all that “stuff” into the livelink “server” listening on “localhost” and “2099”.None of this is hard coded and most livelink organizations will not use localhost resolution.And as a client api programmer you don’t need to worry too much.Ask for a webgui account before you start any livelink programming.It will keep you sane.What you are programming with a language is the same “business rules'” that livelink will throw to your code.Typical “new” programmer things like expecting category workspaces,enterprise workspaces to be 2004 & 2000 should be avoided the mistakes are very commonly seen in even vended applications.there are many livelinks in the world that do not have those ids.BTW like many others I also thought that to write java client code I had to have livelink running in a java app server.No I regularly now write .Net clients against a TC deployed WSAPI and java clients against a IIS deployed WSAPI. I also have written oscript based CWS things that is only needed when OT supplied stubs & proxies won’t cut a particular task.BTW when you install Records management,Physical Objects,Classifications they all deploy their CWS API.As your administrator to deploy that if you wanted to do programming against those functionalities . I advocate bundling everything under one website it makes the admin’s life easier well they are unsupported by OT but I do it anyway
Once you are prepared to first write your lines of code you may want to understand what you are doing.
- Livelink is a protected/authenticated DMS application so it will check if you have a valid account and if you have permissions to a particular object. BTW OpenText is the company making these products as far as I know there is not a product(binary) in that name.many consultants I have worked with refers to “we have given stuff to OpenText” which ain’t happening because there is nothing called that you can hand it to” In webgui the authentication is achieved primarily by putting a userid and password,almost nobody uses this method now or by a authentication service.In most companies if the application is IIS served that means you will almost for certain be vetted by IWA. Unfortunately OT does not provide samples ,I have written things and many others have done it too. nobody But ultimately your code has to pass a webserver and pass into the application layer
- OT markets a TC (java stack) application called OTDS .It is some very simple java code that interacts with livelink,active directory or other LDAP sources .It relies on your call being passed off to a OTDS server which uses industry standard methods to create a auth token.In many simple installs it is akin to the cookie that is given to your browser after login.OT provides samples using that.It also will be mandatory in several OT installs which are primarily not a DMS.Like SAP integration,AGA integration and so on.You now have “kewl” tools like Fiddler,Wireshark etc to debug many things
- If you have a authentication token half the battle is one,you can now try simple things like adding folders,documents,applying categories to etc when you stumble simply bring up the web ui browser and see what you are trying is possible in “that” livelink.Because code you may have got working in another project may not because every livelink install can define its business rules differently 🙂
- These conditions can be tested in a matter of minutes by using SOAPUI .Once you have gotten in with a auth token and accessed enterprise workspace or perosnal workspaces,then switch to a java client ide or a .net ide . SOAPUI can only be used for certain aspect,things will get extremely complex when you encounter category/attribute data structures(funny the push to get away from llvalue data structures in lapi is still there albeit using data structures like AttributeGroups) so soapui will not cut it.
Other Buzzwords you may hear in a Livelink based project
- REST API. OT has been forced by the programming world to have a REST API implementation available in kick butt livelink installs.Note every call with a REST API is akin to you accessing livelink via a browser so save yourself some head ache by not designing bulk loader things with it.You may want to show off your livelink in a mobile application.BTW I think AppWorks is the marketing hype name for that.
- Search API-when you are in a livelink session and type a search term it is the Search API that is working for you.You can create cool search based apps with it.For heaven sake resist the temptation to write lapi or CWS code for livelink search it ain’t very easy and it si convoluted.
- ELS API- It is the wrapper connecting Livelink and archive server .The definition is not technically correct.If you wanted a SAP system to use Records management or Business Work Spaces you would put this middle ware called (old name RCS). This is a solution… means utimately you will have to pay people who know SAP Basis configuartion & Functional , Livelink configuration and Archive server configuration.Recently a guy asked me about CMIS . I looked at it and I told him to concentrate on the 3 aspects and he figured it out note that CMIS is a industry protocol and ot uses that in a ELS API layer for some objective I know not. Most solutions you will hear terms like Archive Link ,RM Link,ECM Link
Happy Livelink API or CWS or EWS programming