This morning I have arrived back from Directions 2009 in Austin, Texas. Directions was a fantastic conference with a great setup at a incredibly beautiful location. The program was packed with great sessions and I had lots of networking and feedback from partners on Client Extensibility for the RoleTailored client.
I have learned a lot from our partners, for example about licensing requirements that partners have in order to run a viable business on “Business Data Visualizations”. A big Thank You for all the feedback and inspiration!
For the restless reader (“in a few words”)
 |
Download the presentations an supporting material on Client Extensibility:
|
It was my great pleasure that I had been invited to present two sessions about client extensibility on the last day of the conference – the Deep Dive day. And because I have been given this honor by our partners I brought “presents” for our partners.
The first session (introduction) started the general concept of extensibility in different places of NAV and I mentioned samples where the different extensibility mechanisms can be used together. The focus was of course what the Add-in concept is all about, and how it plays together with the other extensibility models (like client side & server side COM and exposed Web services). Then I went through three different categories of Add-ins: Value fields, Content renderer based on a value and “Business Data Visualizations”. For each of the categories I showed several Add-ins live. Special feature was of course my TreeMap control Add-in for Dynamics NAV. Then I talked about how to use Add-ins in page metadata, connect to data and integrate with application code.
In a (I believe) cool demo I showed how to take the TreeMap control that I had shown previously in the demo of an “Analysis place” for Customers and use it in a similar place for Sales Orders, connect it to data and triggers. Finally I demoed how to enable on-the-fly client distribution (see also Freddy’s blog) for related material.
The last part was about the impact of the Add-in concept on the current business with NAV and sketches out a framework for new business opportunities: “Business Data Visualizations”. The present was the announcement of the near availability of the TreeMap control.
In the second session (how to create Add-Ins) I began with a new page, and loaded it with with Add-ins. Then I looked at a Visual Studio solutions which contains the code of all the Add-ins – the Add-In Workshop. With the help of these code samples I walked through the different aspects of the Add-in API and pointed out the typical steps you take when you create a new one.
Initially I had planned to do a deep-see-dive on the classes and interfaces of the Add-in API. But on my flight to Directions I really got scared – scared, because this approach would have simply produced confusion and not have shown how simple it actually is to create an Add-in. So I decided instead to provide a diving suite for the second Deep Dive session.
Instead of spending the flight with watching movies, I wrote a set of Visual Studio projects and item templates that once will be part of a guided Visual Studio Starter Pack for Dynamics NAV RoleTailored client Add-Ins. Right now it contains two project templates (one for a Control Add-in project base on WinForms and one based on WPF). It also contains 6 Add-in class templates for typical Control Add-in interfacing scenarios. One of the Add-in class templates is tailored to WPF “Business Data Visualizations” and is actually based on the code I used to implement the TreeMap Add-in.
In another (I believe) cool Demo I created a new Business Data Visualization Add-in for a WPF map control of the US states, featuring heat-map visualization. I took me only a few minutes to build this new Add-in with the help of my Visual Studio templates – including hosting it in a RoleCenter page and a quick debugging demo.
As you can imagine, the present for the audience in this session was this Visual Studio template package. Quite a number of attendees queued up to get a copy of the template installer on their USB stick right away. And you can download it also here.
Aside to all the other great sessions we had lots of fun too …
The C/Siders live on the shore of Colorado river, together with great food and drinks, and the great spirit our our wonderful partner community …
Christian Abeln
Snr Program Manager
Microsoft DynamicsNAV
Yesterday afternoon, a colleague from Italy send me an IM asking for help on a customer scenario. The customer wants his users to see a strong warning sign attached to the item availability in the Item FactBox. The warning shall only be shown if the availability drops under a certain level. He had already experimented with the new Style property on NAV fields in SP1. He was able to show conditional formatting on the item availability field. But what the customer really wants is a more visual indication – yeah, a screaming warning icon!
On my way home in the train (public transport is just great for such tasks) I could not stop me from creating two little Add-ins as samples for that purpose. And because these two Add-ins nicely continue on the topics I have covered in part1, I decided to share this with you.
For the restless reader (“in a few words”)
|
A Control Add-in may listen to its context (“context binding”)
- The context for a control Add-in is provided through the Site.
- The Style is one of the properties of the Site, and the respective change event is also available.
- An Add-in can listen to changes in the context (Site) and reflect it in its visual appearance. I call this “context binding”.
|
And the result might look like this: |
 |
