Stephen Smith's Blog

Musings on Machine Learning…

Posts Tagged ‘swt

Sage 300 ERP Web UIs and MVC

with 2 comments


We spent the last couple of blog posts talking about our new Sage 300 ERP (the product formally known as Sage ERP Accpac) server side programming framework and gave some examples. This week we are going to start turning our attention to the client side. We will be looking at how to structure the code in a UI form to create a well-structured Web Form, using SWT. We’ve refactored the client side SWT (Sage Web Toolkit) framework quite a bit since I wrote this blog post, so we’ll cover how that all works in detail over following blog posts.

Model-View-Controller (MVC) is a common design pattern in software architecture for designing UI programs. People tend to adopt the MVC design pattern, since it enforces some order on the creation of a UI program separating out the various parts into separate classes. This make the program more maintainable, but there are some other goals as well including allowing the UI look to be changed easier and to make the UI form easier to test.

In the diagram above, the dashed lines represent actions that happen directly from events, either from a user interaction with a control on the View or via something changing in the model perhaps due to receiving an SData data source event. Everyone draws this diagram a bit differently and no one really ever likes how data binding fits into this framework. But data binding is just too useful to do away with, so often the model is representing excluding any data binding. In some cases the model doesn’t generate events, but for us it does since changes in one part of the screen will generate changes for another through the model. So in a way this is the Sage 300 MVC design pattern.

We’ve adopted the MVC design pattern for all the new Sage 300 ERP Web Based UIs. We use the same design pattern for the main form as well as for popup forms. Within Sage 300 this gets a bit confusing since we use the name “View” for our business logic. However in this discussion a “View” has nothing to do with business logic and instead represents the actual visual part of the form with all its controls and such. The Model represents the Business Logic and is the part that communicates with the real Sage 300 Business Logic (in other discussions called Views).

There are quite a few other design patterns that are variations on this such as MPP, and several others. Sometimes the differences are subtle, but in our case we find it more convenient to stick with call it MVC model and frame things in regard to this. In a way our application programmers really program in a more MPP model, since all the direct communication between the View and Model is really handled by the SWT framework as part of our data binding support.

One of the key goals of these design patterns is to move as much code as possible away from the actual user interaction part. This is because testing user interaction is hard to unit test and requires specialized tools like Selenium to simulate real users pressing buttons and entering text. Anything that doesn’t directly interact with a user can be unit tested using regular tools like JUnit. Tests using JUnit are easier to include as part of the build process and so catch errors much quicker. So this approach allows much more of our code to be unit tested and facilitates test driven development.

Sage 300 View

Our View part of MVC is the declarative layout. This is the XML file that defines the form layout. This file defines all the controls, their layout and their CSS styles. We also provide a WidgetHelper class as part of SWT to simplify interacting with the controls on the form. The WidgetHelper class isolates the Controller code from having to check for controls being null (say because they were removed due to customization) and other details.

By keeping the View isolated from the other code, it makes it easier to replace the declarative layout either due to customization or due to special needs, like providing an iPhone version of a layout that is optimized for touch and small screen size.

Within our framework we have the ability for the View to create and define “Actions”. These actions can then be bound to the controls in the declarative layout. These actions are then the events of the View. This allows a greater level of customizability, since people can change the action that is called in the declarative layout to their own action to customize the behavior. Then the Action is the event that the controller receives rather than an underlying control event. So rather than the controller being notified of a button click, it’s notified of say a “save” action. This then further separates the details of the View from the controller (i.e. it isn’t tied to an exact specific control event).

Sage 300 Model

The Model manages the behavior and data of the application. It answers questions about its state and responds to requests to change its state. The Model encompasses the business logic, its state and the SData data source (including events). The model doesn’t just send data source events to the controller, rather it translates them into something higher level that is meaningful for the controller of this process.

We provide a couple of base Model classes in SWT that you can extend for your own applications needs. These base classes include support for interacting with the SData data sources and setting up the eventing mechanism.

Sage 300 Controller

The Controller responds to user and model events, informing the other to change as appropriate. Basically the Controller orchestrates the whole process and is usually responsible for creating and initializing everything as well as tearing down and releasing everything.

If things are written correctly then you can almost think of the controller as a workflow manager, which is controlling the workflow as things happen in the Model and the View.


