DATA MANAGEMENT SOLUTIONS WITH MS GREAT PLAINS PACKAGE
SYNOPSIS
This document performs a high level evaluation of the MS Great Plains package and will derive the possible integration strategies that could be used for integration.
MS GREAT PLAINS
The structure of the core Great Plains application is shown in the following illustration. For single-user installations, all components are installed on a single workstation. For multi-user installations, the Runtime engine and Great Plains application dictionary are installed on individual workstations. Data for the system is managed by a separate server.
It is composed of the following parts:
- Dexterity runtime engine
- Great Plains Application dictionary
- Microsoft SQL Server database
MS Great Plains Dexterity engine based integrations:
Dexterity is the development tool used to create the Great Plains application. The Dexterity runtime engine presents the Great Plains application to the end-user. Both the development tool and runtime engine are standard Windows applications developed using Microsoft Visual C++. Dexterity is a completely integrated development environment.
Its features include:
- Graphical forms designer – A WYSIWYG layout window used to design forms visually.
- sanScript scripting language – An English-like scripting language used to add business logic to the application.
- Extensive function library – Hundreds of special-purpose functions allow implementing key functionality in an application.
- Integrated script debugger – Allows interactive debugging of an application.
- Structured exception handling – A built-in mechanism for dealing with unexpected conditions in the application.
- COM support – Excellent access to features made available by other applications through COM.
- Integrated Source Code Control – Built-in support for managing application resources using Microsoft Visual SourceSafe.
- Built-in Report Writer – A WYSIWYG report layout tool used to design reports.
The tools used to create third-party integrations to Great Plains can also be used to make customisations. For instance, a Dexterity-based application can make extensive customisations to the Great Plains application. These types of integrations can even replace entire forms and reports in the main application.
The Dexterity runtime engine displays the functioning application to the end-user. It provides the basic capabilities used by the Great Plains application, such as the subsystems to display the user interface or access the SQL database.
The runtime also provides additional tools and technologies available for Great Plains. For example, the Modifier, Report Writer, Visual Basic for Applications (VBA) environment, and COM interface are just some of the tools and technologies provided by the runtime engine.
Based on the knowledge gained from the preliminary investigation of MS Great Plains, the following integration points were identified:
- COM object based integration (based on MS Great Plains Dexterity engine).
- Converter Agent centric integration.
- Direct DB Mapping.
COM OBJECT BASED INTEGRATION
COM component based integration is one of the most versatile methods of application level integrations available for Great Plains. This integration method effectively utilises the COM interface provided by MS Great Plains that allows the external applications to customise Great Plains (an application written with Visual Basic .NET could use the COM interface in Great Plains up to the level of modifying the appearance of a form).
In this level of integration, the COM objects will implement any data conversion or filtering logic required during the integration. The integration happens at the application level, allowing the application to control the data items that need to be saved on their respective databases. If required, one application could utilise the data stored on the other application’s database and depend on it totally, without committing or retrieving any data item on its own database. The Data access interface provided by the COM components will allow both applications access to each other’s databases seamlessly.
Optionally, each COM component could be controlled by a Controlling interface that could be used to grant or deny access to COM objects based on the authentication levels or any other required criteria. Any transaction that takes place on either system and/or database could be reported to an audit trail, which can be utilised to audit the transactions that took place between the two systems. These features will particularly be important if an organisation is exposing its local system to third parties through the integration.
Depending on the level of component orientation, and the requirement, this approach could successfully be implemented allowing for a high level of flexibility in terms of access and provides excellent control over the integration.
CONVERTER AGENT CENTRIC INTEGRATION
This approach would require the implementation of a standard schema (like xml) based agent service that would expose the two systems to each other. Being more close to the COM component based integration architecture; this approach has other strengths in terms of licensing costs and resource requirements. This solution would require additional access interfaces to be developed on both ends to extract the data transferred through the agent.
The converter agent performs the tasks of:
- Data conversion
- Encoding data into the proper schema
- Access granting, control and monitoring
The following diagram depicts this type of integration:
The specialty of this method is that all the data transfers would occur through data request and the response type of communication happening through the Converter Agent software.
Depending on the requirement, the communication channels could be made secure using technologies (such as SSL) if the data transfer takes place over un-trusted networks.
DIRECT DB MAPPING
Direct database mapping is another effective and probably the most low overhead and high performance integration option. If the two applications that are required to integrate, share the same brand and make of database, it would facilitate this option greatly.
This integration method would integrate the two application databases directly by implementing any required access and transfer logic directly at the database level through the use of database triggers and stored procedures. This method allows either application to access each other’s databases directly or through database views, and a set of properly defined database stored procedures.
Due to the direct data transfer, this method is more suitable if the system integration is internal to the organisation as there can be many security and data integrity considerations in this approach. Depending on the software that is being integrated, this method may require additional coding on both system ends.
