Sage 300 2018.1 Web SDK

Introduction

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.1 Web SDK to coincide with the release of the Sage 300 2018.1 Application.

It’s Available!

The SDK is available at https://github.com/SageNADev/Sage300-SDK.

Branches

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.

master

Contains the current version of the SDK (2018.1).

develop

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

release-…

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

What’s New

Documentation

Updated documentation is available.

In the docs\development folder you will find documents which have updated screenshots in the setup and tutorial documents to reflect the new flow of the Code Generation Wizard.

In the docs\patterns folder you will find a new document for Coding Patterns. At this time, only one pattern is documented, but will soon contain more patterns implemented in the Sage 300 Web Screens.

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

In the docs\templates folder you will find the updated Word Template used by our PDX Content group.

In the docs\upgrades folder is a document for the upgrade procedures for moving partner source from Sage 300 2018 to Sage 300 2018.1. This folder also contains a document for manually upgrading a customization solution’s controller to inherit from our MultitenantControllerBase class instead of Microsoft’s Controller class.

In the docs\wizards folder you will find documents which have updated screenshots to reflect the new flow of the Code Generation Wizard and the new HeaderDetail Code Type.

Visual Studio Code Maps

Visual Studio Code Maps have been provided for specific entities, controllers, utilities and helper classes.

In the maps folder you will find various code maps which can be opened in Visual Studio to see a graph of relationships in specific classes.

Blog11CodeMap

Samples

The previous samples have been updated with new references and minor corrections.

The Receipt sample has been re-factored to use the new base class and implementation for HeaderDetail code type.

Solution Wizard

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

Customization Wizards

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

The Customization Wizard Plugin was modified to generate a controller inheriting from Sage’s MultitenantControllerBase instead of Controller. See the document in the docs\upgrades folder for manual steps.

Code Generation Wizard

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

The new HeaderDetail code type generates enough code to have a functioning header-detail screen that compiles and can be run. However, in this initial offering, a grid (main component of a header-detail screen) is not generated by the wizard. This is being planned for the next release of the SDK!

Blog11Step1

The flow of the wizard has been enhanced to support the new HeaderDetail code type with multiple entities (Accpac Business Views). Information that is relevant to all entities has been moved to the first step.

 

Blog11Step2A tree control has been added to the second step for adding, editing and deleting entities. The tree control displays and allows for hierarchical entities as required by the HeaderDetail code type.

 

Blog11Step2aThe Entity tab of the second step allows selection of the entity and editing of the properties.

Blog11Step2bThe Options tab of the second step allows selection of assorted options.

 

Blog11Step2cThe Properties tab of the second step allows for manual entry of properties for the DynamicQuery and Report code types. It now allows for the modification of property names before the code is generated for the other code types as well.

 

Blog11Step2dThe Compositions tab of the second step is only relevant for the HeaderDetail code type and allows for the compositions of the entity to be included or not. The wizard will generate the composition logic in the CreateBusinessEntities routine of the Repository class.

 

Blog11Step3

The third step has been refactored to display an XML representation of what will be generated by the wizard.

WebApi

A new GL Segments endpoint has been added.

Defects Corrected

The module name for a development partner’s menu item was not being localized when displayed in the window manager. This has been resolved.

An error might be encountered in the Clear Statistics sample. This has been resolved.

Vertical Menus

There are no code or menu changes required for the new Vertical Menus of the Sage 300 web screens. A default icon (colored puzzle image) will be assigned to a partner’s menu item.

In 2018.2, we are modifying this implementation to allow the partner to specify an icon they want to associate with their menu in the menu XML. The partner will then be required to deliver this icon along with the other module assemblies.

Blog11VerticalMenus

Summary

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

Documentation Updates, new Visual Studio Code Maps, a new Code Generation Wizard flow along with a new HeaderDetail Code Type, updated Samples, and a new WebApi endpoint are all in the 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.

 

Advertisements

Sage 300 and Visual Studio’s Code Maps

Introduction