When you press the “Ship All” button on the Order Entry screen, you would think it simply issues an SData service request to the server to call the Order Entry header view to process the request. However there is a bit of error checking first and then afterwards things need to be updated accordingly. Still this is about the simplest example there is, and can serve as a simple example of the MVC process.

Below is a UML process diagram showing, in gory detail, the whole “Ship All” process. The heading show the various components involved and whether they are part of the View, Model or Controller.

Keep in mind that many of the steps here are automatically handled either by GWT or SWT, so most of the application programming is in the ship-all controller to orchestrate the process between the View (User Interface Form) and the Model (wrapping the Order Entry SData feeds).


You might think that a screen only really requires one model or one controller. This is the case for many popup screen and many simple UI forms. However for larger screens like the main Order Entry screen this would lead to an extremely big model and controller. So conceptually we break down the main OE controller into many smaller controllers and similarly even though we have the main Order model, there can be many sub-models under this. Basically we don’t want our classes and objects getting too big. We want them all to stay maintainable and testable. We want to be able to work on one without breaking unrelated functionality elsewhere.

We also don’t want to create too big an MVC framework so that it requires a lot of boiler plate code to create these; we want the creation simple and if a part isn’t required in a certain situation, then it can be safely omitted entirely.


Hopefully this gives an idea of how we are using MVC as the model for our new Sage 300 ERP Web UIs. Perhaps this discussion is a bit theoretical at this point, but hopefully this will set the stage for looking at the mechanic of this in detail over some following posts and starting to look at some code.

Written by smist08

October 29, 2011 at 5:23 pm

Moving VB Screens to the Web

with 6 comments

Now that 6.1A development is ramping up and we are on the journey, I thought I’d blog in a bit more detail on how we are moving the VB screens to the Web. In order to complete the Accpac journey from VB to the Web we have to convert thousands of screens. In order to do this we have developed a number of tools to help in the process. However in order to reach our usability and performance objectives, a certain amount of hand tuning is still required.

After the TPAC conference we had a developer open house, where third party developers could come visit with our developers and tour our facility. We provided a number of presentations including one on using our Porting tools and on our Porting process, including how we want to improve our usability. These tools are now in the SDK which is posted on the development partner Wiki and the various porting guidelines are being posted there as they become finalized.

Porting Tool

Our Porting tool consists of two parts. The first is a Visual Basic plug-in. This plug-in takes a list of VB Projects, loads each one and then iterates through the various collections in the project and writes them out to an XML file. Below is the screen you get when you run the Porting Wizard from VB:

This tool needs valid Accpac Sign-on information since it actually loads and activates each UI. This allows it to load all the language specific strings so these can be ported as well. Basically when run it outputs all the information on the screens (including popups), all their controls, all language strings and their layouts. As a VB plug-in this tool can find and export any design time or runtime information from the VB projects.

The next step is to take this XML file and create a SWT (Sage Web Toolkit) project from it. Our tool for creating SWT projects is SwtUICreator. This tool can either be run command line or from an Eclipse plug-in. To convert UIs it needs to be run from the command line. Usually you would create a batch file to convert all your UIs. For instance the following will create a SWT project for Order Entry based on the OE1100AccpacCtlInfo.xml file generated by the VB Wizard mentioned above.

swtuicreator.cmd –accpacui
       -uiid oe1100
       -uiversion oe61a
       -productid Accpac
       -companyname sage
       -libdir “C:\Pluswdev\SWT\lib”
       -gwtdir “C:\dev\google\gwt-2.2.0”
       -out “C:\dev\PortingTools\out”
       -accpacctlinfo “C:\dev\PortingTools\AccpacCtlInfo\OE1100AccpacCtlInfo.xml”
      -copyright “2011 Sage Inc. All Rights Reserved”

This will then create a SWT project with the screen layout converted, SData resources defined and is ready to run.

The following screen shot is that A/R Customer UI straight from the porting tool. It should look somewhat familiar if you are used to the VB screen. Notice that it has converted the notebook tabs into disclosure panels and has changed the record navigation controls to upper right of the screen. We haven’t finished updating the Cascading Style Sheet (CSS) for this yet, so the look will change (and hopefully improve quite a lot).

There is quite a bit of room for tuning this UI to look much better. Developers now have as a starting point a screen that can navigate, create, update and delete records. All the fields are connected to datasource properties and all the translated strings have been moved from VB language DLLs to XML strings definition files.

