Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘jquery

Error Reporting in Sage 300 ERP

with 18 comments


A very important aspect of all applications is how they handle errors and how they inform the end user about these errors. When everything is entered properly and people take what is called the “happy path” through the program then there is no issue. But end users will stray from the “happy path” and other circumstances can conspire to cause the need for informing the user of unusual circumstances.

In our previous blog postings on using the .Net API we have been deferring our discussion of error reporting, but now we are going to tackle it and add error reporting to the ASP.Net MVC sample program we started last week. In doing so we will introduce some new concepts including starting to use JQuery and Microsoft’s Unobtrusive Ajax.


Generally when we refer to errors in this articles we will also mean warnings and informational messages. Often you hit save on a form and if something is wrong then you get a message box telling you what was wrong (and maybe even what to do about it). However this is bit of an oversimplification. Sage 300 ERP is a three tier client server application. Many of the errors originate in the business logic or the database server. These may be running as Windows services and have no way of doing any user interaction. They can’t simply popup a message box. The error message must be transmitted to where ever the UI is running (say in a web browser somewhere on the Internet) and displayed there in a nice form that fits in with the general design of the form.

Further there may be more than one error. It is certainly annoying to have error messages popup one at a time to be answered and it is also very annoying to Save have one error message appear and correct the thing wrong, hit save again and then have a further thing wrong and so on.

To solve these problems we collect errors, warnings and messages up into a collection which is maintained during processing and forwarded up to the higher levels when processing is complete. We see this in the .Net API with the Errors collection on the Session object. As processing proceeds any business logic component can add messages to this collection. This collection can then be processed by the UI and cleared after it has reported the errors.

All the actual error messages referenced from the business logic are stored in Windows resource files and one of these is provided for each language. So the API used by the Business Logic will access the correct language resource file for the language of the Sage 300 user associated with the session object.

Inside the collection, each error has a priority such as Severe Error, Error, Security, Warning or Message. This way we can decide further how to display the error. Perhaps have the error dialog title bar red for errors, blue for warnings and green for messages.


Inside our .Net API we will return a return code for simple things that should be handled by the program. For instance if we go to read a record, we return false if it doesn’t exist, true if it does. But for more abnormal things we will throw an exception. You should always catch these exceptions, since even if you are debugging a program, these messages can be very helpful.

Just because an exception is thrown, doesn’t mean there is an error on the error stack. The exception might be because of some other exception, say from the .Net runtime. Because of this you will see in our exception handler, that if there is no error from Sage 300 then we display the error that is part of the exception (perhaps from .Net).

Sample Program

To add error reporting to our ASP.Net MVC sample programming we are going to start introducing how to program richer functionality in the browser. As we left off you just hit submit, the processing was done and the page was refreshed completely. This is rather old school web programming and a bit better user interaction is expected these days. Now I’ve updated the sample ARInvEntry sample (located here) to do an Ajax request rather than a page submit request. As a result the page isn’t completely redrawn and we can do a bit more processing. In this case we will use JQuery to put up a dialog box with any messages, warnings or errors that were encountered. Normally when you save an Invoice there is no success message displayed, but here we will put up a success message as well.

First off now that we are programming in JavaScript in the Browser, this is an interpreted environment which means there is no compiler to catch dumb programming mistakes and typos. One thing is to watch the syntax highlighting in the editor and use intelli-sense to avoid some typos. The other things is that we are passing data structures from C# on the server to JavaScript on the client. Which means there is no validation that C# and JavaScript have the same understanding of the object. Further JavaScript tends to silently ignore errors and keep on going, so you can be rather mystified when things don’t work. Some good tools to look for errors are Firebug and Fiddler. Trying different browsers can help also.

First I changed the page submit call to an Ajax call using Microsoft’s unobtrusive JavaScript library.

        @using (Ajax.BeginForm("CreateInvoice", "Home", null,
             new AjaxOptions { OnSuccess = "showResult" }))

