#GPPT What’s New: GP Power Tools is faster and easier to navigate

As mentioned in recent posts, GP Power Tools is almost ready for release. The user guide manual documentation is now completed… all 256 pages of it. If you want to get the code now, you can already install the public beta and upgrade to the final release later.

This is the first article in a series of What’s New posts for GP Power Tools. The aim of this series is to highlight some of the new features of the tool and flesh out more details than the 21 reasons to upgrade article.

When creating GP Power Tools, one of the first changes (other than rebranding) was to change the data storage from a Debugger.xml setup file to tables in the system database on SQL Server.

Performance

A bit of history …. The Debugger.xml file was originally used to avoid the creation of any SQL objects to allow easy installation and removal of the Support Debugging Tool for its role as a troubleshooting tool. As the functionality of the tool grew and more data was stored in the Debugger.xml, performance slowed as the data was written to and read from the Debugger.xml file. To help with the read performance, ctree tables were used to cache the contents of the Debugger.xml. Also, the additional features added to the tool meant that the Debugger.xml needed to be stored in a shared network location. Finally, because the tool has lots more functionality than the original troubleshooting tool, it was being left installed on systems and the ease of removal was no longer important.

When creating GP Power Tools, one of the first changes (other than rebranding) was to change the data storage to use SQL Server tables. You would think that this would be a simple change, but it took about two weeks to complete. To make the Debugger.xml setup file work as a storage system required a large amount of custom code. The windows would read the Debugger.xml contents into temporary tables and then read and write from the temporary tables. When saving or applying, the data was written back the Debugger.xml file and the cache tables. All this code needed to be removed and replaced with more conventional code to use the SQL tables. To complicate the conversion, on some windows, data needed to be stored temporarily and only saved to the physical tables when applied. This meant that additional code was needed to store data in temporary tables until applied.

The end result is that when saving data, there is no longer a noticeable pause as the data is written. Also there is no requirement for a shared location to store the Debugger.xml file, however a shared location is still useful to centralize storage of log and export files. Finally, having the data stored in SQL Server is more secure than a shared location in the file system.

Navigation

One of the areas of feedback received about the Support Debugging Tool was that it was difficult to find the options / windows. Part of the cause of this is that when new features were added, their navigation options were just added to the bottom of the Standard Mode or Advanced Mode features.

So GP Power Tools resolves this by providing multiple options for navigation as well as grouping the features. You can still find the main GP Power Tools Logging Control window on the Tools menus of the application and individual windows (both menu or ribbon style). The Ctrl-D keyboard shortcut is also still available.

     

You can also find the options on the Standard Toolbar and Quick links on the home page.

    

From the main GP Power Tools window, you can use the Options button drop list or the GP Power Tools window menu to access other features. Both of these menus are now broken down with sub menus into functional areas:

• Resources and Security
• Scripting
• Export and Import
• Administration

  

    

Also, GP Power Tools has been added to the application level menus as a sub menu under Transactions, Inquiry, Reports, Cards, Setup, Utilities and Routines.

Finally, GP Power Tools has its own Area page from the Navigation buttons:

The Area Page means that navigation on the Microsoft Dynamics GP Web Client is now simpler.

Access to the windows is controlled by application level security and the four automatically created security roles:

• GP POWER TOOLS USER – For Standard Mode (User) features
• GP POWER TOOLS ADMIN – For Advanced Mode (Administrator) features
• GP POWER TOOLS PASSWORD – For Administrator Password Setup window only
• GP POWER TOOLS SERVICES – For GP 2015 (or later) Service Enabled Procedures

Note: Access to Advanced Mode features also requires sysadmin or dbo access at the SQL Server level and the System Password or Administrator Password (if enabled). The option to hide Advanced Mode features using a Dex.ini setting is no longer used.

So now you should have no trouble navigating the various windows of GP Power Tools by whatever method you decide.

Enjoy

David

This article was originally posted on http://www.winthropdc.com/blog.