Sage 300 How to Return Super View Values from the Process Service


So, you are developing Web Screens for Sage 300 and you want to be able to check a field value or some field values that are returned from the super view. In the Sage 300 Desktop, which is based upon the Visual Basic 6.0 development environment, this is simple and straight-forward.

But, how is this done in the Web Screens where the process is handled by a Worker Role?

This article will explain how this is accomplished by looking at our Sage 300 Web Screen Payment Batch Unit of Work (UOW) service implementation as an example.

Process Flow

But, before we begin, let’s briefly review the Web and Worker Roles as they relate to a Process task.


The Sage 300 Web Architecture uses both web and worker roles to serve the functionality of the web screens. Worker roles are used for most long running processes, usually indicated by a progress-meter, and some reports.


The above diagram illustrates the flow once a process screen submits or starts the process.

Because the super view is handled and processed in the worker role, the business view (which is mapped to an MVC model) is not returned to the web role to access the required values.

Process UOW Service


The Process UOW Service is the class that invokes the Process Repository where the super view’s Process function is invoked and hydrates a model upon return from the function.

var model = repository.Process(seedEntity.Model);

But, this model is in the worker role and the model is not serialized back to the web role.

Process Result’s ResultObject

The ResultObject in the ProcessResult object will contain the value or values that you will want to return to the web role. But, you must place what you want in this object since we do not serialize the model into this object (hindsight says we should have!).

Prior to Sage 300 2019, the setting of the ResultObject was done by the developer by overriding the Process UOW’s OnExecute base class method. The following routine is from our 2018.2 implementation of the Payment Batch UOW class:


While overriding this base class method effectively was able to access and set the ResultObject, it also needlessly had to implement a lot of other code.

Sage 300 2019 eliminated the need to override the OnExecute base class method by providing an override method which provides the ability to set the ResultObject without re-implementing the base class method. The overridden OnExecute was deleted in the Payment Batch UOW class and replaced with an override to the GetResultObject method instead:


Back in the Web Role

At the completion of the process, control is returned to the screen’s JavaScript callback function onProcessComplete. If the ResultObject was set in the Process UOW Service’s override method GetResultObject, it is now available in this callback event:



This article explained how to return a super view value or values from a process service in the Sage 300 Web Screens.

As indicated in the XML Comments for the GetResultObject virtual method, since this is a single object and not an array or dictionary, if multiple values are required, use the pipe symbol as separator to concatenate multiple fields.

The GetResultObject is a virtual method that can be overridden in the Process UOW service class to return a value or values from the worker role to the web role.

The onProcessComplete JavaScript callback function is invoked at the completion of the process and the ProcessResult.ResultObject is available for the developer with any values that may have been set in the worker role. By default, the ResultObject is null.

So, not as simple as the desktop implementation, but still doable with a few extra steps!

As a standard disclaimer, any topic in this article is subject to review and doesn’t represent a commitment as to when it will be available.



Sage 300 2018.2 Web SDK


The Sage 300 Web SDK (SDK) is a collection of wizards, utilities, samples and documentation for developing Web Screens for the Sage 300 Application.

This week we released the Sage 300 2018.2 Web SDK to coincide with the release of the Sage 300 2018.2 Application.

It’s Available!

The SDK is available at


As described in a previous blog and in the README file in the root of the repository, the branches contain the different versions of the SDK.


Contains the current version of the SDK (2018.2).


Contains the in-progress version of the SDK (2019).


Contains the previous versions of the SDK (release-2017, release-2017.1, release-2017.2, release-2018, and release-2018.1)

What’s New


Updated documentation is available.

In the docs\upgrades folder is a document for the upgrade procedures for moving partner source from Sage 300 2018.1 to Sage 300 2018.2. This folder also contains documents for explaining the upgrade steps specific to the Bundle Registration class and the Behaviour JavaScript file.

In the docs\development and docs\wizards folders you will find documents pertaining the wizards and tutorials which have been updated to reflect changes regarding to a …Behaviour JavaScript change.

The docs\presentations folder has been updated and includes a PowerPoint presentation for what’s new in the SDK for 2018.2.

In the docs\utilities folder you will find a document for the new Sage300Utilities utility which is used by the Sage 300 UI Wizard during compilation and an updated document for the MergeISVProject utility which has been refactored and enhanced for JavaScript Minification and Partner Deployment folders.

The samples\customization folder has a new folder called Sample4_AR_Invoice_Entry_Customization containing a new sample and document.

Visual Studio 2017

All wizard manifests have been revised to include Visual Studio 2017 as a target IDE.

This means that when registering the wizards, the registration process will prompt you to select the Visual Studio version for the wizard being registered.

Visual Studio 2013 and Visual Studio 2015 are still supported targets and all three versions can be used for Sage 300 Web Screen development.



The previous samples have been updated with new global references and now reference the common AccpacDotNetVersion.props file in the settings folder.

A new sample has been added to the Web SDK. The AR Invoice Entry Customization Sample illustrates the following:

  • Adding a tab control
  • Enhancing the display via CSS
  • Populating a dropdown list
  • Populating a grid with a method in the Finder!
  • Save, Delete, Update, Grid Refresh


Solution Wizard

Minor changes to the wizard to support the updated components and references in the Sage 300 web screens.

Customization Wizards

Minor changes to the wizard to support the updated components and references in the Sage 300 web screens.

Code Generation Wizard

Minor changes to the wizard to support the updated components and references in the Sage 300 web screens.

See the Defects Corrected section for information on the resolved defects

Sage 300 Utilities Executable

This is a new utility for 2018.2 which facilitates the building of template files used by the wizards. This is only relevant if the Sage 300 UI Wizard package is compiled in Visual Studio.

MergeISVProject Executable

