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 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 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.

Open Source Web SDK – Policies and Procedures

Introduction

In my previous article, I shared my thoughts on open sourcing the Sage 300 Web SDK (SDK) and how, in my opinion, this will benefit the Sage 300 Ecosystem.

In this article, I am introducing the SDK as Open Source Software (OSS) and will explain the changes to the original vision since the idea of open source was first presented along with the policies and procedures for the repository.

It’s Available!

The SDK was pushed to the public repository on July 23rd, 2016. The goal was to make this available for our Sage 300 2017 Release (August 2, 2016) and to also have it available for Sage Summit 2016 in Chicago (July 25-28, 2016). We made it by 2 days!

Licensing

The original plan was to use the Apache License 2.0 for our OSS. However, in discussions with our Sage Legal Team and the Open Source Initiative team, The MIT License (MIT) was chosen instead. The license can be found here: https://opensource.org/licenses/MIT

GitHub Repository

Repository Name

The GitHub Repository is SageNADev/Sage300-SDK and can be found here: https://github.com/SageNADev/Sage300-SDK

Blog4Github

Administration

The administration of the repository is performed by Sage’s DevOps Team located in Richmond, BC.

Anonymous Users

The repository is read-only for anonymous users which means that these users cannot “push” their changes into the branches in the repository.

Collaborators

Collaborators are Sage assigned developers and personnel which have write/push access to the branches in the repository.

Collaboration Model

There are two main models for collaboration using GitHub:

  • The Shared Repository Model
  • The Fork and Pull Model

In the Shared Repository Model, in order to allow everyone to “push” to the repository, users have to be granted collaborator permissions. This is a good solution for small teams where members know and trust each other. This model cannot, or should not, be applied to large teams or a public repository where all users have the right to contribute.

In the Fork and Pull Model, any GitHub member can “fork” a public repository. When forking the original repository, another one is created. Modifications can be applied to the forked repository without the changes affecting the original repository until a pull-request is submitted and evaluated by a collaborator who may or may not merge the changes.

Therefore, with Sage in the collaborator role, the model of choice is the Fork and Pull Model.

See the following article on Forking: https://guides.github.com/activities/forking/

Forking and Branches

There is a difference between a fork for an anonymous user and one for a collaborator.

Blog4Branches

Story Branches (Private)

Story branches are where the Sage collaborators make modifications and enhancements to the next version of the SDK. However, on GitHub, the repository is either public or private and branches cannot be private in a public repository.

The branch where the work is performed is not ideally suited for public consumption from an interest perspective, but also from exposing the developer and potentially numerous changes.

Therefore, in order to take advantage of GitHub for both public and private development, a Sage collaborator will:

  • Fork the public repository
  • Change the settings of the new fork to private
  • Clone the private version down to their local machine
  • Create a story branch based upon the develop branch
    • Note: Story branches are prefixed with a Version One Story plus Description
  • Make changes locally
  • Commit to the local repository
  • Push up to the private fork
  • Use pull-requests to selectively copy the required branch (develop) to the public repository

The Sage collaborators use squashing in order to reduce the commit history being pushed into the public branch.

Fork (Anonymous Users)

While Sage collaborators used a forked repository for making changes to the public branch, any anonymous user can submit changes to the public repository. However, an anonymous user is not able to commit or push these changes themselves since they only have read-only access.

Therefore, an anonymous user will:

  • Fork the public repository
  • Clone the fork down to their local machine
  • Make changes locally
  • Commit to the local repository
  • Push up to the fork
  • Submit a pull-request, which is evaluated by a Sage collaborator for inclusion into the public repository

Development Branch

The development branch (develop) is just what the name implies as it contains the in-progress contents of the SDK that is currently being worked on for the next release.

Sage collaborators are pushing changes and potentially merging anonymous requests for the next version of the SDK.

Only Sage collaborators can make changes to this branch.

This is the branch to be accessed based upon the following question: “Get me the in-progress version of the SDK that is not ready for release, but is to be released with the next version of the SDK”.

Current Branch

The current branch (master) is the branch which holds the current release of the SDK.

Sage collaborators may push changes to this branch in response to defects or issues either discovered internally or externally which require immediate correction. Any changes to this branch are also made in the develop branch.

Only Sage collaborators can make changes to this branch.

This is the branch to be accessed based upon the following question: “Get me the current version of the SDK”.

Release Branches

The release branches (i.e. release-2017, release-2017.1, etc.) contain the contents for that particular release.

When the next version of the SDK is released, the current branch (master) is copied into a release branch (release-2017, for example), the development branch (develop) is copied to the current branch (master) and then the development branch (develop) becomes the basis for the next release.

Blog4Releases

  • There is only one in-progress branch: develop.
  • There is only one current version branch: master.
  • There will be numerous version branches: release-2017, release-2017.1, etc.

Only Sage collaborators can make changes to these branches.

Folders and Files

The folder structure is identical between the development, current and release branches. The folders are used to segregate the various components of the SDK. The contents are different in that they contain content relevant to the version of the SDK that the branch represents.

docs Folder

This folder holds the documentation for the SDK and contains the following sub-folders:

  • development
  • patterns
  • presentations
  • standards
  • upgrades
  • utilities
  • webapi
  • wizards

patch Folder

This folder holds files, if any, regarding any patch work required to the SDK due to late minute changes that were not able to be included in the Sage 300 application. The README file in the patch folder will discuss the patch, the requirements and any steps necessary to apply the patch.

samples Folder

This folder holds the sample projects, which are standalone, runnable versions of different web screens and reports within the Sage 300 application. These samples are to provide implementation knowledge.

src Folder

This folder holds the source files which comprise the wizards and utilities and contains the following sub-folders:

  • utilities
  • wizards

root Files

The branch root not only contains the folders just mentioned, but also contains the following:

  • LICENSE.md
    • A read-only file for displaying the MIT Copyright notice
  • README.md
    • A read-only file for displaying any SDK information on the main GitHub page
  • VERSION.md
    • A read-only file for displaying the current version of the SDK

Release Cycle

The SDK follows the release cycle established in the roadmap for the Sage 300 application. Therefore, new versions of the SDK are released when the application is released.

Approval Timeline

The approval process for changes submitted by anonymous users are performed by Sage collaborators who will review these changes for inclusion based upon the value added to the SDK for the benefit of all users.

Therefore, it is extremely important to provide as much useful information and rational to support the request being made. And, not all requests will be accepted. But, the good news with OSS is that the submitter can still enjoy their version of the SDK even if the request is not accepted.

Sage collaborators will review new pull requests on a bi-weekly basis.

Depending upon the SDK roadmap, Sage collaborators may be working throughout the development cycle on changes and enhancements and will want to potentially include any requests and issues discovered and presented by anonymous users.

Summary

The SDK is released to open source! This article covered the GitHub repository, the license strategy, and policies and procedures pertaining to usage and management of this public repository.

I am excited for the Partner and ISV community to participate and contribute to not only their success, but to the success of the SDK and to other users of the SDK. I look forward to the submissions from the community in modifying and enhancing the SDK.

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.