Monday, February 23, 2015

Lessons learned from trying to integrate with Dynamics GP web client

Integrating to the dynamics GP web client, which uses silverlight on the client side, gave me experience in a lot of different areas:

1. COM automation. I used this to get the client computer name.

2. WCF web service. I used this to get the client computer name the first attempt. The problem came when load balancers were involved and changing the source IP address in the http request.

3. Visual Tools for Dynamics GP. I used this to create a GP addin. This is incredibly powerful for extending GP. I also learned about DAG.exe, which is how you create a .NET representation of a Dex dictionary. The GP addin is in .NET and it gives you access to more events, and can be used to do more complex tasks that are difficult to do in Dex. For example, string processing is very limited in Dex, so you could do the processing in .NET instead.

4. P invoke / windows native API calls. I've used this before, but very limited and I didn't know what I was doing really. In this case I had to figure out how to do some printer calls. This is very useful to know, especially if you're using silverlight, because the built in library is pretty limited.

5. Silverlight. I didn't do any UI, just processing. I found out all of its limitations as far as processing goes. 

6. Portable Class Library. I had to do a .net dll and a silverlight project. There was a lot of duplicate code at first, but then I discovered the PCL. This allows you to create a DLL that can be used by multiple platforms, and thus get rid of the duplicate code.

7. Dynamics GP web client, and specifically the limitations. There are numerous limitations but I'll just list the ones I learned the hard way: 1) quick reports print to the screen only. 2) standard reports ask the user "do you trust this application to print to your printer?" And then prompts them to choose a printer. It does these two prompts even if you're running in trusted mode, even if you have "NoPrintDialogs=True", even if you specify the printer in the run report command. 3) because of 1 and 2 there is no way to avoid prompts while printing. 4) the Printer_Define() call freezes GP, so if your code does this make sure to not call it if running in the web client. 5) lookup buttons on scrolling windows return the value to the field, but don't run the fields change script 6) push buttons are 3D. So if you have a scrolling window with some push button column headers, and others as static text, it is going to look weird. 7) it freezes a lot. Using it on a virtual machine with 8 gb and 8 core CPU and a few users (this is a test environment) tends to freeze quite often. I don't know about this in a production environment 8) exceptions thrown from the silverlight WC addin are suppressed. That is vital to know, because it makes it very difficult to troubleshoot. The best solution is to just wrap everything in a try catch block and log the error or show the messagebox, otherwise it will crash and you won't know it

No comments:

Post a Comment