Now the request will be made with Ajax and any returned data will be passed to the showResult JavaScript function. Pretty easy change, but there is one major missing piece. We must include the JavaScript library for this. The JavaScript file for any library needs to be added to the Scripts section of the project and then an entry needs to be added to BundleConfig.cs. Here we added jquery.unobtrsive-ajax.js to the jquery bundle.

     bundles.Add(new ScriptBundle("~/bundles/jquery").Include(

We also added the jquery-ui-{version}.js. The framework will figure out which version to fill in from the js files in the scripts folder. This way we can update these without having to change any C# code. If we didn’t add the unobtrusive library then nothing would happen and we wouldn’t get any errors because nothing would be hooked up to fail. When having trouble with JavaScript always check you have the correct libraries added. Similarly we have added the css and images for JQuery to the project. You could put these in script tags in your HTML, but the bundles help with eventual deployment as we’ll see in a later article. These bundles are referenced in the cshtml files to actually include them in the generated HTML and one gotcha is that sometimes the order of including them matters due to namespace conflicts, for instance the bootstrap bundle must be placed before the jQuery bundle or something in JQuery won’t work due to some naming conflicts.

Now we add the showResult function and what it calls.

function showResult(data)
    $.fn.showMessageDialog(data.Warnings, data.Errors, data.Messages);
(function ($) {
    $.fn.showMessageDialog = function (warnings, errors, messages) {

        if ((warnings != null && warnings.length > 0) ||
            (errors != null && errors.length > 0) ||
            (messages != null && messages.length > 0)) {

            var text = "";
            var i;
            if (messages != null && messages.length > 0) {
                for (i = 0; i < messages.length; i++) {
                    text = text + "<li>" + messages[i] + "</li>";
            text = "";
            if (errors != null && errors.length > 0) {
                for (i = 0; i < errors.length; i++) {
                    text = text + "<li>" + errors[i] + "</li>";
            if (warnings != null && warnings.length > 0) {
                for (i = 0; i < warnings.length; i++) {
                    text = text + "<li>" + warnings[i] + "</li>";

                title: "Information",
                modal: true,
                buttons: {
                    Ok: function () {


Besides setting up the HTML to display, this code mostly relies on the JQuery dialog function to display a nice message/error/warning dialog type box in the Browser using an iFrame.

This routine requires a bit of supporting HTML which we put in _Layout.cshtml file so it can be shared.

    <div id="informationDialog" style="display: none;">
        <ul id="infoSuccess" style="display: none;"></ul>
        <div id="infoWarningsBlock" style="display: none;">
            <div id="infoWarningsHeader">
            <ul id="infoWarnings"></ul>

Notice it has display set to none so it is hidden on the main page.

From the C# code on the server here is the error handler:

        // Simple generic error handler.
        private void MyErrorHandler(Exception e)
            if (session.Errors == null)
                if (session.Errors.Count == 0)

        private void copyErrors()
            int iIndex;

            for (iIndex = 0; iIndex < session.Errors.Count; iIndex++)
                switch (session.Errors[iIndex].Priority)
                    case ErrorPriority.Error:
                    case ErrorPriority.SevereError:
                    case ErrorPriority.Security:
                    case ErrorPriority.Warning:
                    case ErrorPriority.Message:


It separates the errors, warnings and messages. Also the copyErrors method was separated out so it can be called in the case of success, in case there are any warnings or other messages that should be communicated.

The controller now just passes the variables from the model back to the web browser.

        public JsonResult CreateInvoice(Models.CreateInvoice crInvObj)
            ResultInfo results = new ResultInfo();

            results.Messages = crInvObj.Messages;
            results.Errors = crInvObj.Errors;
            results.Warnings = crInvObj.Warnings;


            return Json(results);      

All the work here is done by the Json method which translates all the C# objects into Json objects. It even translates the C# list collections into JavaScript arrays of strings. So for the most part this handles the communication back to the Browser and the JavaScript world.



We discussed the Sage 300 ERP error reporting architecture and saw how to integrate that into our ASP.Net MVC sample program. Since this was our first use of Ajax and JQuery, we had a bit of extra work to do to set all that up to operate. Still we didn’t have to write much JavaScript and the framework handled all the ugly details of Ajax communications and translating data between what the server understands and what the browser understands.

Update 2015/01/29: Sometimes View calls will return a non-zero return code for special informational purposes. These will cause the API to throw an exception. To handle these you need to catch the exception, check the View’s LastReturnCode property to see what it is and then continue processing. Perhaps a bit of a pain to do this, but it is the exception rather than the rule.

Competing Web Development Systems

with 5 comments


The pace of development of Web based applications has been frenetic. The pace of development of tools to program the Web is also frenetic. There are new programming languages, libraries, servers and systems announced daily. Whatever happened to the good old days where you got a new version of Visual Studio and an updated C compiler every three years or so? In this blog posting, I want to look at the problems that people are trying to solve and the innovations they are trying to introduce to address them.

One nice thing about working at Sage is that we have so many products; someone will be using one of the systems mentioned in this article. For instance SageOne and Sage Billing Boss are written in Ruby on Rails. Sage 300 ERP and SageCRM use GWT extensively. Other products use JQuery and Node.JS. Several of the mobile offerings were produced with JQuery Mobile. So within Sage we have some opportunity to compare these on real non-trivial projects.

The Perfect Programming System

The real goal of all this is delivering real value to customers (end users). All other goals are in support of this. Nearly everyone is adopting some sort of Agile development process centered around delivering value (or even delights) to their customers. Once you are delivering customer value, then the next question is always: how to do that faster? Everyone are looking for a software development toolset that delivers customer delights and improves productivity.

That’s the high level goal, but what are the more detailed goals:

  • Quick to enter changes, ideally just edit some code, save it and refresh the browser to see the results.
  • Easy to test. Meaning there are good ways to write unit tests that can run quickly every build. That the system promotes test driven development.
  • Easy to maintain. The system produces readable code that is easy for another programmer to figure out and change.
  • Little impedance between problem domain and language. When thinking about what you want to do, it isn’t a huge change of perspective to write the code; somehow the code reflects what you want to do naturally.
  • Easy to learn. You don’t need to know 3 programming languages, 5 scripting languages and 27 runtime libraries all of which interact in a complicated way to get up and running.
  • Large ecosystem – lots of tools and libraries to save you work.
  • Produces correct code. You don’t have to worry about unexpected syntax errors or other strange unexpected runtime errors that testing might have missed. By the same token you don’t have to spend a lot of time testing for and removing these sorts of things.
  • Easy to install and setup. It’s easy for programmers to setup the development environment and get up and running quickly.
  • Easy to deploy. It’s easy to transfer changes from the development environment to a live environment.
  • Ability to integrate with (consume) modules that are part of legacy systems.
  • The generated code is very small, fast and scalable.
  • Great development tools for debugging, code analysis, etc.

In life, there are many tradeoffs to make. The same in programming. You might want three things, but you can only have two. Which do you pick? Which do other people pick? Usually with a large set of goals, some practical tradeoffs need to be made. Usually there will be a lot of disagreement in a group of people as to which goals are the most important and which ones can be lived without. Often the group will break up into different camps each with the conviction they have made the correct choice and theirs is the correct way to do things. So too with programming and hence all the different camps of web developers. Here we’ll look at a number of the camps and the tradeoffs they are making. Obviously I have my own opinions and preferences and the members of these various camps will probably disagree with my assessments.

For instance would you want to sacrifice several of the items for scalability? Everyone would like to be as popular as Facebook, but if you are a new web site, then perhaps it’s better to go live quicker to get feedback rather than spend the extra time engineering scalability. Often it’s more important to get feedback quicker so you can adapt your plans rather than over-engineer and be slower to market and slower to react. This fits in with the “fail fast” methodology of innovation where you are trying lots of things to see what works, you want them live as fast as possible to see what is good. Then you can take the good ideas and engineer them for the projected growth once you know what that will be.

Client Side Programming

As a Web developer you are targeting being able to run inside of Browsers. Here you can rely on HTML, CSS and JavaScript. Nothing else is common and nothing else will run on a large enough selection of Browsers and devices. If you don’t care about rich interaction or looks, you can just write using HTML and server side code, but this is Web 1.0 and probably won’t be very popular with your customers. There are good layout tools, or just text editors for writing HTML whether it’s static or generated by a server program. For CSS the tools aren’t as good, but there is help from libraries like CSSPie or Sass. Then for JavaScript, you can either write directly in JavaScript or use something that compiles another language into JavaScript; the merits of either approach are fiercely debated. Of course when writing in JavaScript you can use libraries like JQuery to hide the complexities and provide a lot of missing support.

Server Side Programming

You control the server and you control what runs on it, so you can theoretically use any programming language that can receive HTTP requests via a network socket. But usually you want something that integrates with a Web Server like IIS or Apache. There are good server frameworks to create the server programs in Java, .Net, C or any of a thousand scripting languages. Nearly every programming language has been adapted to write Web server applications with, even COBOL.

Client and Server Together

Although it is possible to program the Browser and the Web Server completely separately and independently. Perhaps only communicating through a well defined RESTful Web Services protocol. Usually we would like to leverage the skills of one to help with the other. We would also like a unified debugging and problem solving system. We would also like to reduce the number of specialized tools that people need to learn. Wouldn’t it be nice if the separation between client and server is largely transparent to the programmer? How well the client and server environments are harmonized is often a critical deciding factor in decision making.

Some Leading Development Platforms/Libraries

JQuery is a leading framework for developing using raw JavaScript. The innovation with JQuery was separating the JavaScript code out from the HTML that it controls. It uses a method to interact with the HTML very similar to CSS. The Query part of JQuery refers to how you build queries to specify which DOM objects to operate on, rather than having the JavaScript attached to each DOM object directly. JQuery has a powerful extension framework allowing many powerful libraries to be added to JQuery like SproutCore. A key goal of JQuery is to separate the JavaScript code from the HTML and then to insulate the JavaScript programmer from many of the Browser dependent parts of JavaScript like making AJAX RPC calls. The difficult part of JQuery is how it interacts with the DOM, although very powerful is quite complex and tricky. JQuery by itself is a client framework, but it integrates to pretty much any server framework. In fact Microsoft has given up on running .Net in the Browser and is now promoting using JavaScript with JQuery communicating back to .Net running on the server.

Node.js is a JavaScript server framework. For people who love JavaScript and JQuery, it then kills them to have to program the server in something else like Java, .Net, PHP or Ruby. They love JavaScript and would like to do all their work in JavaScript. With the Chrome Browser, Google introduced the incredibly powerful V8 JavaScript engine. Node.JS then uses the Chrome V8 engine to run JavaScript on the server. Additionally the Node.js developers consider using a thread to execute each web request as too much overhead (nearly every other server framework uses threads). So they also brought all the asynchronous ideas associated with JavaScript from the Browser to the Server. So anything that is executed outside of Node.js is done purely asynchronously, such as calls to the database, operating system or such. This is very powerful and very low overhead for highly scalable systems. However it is fairly difficult to program with (according to me, not Node.js fans). To help tame the asynchronous problem, Bruno Jouhier, an Architect at Sage developed streamline.js which he talked about here.

Ruby on Rails is a server framework for developing the server side of things in the Ruby scripting language. In a way Ruby on Rails is a contradiction, since it is a framework that was developed to eliminate frameworks. Many people feel that frameworks and libraries just get in the way. Why do you need all these middleware components to connect things up? Why can’t the UI just access things in the database directly without a lot of messing around with intervening layers? Ruby on Rails implements web screens using a strict MVC model, where Ruby helps generate the Model part directly on SQL database tables, so the Model part is your business logic. After all why would you need anything else? Ruby on Rails is a server framework similar to ASP or JSP, but people want AJAX web applications, so you write any richer or interactive parts of your web pages in JavaScript with JQuery that then talks back to the Ruby components on the server.

Google Web Toolkit (GWT) is a framework where you program in Java which is then compiled to JavaScript for the Browser half of the application. The server side is programmed in Java which runs as a Java Servlet under a Java container like Tomcat or Jetty. The nice thing is that you do all your programming in Java so you are only using one language. You also get to use all the thousands of tools and libraries that have been created for Java over the years. Since it’s a compiled language, you will not get runtime errors due to typo’s in your code like you do for scripting languages (some just ignore the errors which is even more confusing). On the downside you have to compile your code, so you can’t run it as quickly as you can with a scripting language. I’m not really sure which is faster, since when I use scripting languages I’m always fixing undefined variables and syntax errors, so although I can run quickly, I have to run many times to get things working. GWT also lets you use the Java symbolic debugger to debug your code which is very helpful.

Dart is a new project from Google that attempts to combine the best of the worlds of JavaScript/JQuery/Node.JS with Java/GWT. The idea is that Dart is a structured object oriented language (like Java) but you can choose whether variables need to be defined and adds a number of dynamic features usually only seen in scripting languages. Then the idea is that Dart can be run in some Browsers natively, allowing scripting type rapid development and for Browsers that don’t support it (like probably IE), you compile Dart to JavaScript. Dart isn’t ready for primetime yet, and it isn’t clear whether it will succeed, but it does show that the pace of development of these tools and systems is continuing at a rapid pace. Some theorize that the real intent of Dart is to replace Java as the tool used to develop Android applications, mainly due to all the frivolous lawsuits from Oracle.

Which to Choose?

The choice comes down to which items are most important to you in the list of what makes a perfect programming system. Which one gives you the best vibes, or feels right for what you want to do. Often this is heavily influenced by your current experience; what technologies are you most fluent in already; which new ones will you need to learn. This usually goes beyond a single person and you have to consider the expertise and experience of your development team.

A big influencer is whether you are writing a new system completely from scratch or you have to extend or integrate to a large existing system. If you need to extend or integrate then often your choices are limited to things that can easily do that. If you are writing a new system then you are much free’er to choose. For the new system, often it depends how much you want to rapidly prototype, versus how much the requirements are set and you want to implement quickly.

You also have to consider the longevity of the tools you are choosing. Perhaps you don’t care since you just want to rapidly prototype and start from scratch every few months. Or perhaps you know the system you are developing will need to be maintained and extended for the next ten or twenty years. Then you have to look carefully at the health of the open source community around the tool, or the commitment of the company behind the product to keep developing it.


There are many more systems in use. As I mentioned, nearly every programming language ever invented has a Web Development framework. People fuss quite a bit about which one to use, but I think once you bite the bullet and dive in, you can’t go that wrong with any of these. Also most of these can interact and interoperate at different levels, so usually you can build a composite system using many different tools (you just have to learn them all). Anyway the Web continues to be a platform that promotes innovation and fosters continuing learning.