Let's Talk About DMCoreX and Web Services Toolkit Going Away in OnBase 15

[Nathan_Kossover]

With the release of OnBase 15 we say goodbye to some old friends. The DMCoreX API (also known as the Core API) and the Web Services Toolkit (often referred to as Hyland.Services) have been removed from the software in OnBase 15.

History

The very first files for the DMCoreX code base were added to our repository back in August of 2000, which means that it was first released with OnBase 4.1 back in 2001.  DMCoreX originally served as the private server API for the first iterations of the OnBase Web Client, but its COM-based nature meant that anyone could write code against it. Even though it was not initially intended as a public API, it was soon the de facto API for anyone who wanted to use the Core.

A few years of this quickly showed that having an API that was simultaneously being modified by Hyland Software’s Development team to add new features to OnBase modules while also supporting the custom integration efforts of thousands of customers and resellers was a bad idea. Backwards compatibility was often broken, whether by accident or intentionally. In addition, the COM-based nature of DMCoreX meant it wasn’t necessarily the easiest thing to deploy as it forced the installation of several dozen DLLs and the creation of ODBC connections on any computer where it was used.

Hyland Software realized that what we really needed was a dedicated API specifically designed for Public usage. Thus was created the Web Services Toolkit, which received its own license in OnBase 6.4 in April of 2007. The new API was a huge jump forward. It used a web services model, which led to it being referred to as Hyland.Services. More importantly, the web services model meant that only one DLL had to be deployed on the client. Additionally, no ODBC connections were required client side. Because it was designed from the beginning as a public API it did not need to have nearly as many methods and properties as DMCoreX, and changes could be made to the underlying Application Server without requiring changes to the Web Services Toolkit methods. Backwards compatibility was easier to maintain as well.

Although the Web Services Toolkit was on balance a substantial improvement over DMCoreX, it was not without its flaws. Instead of being object-oriented and IntelliSense-ready like DMCoreX, Web Services Toolkit relied on esoteric knowledge of what strings needed to be passed into service requests for given behaviors. Because of this, the learning curve was steep, and even experienced users often found themselves resorting to the SDK to figure out how to perform basic operations.  In addition, the server-side components of Web Services Toolkit were still built on DMCoreX.

After receiving extensive feedback from our customers and resellers, we tried again. The Unity API, which is often referred to as the Unity Integration Toolkit after its official license name, was released with OnBase 9 in 2009. This time we took the best of both DMCoreX and Web Services Toolkit and combined them into one API. Like DMCoreX, the Unity API is object-oriented, and the interfaces are much more intuitive than DMCoreX, and it is easier to discover methods via IntelliSense. Like Web Services Toolkit, it is service-oriented and deployment to client computers requires only two DLLs to be distributed. Client-side Java support was added in OnBase 13. We also promised to maintain backwards compatibility for the Unity API in all but the most problematic cases, a promise that thus far we have successfully kept.

Over the last six years, time and customer feedback has shown that with the Unity API we now had a public API that addressed all the concerns that had been brought up about DMCoreX and Web Services Toolkit. This of course led to another problem: we were supporting three different public APIs. New enhancements had to be made in all three places; if we found a defect in one we had to check for it in the other two. This was further complicated because DMCoreX was a COM-based application written in C++, Web Services Toolkit uses C# to reach the server where it then calls into a hybrid of DMCoreX and native C# code, and the Unity API is written in C# on the server and in either C# or Java on the client. As you can imagine, writing the same code as many as three times was not popular with anybody.

Ultimately, the decision was made to remove both DMCoreX and Web Services Toolkit from the product suite. Both APIs entered deprecated mode on December 31, 2010 with an end-of-life of December 31, 2014.

15 and Beyond

What does this mean to our customers and resellers? If your custom code uses either DMCoreX or Web Services Toolkit, you will not be able to upgrade to OnBase 15, 16 and beyond until you have converted that custom code.  

This might mean converting scripts and external applications to the Unity API, or it might mean converting those scripts to use features of OnBase. We’ve made an awful lot of enhancements to OnBase since 2001, and often those enhancements were driven by someone saying “hey, I have to write a script to do this and it would be great if could just be configured.” It’s entirely possible that you have scripts doing things that can now be done natively in OnBase.

If you aren’t sure if you are using DMCoreX or Web Services Toolkit, you should check out the Legacy API Conversion site here on Community. There are many blog posts containing information on how you can detect DMCoreX and Web Services Toolkit usage. You can even watch videos of the presentation “Migrating DMCoreX and Web Services Toolkit Solutions” that was presented at the last several TechQuests and at OTTC in 2013. If you have any questions, you can ask in the forum.

What Isn’t Going Away

Hyland Software has provided a number of other integration points over the years. These are not going away in OnBase 15. For instance, the OnBase Client API (sometimes referred to as mzAPI) is still fully supported. The HylandViewer and HylandDocumentSelect ActiveX Controls, as well as their predecessors OBXAltViewer and OBXAltDocumentSelect, are still fully supported.

If you are using DMCoreX or Web Services Toolkit in OnBase 14, 13 or earlier, that usage is still fully supported. It is only when you move to OnBase 15 or later that you need to convert, although the more you do now the less you have to worry about when you go to 15+.

In Summary

The DMCoreX API (also known as the Core API) and the Web Services Toolkit (often referred to as Hyland.Services) have been removed from the software in OnBase 15. Before you upgrade to OnBase 15 (or later!) make sure that you have converted all of your scripts and external applications that use those APIs to something that is still supported, whether that’s the Unity API or functionality that is now native to OnBase.