Combine simple data binding with context binding
- A control Add-in inherits the data binding of the field through the source expression in page designer.
- By implementing the properties Value and HasValueChanged it participates in data binding.
-
An Add-in can combine data binding with context binding for maximum data awareness.
-
And it might trigger custom events in business logic, for example an advanced lookup.
| And the result might look like this: |
 |
Download the full source code project here |
A train ride on the “Notification Icon Add-in”
First stop – “Vedbæk”: Check the requirements Requirements
The requirements for these Add-ins have been given to me:
- Used to show a notification icon in a FactBox.
- Show the standard field title
- Add-in number 1: If a certain condition as defined in Business Logic fulfilled then show a LARGE notification icon. Otherwise, show no icon.
- Add-in number 2: Render nicely in the flow of other fields, render the value aligned with other values, support the same field click and DrillDown capabilities as standard fields. If a certain condition as defined in Business Logic fulfilled then show a notification icon in front of the value. Otherwise, show no icon.
Let translate those requirements into the world of Add-ins:
- FactBoxes are read-only. Therefore I will only need to implement read-only data binding. And I only need to provide rendering support for the icon and a value for number 2. – a PictureBox and a Label control will do.
- A field title is shown be default unless we actively suppress them in code by implementing the AllowCaptionControl and making it return false. Therefore nothing needed here.
- Of course, a couple of icons are needed in the Add-in resources - not problem either.
However, we need a mechanism that communicates the condition. In a second version of the Add-in, we also want to show the value. Therefore, we reserve data binding for for the value and utilize the Style property of the field for the warning condition.
(A field can be bound through the StyleExpr field property to a Boolean variable which decides whether the Style as specified in the Style field property will be applied or not. The Add-in subscribes to the StyleChanged event and shows one of the notification icons based on the style it sees. Nothing simpler than that…)
- For the last requirement we need to adjust the height of the control properly, align the controls nicely to the right, be sure that we draw the value in blue and finally switch underlined on and off as the mouse hovers in and out of the field. Moreover, we should not forget to set the “Hand” cursor and listen to the click event plus trigger C/AL code.
That should be doable in one train ride. Let’s code it!
Next stop – “Kokkedal”: Build a simple Notification Add-in with “context binding”
A read only Add-in showing a right aligned Icon from the resources, based on the Style property of the Site - nothing simpler than that.
What is worth to mention here is the use of a Panel control as the layout container, which I return as the Add-in control. In the Panel I can easily dock the icon to the right such that it appears nicely aligned under the other values in the Factbox. A PictureBox control renders the Icon, and the Add-in must specify a proper maximum and minimum size.
The “context binding” is achieved by overriding the OnStyleChanged method which already delivers the new style. Please note: if the variable to which the NAV field property StyleExpr is bound to is false, then the Style will be “None”, otherwise it is the value of NAV field property Style.
[ControlAddInExport("SampleControl_NotificationIcon")]
[Description("Notification icon based on Style property")]
public class MyNotificationIconAddIn : WinFormsControlAddInBase
{
private PictureBox _picture;
protected override System.Windows.Forms.Control CreateControl()
{
Panel panel = new Panel();
Bitmap icon = StaticPicturHelper.StyleToPicture(Style.Attention);
panel.MinimumSize = new Size(icon.Size.Width, icon.Size.Height);
panel.MaximumSize = new Size(int.MaxValue, icon.Size.Height);
_picture = new PictureBox();
_picture.Visible = false;
_picture.SizeMode = PictureBoxSizeMode.AutoSize;
_picture.Dock = DockStyle.Right;
_picture.Parent = panel;
return panel;
}
protected override void OnStyleChanged(Style style)
{
_picture.Visible = (style != Style.None);
_picture.Image = StaticPicturHelper.StyleToPicture(style);
base.OnStyleChanged(style);
}
}
Now, that was easy – wasn’t it? Take a look at the Add-in Project in the download for this blog post. This also contains a modified “Sales Line FactBox” 9087 with little integration code.
Next stop – “Humlebæk”: Show the value, read only data binding and click with drill down
Now I want to show also the value for Availability in a similar way as a standard field does. I shall look and behave like a link, with mouse over effect and all that. As mentioned above, I just need to add a Label into the layout container and handle the mouse events.
More interesting is the data binding. I decide for a different base class (StringControlAddInBase), which has some support already built in, override the Value and HasValueChanged properties, and reroute the value that arrives at the Add-in to the Label control.
And what about the click event? A mouse click event handler for all the controls (Panel, Label & Picture) triggers the ControlAddIn trigger in the Business logic on Page 9087, which in turn asks for the Drill down.
void DoOnMouseClick(object sender, MouseEventArgs e)
{
this.RaiseControlAddInEvent(0, "");
}
The ControlAddIn event allows me to send a message ID with text data. But for this Add-in I really don’t need any discriminator for different events, therefore I can specify whatever parameters here.
And this is the code that handles the event in the server side business logic. It is the standard code that executes drill down on availability.
Last stop – “Helsingør”: Integration
It is time to utilize the Add-ins on the “Sales Line FactBox”. As usual, I copy the Add-in library to the Add-ins directory of the RoleTailored client and register them once with the Registration Tool.
In Page 9087 (“Sales Line FactBox”) I add a new field at the bottom for the simple Warning notification field and specify the first Add-in in the Control Add-in Property. The existing “Availability” field gets the second Control Add-in configured. Both fields get “
The variable “styleActive” is declared as a global Page variable and reflects is set by the business code for each record based on the item availability.
The fob files 9087.fob / .txt in the download material contain all changes for your review.
Ferry ride home and Wrap Up
The last ride home on the ferry gives me time to write up this little document package the project files so I can make them available to my colleague in Italy and to you through this blog post.
I hope this information is somewhat useful and gives you a little more insight into Control Add-ins for the RoleTailored client in Dynamics NAV 2009 (SP1).
You can download the project here.
And what have I learned from this small exercise? There are a few improvements needed for the future of our Add-in model in Dynamics NAV:
- An Add-in should be able to find out about the sizing of a standard field. Look at the distance between the fields “Availability:”, “Substitutions:” an “Sales Prices:” and you know what I mean.
- An Add-in should be able to trigger the default behavior for Lookup, Drilldown and Assist Edit such that it does not need to raise the ControlAddIn trigger for the same purpose and force the Business Logic developer to move respective code.
However, do not worry about changes in the future now. We have one important design goal for the Add-in framework: Existing Add-ins shall be usable without changes in later releases of the NAV product.
Christian Abeln
Snr Program Manager
Microsoft DynamicsNAV
Ps: If you have other suggestions for useful control Add-ins, don’t hesitate to contact me – I have a train ride and a ferry home every day ;-)
A Virtual PC image of Dynamics NAV 2009 SP1 is available for partners on Microsoft Partner Source! This image is already loaded with a number of cool Add-ins.
Dynamics NAV Partners: Go get it, and check it out!
Christian Abeln
Snr Program Manager
Microsoft DynamicsNAV
Recently I was giving a presentation about Client Add-ins and it turned out that the audience had already seen all available material about Add-ins. So what could I show instead? Live programming of a new Add-in was what I came up with. The Add-in should be a traffic-lights type of state indicator. This is a control that shows one of three images based the value that arrives trough data binding.
Of course, what happened when I tried to run the RoleTailored client with the first build of the new Add-in – it failed from an exception thrown by faulty code in the Add-in.
Please note: The Add-in is responsible for catching and handling any exception, which might occur in its code execution.
In order not to lose the rest of goodwill of my audience, I had to deliver a piece of information, which would nicely camouflage my blunder. I decided on showing debugging of an Add-in the NAV RoleTailored client.
Debugging of an Add-in in the client is very simple. After the client has started up all you need to do is to attach the Visual Studio to the process of the RoleTailored client.
For debugging compile your project with the “Debug” solution configuration.
Before you open the page that contains your Add-in attach Visual Studio to the process “Microsoft.Dynamics.Nav.Client.exe”.
Now you can monitor the program flow in your Add-in code. Go ahead and set breakpoints in the implementation of CreateControl or in your implementation of the IObjectControlAddInDefinition interface.
You think it is too cumbersome to attach the debugger from Visual Studio each time you run the client?
Then consider adding the following code line in the CreateControl method:
System.Diagnostics.Debugger.Launch();
This will fire up a dialog where you can pick the instance Visual Studio and for debugging and already breaks at that code line. Remember to remove this line, when you are done with debugging ;-)
After I had found the typo in my Add-in code with the help of debugging, I then could conclude the session just is time. So debugging of Add-ins while running in the RoleTailored client is a helpful thing. Give it a try!
Christian Abeln
Snr Program Manager
Microsoft DynamicsNAV
Yesterday I have recorded a “Hot Topic” on Client Extensibility and the creation of Add-Ins. Feel free to review the content here:
https://training.partner.microsoft.com/plc/details.aspx?publisher=12&delivery=269574
Now after Dynamics NAV 20009 SP1 has been released to partners, it time to start experimenting with this exciting feature.
I hope this 1 hour presentation will give you a good jump start into the subject of Client Extensibility and Add-ins for the Role Tailored client.
Christian Abeln
Snr Program Manager
Microsoft DynamicsNAV
(Please note: “Add-ins” are supported with SP1 for Dynamics NAV 2009.)
In my last blog post on “Add-ins” for the RoleTailored client of Dynamics NAV 2009 I have shown a very simple Add-in – no support data binding, no events. But already this one requires proper registration in the database, before it can be used for development and at runtime in your Dynamics NAV business application.
Before going into further samples for Client Extensibility with data binding and events I think it is a good idea to explain the concept of this registration in a little more detail. And even better: provide a tool for point-and-click registration for Add-ins.
For the restless reader (“in a few words”)
 |