The Sage 300 web screens are comprised of 113+ Visual Studio projects. This represents a large and complex code base. Simply opening a project and viewing the components and references to understand the relationships and dependencies can be a daunting task.

The relationships and dependencies between not only projects but also classes and methods are sometimes best understood when presented visually.

Microsoft’s Code Maps, which is a core feature of Visual Studio 2013 Ultimate and Visual Studio 2015/2017 Enterprise Editions, is a fantastic tool to assist with the visualization of these relationships and dependencies.

ReSharper, which all internal Sage 300 developers use, also offers a graphical code mapping feature. However, the features, functionality and even the debugging integration with Code Maps make Visual Studio tool, in my opinion, the best tool to use.

This post will introduce the Visual Studio Code Maps and present how developers can leverage this tool to graphically display relationships and dependencies for a project or projects, a class or a method. Code Maps can assist not only new developers, who do not know anything about the code base, but also experienced developers wanting to better understand relationships and dependencies.

Code Maps

Code Maps is an architectural tool in Visual Studio that generates a graph, like a dependency graph, to assist the developer with understanding and viewing the relationships and dependencies of a large code base in a visually appealing, dynamic and interactive graphical display.

A code map visualizes code and project relationships and can even be viewed in a tab next to the code editor inside of Visual Studio. This allows the developer to see where they are in the map and therefore in the hierarchy of the code while in the code itself.

A code map may be saved within the solution or even exported as an image to email or an XPS viewer. While inside Visual Studio, the code map is interactive:

  • Add or remove or hide components in map
  • Add or remove filters which control relationships (Class, Methods, Call, References, Calls, Returns, etc.)
  • Add comments to a component or relationship
  • Double-click component to be taken to that place in the code
  • etc.

While all versions of Visual Studio can access (read-only) a Code Map, only the following versions of Visual Studio can create a Code Map:

Visual Studio 2013 Ultimate Edition and Visual Studio 2015/2017 Enterprise Edition

Example

In this example, I want to better understand the A/R Payment Code’s business repository located in the A/R Business Repository project of the A/R solution. I want a visual graph which Visual Studio’s Code Maps feature can generate.

Let’s start by creating a map for the Payment Code Repository. Open the PaymentCodeRepository class and Right-Click on the name in the code window and select the Show on Code Map option:

Blog10Fig1

Figure 1: Generate code map for class

The code map for the class will be generated with a green chevron indicating where in the code the code window is:

Blog10Fig2

Figure 2: Generated code map for class

Hover over the code map and select the dropdown chevron to retrieve the components in this class:

Blog10Fig3

Figure 3: Retrieve components of class

The components (methods, properties, etc.) of the class are retrieved and added to the code map:

Blog10Fig4

Figure 4: Components in class

We can visually see all the methods and properties in the class. I’m interested in the GetAccessRights method, the methods that this routine invokes, and where they are located. Rick-Click on the GetAccessRights component in the code map and select the Show Methods This Calls option:

Blog10Fig5

Figure 5: Show methods

Note that the code map window is side by side with the code window.

Upon showing the methods that are called from this routine, you will notice that they are coming from an external assembly or assemblies:

Blog10Fig6

Figure 6: Method calls are in external assembly(s)

Hover over the External component and select the dropdown chevron to retrieve the components in this class:

Blog10Fig7

Figure 7: Retrieve and show assembly(s)

The external assembly is now shown:

Blog10Fig8

Figure 8: External methods are in the Common BusinessRepository assembly

Hover over the external assembly and select the dropdown chevron to show the methods:

Blog10Fig9

Figure 9: Retrieve and show methods

The methods are in a folder within the assembly (namespace):

Blog10Fig10

Figure 10: External methods are in the BusinessRepositoryBase namespace

Hover over the external assembly and select the dropdown chevron to show the methods:

Blog10Fig11

Figure 11: Retrieve and show methods

We are getting closer! We can see now that the methods are in two different classes:

Blog10Fig12

Figure 12: External methods are in the BaseRepository and FlatRepository classes

Hover over the two classes and select the dropdown chevrons to show the methods which results in our final display:

