I’ve recently had to set up a local Livelink environment because my system is running too smoothly and I need to throw an enterprise-level content management system at it to remind it that there are things in this world that can take you down in a second.

To minimize the (inevitable) damage, I’ve set up a separate virtual machine for it using a clone of a base Windows 2008 Server image I have. One with IIS7.

I’ve become quite adept at configuring IIS6 for Livelink (versions 9.5 and 9.7). You create a virtual directory against C:\opentext\cgi (configured as an application) and another for c:\opentext\support. You also need to allow executables. AND Allow Unknown CGI Extensions and Allow Unknown ISAPI Extensions under Web Service Extensions in IIS6. I’ve always been leery about opening it up like this so for IIS7, I was looking for a more restricted way of allowing livelink.exe to run.

IIS7 does things similarly but the options are in a different spot. Essentially, you’re configuring it to run CGI applications.

I’m assuming you’ve run the Livelink install on your machine already. In order to configure IIS7 after it’s done:

• Open IIS
• Click on the server name at the top
• Double-click ISAPI and CGI Restrictions

• Click Add and enter the page to your livelink.exe. Make sure you select Allow extension path to execute

• We’re only partway done. This allows the livelink.exe module to execute when given permission. But by default, IIS7 doesn’t allow CGI applications to execute. In the main IIS window, select the Livelink application and open Handler Mappings

• Next, select cgi-exe at the top of the list in the main panel, then click Edit Feature Permissions… on the right. In the dialogue box, check off Execute and click OK. (In the screenshot, I haven’t checked Execute because as soon as you do, the UI is updated underneath, making the screenshot harder to explain.)

• Finally, reset IIS (i.e. run iisreset from the command prompt or the Run dialog).