This utility is a post-build utility used by various wizards and the generated partner solution to pre-compile Razor Views and deploy assets to a local Sage 300 installation for developer testing.

It has been refactored and enhanced in 2018.2:

  • Minify JavaScript files
    • Now your JavaScript files can be minified when delivered to a customer
    • As of 2018.1, Sage 300 JavaScript files are minified
  • Create deployment folders
    • Helpful for when the partner needs to create an installation for a customer
  • New informative messages in the Visual Studio Output Window
    • Easily see what has been created in what deployment folder

New settings folder in the Web SDK

The new settings folder in the Web SDK now contains a common AccpacDotNetVersion.props file that is used by the wizard and sample source instead of every solution having its own version.

A generated solution will still have its own version as it should no longer reference the Web SDK’s version.

Defects Corrected

  • An error will be encountered in the Code Generation Wizard if a column in a partner model is named “EntityName” as this is the name of a public constant in the Model class. A warning message will prevent the code generation until the column name is changed.
  • Finder code generated by the Code Generation Wizard regarding data type and expressions has been simplified and corrected. Additionally, the …Behaviour.js file, on successful return from a finder selection, was not performing a Get to get the record from the repository and instead used the object returned from the finder. The record returned from the finder is out-of-process and needs to be fetched by the screen. Changes to partner code are only required if a partner’s business view has logic regarding a new record which was incorrectly being invoked by an existing record that “looked like” a new record. This has been corrected. The following shows the previous routine from the Source Code Sample and the new routine:

Previous Logic

setFinderData: function () {

var data = sourceCodeUI.finderData;


         ko.mapping.fromJS(data, {}, model Data);

sourceCodeUI.finderData = null;





New Logic

setFinderData: function () {

var data = sourceCodeUI.finderData;


sourceCodeUI.finderData = null;

sourceCodeRepository.get(data.SourceLedger, sourceCodeUISuccess.get);


The Upgrade Wizard includes a step that indicates that this change is optional and MUST be done manually in existing partner Behaviour JavaScript files. Because manual changes may have been made to this routine since it was generated by the Code Generation Wizard, we are unable to automatically make this change via the Upgrade Wizard.

  • A business view property name of “Type” was previously generated by the Code Generation Wizard as {EntityName}Type.cs. This creates an error in our Optional Fields JavaScript implementation. This has been resolved by generating the model property as “Type” but prefixing the property with the namespace to avoid ambiguous references with the System.Type.
  • Corrected issue where the Next step validated credentials for Code Types that do not use credentials

Images for Partner Menus

Sage 300 2018.1 introduced vertical menus for navigation. However, the hardcoded images for partner menus were based upon the position of the partner menu (12 hardcoded images for 12 partner menus). It was not ideal, but all the time we had in 2018.1!

Sage 300 2018.2 has removed the hardcoded images and replaced them with default images that maybe overridden by the partner who wishes to supply their own images.

The {module}MenuDetails.xml has been enhanced with two new elements that are supplied via the Sage 300 UI Wizard. The elements are: IconName and MenuBackGroundImage:

<IconName>ValuedPartner/menuIcon.png</IconName>   <MenuBackGoundImage>ValuedPartner/menuBackGroundImage.jpg</MenuBackGoundImage>

Where ValuedPartner is the name the partner supplied in the UI Wizard

  • The IconName element defaults to the “puzzle piece” image
  • The element value is added as $companynamespace$/menuIcon.png
  • The MenuBackGroundImage defaults to the “discussion” image
  • The element value is added as $companynamespace$/menuBackGroundImage.jpg


The MergeISVProject utility is the post-build event utility that deploys your solution to the developer’s local installation of Sage 300 when your solution is in Release Mode. It copies these files (menuIcon.png and MenuBackGroundImage.jpg) from your web project’s Content\Images\Nav folder to the External\Content\Images\Nav\$companynamespace$ folder of your local Sage 300 installation.

Therefore, in your web project’s Content\Images\Nav folder is where your will place your partner images (named menuIcon.png and menuBackGroudImage.jpg) and overwrite the existing files.


The Sage 300 2018.2 SDK is released and ready to be downloaded!

Documentation updates, the ability to run the wizards in Visual Studio 2017, a new AR Invoice Entry Customization sample, minification of JavaScript files, enhanced deployment folders, and the ability to specify partner images for the vertical menus are all in the Web SDK.

We continue to look forward to addressing the needs and expectations of the Sage partner community and ecosystem.

As a standard disclaimer, any topic in this article is subject to review and doesn’t represent a commitment as to when it will be available.


Sage 300 JavaScript Bundle Names


JavaScript Bundling is a technique that can be used to improve request load times. The Sage 300 Web Screens use this technique to bundle the required JavaScript files on a per screen basis.

Known Issue

There is a known issue that bundle names with a dot will generate a 404 error condition in certain situations. While the Sage 300 bundle names do not have a dot in the bundle name, it was recently discovered that the code generated by partners by the Code Generation Wizard might include a dot.

Remember that the bundle name is separate from the JavaScript file name which can contain a dot.

Manual Resolution

For any existing projects, the change is quite simple and must be performed in two locations: The Bundle Registration class where the bundle is registered and in the Index Razor View where the bundle is referenced.

Example 1: BundleRegistration.cs (Before and After)



Example 2: Index.cshtml (Before and After)




This article presented a known issue with a dot being in the name of a JavaScript bundle, the potential existence of this issue in code generated by the Sage 300 Web Code Generation Wizard, and the steps required to resolve this issue.

The Sage 300 Code Generation Wizard has been modified for the 2017.2 release (April 2017) of the Web SDK to prevent this issue from being present in any newly generated code.

As a standard disclaimer, any topic in this article is subject to review and doesn’t represent a commitment as to when it will be available.