Blog10Fig13

Figure 13: PaymentCodeRepository showing external reference and methods

We wanted to see where the GetAccessRights and SecurityCheck methods were located and Code Maps provided a visual graph in just a few steps.

Blog10Fig14

Figure 14: GetAccessRights routine in the PaymentCodeRepository

Code Map Toolbar

Blog10Fig15

Figure 15: Code Map Toolbar

The Code Map Toolbar provides numerous options that can be undertaken on the code map:

  • Undo
    • Undo recent changes to the code map
  • Show Related
    • Context items for acting on the selected component, such as Find All References, Show Methods This Calls, etc.
  • Layout
    • Context items for how the code map is displayed, such as Top to Bottom, etc.
  • Find
    • Find feature
  • Call Stack
    • Automatically show debugger call stack on Code Map
  • Share
    • Collaboration options, such as Copy Image, Email as Image or Portable XPS (to be viewed in XPS viewer), Save as Portable XPS, Save as DGML, Move DGML (once saved) into a folder/project within the solution, etc.
  • Comment
    • Add comment to the code map
  • Zoom
    • Zoom to fit the code map window or enter a zoom percentage (mouse wheel also controls zooming in and out)
  • Legend
    • Toggle to display window of icons and icon descriptions of icons
  • Filters
    • Toggle to display window of filters available for selection and de-selection
  • Skip Build
    • Toggle to determine if code map should build solution before generation of code map
  • Include Parents
    • Toggle to determine if code map should include parents of components to be generated

Summary

The Sage 300 web screens represent a large and complex code base where understanding and viewing the components, relationships and references can be a daunting task.

Microsoft’s Code Maps, which is a core feature of Visual Studio 2013 Ultimate and Visual Studio 2015/2017 Enterprise Editions, is a tool that provides the ability to visualize relationships and dependencies in real time from within the Visual Studio IDE.

To create a Code Map you must be on either Visual Studio 2013 Ultimate Edition or Visual Studio 2015/2017 Enterprise Edition.

Developers can leverage this tool to graphically display relationships and dependencies for a project or projects, a class or method. A simple example was used to provide a graph of a class and its externally referenced method calls.

The graphs can be used at an elevated level to show project relationships or a detailed level to show code flow and dependencies. This visualization is a proven way to understand complex concepts, and understand and navigate complex 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.

 

 

Sage 300 Optional Resource Files

Introduction

The Sage 300 Web Screens use Resource Files (Resx files) to localize strings, text, captions, messages, etc. that are presented in the screens. Behind the scene, these Resx files are supported by Microsoft’s Resource Manager class and framework.

So, what happens if a Resx file for a language is not provided or blank values exist in a Resx file?

Supported Languages

Before we begin, let’s identify the languages that are currently supported in the Sage 300 Web Screens:

  • English (en-US) (i.e. MenuResx.resx)
  • Chinese Simplified (zh-Hans) (i.e. MenuResx.zh-Hans.resx)
  • Chinese Traditional (zh-Hant) (i.e. MenuResx.zh-Hant.resx)
  • Spanish (es) (i.e. MenuResx.es.resx)
  • French (fr-CA) (i.e. MenuResx.fr-CA.resx)

English is considered the default language and all Resx files without a locale extension are to be considered the English Resx files.

The Sage 300 PDX Group takes the completed English Resx files and translates the values into the other supported non-English languages.

How Does It Work?

The Sage 300 Web Screen implementation is to place the Resx files for the same screen into the same folder.

This is a requirement for the Resource Manager magic!

These resource files are referenced with a standard Object.Property notation and do not specify a locale. The magic is performed by the Resource Manager to understand the current locale and retrieve the string (property) from the correct Resx file based upon the locale.

This is very convenient from a code perspective in that the application code does not have to determine which Resx file to access.

Non-existent Resx File for a Locale

If a specified locale’s Resx file does not exist, the English Resx file is used instead. Since the code does not specify a locale, this default behavior by the Resource Manager is perfect and the resulting English resource allows the application to function without error.