After that, you should be able to access your new Livelink installation from Internet Explorer (e.g. http://localhost/livelink/livelink.exe). Firefox is another matter. For whatever reason, it’s not working on my machine. It keeps wanting to download livelink.exe rather than run it as a CGI application. I have reason to believe it is related to content type but I’m nearly positive it worked under IIS6 without any further configuration.

Ah well, a post for another day. If ambition holds, I’ll put something up on configuring a SQL Server database for a local environment too.

Kyle the Livelink’d

Finally! I'm part of the elite! Part of the clique who can now recommend Lutz Roeder's Reflector with full knowledge of its greatness.

Until today, I was just a poser. I knew of Reflector and was keenly aware of what it did. I played with it for a bit but had never in my consulting career come across an instance where I needed to dive that deeply into someone else's code. But I left it installed on my machine because I wanted to pretend to be one of the big boys. And I started to crave the appreciative nods I'd get from better developers when they'd see it prominently displayed on my desktop.

Then lo! An e-mail comes screaming through my Inbox: where is this error message generated for the Franken-app you built that syncs PalmPilot data with Livelink?

(Side note: If I can brag a little, I'm actually kind of proud of that app. Built in .NET, it works better than the application I was trying to mimic on the old software Livelink was replacing.)

The app uses Livelink's API to wedge stuff into the system so after a quick look through Livelink's code base itself to see if the error was there, I dusted off Reflector and pointed it at the API assembly. String search and lo, again! There it is!

So now I can accurately answer that e-mail: It is generated in the receiveOpenResponse method of the LLConnectRouter object in LAPI_NETp.dll.

That should get them off my back, yesno?

I've mentioned before that I like working with Livelink which is not the same as recommending the product. I have been working pretty extensively with the Livelink Physical Objects and Records Management modules and those two modules are pretty hideous. I have yet to work with a buggier enterprise-level product, and they are both at version 3 already.

Here is a laundry list of issues that my current client alone has reported to Livelink:

• The PhysObjAssignToBox LAPI function fails. Always
• The PhysObjGenerateLabel LAPI function fails. Always
• The PhysObjAssignLocator LAPI function fails when the locator doesn't exist. But not in the way it's supposed to.
• There is a PhysObjChargeOut LAPI function but no PhysObjChargeIn.
• When browsing a folder, boxes will always show as containing 0 items, even if they have items in them
• When checking out a box, the locator is not removed. I.E. The box still "occupies space" in its locator
• When browsing a folder, subfolders do not automatically appear at the top as they do in Windows

This is a seriously trimmed down list because most of the other items are too complicated or too frustrating to talk about.

As an aside, these types of errors are part of the reason I like working with the product. As I mentioned in a previous post, you are able to step through the entire codebase for Livelink as its running. And when I encounter these problems, it's very empowering to be able to determine if the bug is mine or theirs. Again, it doesn't mean I'd recommend it (at least for records management) but as a developer, I like working with it.

The other big problem I have is that the product is not very extensible. I'll need to explain because that counters pretty much everything anyone knows of the product. What I mean is that in order to extend Livelink, very often you need to do a customization. And very often, that means overriding an existing request handler or function or feature somewhere.

So while you can do this easily, I have been doing my best to avoid it. I have been asking for nigh on eight months now what the upgrade path is if we do override existing functionality and upgrade to newer versions of a module or the core product. No one seems to know. And my guess for the answer is that you will essentially have to go through all of your customizations and make sure they don't break or interfere with new functionality.

Which is what you would do normally but in this case, the customizations are at a very low level. As in they often talk directly to the database. As in the presentation is pretty tightly coupled to the business logic and sometimes even the database. So while I would love to fix the bug where boxes always show as containing 0 items, this would involve making changes that are very likely to be overridden in the next version of Livelink. In short, upgrading a Livelink installation with a lot of customized code is not to be taken lightly.

Compare that to SharePoint or other products where the entire application is designed to be customized and extended. There is a rich API that doesn't require (or even allow) you to go so far into the bowels of its inner workings.

Besides which, the API errors alone do not inspire a lot of confidence. There is absolutely no excuse for the first two items in my list above. These two API functions just plain fail. In every single scenario. There is no way to call them without getting an error back. Which says to me that Open Text didn't perform even basic unit testing on them. Or any kind of testing. They just compiled it and hoped for the best. (In fact, the PhysObjGenerateLabel API function shouldn't even technically compile because it references a non-existent feature.)

Here's one for you .NET Livelink developers. I love Christopher Meyer's EasyLAPI library from the Open Text Knowledge Centre. But of course, it's in Java and the Coding Hillbilly is strictly caffeine-free these days on account of his cholesterol.

The library was manageable enough that it didn't take too long to create a C# version. Some minor syntax changes and some other changes based on how I would do things if I were to write it from scratch in C# (most notable, replacing the Vector references with ArrayLists), and away I went.

Of course, that doesn't help you, the throngs of C# LAPI developers, in my readership. So I cleaned it up further, converted the comments to be .NET-like, and changed a couple of methods to properties as I saw fit. Resulting library is attached.

One fairly major change is the addition of a configuration handler for the sessions. The Java version used an .ini file to manage multiple sessions. I'm using a custom config section. The upshot is that you should include something like this in your app.config:

<LLSessions>
    <Session name="local" server="localhost" port="2099" username="Admin" password="livelink" />
    <Session name="dev" server="localhost" port="2099" username="Admin" password="lldev@dm1n" />
    <Session name="test" server="localhost" port="2099" username="Admin" password="lltst@dm1n" />
    <Session name="prod" server="localhost" port="2099" username="Admin" password="llprd@dm1n" />
</LLSessions>

Then in your code:

In my code, I also add a defaultSession key to my app settings which allows me to switch environments quickly and without having to re-compile the code. Ideally, I should have a defaultSession attribute on the LLSessions node but I haven't got that far yet. Also on tap is the ability to encrypt username and password. Wouldn't mind using the Enterprise Library for configuration as well but then I get into problems of having one version for .NET 1.1 and another for .NET 2.0 (and perhaps 3.0 but I doubt it). Plus I don't want to force people to use the Enterprise Library if they don't wanna.

It has been tested very little except to create some folders and some RM objects. The rest of the code is lifted directly from Christopher Meyer's version which seems to be pretty solid to my limited understanding of Java and LAPI in general. The commenting took more time than the conversion.

I've been developing in Open Text Livelink for nigh on six months now and have avoided talking too much about it because frankly, I think it would be a career-limiting move. But I think it's time...

Livelink development is a strange beast coming from the .NET world. It has its own development language, OScript, which I have no doubt was quite powerful in its day. Today, it's pretty archaic.

One of the major data types is an Assoc. It's used everywhere and for everything. It's essentially an array of name/value pairs. To add to it, you just start using a new key:

Assoc emailAddresses
emailAddresses.CodingHillbilly = kyle@hillbilly.org
emailAddresses.SisterWife = ma@hillbilly.org

So to summarize: it's a hash table. Except that you don't have to explicitly add values, you just start using them. Which in my opinion makes it a dangerous hash table. (There's a reason good VB programmers turn Option Explicit on.) And it seems to be the cornerstone of most OScript code I've seen.

The development environment also strikes me as "revolutionary in its day". Nowadays, a hillbilly gets testy when the scroll-wheel doesn't work out of the box. And when Ctrl-Left Arrow only works on the first word. And when you can add breakpoints only at the beginning of a function (except when you have actually broken into the function). And when there's no watch window. And so on and so forth.

Next up: the development community. Whoa Nellie, are .NET developers a spoiled bunch! Google the text of an error message and more often than not, you'll find at least something to get you started down the path of righteousness.

For Livelink, the main (and as far as I can tell, only) source of answers is their Knowledge Centre, which I won't bother linking to because you need to log in to see it. Which means no Googling. And answers are fairly sparse, I suspect because it's such a pain having to log in and navigate through the discussion forums to provide your insight.

Most of my frustration, to be fair, is because like I said, .NET developers are spoiled. OScript isn't as prevalent as C# or Java so that also contributes to the lack of help for tough problems. It has its own little web architecture that differs from what I'm used to with ASP and ASP.NET as well. And I'm only six months into this little odyssey so I imagine it gets easier with time.

But despite this, I'm having fun with the product as I often do when I'm playing with something I've never done before. Archaic or not, it's still a new language. And they allow you almost inhuman access to modify absolutely anything in it, including the development IDE itself. Which is good because their Records Management and Physical Objects modules are some of the buggiest software I've ever seen in an enterprise-level product.

I'm also encouraged by the fairly recent partnership with Microsoft which will almost certainly improve the SharePoint integration. Until then, I shall continue to die a little every time I use a variable without declaring it.

I gotta start a personal blog again. It's just way too hard to be witty about technical topics.

This post is seriously stretching the bounds of my readership's general area of interest but I'm going anyway. As I've alluded to in the past, the Coding Hillbilly has dabbled in Open Text Livelink. Oh, stop laughing. I kinda like it actually. There's something liberating about being able to fix another company's software.

At any rate, Livelink has a theoretical limit of 200 items per folder. After that, the performance starts to degrade pretty significantly. They have no problem storing more items but when it comes to displaying them, the interface becomes wholly unusable. Not only does it take a long time to render (because a bunch of checking is done on every item as it is being rendered, I think) but just clicking checkboxes next to items is an exercise in frustration.

So my current employer tasked me with investigating how long it would take to incorporate pagination into the product. Livelink is somewhat unique in ECM in that almost the entire codebase is available to tweak/butcher should you want to...shall we say..."pursue that option" to be politically correct.

And pursue it I did. I started out with investigation but it was boring so I wrote the module instead.

So to summarize for the search engines: I have added pagination capabilities to Livelink. Those not in the know probably don't realize the impact of this statement but I'm betting those that have dealt with this are searching the screen for the "E-mail me" link as we speak.

The implementation is pretty straightforward, actually. Not a lot of code behind it. Most of it has to do with managing the links to go to the next/previous/first/last page.

My intention is to release it into the wild but that is not my call to make at present unfortunately (which is also why there is a distinct lack of screenshots here). Hopefully I'll be able to in the coming weeks but in the meantime, contact me if you're interested.