Documentum and C#

One of the advantages of Documentum is that its true multi-platform software.  Historically the problem of scripting in Documentum was addressed with a product they did themselves called Docbasic. A nice idea based on VB3 – and still an integral part of the product as Docbasic is implemented on all platforms.

However I was thinking that the only alternative to multi-platform scripting is java-bloat. You know the sort of thing – you need to devote large parts of your life to get a successful print statement.

Well I had a look at MONO for this. If you have a requirement for writing back-end scripts for Documentum and you don’t want them in Docbasic and you dont want in them in java-bloat then MONO could be thing as C# is much easier and nicer to work with.

I put a small class together –  http://www.dhrobertson.com/projects/csharp/dmclcom.zip

Its quite straight forward – this is a VS 2005 project. But if you build it as an exe, it will run on Linux and get this – Solaris 8 under Mono.

What you do need to do on the mono side is provide DLL/lib mapping. Modify your web.config file on Solaris to map cygwin1.dll to libc.so.1 and dmcl40.dll to libdmcl40.so.1 – all very simple really.

So its possible to write quite nice scripts or applications in the lovely C# – with WinForms and be able to run them cross platform. You don’t need Java-bloat and you can program in something nice and easy and rich – C#. Also note that you can use MS Visual Studio to develop the apps and then run them on Solaris – so you don’t need a Java-bloated IDE – most of which are bloatware tosh. Given this, you could also write VB.NET if you wanted and do the same thing.

Nice I think.

I had to figure out about memory management between managed and un-managed code here, but that all seems pretty straight forward.

Yes I know its not DFC and you could just use a COM wrapper – feature rich but heavy and bloated (well it is all java right!) but for simple, high speed automation for Documentum tasks, this is a good alternative to Docbasic – and you can have VB style windows and buttons to drive it – all of which works in Solaris or Linux.

In commercial terms, I’m thinking that most sensible people would want to write their client (web inlcuded!) in C#.  If they had a sensible OS running Oracle and Documentum – like Solaris or Linux, then they might have to write that in Java – which would then add to the complexity and cost of a large project.  Use this approach and you can write it all in C# and have .NET as the basis.  .NET is much better for writing web/client applications.

Advertisements

