This is the sixth and final article in a short series that explains the integration between Sage CRM and Sage 300.
This article will cover the technology used in the integration AND the new approach to the proxy & why it matters.
The earlier articles explained the integration uses some of the key features of Sage 300; the Sage 300 Web Screens and Sage 300 Web API. These are enabled and set up within the server as the Sage 300 instance is installed.
The integration can call the Sage 300 Web Screens directly from within Sage CRM. The users see and interact with the same screens as within the Sage 300 interface so providing direct access and control over the accounting data. And where dynamic access to data is needed within Sage CRM screens the RESTful Sage 300 Web API allows data to be returned in an easily consumed JSON structure that can be used within powerful screen controls.
Below is one of an Inquiry screen that has been built using the new technology. The page is a DLL (inquiry.dll) built using the Sage CRM .Net SDK. This provides for improved security and source code protection. The page a generic Inquiry page Engine. The same page can take different parameters to run different Inquiries. These are sent to the relevant Sage 300 Web API endpoint. The Sage 300cloud instance returns the result set in JSON format. The DLL is able to use the JSON metadata that describes the returned data with the application data to build the grid.
Because endpoints exposed by the Sage 300 Web API are extensible & discoverable. The design of the integration is able to take advantage of that and allow new types of Inquiries to be made. The grid is built using the Kendo UI library and allows the grids to appear like native Sage CRM list pages at the same time opening up the possibility of inline editing of data.
Where drill down is required, for example, to start editing or inserting an order then Sage 300 Web Screens are called (via a standard DLL - ScreenPage.dll) and embedded within the Sage CRM interface within an iframe.
The user experiences a seamless integration. As the Sage 300 Web Screens appear within the Sage CRM interface there is no jarring prompt for credentials. This blending of the two systems is enabled through the use of a proxy server.
In the example of the O/E Order Entry screen shown above the user has started in the context of a company. When the integration DLL page is first called the code fetches the Sage 300 Company ID and the Sage 300 user credentials associated with the Sage CRM user accessing the page. Company ID and User ID along with the encrypted password is then sent to the proxy server along with the request for the Sage 300 Web Screen. The proxy server then uses these credentials to create a Sage 300 session and once the user is authenticated the Sage 300 server returns a cookie to the proxy server for it to use in subsequent requests. The requested Web Screen is then returned to the Sage CRM interface for display within an iframe.
That is the basic flow of the proxy and the Sage 300 Security team has reviewed the implementation for standard security issues and vulnerabilities.
The use of the RESTful Sage 300 Web API means that if a new Sage 300cloud Inquiry is needed to be added as a linked menu item in Sage CRM, a new entry can be simply added in metadata and the link will be shown in CRM.
And new Sage 300 Inquiry can be created using metadata for consumption display.
And because Sage CRM is surfacing Sage 300 Web Screen directly, if this Screen is customized by a partner then this is the Sage 300 Web Screen that is seen by the Sage CRM user.
There is no coding required on either the Sage 300 or CRM sides for customization. The Inquiry and Sage 300 Web Screen entries are stored in the Sage CRM's AccpacInquiry table, this is the metadata used to control the behaviour of the integration. The metadata definitions cover both the Inquiry tabs that use the Custom .Net DLL 'inquiry.dll' and the Sage 300 Web Screens surfaced within the Custom .Net DLL 'ScreenPage.dll'.
The use of the metadata to control the interface and the use of the Sage 300 Web API and Web Screens means that customization should be considerably easier for implementers and System Administration.
-
The integration between Sage CRM and Sage 300