Add-in registration basics
- An Add-in must be registered in the “Client Add-in” table (2000000069) with at least its name and the public key token of its signature.
- Optional: The file version of the Add-in assembly
- Optional: A description text
The registration tool
- The Add-in registration tool analyzes Add-in libraries, discovers Add-ins and inserts / updates the registered information in the Client Add-ins table.
- It provides a form in classic client which shows the list of registered Add-ins and provides a point-and-click type of file selection.
- And you can download it from here.
|
Name of the Add-in
This was the name thas had been specified as the parameter to the ControlAddIn Attribute. In this sample “SampleControl_InkEdit”.
[ControlAddInExport("SampleControl_InkEdit")]
public interface IMyInkEditControlAddInDefinition : IObjectControlAddInDefinition
{ }
[ControlAddInExport]
public class MyInkEditContolAddIn : WinFormsControlAddInBase, IMyInkEditControlAddInDefinition
{
...
}
or simply:
[ControlAddInExport("SampleControl_InkEdit")]
[Description("Edit and displays TabletPC ink")]
public class MyInkEditContolAddIn : WinFormsControlAddInBase, IObjectControlAddInDefinition
{
...
}
 |
With the registration tool you don’t need to look up the Add-in names in the documentation that came with it or in the source files of your Add-in projects. It will discover the names of all Add-ins in the libraries you register automatically. |
The Public Key Token
The requirements of signed assemblies allows Dynamics NAV to indentify exactly the assembly for an Add-in, regardless of the existence of other assemblies with the same name from other vendors. Please note: assemblies with the same name can very well reside in different subdirectories of the Add-ins directory. It also assures that only the assembly that has been signed by the same vendor like the one used for registration will be accepted at runtime.
The key pair for signing had been created with the Visual Studio project settings dialog or by using the
signing tool manually to create a key pair and perhaps even for the actual signing in dedicated signing procedures.
But how do you get a hand on the public key token for an Add-in assembly you have received?
sn.exe -T <assembly> is the answer to this.
|
With the registration tool you don’t need to analyze the assembly to get the public key token. It will find it for you and add the key automatically upon registration. |
The Version of the Add-in assembly
The assembly version of the dll file an Add-ins can be found is optional information. This will be very useful, as soon as several versions of Add-ins exist and need to be supported in the same NAV installation.
|
With the registration tool you don’t need to analyze the assembly to get the version. It will find and add the version information automatically upon registration. |
The Description
Now, this information is again optional and only useful for the developer for a better understand what a certain Add-in in the table is good for. At runtime this description is not used at all.
But where is it specified?
If an Add-in developer wants to manifest a description together with his Add-in implementation, the Description attribute is the right choice - as in the sample code below:
[ControlAddInExport("SampleControl_InkEdit")]
[Description("Edit and displays TabletPC ink")]
public class MyInkEditContolAddIn : WinFormsControlAddInBase, IObjectControlAddInDefinition
{
...
}
|
And of course, the registration tool will discover the description and add it automatically into the table upon registration. |
The Registration Tool
The Add-in registration tool adds point-and-click registration to the classic client. Is is composed out of a COM object that executes the assembly analysis Form 10000 which represents the user interface below. Codeunit 10000 is used internally to executes the COM object and update relevant registrations in the Client Add-in table.
You can download the Registration tool here.
I hope this is somewhat helpful to you.
Christian Abeln
Snr Program Manager
Microsoft DynamicsNAV
(updated: Sample project download: Sept 09)
(updated to SP1 CTP2 and release API: 07.June09)
Extensibility for the RoleTailored client also called “Add-ins”, is the feature which I personally love most in our SP1 release of Microsoft DynamicsNav 2009. Starting with this service pack partners have the possibility to add custom controls to the IU of the RoleTailored client.
These controls can be anything - from a static logo picture (not read from the database), to an edit control with rich formatting, to a web browser control pointing to sites relevant for the user or his role or to advanced data visualizations. These controls are truly hosted within the pages of the RoleTailored client and treated with the same respect as the build-in controls.
In this post I want to introduce the concept of Add-ins for the RoleTailored client and show the most basic code sample.
(We will have a few minor changes to the Interface when we release, and I will update my posts when it comes out.)
For the restless reader (“in a few words”)
|
Using a control Add-in
- Control Add-ins are contained in assemblies.
- Add-in assemblies must be placed in the “Add-ins” directory of the RoleTailored client.
- Each Add-in must be registered in the C/Side development environment with at least its name and public key token.
- For any field on a page the property ControlAddIn can be used to specify a custom control.
Creating a simple control Add-In
Download source code here |
The concept of Add-ins
Add-ins are contained in a DLL file, which must be a managed assembly. They are discoverable artifacts, which follow certain standards. An Add-in is the provider of a control that can be rendered and hosted in the layout of the UI of the RoleTailored client. Controls from an Add-in can only be used on pages and not on forms for the Classic client.
How to to utilize existing Add-Ins
The C/Side development environment must be made aware of an Add-In. All Add-Ins must be registered in Table 2000000069 (“Client Add-In”). The required information, such as the Control Add-in Name and Public Key Token, are typically delivered by the provider of an Add-in.
In an upcoming blog post I will make a tool available that allows you to select one or more assemblies and register all contained Add-ins.
The property ControlAddIn of a field on a page must set in order to select a certain Control Add-in.
Control Add-ins are supported for stand alone fields on a page. Please note the exception: Fields in a repeater are not supported yet.
How to write an Add-in
For the Add-in developer: What essentially is an Add-in?
- An Add-in is essentially composed by an interface which tells the RoleTailored client how it should communicate with the client. And a class which implements the interface. Both the interface and the class declaration must be equipped with certain attributes by which they will be discovered in an assembly.
- The assembly, which is a compiled Add-in library, must be placed in the “Add-ins” subdirectory of the program directory of the RoleTailored client (something like: c:\Program Files\Microsoft Dynamics NAV\60\RoleTailored client\Add-Ins). Also referenced assemblies might need to be copied there.
- The Add-in class works as a factory. It will instantiate a WinForms control and deliver an instance to the RoleTailored client. The control can really be any you can think off: a standard WinForms control , a 3rd party control, or a control you have developed yourself.
- The Add-in class will provide the plumbing between the control and the RoleTailored client. This includes routing back and forth of a value to show or edit, setting sizing and other layout options and firing a trigger in C/AL code. The Add-in class has access to a set of tools which allow it to further interact with the environment it is running in.
But don’t worry, so much about all the options right now. In this post i will begin with a basic sample and you will see how simple it really is to create an utilize an Add-In.
So, which tools do I need to create an Add-in?
- Any version of Microsoft Visual Studio 2005/2008 is good. For example Visual Studio Express for C# (which is a free download)
- The library Microsoft.Dynamics.Framework.UI.Extensibility.dll. You will typically find the library in the program directory of the RoleTailored client (something like: c:\Program Files\Microsoft Dynamics NAV\60\RoleTailored client).
The first Add-in Sample
1. Create a project for an Add-in
My first Add-in sample is a simple static picture control. The special characteristic is that picture data has been embedded into the control instead of having to retrieve it through data binding from a table on the server. This could be used for a static Logo. Instead of embedding the data into the picture, the control could load pictures from a local store or a Web Service instead – but this out of scope of my goal for this blog post.
I start by creating a class library in Visual Studio. In Solution Explorer add a reference to the library above. Then, in the Project settings I create a new signature file. If I had created Add-ins before, I might choose to use the same signature for all and select an existing signature file from another project.
Please note: It is required that Add-in libraries are strong signed. This requires that all referenced libraries are also strong signed. This is not an issue for any of the .NET Framework libraries. But you might find 3rd party libraries that have not been signed. You can sign those yourself with the signing tool of the .NET Framework.
2. Add a code unit for the interface and implementing class of an Add-in
Now I add one code unit to the project. In it I declare a public class with the [ControlAddInExport("name")] Attribute. The chosen namespace and the name of the class do not matter as far as how the Add-in is exposed. However, is the name you have chosen is essential for theControlAddInExport attribute. This name together with the Public Key Token of the assembly signature will be used at runtime to identify the Control Add-in.
using System.Windows.Forms;
using Microsoft.Dynamics.Framework.UI.Extensibility;
using Microsoft.Dynamics.Framework.UI.Extensibility.WinForms;
namespace AddInSamples
{
[ControlAddInExport("SampleControl1_StaticPicture")]
public class MyStaticPictureControlAddIn : WinFormsControlAddInBase
{
}
}
The class is derived from one of the Control Add-in base classes for the WinForms Display Target – which represents the RoleTailored client. These base classes can all be found in the namespace: Microsoft.Dynamics.Framework.UI.Extensibility.WinForms
Because my picture control Add-in does not show any data from the backend server and does not communicate with it, I have chosen the base class WinFormsControlAddInBase, which has no pre-built support for any of these behaviors.
In follow-up posts we will see how other base classes and interface can be used to declare the way an Add-in communicates with the RoleTailored client. Interfaces will play a much stronger role when it comes to Add-ins for multiple display targets and custom methods, properties and events – in future releases.
3. Implement the Add-in interface
Next I need to provide an implementation for the abstract method CreateControl. This is the place where I instantiate a PictureBox control and load it with an image, that I had added to a resource file in the project.
[ControlAddInExport("SampleControl1_StaticPicture")]
public class MyStaticPictureControlAddIn : WinFormsControlAddInBase
{
protected override System.Windows.Forms.Control CreateControl()
{
PictureBox pic = new PictureBox();
pic.Image = StaticPictureResources.Logo;
return pic;
}
}
After compilation of my project I already have a fully functional Add-in. But we still need to fine-tune it a bit until it looks good:
4. Add special sizing and preventing the field title
Two modifications should be applied:
- This control should never have a field title
- This control should always be sized to the picture content
Modification 1 is achieved by overriding the virtual property AllowCaptionControl
public override bool AllowCaptionControl
{ get { return false; } }
Modification 2 is done by setting the MinimumSize and MaximumSize of the PictureBox control.
protected override System.Windows.Forms.Control CreateControl()
{
PictureBox pic = new PictureBox();
pic.Image = StaticPictureResources.World;
pic.MinimumSize = pic.MaximumSize = pic.Image.Size;
return pic;
}
Perfect ! Now we have a static picture, by default without a title and sized to the original size of the embedded picture.
You should take the tutorial in this blog as a sample of non-data bound content from any source on a page in the RoleTailored client of Microsoft Dynamics NAV 2009.
My next blog post will show how to create a custom text box, bound to data.
Stay tuned!
Christian Abeln
Snr Program Manager
Microsoft DynamicsNAV
Directions EMEA last week was fantastic! A big thanks to the organizers!!! I had the great pleasure to present some new features in Dynamics NAV 2009. Now we all wait for the official Statement of Directions, until we can share the details in a public format.
Funnily enough I had even seen a blog post flashing up, which talks about some of the new hot topics. It had to disappear … (but do you really believe, the Internet ever forgets?)
Nevertheless – stay tuned!
Christian Abeln
Snr Program Manager
Microsoft DynamicsNAV
For a while now I wanted to start blogging about DynamicsNAV technical topics and by that hopefully help our great community around Dynamics NAV to be even more successful.
A number of new and improved features are usually appearing in every software release – this seems to be the nature of the software business. But this time I am really enthusiastic about what we have added - so I can’t stop me from telling the world.
Stay tuned!
Christian Abeln
Snr Program Manager
Microsoft DynamicsNAV
