CygNet .NET API: Integrators, your life just got (a wee bit) easier

July 27, 2015 / 0 comments / in API  General  / by CygNet Blog Admin

I’m not sure how many of you noticed, but with the arrival of CygNet 8.1.3 came a fresh face in town to help with all your API woes (well, some of them anyway).  Our first round of .NET API assemblies were unleashed into the world to bring hope and joy to all who write their own integration applications on top of the CygNet system.

Up until this point, you’ve had a couple of different tools at your disposal.  CygNet ODBC, the COM scripting API, and the Enterprise Integration Suite are some of the different options you have to select from when you want to build an application to interact with CygNet. Each of these tools has its own set of advantages and disadvantages.

But what about the user working in a .NET environment who just wants to make a couple simple calls to get some CygNet data and process it in their .NET language of choice, without some of the additional overhead required by those other methods?  Well, finally we have something to offer you.

I don’t know about you, but I’ve done plenty of CygNet integration projects in my day where the Scripting COM API has been my bread and butter.  How many times have you had to slog through some VBScript code like this?

Snippet

Dim vhsClient
Set vhsClient = CreateObject("CxVhsLib.VhsClient")
vhsClient.Connect("MYSITE.VHS")

Dim tag
et tag = CreateObject("CxVhsLib.HistoryTagStringEx")
tag.TagString = "MYSITE.HSS:MYTAG1"

Dim value1
Set value1 = CreateObject("CxVhsLib.HistoryEntryEx")
value1.TimeStamp = "7/10/2015"
value1.Value = "33"

Dim value2
Set value2 = CreateObject("CxVhsLib.HistoryEntryEx")
value2.TimeStamp = "7/11/2015"
value2.Value = "37"

Dim req
Set req = CreateObject("CxVhsLib.StorePointHistoryExReq")

req.TagString = tag
req.Entry(0) = value1
req.Entry(1) = value2
req.Count = 2

Dim resp
Set resp = CreateObject("CxVhsLib.StorePointHistoryExResp")

Dim returnValue
returnValue = vhsClient.StorePointHistoryEx(req, resp)

A little klunky, right?  And I didn’t even try to add error handling (just thinking about managing the VBScript Error object is starting to give me hives).

Let’s look at implementing the same chunk of logic in C# with the new CygNet.API.Historian class.

Snippet

var tag = new Name() { ID = "MYSITE.HSS:MYTAG1" };

var value1 = new HistoricalEntry() { Timestamp = new DateTime(2015, 7, 10, 0, 0, 0, DateTimeKind.Utc) };
value1.SetValue(33);

var value2 = new HistoricalEntry() { Timestamp = new DateTime(2015, 7, 11, 0, 0, 0, DateTimeKind.Utc) };
value2.SetValue(37);

var values = new List<HistoricalEntry>() { value1, value2 };

var vhsClient = new Client();
vhsClient.Connect(new DomainSiteService("[5410]MYSITE.VHS"));
vhsClient.StoreHistoricalEntries(tag, values);

That looks quite a bit cleaner. And as I was writing this code snippet in Visual Studio, I got all the benefits of my modern development environment: Intellisense, object browsing, useful debugging tools, code and performance analysis…the list goes on.

Now, you might be saying “But Dan, I already had access to those shiny Visual Studio conveniences since .NET creates COM Interop wrapper assemblies for me!” True, the framework has made it easier to program with COM interfaces. But what about all the other headaches that COM generously presents you?

For instance, what do you do when you need to deploy applications that depend on different versions of CygNet COM DLLs? Oh yeah…you’re kinda screwed since you can only register one version of the DLL on the client machine. The use of CygNet .NET assemblies solves this problem: you can now deploy whichever versions of assemblies you wish with your different applications, and since they are strongly named you can GAC them if you choose (In the spirit of full disclosure, the CygNet .NET assemblies ARE dependent on Dclnd.dll to be registered).

I could go on about all the other benefits of using CygNet .NET API over COM: simpler error handling by throwing context specific exceptions, support for 32-bit, 64-bit, and AnyCPU applications, use of system framework classes in CygNet objects.  But I know you are chomping at the bit to start using the new API, so I’ll let you get to coding.  Just don’t be startled when you hear the angelic chorus begin as you begin your most awesome CygNet integration ever.

In addition to the Historian and Core classes already released in 8.1.3, get ready to see more great .NET APIs arriving in the next and future releases.  We just can’t wait to provide you with your fix of .NET coding with points, facilities, alarms, and more!  If you have suggestions about particular areas of the API that’d you like to see added or enhanced, we’d love to hear about what’s important to you.  Also, if you are currently building .NET apps with CygNet, feel free to tell me some stories about your experiences and techniques.

I can’t wait to see the cool things you build with our API!  And the day you can rip out the last usage of COM from your application will be a joyous day indeed.  Happy coding!