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


Simple Easy To Understand Livelink Authentication using Just IWA

Update- I have  successfully implemented OTDS (Auth & Sync).OT wants all of us to install Tomcat and use java based OTDS for all the things that is Authentication(letting people into livelink) and Synchronization(Creating those people in livelink). Oscript based Directory Services called CSDS will stop shipping when 10.5 dev is complete.I still don’t like the fact that a livelink URL is redirected to TC to come back to livelink,when it could be avoided.That is the mechanism of a OTDS authentication implementation.If left to me I would use OTDS synchronization and just IWA for livelink.

My colleague John taught me how to record video so it is my yet another attempt to teach other users how to make your livelink  single sign on

These are my assumptions.You want to run Single Sign on in your livelink.Your livelink is running on windows and uses IIS7/7.5.

  • Chore #1-Prepare the IIS website for IWA.IWA is called NTLM some times ,  but if you use Fiddler to watch a request you will see a 401 Challenge against AD. Theory is you are accessing a protected resource and the web server will check against AD. No where remotely connected to livelink software.I also say AD because most companies use that.If your company used something else it would do that.

Kyle Bailey was the first guy to use IIS7 on livelink this link will not work If you do not know preliminaries about IIS learn it.

OT uses almost ditton info in their install documentation

Watch this Video of how I check that.






Checking if IIS is upto our job of providing IWA?

  • Chore #2-You have to enable the livelink website or VD for IWA. For administrative reasons I usually put a anonymous  website so I can login as ‘Admin’ or any other user whose password I can change. I will also create my userid in that livelink before I do this so I don’t get knocked out. So if my domain info was appudomain\appunair in livelink I would create my userid as appunair in lower case

Checking if the Livelink website or Livelink Application is IWA enabled

  • Chore #3-You have to find CSDS. Oscript Directory services for your version and install it in livelink. Most livelink modules are executable that just drop them into the staging folder. The author assumes the user knows how to do that .If your manager says to do OTDS frown at him and when he is not watching you do this instead.
  • As of CS10 Update 6 the code to vet the REMOTE_USER into livelink is in core code.All you need is put the livelink webapp as IWA, go to the admin.index and make sure you say “use webserver for authentication” radio button.Here’s an article that was mostly written by me in the Knowledge Base
  • If your users are using livelink purely thru the webgui this is more than adequate for you.How ever if you find yourselves saying yeah this is fine,but how do I get 2000 users into livelink,that is when “Synchronization” code in CSDS or OTDS comes into play.You can create users in livelink by writing about 20 lines of code reading from a spread sheet as well.
  • If you have Programmers who were using SSO with lapi or CWS applications they can either change the WSDL to point to the OTDS WSDL .AFAIK it is not possible to entertain coding that des SSO without Oscript Directory Services.

Checking if the Livelink administration page is correct to allow IWA authentication

  • Chore #4-In case it does not work type ?func=admin.testargs. If you do not see REMOTE_USER is not coming thru you will have to trouble shoot. You have to be a sys admin to do that as well.Note admin.testargs is livelink oscript code spitting out web environment variables.You can find equivalent aspx files in the web.

Why do I not like RCS(OTDS) .It will take a good few years before it is stable. Also I do not like the idea of a call to livelink ,hopping over to Tomcat,to again call AD to return a ticket which again was the REMOTE_USER.Now you would surely benefit if your org wanted to make SAP talk to livelink .Also it is downright confusing if you have to write SSO code against livelink as well.It is confusing to write even when it is IWA on the web server

I feel unless OT is able to assure its existing IIS clientele(about 75 to 80 %) that OTDS will be a better alternative than the OOB IIS IWA, most customers will stay with trusted windows authentication rather than the contraption/conundrum.What they can do is to make the java code base in tomcat stronger rather than telling each customer the slightest crapping out of RCS results in a re-install.What OT does not understand is big companies cannot hot patch /change stuff right when OT wants is that is far from the truth in the ground.Obviously the Synchronization code with which one creates users and groups in livelink is very much better in this java version.Once again many people confuse synchronization to be somehow tied to authentication. Nicht, Nein they are no way connected.Synchronization just allows users and groups to be created and held synchronized based on a LDAP query both of the activities are in no way connected to each other.

If the reader now understands who is doing what then I see why a intelligent user could not use another server say apache or tomcat to do windows authentication and help the livelink world.I just wanted the users reading this to know that OT has no interest in teaching you how to configure IIS as it is expected that a web server admin knows all this.It just happens that Livelink is a webserved application and hence the livelink admin sort of is the IIS admin and so on.