After the Porting Tool produces the starting point, people start modifying the code to produce the final product. But what if we improve the porting tool? With-in the porting tool we are providing the facility to re-run it, but not to overwrite any changes made since last time. So we can start porting without worrying that we will have to start over. For instance we are planning to generate automated test scripts from the porting tool, but porting has already begun. So the porting tool will be able to add these automated tests to existing projects later.

Porting Guidelines

The porting guidelines are basically a set of rules of how we want the various design patterns used in the VB screens to be converted to the Web.

The porting tools will try to apply as many of these as possible, but it can only work with what it has available in VB. So the next step is to apply any tweaks to the UI that are necessary in the SWT UI Designer to get the screen to follow the porting guidelines. For most simple screens, no work is necessary. But as screens get more complex then more hand tuning is required.

For the main document entry screen like Order Entry where we expect many users to spend the majority of their time, then there will be custom usability research applied to go beyond the straight porting process.

The developers take the screens output from the Porting Tool, make any necessary tweaks to follow the porting guidelines, then get a usability expert to sign off on the screen design. Then they write any necessary code.


Although the Porting Tool makes a good start, there is often much more to a UI than just basic CRUD operations on simple records. The developers now have to add code to support all the things that go beyond this. They need to hook up all the popup forms correctly. They need to ensure the right things happen on fields that have a lot of logic behind them, like entering a customer number in Order Entry. On simple setup screens there probably isn’t any coding required. But on complicated document entry screens, there is a lot of code going on behind the scenes.


If we just run the screens as produced directly from the porting tool then they are quite slow. This is because the porting tool ports all the VB datasource to SData datasources. But each SData datasource requires calls to the server to configure and get data. We don’t want multiple of these happening. Ideally each screen should use very few datasources (ideally one). If a VB UI requires something, it just asks for it, this is a problem on the web since we want to reduce the number of round trips to the server. Often a UI wants to look up ancillary helpful information to help users, which is good, but we don’t want a separate server request to do this. So we have to remove these extra datasources from the project and add this information to the main SData feed for the project. This is relatively easy since it’s just a matter of editing the XML definition for the main SData feed to define what extra information to include (like G/L Account descriptions).


From the A/R Customers screen above you can see that some of the controls like the record navigation control are still in the early stages. We are starting moving all the VB screens to the Web while still completing the framework so we can get feedback to ensure the SWT framework supports all the things we require. We made sure all the APIs were competed so we won’t have to keep making changes to the UIs as we finish the framework. We left some of the cosmetic affects and some of the usability tweaks to be completed later. This is to get as much feedback as possible as early as possible so we still have plenty of time to make adjustments.


The main benefit of this project is to move to the Web. To reduce TCO by removing the need for any sort of Workstation Setup on a computer that is using Accpac. As we move to 6.1 we are supporting the IE, Firefox, Safari and Chrome browsers. This means you can run Accpac from any device/computer that supports one of these Browsers. This includes regular PCs, Linux PCs, Macs, iPads and Android Tabs. Additionally smaller versions of the screens can run on devices like iPhones and Android phones.

As we move all the screens to the Web we are looking to improve usability and address various customer complaints about the screens. For instance people have complained about optional fields always being in popup forms. Now they are either in disclosure panels or are actually in the grid control as additional columns rather than requiring a popup. People have complained about the notebook tabbed panels we use in VB, that it is too time consuming switching between tabs and that you can’t see all your information at once. Now with disclosure panels you can leave them open or closed as you wish depending on what you want to see (and the state is remembered from use to user). When entering comment/instructions you had to enter several fixed length lines which made copy/paste difficult. Now these are a single field so you can easily cut and paste the data.

Another complaint is that when you open a report, it is model, so it’s hard to open different versions of a report with similar parameters. Now each report opens in a separate Portal panel and you can open as many as you want to compare data much easier.


Now that we are getting into full swing moving all our screens from Accpac to the Web, I hope this gives an idea of the process that we are following. As the various Accounting Modules start to come together we’ll post them on an externally facing Web server so people can see them and provide feedback as we develop them.

Written by smist08

March 26, 2011 at 5:16 pm

How to Layout Forms in Sage ERP Accpac 6

with 7 comments