Blank Values in a Resx File and Resulting Issue

A blank value is a value. It is just blank. But, this can cause issues in the application when a value is retrieved from any Resx file, not just non-English Resx files, and then the value is displayed on the screen. Where is my caption? Where is my menu item? Where is my message?

As mentioned in the previous section, a missing non-English Resx file will default to the English Resx file so there is no loss in functionality or behavior.

But, it was recently observed by a partner, that the Solution Wizard and Code Generation Wizard will generate the Menu Resx files and any screen Resx files for all supported languages. But, the values in these non-English Resx files will contain keys, but blank values, which is perfect for Sage internal developers, but in many cases not ideal for external developers.

Example 1: English Resx File

blob10example1

Example 2: French Resx File

blog10example2

External developers must also fill out these files to avoid having a Sage 300 supported locale selected by the customer, but now the screens and menus will display blank or key values (in the case of the menu system, it has explicit logic that states “if the localized menu value is blank, display the keys instead”). This behavior then places the burden on the partner to delete these non-English Resx files IF the partner does not intend to support the translation of a particular language.

Resolution to Blank Values in a Non-English Resx File

Blank values in an English Resx file must be resolved to contain a value. This is plain and simple in order to avoid any issues in the display.

Blank values in a non-English Resx file can be resolved in one of two ways:

  • If the partner is intending to support their screen in a Sage 300 supported locale, the locale’s Resx file must be translated with proper values
  • If the partner is not intending to support their screen in a Sage 300 supported locale, the locale’s non-English Resx file can simply be deleted from the project while in the Visual Studio IDE.

But, regarding the deletion of the non-English Resx file, what if it was never created in the first place? Yes, this is a better option!

Sage 300 Solution Wizard’s New Feature

If the partner is able to determine when creating the solution and projects that a Sage 300 supported language will not be supported by their screens (i.e. a partner in Asia may not want to provide Spanish and/or French for their screen), the Wizards should not create the non-English Resx files in the first place.

Therefore, an enhancement has been made to the 2017.2 version of the Sage 300 UI Wizards (Solution Wizard and Code Generation Wizard) to prompt the developer for the language Resx files to be included/created in the projects of the solution.

blog10newstep

This new step has been added to the Solution Wizard in order to allow the developer to decide which language Resx files to include/create.

English is defaulted as it is a requirement.

Sage internal developers will select all of the languages.

The Code Generation Wizard will not prompt again for this, but instead will look at the Menu Resx files that exist and when creating Resx files for the specific screen, will create the language files based upon this discovery.

If a new solution is being generated starting with release 2017.2, this ability to limit or restrict what is created is a welcome new feature.

For partners with solutions and projects created prior to release 2017.2, the Code Generation Wizard will discover the Menu Resx files and create the non-English Resx files accordingly. Therefore, if a particular locale’s Resx files exist and they are not required to be translated, deleting the MenuResx.{locale}.resx file(s) from the Resources project will need to be performed.

Summary

This article presented how the Sage 300 Web Screens implement the Microsoft Resource Manager, what happens when a locale’s Resx file is missing, what happens when a locale’s Resx file has blank values and the steps required to avoid “blank value” issues.

The Sage 300 Solution and Code Generation Wizards have been enhanced for the 2017.2 release (April 2017) to present a new step which allows for the selection of which non-English Resx files are to be included/generated. This new step is a proactive approach to not creating locale Resx files that are not used by the partner and therefore preventing display issues if a customer selects a Sage 300 supported language that is not supported by a partner screen.

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

Introduction

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)

blog8example1before

Blog8Example1After.png

Example 2: Index.cshtml (Before and After)

Blog8Example2Before.png

Blog8Example2After.png

Summary

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.

Sage 300 Date Utility

Introduction

Microsoft’s DateTime Structure is an object that represents an instant in time, typically expressed as a date and time of day.

In Sage 300’s Web Screens, we use this object for dates and times in our C-Sharp code. However, we do not use its numerous properties and methods directly. Instead, we have encapsulated this functionality in our DateUtil class.

