BITtelligent ERPLink Update

One of the most requested features of late is web forms for ERPLink. They are a long time coming and I am happy to say great progress is being made on them. I want to give a bit of history behind the forms and then provide you with a glimpse of the new web forms that will be included in the next iteration of ERPLink from BITtelligent.

Initially the ERPLink web forms were a collaboration between a Business Partner and Sage in development. I was working on the Sage side to enable API access to the system. Progress was made and a iteration or 2 was provided out to the community to test and confirm the functionality. Not a lot of feedback came and other priorities took over in the mean time. One of the biggest problems with the web forms was the usability story. ERPLink is a pretty heavy sync engine that works in process meaning that it was quite possible that there could be lockups, timeouts and potentially crashing of the IIS process when doing a link and sync. Also most of the core functionality was provided through SalesLogix LAN client. Management and Loads would need the client to be installed even in a web only environment.

When we acquired the ERPLink and DynaLink IP some tough decisions had to be made, some I am still living with since we are not yet ready to come to market and we have done what we can to provide timely updates to the progress of the updates we are making to the platform, however the changes are quite substantial and take both time and effort (as well as $$s) to execute. We have finished principal development on DynaLink and are ready for providing CTP to customers who sign up to the BITtelligent software assurance program. It’s a great time to do so because the feedback will shape the product and the features in a meaningful way.

ERPLink however is taking a much longer time. It’s a bigger beast and we really want to make sure its completely ready for prime time. We have in the mean time built out a interim release based on the HF code release that is branded and includes some incremental fixes. This interim release will be provided to any existing ERPLink customers who sign up the the software assurance plan and they will automatically be eligible for future releases of the platform.

Now back on web forms. Though the team at Sage have created an incredible product in SalesLogix and I am very happy to work with all of them I had to make some critical decisions on how I was going to invest into ERP integration into the Web client. I mulled over the current smart part architecture and the bundler. Also how 3rd party functionality integrates and the development effort required. I also balanced it out on the product plans that Sage has publically stated for both MAS 500 (now Sage 500 ERP) and SalesLogix. Factoring in the future push for windows 8 and some more immersive UI’s and the goal of standardizing on a code base in the future for all of our integration platforms. Ultimately I had decided that for US (BITtelligent) a focus on XAML based UI technologies would give us the best in several worlds. For the following reasons we are picking Silverlight as the UI web forms technology for our ERPLink integration;

  1. Simpler packaging and distribution in .xap files where we do not need to worry about merge/upgrade issues with SalesLogix smartparts
  2. Silverlight currently has a greater published support lifespan then MAS500 (MAS 5+ years, Silverlight 10)
  3. Quicker development time. We can develop all of out UI code outside of the SalesLogix build/deploy cycle. There are robust tools and the code can be contained into 3 known tiers (UI/Services Façade/DB access)
  4. Easier to integrate both platforms in our UI. To reduce the sync cycles we will be adding dynamic queries as an option. Therefore there will be a huge win on the daily data request cycle.
  5. Though this is subjective I believe with XAML based tech we can provide a better UI with a greater ROI
  6. Shared code base. Moving forward a lot of the assets can be shared seamlessly between a win forms (WPF)/Web and future Win8RT client

and there are other reasons. Its always good to review product goals and ensure that the investments that we make coupled with the investments our customers make .. well .. make sense. Its tough to predict tomorrow but for our team we will need to focus on the consolidation of efforts and platforms and choose technologies where we can deliver the greatest value with the least effort.

This post includes some screenshots of the upcoming ERPLink web plugins. Hopefully you will like what you hear and see and I welcome your comments.






To Registry or Not To Registry

Dynalink uses the registry for storing configuration details. This includes runtime settings as well as paths to any of the configuration databases located on the system. While developing the new version of the platform several things bothered me about this approach but one thing specifically with handing different versions of the product on the same machine. Our goal is to allow for side by side versions of the service application. Each capable of service a different set of databases or versions of MAS. This would work well when testing new environments or migration work.  I am not a fan of the Registry and believe that having the configuration stored in the file system local to the runtime is a much more desirable solution.

To that end the latest build now uses local configuration files to handle the runtime details of the server.

My Head Hurts

No matter how much you might know about a given subject there are times when you cannot see the answer no matter how much you beat your head against the table.

Yesterday was one of those days for me and I lost several hours that I cannot get back. We are working on getting a build of ERPLink out and during some testing I could not get the .net extension part of the product to work. No matter what I tried I could not get them to work, however a set of the extensions build on my local machine worked without issue. Finally I decided to do a side by side comparison of the assemblies that worked vs. the broken ones. Everything looked the same, both having the same .Net version, references, and so on. However, after closer inspection of the Assembly info the one difference was in the assembly title, where the working set had a title and the non working was cleared. It seems that our Finalbuilder build was clearing out the title (we set other attributes like incremented version) and the title is required by SalesLogix .net Extensions. After getting the build fixed to ensure that title remained the system registered and UI elements showed up as expected in SalesLogix.

So make sure that the title attribute is set accordingly or your SalesLogix .Net Extensions will not be located by the runtime correctly.