With the advent of the web client, a lot of things have had to change in the way we create customizations in Dynamics GP. VBA is not used with the web client, so right away, all those old VBA customization are going to need to be re-done in Dexterity or Dot Net. Many existing Dot Net add-ons will need to be updated to work with the web client, especially when it comes to rendering the forms for the web client.
One of the most useful and often used controls by my development group is the data grid. This is like your scrolling window in Dynamics and is great for showing lists of data, like line items on an order or a lookup of customers. However, here comes the pain. Only certain controls are available to be automatically rendered by the web client, and the data grid is not one of them. Below is a list of controls that will automatically render on your windows for the web client:
- Button
- CheckBox
- ComboBox
- GroupBox
- Label
- ListBox
- RadioButton
- TextBox
Nope, no data grid and no listview. That is a bummer. So what do we do when we need to use those controls? The short answer is feel the pain. In order to make sure of controls that are not in the list above, you have to create your own form using Microsoft Silverlight to duplicate the form you have for the desktop. And even if you are developing specifically for the web client, it is best to create that desktop version of the form.
What you are going to do is create that desktop version and get it working well. Keep in mind that your web client form is going to make calls using messages to that desktop form and code. This is the recommended way to hook up the web form.
First things first. On your Dot Net add-on GPAddIn class, you are going to need to add some attributes.
This takes one parameter that indicates which platform or platforms are supported by the integration. In this example, the logical-or operation is used to indicate that both the desktop client and the web client are supported.
Next your GPAddIn class will need to implement the interfaces IDexterityAddin as normal, but now we add in the IWCCustomMessagingAddin, which is used for the messages between the web and desktop client.
InitializeMessaging is used to setup the messaging proxy property which is a public static that you will add to the GPAddIn.
public static IWCCustomMessagingProxy Proxy;
ProcessMessage is used to receive messages from the web client or from the desktop client to the web client.
Recover is used to reset the messaging when done, or an error occurs.
How messages are used
The messages that keep the Silverlight application synchronized with the Visual Studio Tools
add-in are used in several ways:
- Some messages will contain the data that is retrieved by the add-in running on the server and then sent to the web client to be displayed in the Silverlight windows.
- Some messages will contain data that is entered by the user on the web client, and then transferred to the server to be processed by the add-in.
- Some messages indicate actions to be performed within the integration, such as opening or closing a window.
- Some messages will indicate actions the user performed in the web client, such as clicking a button in a window.
For a specific example of the messages used in an integration, see Chapter 35, “Salesperson
Analysis,” which lists the messages that the Salesperson Analysis sample application uses to
implement custom rendering.
Message structure
Each message that is sent between the web client and server has the type
WCVstCustomMessage. It has the following parameters:
Source: This is a string value that must contain the namespace and class of the sender.
Destination: This is a string value that must contain the namespace and class for the message processor method in the destination.
Description: This is a string that contains a description of the message. It is used to help identify the message. In some cases, it can contain the information to be sent by the message.
Data: This is a byte stream value that contains the data for the message. Typically, this is a serialized value. The contents of the byte stream is automatically compressed to make the data transfer more efficient.
Message examples
The following examples show how messages are sent between the Visual Studio Tools add-in and the Silverlight code running on the web client. These examples are messages used for the Salesperson Analysis sample.
Sending a string value from the server
This example shows a message that sends a string value for the Salesperson ID from the Visual Studio Tools add-in on the server to the Silverlight application running on the client. The first line of the example checks a variable that was set based on whether the web client is being used. Notice how the value was encoded so that it can be sent as a byte array.
The following code is the C# version of this example.
if (IsWebClient == true)
{
// Send the selected salesperson ID to the web client
// Convert the string value to encoded bytes to send
byte[] bytedata;
System.Text.UTF8Encoding val = new UTF8Encoding();
bytedata = val.GetBytes(SalespersonMaintenanceForm.RmSalesperson.
SalespersonId.Value);
// Send the byte data to the web client
proxy.SendMessage(new WCVstCustomMessage(“SalespersonAnalysis.GPAddIn”,
“SalespersonAnalysisSL.GPWCAddIn”, “TransferSalespersonID”, bytedata));
}
What this basically all comes down to is you want to press a button on your web client form and send a message to your desktop client version that in turn pressed the button on the windows form version of your screen. Then, depending on the outcome of the button press, send a message back to your Silverlight form to update it accordingly. Obviously a web client only customization could be made without the desktop form, and the messages could just call code directly from a class or other component, but it seems logical that most customizations would be expected to work on both the web and desktop clients.
Also, debugging the web client is not nearly as easy as it is to debug the desktop client, so getting everything working smooth with the desktop client, then just hooking up the web form on top of that will make life a little easier.
WILL STAFFORD | .Net Business Solutions Team Leader
Will is responsible for the creation and maintenance of software customizations, reports and applications. He works on the entire development life cycle, gathering requirements, designing, coding, testing and providing support for applications. Will handles custom applications and the KTL suite of products. He has worked in the GP channel for over 15 years on integration and customization to Microsoft Dynamics. Will has extensive knowledge of Visual Basic, Visual Basic for Applications, MS SQL Server T-SQL, Crystal Reports and SQL Reporting Services. Will also works with the Microsoft .Net framework, including WPF, Web Services, Desktop Applications and Web Application development.
