Implementing an External Finder

Introduction

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.

Example

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:

InitFinders:

finderSuccessVendor:

getFilterVendor:

Step Six

Mission accomplished!

 

Summary

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.

Summary

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 http://sagecity.na.sage.com/sage_partners/f/53 as this forum is monitored by DPP Support and myself.