Let’s me explain why we came to the decision to encapsulate this functionality.

Encapsulation and Technical Debt

But, first let’s cover some concepts that were at the core of our decision.

What is encapsulation?

Encapsulation is the ability to provide users with a well-defined interface to a set of functions in a way which hides their internal workings.

Benefits of encapsulation

One of the principles of encapsulation is that the internal representation of an object should not concern its consumers. It also hides complex mechanisms and provides code reduction.

What is technical debt?

Technical debt is the set of problems in a development effort that make progress on customer value inefficient.

What does technical debt look like?

Technical debt are problems found through code analysis, duplicate code patterns, code complexity, spaghetti code, …

Encapsulation Decision

We analyzed the code and determined that individual usage of the DateTime properties numbered in excess of ten thousand lines of code. Yikes.

Sage 300 Web Screens can be localized and therefore these lines of code had to specify a locale along with the necessary conditional logic.

And, unfortunately we had different patterns being implemented in those individual lines of code.

So, the decision to encapsulate and to create a single design pattern for the developers to access a date and time was the best choice.

Date Utility Class

Thus, the DateUtil class was created and is available in the Sage.CA.SBS.ERP.Sage300.Common.Utilities assembly.

dateutil

Why should I use this class?

  • Sage 300 Web Screen Date and Time Pattern
    • Let this class do the date validations, acquire a new date, perform conditional checks, etc. for you
    • It’s the standard for Sage 300 Web Screen developers
  • Minimum Date logic is centralized
    • The DateTime structure has different values for the minimum date value based upon how the object was instantiated
    • The DateUtil class has the ability to standardize on a single minimum date value and therefore the application will not have multiple minimum date possibilities
  • Formatting based upon Current Culture
    • The encapsulation allows for the DateUtil class to perform the culture specific logic
    • This eliminates the developer from having to specify this where required
  • It’s easy and does the work for you
    • Enough said on this!

Before and After Examples

In this section, I will show some examples where we replaced code in our application with usage of the DateUtil class.

Example 1: Before

before1

Example 1: After

after1

Example 2: Before

before2

Example 2: After

after2

Example 3: Before

before3

Example 3: After

After3.png

Example 4: Before

Before4.png

Example 4: After

after4

Summary

This article presented the DateUtil class for dealing with dates and times in the Sage 300 Web Screens (C-Sharp code) along with the benefits of using a single pattern by developers.

By encapsulating the date and time functions, we are able to provide a consistent and simple pattern while reducing the potential for technical debt.

When this class was implemented, we removed over 6,500 lines of code from the application.

The DateUtil class is available in the Sage.CA.SBS.ERP.Sage300.Common.Utilities assembly which is referenced in most if not all projects.

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 Open Source SDK First Partner Contribution

Introduction

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 article is about the first partner contribution to the SDK!

Ecosystem Benefits

As I mention in the README document for the SDK in GitHub:

All tools can only be so much to everyone in order to consider everyone’s based needs while providing functionality that is easy to use. The open sourcing of the SDK will allow the community to extend, enhance and tailor this SDK to their specific needs.

Sage wants this community to be successful in the conversion of their applications to the web paradigm. The open sourcing of the SDK will allow those who wish to contribute to the SDDK to do so in a way that not only addresses their needs, but potentially the needs of others as well. With this paradigm, Sage hopes 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
  • Faster Pace to Improve/Enhance/Extend the SDK
    • Everyone benefits (Sage too!)
    • The SDK potentially gets uncompleted sections and areas to be completed

Making the first partner contribution is TaiRox!

TaiRox and the Merge ISV Project Utility

While in a recent discussion about the Merge ISV Project Utility (MergeISVProject.exe), TaiRox inquired about:

  • Adding an additional parameter to the utility in order for it to “not deploy to the local installation”
    • The idea is that the Deploy folder’s contents are only needed at this time
    • The absence of the optional parameter will allow for the utility to perform as before
  • Additionally, a few functions would like to be re-factored as the copy and deploy are currently co-mingled.

My response was “Go for it”!

