aaAttributeBrowser learnings

In my undertaking to develop aaAttributeBrowser I have learned a few things, and as a result I significantly changed the design from the original plan.  Here are some things that were not immediately obvious to me as a novice AOT developer:

  • GRAccess requires an IDE License.  IDE licences are issued out per session.  ArchestrA objects run in session 0 (the session used by services and other system bits), and the IDE runs in session 1 (or higher), which is your UI session.  Hence if you run the app from your desktop it will not gobble an additional IDE license to the one you are using for the IDE.  However as soon as you put GRAccess into an ArchestrA object you will require an IDE license for session 0 as well as your user session.
  • When accessing Arrays with the MXAccess toolkit, you need to add [] to the attribute name to get the entire array!  You can also get individual items using the [1] notation, indexing starts at 1!
  • Using the MXAccess toolkit inside an ArchestrA object seemingly does not go well, and typically results in errors when receiving datachange events.  I am yet to work out the cause of this.
  • For some reason, you can only build ArchestrA objects in visual studio when the objects have not been deployed to the GAC.  This means, that to package a new version, you must undeploy and delete the object from the Galaxy, delete them from the GAC (the .NET 4 GAC is at C:\Windows\Microsoft.Net\assembly$$.  You may have to shutdown the engine that the objects were deployed to, and restart the aaGR service before you can delete the files from the GAC.
  • Any additional .NET assemblies that are packaged with the object, seemingly must be strong named.
  • AOT objects can be debugged!  Just attach visual studio to the correct aaEngine instance for your object and set your breakpoints!
  • The vendor name in the object designer is tied to the company field in the assembly info.  If you change the vendor/company in one place, make sure it is changed everywhere, as mismatches can result in a big mess that ends up resulting in a Galaxy rebuild!  Also, best not to change the vendor once it has been deployed to a galaxy, it really doesn't like it!

With the above learnings, I made the following executive decisions:

  • Ditch GRAccess, as it is not acceptable to expect people to pay upwards of $10k for this simple bit of software.  For enumerating attributes, use MXAccess to read the _Attribtes[] attribute.
  • Because MxAccess doesn't work inside the AOT, don't use it.  Scripting in a regular object is easy enough to start and stop an external process.

Note that there is no technical reason for having a client/server architecture any more.  However, to keep the client control as light as possible I decided to keep the client/server model, as it does provide the handy function of making any object attributes available in a web browser.

| November 27th, 2015 | Posted in SCADA |

Leave a Reply