Appu’s Long Lost OT Blog

Finally I found  the link to my original blog.In 2007 I joined Alitek as a senior person and was instrumental in training/mentoring most of the people there to fearlessly transgress Oscript .I am not sure if OT marketing /sales because of their vested interests trying to scare people from using the language of the application would create rumors in less technical decision makers of the org.What has happened is a reckless decline of proper design architects in the beautiful language of livelink .It is written in un paralleled style withstanding many patterns of OOP.

In any case what I would advise decision makers is if you have installed and said that Content Server  I even hate that name, Livelink it is for me is there for the ORG then hire/train good developers.It does not matter if you cannot get Oscripters. All you need to do is get a good thinking programmer either versed in java or .net technologies.The person could be set for training and that is it.

Do not employ cheap gimmicks like skins,reporting avenues etc. What a org needs can be handled by Oscript. You DO NOT HAVE to look anything other than oscript to get 150 % out of your livelink application.

Link to Patrick Vitali’s Stuff out of the world

http://www.answermodules.com/

Link to Christopher Meyer’s

http://schwiiz.org/?cat=17

The above links are concrete proof of why Oscript Rocks Really.

Now anyone who knows their computer science one on one would not be questioning why Oscript could not be mastered.

I was very thrilled to get accolades from OT and was told it was done by a peer group which does mean something to me.Now they gave me a blog and I lost the blog because I could not obey one of their time things.I doubt if OT has a award for selfless souls now most awards I see at CW is for huge accounts and managers .Money talks in software decisions one must conclude.

https://communities.opentext.com/communities/cs.dll?func=ll&objId=8298936&objAction=view

What is Enterprise Web Services a.k.a Content Web Services

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

 

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.

1. 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
2. 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
3. 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 🙂
4. 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

Transporting Objects with Livelink

Update:10/22/2014

Me and my colleagues recently used this framework for transporting a custom subtype that we designed.We were helped by a kind OT developer All in all it saved our administration team from running XMLEXPORTS and XMLIMPORTS but the key factor is that needs to work for the transport code to work.

Update ends…

Recently OT announced a “Transport” mechanism. Users working in SAP etc are familiar with such a mechanism as changes to a baseline system are marked as configuration changes and ported to other systems.While I am oversimplifying this in a SAP deployment since so many code modules have to be configured it is impossible for an admin to remember what all has to be changed hence they decided at least 20 yrs back an enterprise program needs a transporting strategy as well.

Now lets look at how livelink gets deployed in an org. Mostly Livelink is deployed to address a document management pain/problem.Some consultants or a admin/developer who gets trained in livelink or somebody who has some documentation starts to install/configure this.assuming the person(s) have some common sense and tickets later it is working.Actually the first time install guide is very nicely written and it is mostly a “next” “next” kind of install.

Having configured it the person/persons start modelling the solution.It may involve setting up folders,categories for collecting metadata,classifications for alternative taxonomies,RM classifications ,Permissions(ACL) etc. OT and a lot of ecosystem partners take the money to sometimes set it up.You can make it complicated or simple.

Ok now that it is past the POC phase the next phase is the perhaps a TEST a more formalized place.Now comes the first shock how do I not necessarily duplicate all the work I did on a lower system.Fortunately while there was no advanced GUI or “Transport Bench” mechanism many of these building blocks can easily be transferred by XML IN/OUT operations.Smarter modules such as Classifications/RM anticipated the need for this so they did make their own transport mechanism well ahead of OT. But almost everything one could accomplish in a poor man’s methods

Now in controlled industries like Pharma etc this manual stuff was sheer heresy so companies like Global Cents made excellent products

So why the Transport now. My theory is the entry of integrations between SAP and Livelink.In fact the web services also was something my thought SAP forced OT’s hands.Many SAP customers are now getting a facelift with livelink doing a lot of backend services,pretty gui’s etc.

Here’s an interesting fictitious exchange between different players in a Integration meeting this is circa 2010,2011

SAP Basis Admin-Here we got the xECM thingy and archive server thingy going with OpenText (Notice OT in that because there is no product called that),I sthere anything else you guys need and can I close the client.

OT Consultant- Oh sure but on the next client you have to give me high access to edit the connections,change a few GUID’s(dataids) etc.

SAP Basis Admin-What the …..That means you have to do all this again

OT Consultant-Not everything just a few tweaks and pointing to the livelink admin..Hey Kishore where are we  on the next OT system. Have the ELIB items(categories and folder looking things) coming along

Livelink Admin-I did that according to documentation.

OT Consultant- How about the dataids did you run the queries I gave you for the re-mapping

Livelink Admin-Yeah everything is there

SAP Basis Admin-All the while thinking that what are these guys talking about re-configure every system.I have about 20 different clients I have to maintain.

OT Consultant-Just to prop up the SAP guy,well you know our guys in Germany are coming up with a Transport mechanism just like yours…

Well finally after a lot of back and forths the project is a success

If it is just a DMS project a lot of us have no problem using the old methods.

I am pretty sure the transport mechanism  is a GUI version of  XML Export/XMl Import.

The reason why I wrote this is recently a friend asked if he would be lucky in a project that would not have Object Importer(OI)/Object Exporter(OE) and its RM variations.

I told him this

OI/OE can be leased from OT for a price .They used to entertain that.

With XMLEXPORT/XMLIMPORT here are a few things you would run into.

1. XMLEXPORT is almost available universally but the reverse is not true universally.

. So if one exported PhysObjects the corresponding import will fail.

2. XMLEXPORT will choke on big documents and the number of nodes because of DOM parser limitations. In OE they bundle the file separately so they can get more throughput even though the code invokes a DOM parser there as well.
3. XMLEXPORT/XMLIMPORT is based on source dataids which is not going to match targets. So if you find the xml exported file and change the category id’s to match the target it will work.
4. XMLEXPORT/XMLIMPORT does not understand the hierarchy. For e.g OI will create nodes as it wants enterprise:folder1:::::::::;;;folder99. In XMLEXPORT import you would have to export and follow the reverse process. So if a child object is nested way into a path OI will handle it XML import you will have to handle it
5. Most people will use XMLEXPORT/XMLIMPORT with lapi code so they can manage a lot of things with code in java or a .net lang

Now that GUIDS are part of 10 and 10.5 I do not know how that affects anything

OI/OE is kind of a framework .So with that I was able to transport compound email,email folder and email in a project with relatively less coding.

Readers-Please tell me if the Tranport Bench from OT is good and easy to use and it resolves conflicts et al and I will delete my post.