I see the optional parameter as a nice addition to the utility and I’m all for atomic routines.

And, I certainly appreciated TaiRox giving me a heads-up on the “re-factoring” modification as it would have delayed acceptance of the change as I evaluated the purpose for the additional modifications.

Summary

While Sage has implemented modifications and enhancements to the SDK based upon feedback and suggestions from the community, congratulations goes to TaiRox for being the first to contribute to the SDK outside of Sage.

When we first started discussing the benefits of Open Source, this one was of our goals: participation from the community. Well done TaiRox!

Now, I wonder, who will be next?

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 2017.1 Web SDK

Introduction

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 2017.1 Web SDK to coincide with the release of the Sage 300 2017.1 Application.

It’s Available!

The SDK is available at https://github.com/SageNADev/Sage300-SDK.

This SDK has been previously made available via Sage’s DPP portal. However, starting with this release, we are only making the download of the SDK available via GitHub. It did not make sense to have almost identical downloads available from two different sources.

Branches

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.

master

Contains the current version of the SDK (2017.1).

develop

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

release-2017

Contains the previous version of the SDK (2017).

What’s New

bin Folder

Now that we have a single download of the SDK, the previous version of the SDK, via GitHub, did not include the bin folder, which was included in the DPP download. The bin folder contains the assemblies generated by the wizards and utilities source.

This subtle addition allows the wizards and utilities to be used without first compiling the source for the wizards and utilities.

Documentation

Updated documentation is available.

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

In the docs/development folder you will find two new documents. The first document is Sage 300’s updated brochure which highlights the benefits of the Sage 300 Software Architecture. The second document explains in detail the Worker Processing and Workflow Engine.

In the docs\customization folder are documents for the Customization Overview along with file specification for the XML and JSON files in the customization package.

In the docs\webapi folder are documents for the WebApi Endpoints and instructions for the WebApi Postman samples.

In the docs\upgrades folder is a document for the upgrade procedures for moving partner source from Sage 300 2017 to Sage 300 2017.1.

Customization

The SDK now provides a wizard, samples and documentation for the ability to customize a Web Screen. The bin\wizards folder contains the Sage300UICustomizationSolution.vsix plugin for Visual Studio, the docs\customization folder contains the documentation for the customization strategy, and the samples\customization folder contains three different samples illustrating how to customize a Web Screen.

Samples

The previous samples have been updated with new references and minor corrections.

The Clear Statistics sample has been added and is an example of the Process Type for Web Screens. This sample provides a working example of the A/R Clear Statistics screen along with the SQL required to participate in the Sage 300 Workflow Engine.

Three customization examples have been added and they use the OE Order Entry Screen, the OE Copy Orders Screen and the CS Tax Authorities Screen to illustrate the new customization abilities.

A new WebApi sample was added to illustrate integration and includes documentation and Postman collections.

Component Updates

Several core components were updated this release: Kendo UI (2016), Azure SDK (2.8) and the Target Framework (4.6.2).

Workflow Engine Enhancements

In order to facilitate participation with partner’s process screens, the Workflow Engine required an enhancement to ensure that partner process screens would not interfere with Sage processes or other partner processes. Therefore, integer fields were changed to GUID fields, enumerations changed, Landlord Database Tables modified and even the discovery location of SQL scripts were enhanced to facilitate successful integration with partner process screens.

Solution Wizard

Numerous changes to the wizard to support the updated components and references.

Code Generation Wizard

Numerous changes to the wizard to support the updated components and references.

The Process Type has been completed to generate a Process Screen will all of the required components in order for it to be compiled. A SQL file is generated that can be used to update the Landlord Database Workflow tables (via Portal button in the Database Setup Screen).

While the process screen is able to be compiled, it still requires manually completion to be functional.

WebApi

Several significant changes to the WebApi have been made, such as, an OData upgrade, support for the PATCH verb, Versioning, added endpoints, and Open API (Swagger).

 

Summary

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

Component Updates, new Customization Framework, new Samples, Processing enhancements and WebApi features and enhancements are all in the 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.