Pros And Cons of Different Ways to Custom Programming for eDOCS DM

Below I describe 5 different approaches that I know to programming for OpenText eDOCS DM:

DM Extensions API, DM API, Extending DM Webtop, Consuming WCF Service, and Direct Access.

DM Extensions API 

It's described in detail in eDOCS DM 5.3.1 DM Extensions API Programmers Guide.pdf from eDOCS DM documentation. You may want to use it if you integrate your code into DM Extensions menus or if you utilize many UI elements of DM Extensions, such as profile, search, and lookup forms. This is the advantage of this approach.

Using this approach, you activate an instance of the DM.exe process via COM, the DOCSObjects.Application object. This dependency on DM.exe seems to me as the biggest disadvantage of this solution, if you are considering it for a standalone application and not for extending DM Extensions.

I saw a few tools created with DOCSObjects.Application and the most common problem guys had was that they couldn't properly reuse the running instance of DM.exe and then they couldn't properly detach from it after their tool is closed. DM.exe was left running in the background, and until it is killed from Task Manager, even Windows Explorer DM Extensions couldn't be launched. At the same time the guys hardly used many UI elements of DM Extensions. All they needed from it were the Login dialog and the document download popup progress. The former could be easily built from the scratch; the latter is extremely slow, if you want to upload or download multiple documents. So, what's the point?

Pros:

• You can reuse UI elements of DM Extensions.

Cons:

• In terms of UI, you get what you get, without much control over how it looks and when it pops up. 
• You have to take care of activating / deactivating DOCSObjects.Application properly.

DM API

eDOCS DM 5.3.1 DM API Reference Guide.pdf is about it. Some developers refer to it as DM Server API vs. DM Extensions (Client) API described above, but this is incorrect. It's the client-side API:
Objects are created and executed on the client side; DCOM calls to the DM Server are hidden from the developer.

DM API is a set of COM (ActiveX) DLLs, which are installed in C:\Program Files (x86)\Open Text\DM API by default. DM Extensions is built on top of DM API. That's why you can use it on any computer where DM Extensions are installed. And the opposite is true: if DM Extensions are not installed, you must distribute DM API along with your application. Deployment considerations are on the downside of using DM API.

You can write code with DM API in many different programming languages, which allow the use of ActiveX: C++, VB6, VBA, C#, VB.NET, etc. However, is this a big advantage? With the choice given, I don't even consider anything but .NET. The problem is that DM API is VB6-like and using it in .NET is awkward, unless you write some managed wrappers.

Pros:

• This is documented API. You can find code samples, so it's easy to start with.
• It has no UI. You are free to implement User eXperience as you want.
• It's best to be used in custom applications for client computers where DM Extensions are installed. The DM Server installation also includes DM API, so you can also create custom server tools with DM API and enjoy the ease of deployment.

Cons:

• Deployment complexities. Being ActiveX-based, DM API DLLs are relatively difficult to deploy along with your application, unless you deploy it to a DM Server or a workstation with DM Extensions. There is a standalone MSI installation of DM API if you may need it.

Extending DM Webtop (CyberDOCS)

Check eDOCS DM 5.3.1 Webtop Customization Guide.pdf. This is somewhat similar to extending DM Extensions, but for Web. I don't know much about it, but it's unlikely I would want to use it. It's old classic ASP. Does anyone find fun developing and debugging it nowadays?

Pros:

• The only way to seamlessly embed your custom UI code into DM Webtop.

Cons:

• Old classic ASP. You've got to find some antique developer tools to build for it.
• Depending on how good you are in isolating your customizations, you will have more or less pain in updating your code with new releases of eDOCS DM.

Consuming DM WCF Service 

DM WCF Service is a new feature in DM 5.3. With it you can do everything of what you can do using DM API. At the same time, you are totally independent of DM API dlls, at design time and also at runtime. You can build your application in any language, which allows you to consume Web services. eDOCS DM publishes WSDL-description of its service and this is pretty much all you need to know to build a client. Using Visual Studio: you simply add a Web Reference to your project and you are ready to use the auto-generated classes. Doesn't it sound great?

But it wouldn't be Hummingbird / OpenText, if it were great by all means ;) On the other side of the coin we see:
a) Documentation is nowhere found on eDOCS DM CD.
b) API - classes, methods, and parameters - don't look .NET-like. They are more Pascal-like.
b) It's really low-low-level. When I said that DM API is low-level, then compared to it the DM WCF service is way under the ground. For example, after executing a search criterion, you are to get results from the server in binary chunks and to parse them.

Fortunately, there is an eDOCS_Samples demo project accompanied by eDOCS Samples Application.docx. I hope you can find it in OpenText Knowledge Center. I inherited my copy from a guy who worked before me.

Although DM WCF Service is .NET, it translates calls back to native DCOM objects on the server side. This means that you will not get any performance boost over DCOM and DM API.

In DM 5.3.1 Patch 4, DM WCF Service exposes two server endpoints: basic HTTP and net.tcp. I haven't had time yet to check if there are more and if there is a way to configure their behaviors.

With this said, I like DM WCF more than DM API. You would have to build helpers / wrappers for either of them, so it's probably wiser to do this right away for WCF rather than for both as I did.

Pros:

• It's .NET. It's managed code.
• Easy to deploy. No dependencies on any DM redistributable components, such as DM API DLLs.
• Easy to consume (WSDL to generate a WebService reference).

Cons:

• Undocumented. OpenText may decide to change the interface or take it out completely in the future.
• Low-level. You have to build a set of helpers / wrappers for your own convenience.

Direct Access to Database and Document Servers

I love it, when it comes to extracting metadata and documents from DM! It's way, way faster than going through the DM application server as it's free of any business logic involved and COM+ technology burden. All you need to have is the access to the database and document servers, which you usually have, if you administer the document management system.

Apparently, this approach is for read-only operations only, where DM's business logic is primitive enough to be replicated in your application. Thus, for data extracts I would need to be able to recognize document versions (e.g. find the latest) and compose the file name - not big deal at all.

For the database access I use fabulous DevExpress XPO. And as for copying files, it's as simple as calling System.IO.FIle.Copy.

Pros:

• The fastest possible data access.
• True multi-threading is at your own hands.

Cons:

• For administrators only.
• For read operations only.
• Even for read-only operations, replicating DM logic may be a challenge.