Between 2009-2012 I was instrumental in architecting a very large RMlink implementation.I was mainly hired for setting up livelink.livelink RM,archive server.My peripheral duties included acting as SME to the RM link implementation.Further the customer decided they would make use of two OT products one livelink and the other Artesia(DAM) both would sit in the SAP netweaver and be visible based on the employees roles.I know nothing about all that.Slowly but surly I began to understand that livelink a.k.a Content Server is going to be the brains and Archive Server was going to be the brawn in this implementation.The RCS tomcat stack at best could be described a nuisance or so I thought because once it started misbehaving there was nothing you could do other than uninstall.On top of it we were forced to work on a AIX(Unix) archive server implementation.We had specific archive server things that we had to maintian for that to work and with every patch RCS it overwrote everything we had configured.I figured out that RCS was basically using servlet/java code to call livelink that is pretty much it.It would be called “Enterprise library”,ELItem,ELVariant what not but the real fact remains that it is in dtree with a subtype that is known to most livelink people.At a pre -go live meeting a bombshell appeared in the form of a SAP consultant(big manager kind of guy) who said how are you going to handle the authentication ticket from SAP for livelink & Artesia? Upto that time we had created a IWA implementation of livelink replete with LDAP(AD) SSO and we thought that would be it ,the SAP netweaver user and the livelink user is using the same AD and hence would basically be in the same env not challenged by AD.No the manager insisted that livelink and artesia need to work based on the ticket given to you from SAP.It looked like either the manager knew what he was talking about or he just wanted to show off stuff.Everybody started looking at me and I really had nowhere else to look.Luckily a very experienced person came to the rescue and said to me that SAP produces mechanisms for all commercial webservers including IIS & Java stacks.
Now we started in earnest burning the midnight oil and I had a very great apprentice at that time.I would say he is very good
He started getting the IIS web server loaded with the SAP filter it is like the llisapi.dll that we use in livelink and when it works it needs a certificate form the sap instance that is going to decrypt the cookie.Then we tried writing it to REMOTE_USER which it wrote as http_remote_user.I think REMOTE_USER is a variable that you cannot rewrite.In any case we change the livelink to look for that environment variable voila we had SSO based on MYSAPSSO2 in place.Phew.Firefox plugins,Fiddler,Wireshark and a general understanding of what goes and comes where is what on would need to crack things of this nature.BTW I saved all my work in a drive which I have since lost so some of this is from memory.My knowledge of how livelink handles authentication really helped in making this solution.thanks you builder for that.
I later customized the livelink look and feel and removed most unwanted stuff so the real estate was there for people to work
For artesia we had to take the java class file and retrofit the login again this java file would not work in a regular package declaration like one would do.It was not common knowledge and I basically resorted to Reflections code and got it to work.I got in touch with a SAP SDN member who actually said I should use a particular package that SAP produces or not use a package declaration at all.So go figure.Nothing that SAP gives you in documentation says that.So go figure .You could say OT & SAP are birds of the same feather when it comes to hand holding examples.
In the current setting the OTDS conundrum that you load in RCS will handle the SAP logon ticket.I have not yet had the need to make OTDS work in my job so I hope it is easy and past the buggy stage that I have known to associate RCS with .Our OT ECMLink/RM link people always thought livelink impersonation was SSO which again I fought with them telling no they are actually different.In any case the customer did not do ECMlink when I was there other than trial runs.I am sure the java code stack is much better nowadays.
I hope reading this will help somebody in my same shoes
Appukili's Weblog 