All related posts: Reference Page – GP/QTP Automation  

Overview: COM and Automation 

COM, Component Object Model, is Microsoft framework for developing and supporting program component objects. Whereas Microsoft’s Object Linking and Embedding (OLE) provides services for the compound document that users see on their display, COM provides the underlying services of interface negotiation, life cycle management (determining when an object can be removed from a system), licensing, and event services (putting one object into service as the result of an event that has happened to another object).

COM includes COM+, Distributed Component Object Model (DCOM), and ActiveX interfaces and programming tools.

Automation is a Microsoft technology that allows accessing software objects inside one application from other applications. These objects can be created and manipulated using a scripting or programming language that supports COM such as VBScript or C++. Automation enables controlling and using the functionalities of an application programmatically.

An application that provides access to its objects is called an automation server. An application that accesses objects from an automation server is called an automation client. 

In Quick Test Professional with its VBScript language native for COM developer has all the options to embed and control the external objects supporting COM on their side. In QTP 2 functions implement retrieving automation object reference. 

• CreateObject
• GetObject 

Per their naming, second function retrieves instance of the object already loaded and initialized in system, while first one creates and makes the object loaded. 

MS Dynamics Great Plains Automation model 

Great Plains runtime engine supports COM and can act as an automation server providing access to the key objects from the outside. This functionality is provided by the Continuum Integration Library. The Continuum Integration Library is the code in the Microsoft Dynamics GP application that describes the objects that can be accessed through the COM programming interface. QTP will use the properties and methods for these objects when it interacts with Microsoft Dynamics GP.

The Microsoft Dynamics GP application objects provide two basic actions that enable integration. First, they allow actions to be executed in Microsoft Dynamics GP, such as pushing a button or setting the value of a window field. Second, they notify the integrating application when certain events occur in Microsoft Dynamics GP, such as when a form opens or the value in a field changes. 

Continuum API Guide 

Microsoft Dynamics Great Plains Continuum API Guide online reference: http://mbs.microsoft.com/downloads/public/GP90Docs/ContinuumAPIGuide.pdf

 The document is dedicated for development of Great Plains integrating applications that would be using Dexterity GUI and functionalities. However, same described objects and methods could be utilized for user action simulation from Quick Test Professional. 

Sample code 

Populate data form (“Login” window) 

‘Get reference of launched Great Plains application

Set GPApp = GetObject(“”,”Dynamics.Application”) 

‘Bring focus in

GPApp.Activate() 

‘Select server name (by index)

intRC = GPApp.SetDataValue("'(L) SQL_DataSource' of window Login of form Login", "2") 

‘Set user ID

intRC = GPApp.SetDataValue("'User ID' of window Login of form Login", “TestUser”) 

‘Set password

intRC = GPApp.SetDataValue("'Password' of window Login of form Login", "Password1234") 

As it’s seen from the example above data fields (Listbox, Textbox, etc.) could be directly addressed by internal name, and such a names are defined for the all objects within the hierarchy: forms, windows, and fields. It’s also noticeable that the syntax doesn’t utilize a general object-oriented notation.

Dynamics.Application Object 

The following methods of Application object could be used for simulation of user interactions. 

• Activate
• GetDataValue
• SetDataValue
• MoveToField 

Refer to Continuum API Guide for detailed description of the all available methods and properties of Application object. 

Identified Issues 

1) GUI names (internal field names) 

Addressing the field objects requires knowing the names. Therefore a service routine should be developed for GUI names retrieval.

Possible solutions.

• Map the entire GUI hierarchy from the main Dictionary
• Develop GUI Inspector script, recognizing and reporting Dexterity GUI in a way similar to Object Spy functionality 

2) Application object’s limitations with simulation of user interactions. 

Using Application object’s method we can set or retrieve values of data fields but we cannot send direct mouse clicks or retrieve some required field properties, like contents of the list.

However, the Application object is just a wrapper of Dexterity engine internally operated on SanScript programming language.

ExecuteSanScript method allows executing SanScript code with all the Dexterity native functions and operators covering test automation needs. 

3) VBScript limitation with in/out string pointer type (BSTR*) 

ExecuteSanScript method uses “string pointer” for parameter exchange which is not supported in VBScript that has only and single “variant” data type. Passing in VBScript variables causes “Type Mismatch”.

Investigation of similar experience over the Web revealed that this is common and well-known issue faced by VBScript developers.

There are 3 ways to overcome the identified limitation.

• Do not use “string pointer” type in the COM function. – Not applicable way in case of QTP/GP automation as we have the vendor provided code.
• Implement in C++ (or other similar language) COM compatible DLL module with the all library functions directly operating with Dynamics.Application object and serving as a wrapping bridge to convert “string pointer” type to “variant” and backward.
• Use existing COM object that may act both as Automation Server and Automation Client. For example, Excel.Application object which has built-in internal Excel.VBA execution engine.

The issues discovered will be addressed in the subsequent posts.