I’m so glad the day has finally arrived where I can talk about this innovation, I think this is one of the coolest things in .NET development with Dynamics GP for some time. I have been restless to give it a go since I was first told about it.
What is the fuss about?
Last night VST Controls 1.0 was released. This is a really cool FREE .NET developer control library from Envisage Software (makers of PostMaster) & Precipio Services. When I say control library, it is actually a helper tool (provided as a .dll for GP 2013+) that allows any standard windows visual controls to be layered on a Dynamics GP form, and for the GP addin to communicate to those controls.
.NET development on Dynamics GP is limited to the standard set of dexterity controls that GP provides in modifier. Today users take for granted and expect as standard to be able to use more advanced controls with their applications.
Above shows a product photo on the Item Maintenance form of GP. To a Dynamics NAV developer, perhaps excitement from being able to place a picture from the database onto the form seems odd? -trust me this is cool for us GP .NET developers.
VST Controls®™ solves some of the frustration caused by being restricted to the small subset of controls that GP as standard provides to the developer. Now with VST Controls on the scene, a developer’s creativity is released, as any control, including 3rd party controls can be placed on top of a GP form. Not only that, it is done with a few lines of code, so very simple to achieve!
Often I have wanted to be able to add say, a web browser control or picture control, even hyperlinks to GP forms, but have ended up having to “pop” a dialog window (a .NET form) to do so. This in many cases this upsets the flow that the user experiences as they traverse the user interface. By layering the “VST Controls” on top of the GP windows this should solve many of these issues.
Hey- this is not a substitute for the design time experience if the GP modifier designer suddenly supported .NET controls, but is the next best thing. There are also going to be some limitations to what you can do using this technique, already I've noticed issues around when the user resizes the GP form, but I’ll tolerate those limitations for what this opens up to me.
Go try it
So go try it – let your imagination go wild, it is totally $£€Free – no royalties it is offered as a contribution to our GP community –so well done guys!
This is purely and observational post of a phenomenon we see in GP from time to time.
The telesales team perform data entry in the SOP screens at a lightening pace, tabbing through windows, hammering information into the screens very quickly while the customer verbalises the order to them. Over the years we regularly see inconsistencies between IV and SOP modules. Here is one that I captured that I’ve seen a few times.
The order default site is “1” and the user has no reason to sell from any location than “1”. There is no stock in location “5” nor any reason to look at that location. The order below is curious.
I would say some how the user has entered the item order quantity, accidentally, into the SITE ID field, every time the I see this the quantity ordered is the same as the accidentally entered site id. Thus my assumption.
That alone is not odd, but look further…
The stock has fully allocated to the order line.
However looking above that item has no stock (or ever has had) in location 5. Indeed the location allocation shows zero allocated.
Now above we look at location “1”, where the stock should have come from, and we see 5 allocated. If we drill into that allocation we find no documents allocated, however switching to location 5 shows our SOP document.
So it seems to me that the line originally was taking from location “1” and allocated, then somehow the user has managed to change the site ID without GP attempting to reallocate the stock. If it did reallocate it would have to back order the items as there is none to allocate in 5.
Then the order line has been saved with 5 as the site ID, leaving corrupt figures between SOP-IV modules.
I can only think there is a way or speed at which the events on the form don’t fire correctly or in the right sequence that allows this to happen.
You’ve seen it often enough in GP stored procedures, but what is it doing?
EXEC @iStatus = smFormatStringsForExecs
@I_vInputString = @I_charEndCustomer,
@O_cOutputString = @cEndCustomer OUTPUT,
@O_iErrorState = @O_iErrorState OUTPUT
The above code snippet is the common code pattern it appears in. I had always assumed, until today that this procedure was cleaning the input into the procedures for anti-SQL injection attack purposes, alas it seems not.
The procedure actually turns the passed string into a quoted string for use as parameters when building up SQL by concatenation within other GP stored procedures.
IF we pass the string 6252''5 002 (with the trailing spaces) into the procedure, this is what we find:
DECLARE @return_value int,
EXEC @return_value = [dbo].[smFormatStringsForExecs]
@I_vInputString = N'6252''5 002 ',
@O_cOutputString = @O_cOutputString OUTPUT,
@O_iErrorState = @O_iErrorState OUTPUT
SELECT @O_cOutputString as N'@O_cOutputString',
@O_iErrorState as N'@O_iErrorState'
SELECT 'Return Value' = @return_value
So the procedure has taken any trailing space out and wrapped the passed string in quotes and doubled up any quotes that were in the string to delimit them. Thus the output of the procedure can be used in string concatenation to build a SQL script dynamically.
So you don’t want to use the output of this parameter directly or it won’t work:
i.e. don’t do this with the output from the format strings procedure…
DELETE FROM RM00101 WHERE CUSTNMBR=@O_cOutputString
-as it will not match any customer numbers (unless your customer numbers are in quotes!).
Beware when using eConnect with ASP.NET Web API.
… as exceptions raised by eConnect will not be of type eConnect.Exception
thus using our normal typical catch block, such as:
will not work, because all eConnectExceptions will actually cause the following exception to be raised/returned:
System.NullReferenceException: Object reference not set to an instance of an object.
at Microsoft.Dynamics.GP.eConnect.EventLogHelper.AddExceptionHeader(String action, Object inputParameters, StringBuilder errorString)
This is because there is a flaw in the eConnect, eConnect.EventLogHelper.CreateEventLogEntry method. It attempts to extract the Thread.CurrentPrincipal.Identity.Name as part of the output, but when eConnect is used in the context of ASP.NET Web API, this is null.
As it is null this causes a new exception to be caused, the original exception superseded by the new System.NullReferenceException caused in the exception handler, that masks the original issue.
Explicitly setting the current threads identity name just before calling eConnect solves this problem and so allows the eConnect.Exception to be caught and processed as would normally be expected.
I discovered this whilst diagnosing a problem on the forums for someone, see: Econnect Exception Handling doesn't work in WEB API 2 application