LAPI when your sole requirement is to mess with Records Management or Physical Objects Management

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

**********************************************END UPDATE****************************


LAPI is not dead it seems.Recently some posters wanted to do something with LAPI and especially with Physical Objects Management.The RM & PO modules are very great functional mods very easily installed and configured and works for almost any condition.Excellent design thoughts by OT(or is it iRIMS). The Web services bandwagon has not exactly swept in with the folks it seems.In any case for the old timers here is the cheat sheet

LAPI you are old need 32 bit computer also VJ redistributable on the livelink server if you are on LL9.7.1 or down

win7 64 bit computer livelink server if you are on CS10 or up but a downgraded .net framework

No installer is made for CS10 so I would just go to any old lapi project and put them in a .NET project which is less than 3.5 CLR

The programmer gets into a very simple document add or folder add routine so he /she has the bearings of how to work against livelink and LAPI if you have not messed with LAPI before do not think you can code in RM/PO LAPI API’s

Here’s the Rub.The RM/PO API is written to look like it is its own product in fact it is not.They are just interface files which the programmers can add to their project and nicely hidden in the server install modules.So if LAPI was given to you as a client installer the RM & PO API is sitting inside the SDK folder of the livelink server.I have many times had need to do this in java and C# so without prejudice this  how I do those tasks.Java is a little more complicated as I am not a full time java programmer or for that matter a C# programmer

If you had a IIS server serving your livelink things basically it takes less than 30 mins to create an application to expose DM services,PO services and RM services so if you are in a org that likes to be modern by all means do that approach

Intelligent people on the Sharepoint side have built and safeguarded their investments by creating their own API’s revolving around LAPI(the AGA framework) so I am thinking that LAPI has not been axed and retired.

BTW the ObjectImporter product plus its add on called OI for RM will allow you to bulk add PO and RM info much easier and much less to program than the lapi or webservices approach

How to use WCF Livelink web services to create a quasi single sign on or login with cookie equivalent of lapi

Recently OT Dev said that don’t really spend time on the Search SOAP service but use the Restful search API that has been there all along these years.

Since almost everything in livelink is served off a URL one of the first things it needs is authentication.For livelink deployments who do not have Single Sign On based on web server auth it is inconvenient that a webapp designed in C# provides links to a livelink URL for e.g I may have an href called “My Assignments” and then I may link it to my livelink server url and the query string ending in personal .assignments

I really don’t think organizations using livelink still use userid/password but this will probably help those users.

http:://my livelinkurl/livelinkvd/llisapi.dll?func=personal.assignments

Now everybody reading this should know that livelink will look for a cookie if not it will present a login screen. Our attempt is to use the token (cookie) returned to us by the CWS auth routine and make sure we can pass it off to a livelink URL or making the request to livelink as if one had logged in and subsequently performing operations.

In my example I am doing this with a LL 9.7.1 version so the ref key word is not used.For newer CWS the ref keyword is needed


LL9.7.1 Oracle,IIS6, webserver is anonymous,livelink auth scheme is livelink ,No RCS present,No Dir Svcs module in deployment

in SSO deployments calling a livelink URL from a auth user’s computer results in a pass thru experience so none of this circus is needed anyway.

What I found was if you were adding the LlCookie to the request you have to do a lot of coding as in the user in this thread.I found several hits in the web

to spoof the Cookie but a lot of code for somethingthat you know is not that secure anyway

RE RE RE RE RE Get Region Name

He first gets the auth token and uses cookie setting code to call the search API.

While that is all good and dandy  if you have access to  a web debugging tool like Fiddler if you capture traffic for the first auth call you can see your userid+password

if it is a HTTP connection.I am not sure what it will look if my livelink was HTTPS.So I would just build a userid/password url and specify everything in NextURL.

So if I was coding a C# app and wanted to call my search system in livelink I would just use the simple approach


In the above URL the Func=ll.login sets the Cookie and then the NextURL is indicated,it is just webescaped for transmission