Laying out data entry forms on the web is quite different than laying out forms in Visual Basic. In Visual Basic you place each control on the form with absolute (X,Y) co-ordinates. This leads to problems when you translate text strings, if they overflow the space then you have to manually re-arrange the controls. Resizing windows is difficult since the program needs to figure out how to move and size controls as the form’s size changes.

If you’ve done data entry in a Browser, you’ve probably seen that all forms seem to adapt to the size of the browser and to the length of strings. If a string gets longer things just move over. Originally the browser didn’t have the luxury of programs running behind the scenes to move and size controls as conditions changed, so HTML was originally designed to display forms correctly in windows of different sizes and resolutions. The Browser even supports features like in IE where you can choose Page – Encoding – Right to Left and it will automatically re-arrange the page for right to left reading. HTML was originally designed to not depend on the presence of fonts and to handle running with any font size that the user has set. Below is a bitmap of our sign on page in right-to-left mode. It shows a bug in our decorator panel for doing the rounded corners on the “Sign In” button. It also shows the danger of putting things in bitmaps since the right hand pane and text is all a bitmap and as a consequence isn’t adjusted.

The Browser accomplishes this by representing pages as a tree called the Document Object Model (DOM) ( In this tree there are nodes for layout and there are nodes that contain data like text or images. Typically each layout node will have multiple children.

Inside the Sage Web Toolkit (SWT), layout nodes are represented by layout panels. This way you place the panel on the form, then any controls you place in the panel become its children. You can place layout controls inside other layout controls to build up more complicated layouts. You never specify (X,Y) co-ordinates when building a SWT form. You simply build it by putting controls inside other controls. This makes customization easier, since it won’t easily overlap controls, so if you add a control to a form, all the other controls will move out of the way to make room.

For instance to layout a simple label with an edit box and a button might be done as follows. First a vertical panel is added to be the root object, then a horizontal panel is placed inside the vertical panel. Inside the horizontal panel is placed a label and a text box. So now the label and text box will always be horizontally aligned. The text box will always be to the right of the label and will move over if the text in the label gets longer. Then the button is added to the vertical panel under the horizontal panel. So this form is built without specifying co-ordinates and the text in the label can be any length and the form will adjust to it. If another control is added to the vertical panel between the horizontal panel and button then the button will move down to make room. This makes translation and maintenance of the form very easy since you don’t need to re-arrange everything when you add something or a string’s length changes.

In tree view you can more clearly see how objects are placed inside other objects, or how the tree that makes up the DOM is built up.

These screens shots are of the Accpac SDK’s UI Designer which runs as an Eclipse plug-in that you use when developing forms. The forms themselves are stored as XML files and you can edit this with any XML or text editor as well as the visual screen designer.

The layout panels that are part of Accpac are:

  1. Caption Panel – like a group box, has a caption and puts a box around its contents.
  2. Decorator Panel – wraps a control in 9 images to allow effects like rounded corners.
  3. Disclosure Panel – a panel that can be opened and closed to hide or show the contents.
  4. Dock Panel – Allows you to place controls in the N, S, E, W corners or center.
  5. Flow Panel – Controls placed here flow one after the other as space permits.
  6. Grid Panel – Constructs a grid of a set size with a control in each grid cell.
  7. Horizontal Panel – Controls placed here are arranged horizontally.
  8. Vertical Panel – Controls placed here are arranged vertically.

This isn’t very many layout panels, but by nesting and combining these you can develop very sophisticated layouts, that will adapt to changing text lengths, font sizes, screen resolutions and other factors. Typically we make heavy use of the Grid, Horizontal and Vertical Panels.

For a more complicated example here is part of A/R Invoice Entry:

And in tree view:

If you’ve worked previously either with Java program user interfaces or with web designers, you will probably be familiar with these concepts. In Java the layouts aren’t part of the form, like they are here. Similarly some web tools abstract the layout controls quite differently. But if you are familiar either with Java UIs or web page design, then these concepts should be easy to understand. If you are coming from a Microsoft development tools background then these concepts will take a bit of getting used to. However once you do get used to them, you won’t really want to go back. Generally you have to think a bit more when initially laying out a form. But once a form is done, maintenance becomes very easy going forwards.

Update 2011/11/05: Have a look at this posting on using CSS to layout forms.

Written by smist08

May 28, 2010 at 10:27 pm

Posted in sage 300

Tagged with , , , ,