17 thoughts on “Documentum and C#

  1. Dave,

    Agree that c# is fantastic for client development, but from prototyping work I’ve done I’m not convinced that the .Net platform is the best place to implement Documentum/DFC business logic. Everything I’ve found convinces me at the moment that Documentum talks best to Java and not .Net. This is because of COM/.Net interop layer that calls must go through at the present time.

    When Documentum provide a true DFC managed code interface, that is when c# and .Net will be good with Documentum.

    The best place for .Net Documentum interoperability is currently to implement them in Java and expose them as TBO’s/SBO’s. This makes them callable from c# clients directly.

  2. Hi Brian – thanks for your post. I agree with you – regrettably – the best way for Documentum/DFC client applications seems to be that way. You don’t get the PIA when you install DFC on Solaris or Linux – which would I guess preclude applications being able to go that way.

    I’m thinking that by have an environment like this – simple server applications are possible written in C# and utilising DMCL Library rather than the bloat-angle of DFC. Quite a lot of Documentum back end code is still Docbasic and C# could be a way forward without major rewriting.

    EMC will regret having tied themselves into Java like this. I think C# is actually a return to sanity – not only for software chop shops but also for ad-hoc bods like myself who want to be able to program quickly to automate system tasks or prototype certain data transformations.

  3. Dave,

    I could show you a demo of a lightweight java tool called Eclipse that I have been using to develop server side DFC components that supports full round trip UML to java engineering.

    c# is all package based as is Java. The only difference is that the package structure in c# is burried in the .Net framework whereas in java it is exposed. c# apps run within the CLR and Java apps run in a JVM.

    Microsoft have created a fantastic client application development tool in VS.Net 2005 where all the complexity is burried from site, but it is there and you don’t realise it until you hit some ‘hard’ problem and you have to start debugging deep down in the c# package structure.

  4. You wont sway my inherent dislike of Java. I always saw it as a way of Sun selling more of their processors. Well now look what happened – All of their new servers are getting Intel chips ? Java ? Dont need it. A WINE stack is what you need now.

    I had a little look on the Java site the other day looking for a JVM for a Tomcat release for Webtop. I counted at least 100 different JVM possibilities – I mean how can that be good! Its not good – its a dogs breakfast.

    Java has had its day and C# as a language is much, much better. Sure its all managed code but – and its personal opinion – its new generation. Java is old generation and it shows – otherwise Sun would have kept it.

    I suppose at the end of the day – the true test will be whether C# applications take hold and Java becomes as defunct as its design. I hope so.

  5. I should also say that – as you are an extremely intelligent chap – you can cope with all this bloat-ware-crud quite happily. I on the other hand am not able to cope with it. I just want an easy life.

    Maybe I need to go on a java-anger management course ?

    I feel pretty,

    Oh so pretty,

    I feel pretty and witty and gay

    And I pity….

  6. I’m old enough to take rejection… I’ve had plenty of practice. I remember back in old ’95 having a very similar debate with Paul Lambert when Java was the new kid on the block and being sold on its object orientation and platform independance.

    It looks like the latest push is for the CLR to replace the JVM on Intel chips. That looks like a good thing for interop capabilities if you have a .Net front end.

    If that is the case then it looks like there may be some juicy migration projects coming along, and so………….. Java is indeed dying. Long live C# and the mighty CLR.

  7. PL – Yes well – thats says it all. Java was the new kid on the block for sure but they turned out to be a mindless bastard hoodie.

    Thats the key – CLR – if that goes onto hardware then kiss all that java junk goodbye and welcome back to sanity.

    Also means I can apply a bit of my trusty K&R ANSI C to make things go that bit faster.

    What did Java for me for forking right. I mean its supopsed to be a serious langauage for use on Unix boxes right ? Well do they allow exec ? No they dont. Anyway – onwards for our juicy projects!

    Docbasic to C# !!

  8. I agree that Java is a PITA for most things (although I do love what Open Source has done with it – Jakarta Commons, JUnit, Ant, Spring, Grails, etc). C# is pretty good but I only see it as a minor improvement over Java. If you want to knock something up quickly then have a look at some of the dynamic languages that are available for the CLR & JVM – e.g. JRuby, Boo, IronPython, etc.

    Having seen the very impressive scripting capabilities of Alfresco (which supports Rhino JavaScript & Quercus PHP) I was inspired to try out something similar in Documentum. As a proof of concept I was able to run Groovy scripts via Java Methods (the scripts were imported into the docbase in this case but they could be run from anywhere). I’m pretty sure that you could hook Groovy into BOF to facilitate dynamic document/folder eventhandlers. Another idea would be developing something similar to the API tester in Webtop/DA to run Groovy scripts on the fly.

  9. Dave et al-

    I encourage you all to become familiar with EMC Documentum’s forthcoming SOA enabler in our “D6” release, currently called Documentum Foundation Services. One way to do this is by visiting my blog and the following post in particular: http://craigrandall.net/archives/2007/05/documentum-foundation-services/.

    DFS is the path forward where interoperability is concerned. You can write .NET clients, Java clients and other, direct-to-WSDL clients against services provided with and/or supported by the DFS runtime.

    The DFC PIA is being deprecated in D6. In a mixed environment (i.e. one with both a JVM and a CLR present), the fact of two garbage collectors running without being aware of each other is…problematic (e.g. resource exhaustion probability increases–just forget a critical Marshal.ReleaseComObject() call or two in your application code).

    Shifting gears a bit over to the Java Method Server… Yes, because the JMS leverages a full JRE, you can write scripts in Groovy and JRuby now. In fact we do this internally in engineering. In D6, we’ll provide “Java DMCL,” too, which means that you no longer have to be concerned with native DLLs in your Java application server.

    Cheers,

    -Craig

  10. Beautiful bit of C#, Dave. I had to remove the Mono stuff (sorry) and change the dll references so I could get it working for a Documentum 3.x project, but I am very impressed–stunned, actually–with your fine example of how elegant C# is. Your code has changed the direction of my project and helped me greatly. I think you are a genius. Thanks for posting the code.

  11. Hi,

    I’m working with Documentum 4 and I need to call a C# dll from Documentum, but I really don’t know how. I’ve tried creating a dm_basic method and declaring the function and the dll within the method, but an “DLL function not found” error keeps appearing. Can anyone can explain me how to do this or maybe show alternatives.

    Thanks

  12. Hi; thanks for this , but I got an error while compiling
    /***********************************************/

    The name ‘orig_dmAPIDesc’ does not exist in the current context Program.cs [226] [33]

    /***********************************************/

    any help ?

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s