Open Sourcing the Web SDK


In this article, I want to share my thoughts on open sourcing the Web SDK for Sage 300 and how, in my opinion, this will benefit the Sage 300 Ecosystem.

Open Source Software

Let’s start by first defining what Open Source Software (OSS) is:

Open-source software (OSS) is computer software with its source code made available with a license in which the copyright holder provides the rights to study, change, and distribute the software to anyone and for any purpose.[1] Open-source software may be developed in a collaborative public manner. Open-source software is the most prominent example of open-source development.[2] (


We are planning to use the Apache License 2.0 for our OSS as it allows for use of the source code for the development of free and open source software as well as proprietary software. The license can be found here:


GitHub Repository

We are planning to use a GitHub repository for the storage, source code management and collaboration of the OSS. Internally, Sage 300c uses GitHub repositories for its web source code.

Ecosystem Benefits

I want to first state that there are two SDK’s for Sage 300:

  • Sage 300 SDK (has been around for years and years)
  • Sage 300 Web SDK

The initial SDK has numerous utilities and tools for generating business views, macros, analyzing data, viewing business view configurations, etc.

The new Web SDK has only a few productivity tools (at the moment) for the generation of the Web UIs in an MVC framework, generating JavaScript code grids and a Resx Generation Utility for converting RC files to Resx files.

Only the new Web SDK will be open sourced.

The Sage 300 ISV and Business Partner community is very active (and vocal too!). This was very evident to me at the recent Business Partner Conference in South Africa where I met with numerous companies and individuals. Their applications, add-ons and plug-ins to the Sage 300 application are very exciting and are part of the community life blood. They have used the existing SDK to build their applications and have enabled compatibility with Sage frameworks and the Sage 300 application.

With the new MVC paradigm, this community will need to re-write their applications for our new Web UI screens. The SDK will provide assistance in getting screens developed quicker by creating Visual Studio Solutions based upon the structures that Sage 300 uses internally. It will also generate code for a screen based upon a business view or a report or a dynamic query, etc. The Code Generation Wizard at this point in time only generates “working code” (it compiles and runs, but only creates the base scaffolding without any “business logic” and only key fields, finder, and action buttons (Save, Delete, Create New)) for a basic setup type screen. The other types of screens (reports, queries, dynamic queries, etc.) generate code, but not a working/runnable screen as these have not been fully addressed in the wizard.

However, all tools can only be so much to everyone in order to consider everyone’s base needs while providing a tool that is easy to use. OSS will allow the community to extend, enhance and tailor the SDK to their specific needs. I believe there to be quite a bit of excitement around this OSS endeavor.

The new Web UI screens have certainly created a lot of excitement for the Sage 300 product and its future. Sage wants this community to be successful in the conversion/re-factoring of their products to the new paradigm. The open sourcing of the SDK will allow those who wish to contribute to the SDK to do so in a way that not only addresses their needs, but potentially the needs of others as well. With this participation, we hope to have a couple of outcomes:

  •  Engagement and Excitement
    • Get ISVs and Partners involved by allowing an ownership stake.
    • Generate excitement not only for themselves, but as an example for others to participate and contribute as well.
    • The community can make the SDK more robust. So, now there will be the opportunity to do so.
  • Faster Pace to Improve/Enhance/Extend the SDK
    • Everyone benefits (Sage too!)
    • The SDK potentially gets uncompleted sections and areas to be completed


There are numerous policies and procedures for OSS in terms of contributions, accessibility, versioning, release cycles, etc. We have not chosen a specific one, but when we do, it will be something that is fairly lightweight, managed by the Sage 300 Framework Group, follows regular release cycles, etc. The goal is to allow the SDK to be enhanced and extended for not only the benefit of the contributor, but for the benefit of all users of the SDK. Therefore, Sage will perform the approval and merging of the contributions.


I am excited about open sourcing the Web SDK. And from the initial feedback, so is the ISV and Business Partner community. The community will benefit from participating and contributing to not only their success, but to the success of the SDK and to other users of the SDK. Of course, not every member in the community will participate in the contribution process, but this is natural and expected when it comes to OSS. The SDK is a tool to be leveraged by the community as they begin their re-writing/re-factoring journey. And, allowing this community to participate in the success of the SDK while satisfying their needs is not only beneficial but also empowering.

We are targeting a June 2016 timeframe for making the SDK OSS. However, as a standard disclaimer, any topic in this article is subject to review and doesn’t represent a commitment as to when this will be available.





Implementing an External Finder


The following question was recently asked:

I am a developer working in my Sage assigned module and I need to invoke a finder from one of the standard Sage modules (i.e. AR, AP, GL, etc.). How do I do this?

This article will illustrate the steps required to invoke a finder from a module other than what is currently being developed.


To illustrate the steps involved in adding a finder from another module, I have run the solution and code generation wizards and have created the TU Payment Codes setup screen. This screen is based upon the AR Payment Codes business view (AR0012) and only contains the key field and finder as generated from the wizards. For this example, I am going to want a finder for a vendor (just because it’s from another module).


Step One

In this step, I need to locate the name for the Vendor Finder. The finder name is a descriptive field used to register the finder with Unity for dependency injection. The name is found in the Sage.CA.SBS.ERP.Sage300.Common.Plugin.Finder.js file. This file is located in the Areas\Core\Scripts folder of the Web project:


This JavaScript file contains sg.finder object with the name definitions:


The value “vendor” as this will be used later in the setFinder method.

Step Two

In this step, I need to add the required references to the AP binaries in the Web project in order for the finder to be invoked.

Finders for all modules have already been registered with Unity.

The AP binaries are located in your Sage 300 Online\Web\bin folder.

The following binaries will be added if they do not exist or have not been previously added:


Step Three

In this step, I will add the controls to the razor view.

This example will not be bound to the data model as it is only being added to demonstrate invoking another finder and not data binding


Step Four

In this step, I will add the required localization variables to the _Localization.cshtml partial view.


Step Five

In this step, I will add the code to the JavaScript Behaviour file for this screen in order to setup and invoke the finder:





Step Six

Mission accomplished!





This article was meant to present the steps required to display a finder from another module not currently being developed. Since the finders are already registered via Unity in the Sage 300 application, the work involved is simply to locate the finder name, ensure the binaries for the finder’s module is added to the Web project and to hookup the plumbing in the JavaScript file.

As we begin to implement the customization framework, we will investigate the notion of externalizing the Unity Registrations into external XML files and therefore the discovery performed in Step One of this article will be simplified.


Sage 300c Transition

Stephen Smith

As most, if not all, are aware, Stephen Smith, Sage 300 Enterprise Architect, retired at the end of February, 2016.

I want to acknowledge Stephen’s leadership, mentoring, friendship, his knowledge of the Sage 300 product, technologies and the accounting industry. These qualities and attributes will be missed by all at Sage. Stephen was at Sage (and Computer Associates) for over 22 years and has certainly played a key role in the success of the Sage 300 (formerly Accpac) product.

Personally, I will miss his abilities and working with him on a daily basis. But, I know that Stephen is looking forward to the next chapter of his life.

Here are a couple of pictures of Stephen and me together on a trip to Bangalore India where we were working closely with the Sonata Group (Hari Hara and KP pictured) on the Sage 300c modernization.



John Thomas (aka JT)

I’ve been with Sage for almost 23 years. I was working on the MAS90 product (now Sage 100 in the US) when Sage bought State of the Art, Inc. I was on the team that started the Sage 500 product and worked on that product from 1995 until 2009 when I came to the Sage 300 product. I have been working with Stephen on various projects over the last seven years, but none more exciting and important than the modernization of the Sage 300 product.

Ever since I started working, there has always been another “John” in the company/group. So, back in 1983, I started going by JT. And, well, it has stuck!

Sage 300c

I’m excited to see where this product is going. With the vast ecosystem around Sage 300, the modernization of Sage 300 is an important aspect and the underlying technologies are exciting and modern (MVC, C#, JavaScript, CSS3, HTML5, etc.)!

Exciting times are ahead for the product, customers, partners, ISVs, etc. as we continue on our modernization journey. On that note, in this blog I hope to continue Stephen’s blueprint of passing on relevant information regarding the product, the technologies used, insights and tips regarding coding implementations, and other topics surrounding Sage 300c.


Thanks to Stephen for all of the hard work and dedication to the product over these years. I’ll be thinking of you while knee deep in a problem while you’re taking pictures of wildlife from the relative peace and quiet of your life on the Sunset Coast! J

Be sure to follow the Sage 300 Development Partner Forum in Sage City as this forum is monitored by DPP Support and myself.