Mincom's Ellipse Connectors are a great way to connect to and update Ellipse from applications like Excel. The most common way of doing this is creating a set of separate XLS files with some code in them files and putting them in a central location. Most often this slowly creates a mess of unmanaged and undocumented applications, of which we don't know who is using what and what works and what doesn't.

To address these problem takes some discipline, but it takes more of a change of mind set. The Ellipse connectors that your company uses are not just sets of spreadsheets, they are major Ellipse user interface for many users. They should be secure, logged and managed as such.

I have seen several reoccurring problems across a lot of Ellipse implementations. Luckily they all have some very simple solutions.

  • Problem: Unsecured Code.
    Since code stored in XLS is modifiable if you can modify the file itself, why not store all code in a an Add In? This is very simple with Excel; you create an Add-In (a .XLA), or you can create a Dynamic Library ( a .DLL file) for the rest of the Office products. That file can be protected against your users writing to it.

  • Problem: Distribution.
    This is often solved by putting multiple .XLS on the network (or Citrix). However a single .XLA is a lot easier to distribute whether you have fat clients installed on local machines or not.

  • Problem: Bugs.
    Well i can't solve all of your bugs with a single tip, but by creating a standard library of code for the often repeated functions (eg: formatting sheets, logging, even TableFile interactions) you will save a lot of time initially coding, and save a lot more time maintaining your code. Imagine using a single one line function call to Create010TableFile()? This frees up a lot of time from mundane Copy & Paste coding.

  • Problem: Lack of a consistent look and feel.
    This can be a simple as every Connector using different colours and layout, or can be more insidious of each connector behaving differently. Often i've seen users having to remember that this Connector must have dates like 20090129 and that Connector accepts 29/01/09, some scripts treat a blank as "do nothing" while other treat a blank as "delete the data in the field". This problem can be fixed by code reuse and libraries (see last point) and a few standards. By implementing code libraries you'll solve most of these problems straight away and make your users lives a lot easier.

  • Problem: Lack of usage statistics
    How can you manage a system without knowing who uses what and how often? Do you just listen for the most vocal group in your enterprise? Hopefully not. By using reusable libraries (ie: a .XLA or .DLL) it's very simple to put in a usage logger with details of the time, user and which Connector application they are running. In the past i have done this to a centralised web server (if you have multiple form servers or fat clients) or a simple .CSV file if you have a single Citrix implementation. Very easy to set up and you'll know what and who you need to concentrate your development effort on in the future

  • Problem: Lack of version control
    This can be a tricky problem to solve. How do you make sure that hundred or thousands of users are using the most up to date version of your code? The solution is often very tied to your client implementation. However no matter what distribution and client method you are using, it's very easy to implement a central register that gets called each time a user runs the connector which checks the name and version number and then either allows, denies or warns the user appropriately. Sounds complicated? This can be implemented in under 20 lines of code with most web servers.

The purpose of addressing these problems is making your users lives easier, and freeing up your developers time from dull copy and paste scripting so they can focus on making something awesome.