Well the results are in and I have to say that some of them are not quite as I expected!

I closed the survey a while ago with the intentions of writing up the results straight away but as usual work pressures and the daily grind helped by getting in the way.

Well in that time we had a grand old total of 130 responses to our survey so a big thank you to everyone that took the time to answer.

Question 1 - What version of Microsoft Dynamics NAV are the majority of your customers on?

Ok, so firstly, and a little worrying was that about 4% of you still have the majority of your clients running 3.70. Now I loved 3.70, but come on guys, there have been many different flavours of NAV since then and it really is time to get the upgrades kick started!

Just over 26% of you were running either NAV 5.0 or NAV 5.0 SP1 with 23% of that combination running the SP1 version of NAV 5.0. Still, that is quite a high number as the move from 5.0 classic to NAV 2009 classic really isn't much of a step to be honest.

NAV 2009 SP1 was the clear front runner with over 38% of you having the majority of your clients on this with R2 creeping just over 15%

NAV 4.0 (including all SP's) and NAV 2009 (non R2 and SP1) were neck and neck with just over 7% each.


Question 2 - Have you only ever developed in Microsoft Dynamics NAV (Navision)?


The result here was quite interesting. I had thought the result would be something like this but I was surprised to see that just shy of 70% of you responding to this post had only ever developed in Microsoft Dynamics NAV. Now for me this is something that Microsoft must then take quite seriously. I mean you want to protect this 70% of Dynamics NAV developers quite closely in terms of skill sets, especially if only 30% of you have developed in anything else other than NAV.

I have been to a few Microsoft events and meetings this year, and it is clear to me that Microsoft are taking this fact quite seriously. I think when they released NAV 2009 they had underestimated the fact, let's say, 70% of us are comfortable in a NAV application domain and not comfortable being stretched outside of that. Speaking to other Partners they would agree with this sentiment.


Question 3 - Are you primarily running - RTC or Classic Client?


Well I wasn't surprised by this result. However, I think if you spoke to someone at Microsoft they'd be quite surprised! Over 84% of you are primarily running the Classic Client. That is not great news for Microsoft seeing as how the RTC has been out for some time now. So why is this? Maybe the change over is too hard for a number of Partners? Perhaps they are struggling to convince their clients to dedicate time to the move? We would also fall in to the Classic Client category, although we are working hard towards the RTC. Perhaps some of you are waiting for NAV 7 where you know you would have to do a small amount of re-engineering even if you were on the RTC now - particularly with regard to reports.


Question 4 - Do you have any experience in any of these products in addition to Microsoft Dynamics NAV (AX, CRM, GP, SL)?


Well I'm pleased to report that nobody had any experience in Dynamics SL! Ok, ok, not big news. 11 and a bit percent of you had experience of GP with nearly twice as many as that having experience of AX. The clear front runner was Dynamics CRM with over 66% of you having experience with CRM. This would suggest that Dynamics partners, and particularly NAV partners are starting to look to provide CRM. We definitely fall in to that category where I work and deploying/developing CRM is not as tough as some might think. Interestingly, these days you'll here Microsoft say "if you want Enterprise go for AX" however this would suggest that most NAV Partners have very little experience of AX and moving to such a different platform is simply not an option.


Question 5 - Would you say that you are a capable developer in Visual Studio?


65% of you answered No to this question. I'm not sure how important Visual Studio is to NAV these days as it appears that the replacement of C/AL is not going to happen at present and it is here to stay for now. Where Visual Studio is great is where you really want to get in to the Web Services, SOA and custom add-ins. On the latter, custom add-ins are a great feature of NAV, but I would suggest that most Partners at present are waiting for Microsoft and their developers to bring these to us. Most NAV developers are not capable in Visual Studio and as such are not comfortable, or have the time (or company budgets) to up-skill in this area.


Question 6 - Do you worry about the future of C/AL code?


It was a dead heat with 50% of you worrying and 50% of you care free about the future of C/AL. Only recently have Microsoft started to say they are not working on replacing C/AL. This is a different message to a few years ago. I think Microsoft are likely to put more time in to the core development environment rather than replacing the language. I think they will add to C/AL, such as the ability to overload functions, however I for one am not worried about the future of C/AL. It will take some time I think for developers to relax about it though...


Question 7 - Have you developed any applications using the Dynamics NAV Web Services?


Over 66% have developed applications using the Dynamics NAV Web Services... That's a bit worrying seeing as how 65% of you weren't feeling capable in Visual Studio! Perhaps you were doing everything in Java?! ;o)

Question 8 - How many users would you be comfortable to put through a NAV service tier instance?


My word I was looking forward to the results of this question! I have heard so many different numbers from different Partners. And of course, it does depend on your servers, setup, NAV vertical market etc. However we had a real mixed bag. I spoke to someone at Microsoft recently who told me on an average install they tested on they were getting a ball park of 40 users through an NST instance with plans to raise that to 80+ in the future! WTF I here you cry?! I know... I thought that too. This is a classic case of Microsoft living in their own bubble. Realistically we can't get anywhere near those numbers and I have tested this A LOT!


So what figures did this question throw up... Well... Just shy of 20% (one fifth!) of you would put somewhere between 1 to 5 users through an NST instance with just over 23% of you opting for 16 to 20. I personally fall in to the 11 to 15 bracket... I'm a cautious fellow. 30 and a bit percent of you were happy with 25+, however I prefer to think... you haven't tried it... ok only joking...


Still though it is quite interesting that circa 20% would go for 1 to 5 users and circa 25% would go for 25+.


I am still none the wiser.

Question 9 - Have you ever installed the 3 tier on 3 computers?


Another dead heat with 50% having struggled through the 3 computer install and 50% of you sticking for 2 computers... Pleeeeaassse go for 3 computer installs if you haven't. There are so many benefits, although you may take a year off your life initially trying to get your first install working... ;o)

Question 10 - I find the new MSDN approach for NAV help very useful?

Clearly the new MSDN approach has been well received with over 52% of either strongly agreeing or agreeing with this statement. Actually less than 8% of you disagreed with the sentiment with the rest of you not fussed wither way.

Question 11 - Do you find your PSAM to be useful?


Over 69% of you did not know what a Partner Services Account Manager was with only 12% of you having access to a PSAM.

Question 12 - Do you have access to a TSAM?


Over 69% of you did not know what a Technical Services Account Manager was with 20% of you having access to a TSAM. I was surprised that more of you had access to a TSAM than a PSAM as usually a PSAM costs you nothing and often you are having to pay for a dedicated TSAM.

Question 13 - I have found it difficult changing over to the new 3 tier architecture?


50% of you agreed with this statement with over 30% of you neither agreeing or disagreeing with this statement. That left 20% of you not agreeing with this statement - presumably that must be either people installing only over 2 computers or people providing ISV re-seller solutions?

Question 14 - Do you read any of the articles and blogs on the websites below?

As you can imagine with their being quite a few options to answer here there was a good spread so I thought I'd just mention the top 4.

1) Waldo's Blog with over 12.4%

2) NAV Team Blog with over 11.8%

3) Mark Brummel's Blog with just over 10.8%

4) Freddy K's blog with just over 10.2%

Question 15 - I spent quite a bit of time updating my skills when NAV 2009 was released?


61% of you strongly agreed or agreed with this statement with only 8 % of you disagreeing with this statement. This is an area I think Microsoft could have supported the Partners better in. It was quite a shift, not an impossible shift, (especially not for us super smart NAV boys and girls) but it was more than we'd been used to over the years and there wasn't a great deal of readily available support out there. Thank God for forums such as mibuso and dynamicsuser where we could help each other out.

Question 16 - I am confident about the future direction of Microsoft Dynamics NAV?


14% of you are not confident with the future direction of Dynamics NAV. I found this number to be a lot lower than I was expecting, but I was pleased to see that over 77% of you either strongly agreed or agreed with this statement. We are a positive bunch!

Question 17 - Do you hold a current Microsoft Dynamics NAV Qualification (Microsoft Exam)?

Well we're a qualified lot with over 86% of us holding a current qualification!

Question 18 - I find PartnerSource useful?


Surprisingly 65% of you find PartnerSource useful. I personally find it useful if you can find what you are looking for. In general Microsoft websites, like PartnerSource, MCP etc are quite bad. 35% of you agree with that sentiment.

Question 19 - I keep my clients up to date on the latest Dynamics NAV hotfixes?


Well, well, well. Only 29% of us keep our clients up to date on the latest NAV hotfixes. With a big 41% of you either disagreeing or strongly disagreeing with this statement. Why is that? Is it the hassle of rolling them out and testing them to all your clients? Is it that they are quite frequent at time and you'd prefer less of them with more fixes contained?

Question 20 - How many years experience do you have with Dynamics NAV?

Well it turns out that you can make a career out of Microsoft Dynamics NAV. Over 34% of you who replied to this question have been in the game with Navision for more than 10 years. I am also one of them.


62% of you have been working with the platform for 3 to 10 years. Still not a bad showing there.

Read more...

I'm not 100% sure how successful this is going to be but I thought I'd give it a go. It is entirely anonymous and I hope you will find the time to answer a few small Dynamics NAV questions I have put in to this little survey.

Thank you if you do take the time to give some answers.

Here.

Please click here to take the first ever SoberSmarties Microsoft Dynamics NAV Survey

Read more...

On the 29th and 30th September 2011 in Antwerp (Belgium) I attended the first ever NAV TechDays conference.

Primarily this conference was to focus on NAV 7.0 and on the whole it delivered exactly what I was expecting, if not more...

Unfortunately there were a number of sessions where a non disclosure agreement had to be signed, and as such that means I'm not allowed to blog about those sessions. Having attended all of those sessions I really was a little perplexed as to why we can't write or speak about them to other people. If anything I would say that I hope next time there is a NAV TechDays conference (and hopefully there will be) that this restriction is not put in place...

Ok small rant over.

Now most of what I write here will have to be based on the opening keynote as I'm allowed to blog about that. So what can we expect from NAV 7.0... In short... A LOT! Well firstly, it looks like it will be called NAV 7.0, rather than say NAV 2012. To be honest, that makes lots more sense and I never quite understood why NAV 2009 wasn't just called NAV 6.0.

So here are the bullet point headlines for you...

• The service tier is finally going to be 64 bit! This in theory should mean that we can make more connections to the service tier (although just making it 64 bit doesn't necessarily mean that we will be able to instantly make more connections - it's not quite as simple as that).
• There is also only going to be one service now in NAV 7.0 and not 2 separate services for RTC and Web Services as we have today.
• COM Automation is to be replaced with .NET Interop on the service tier.
• Full Unicode Support in the same database! At long last... this has been well over due and will allow us to negate our previous problems with codepage issues.
• There is finally a new and improved debugger, and a lot to write home about here. First off there is a new 'break on error' and for once the variable values will not be cleared so we can actually examine local variables etc. Not only that but we will be able to walk back through the call stack and examine those variables as well! There will be a new "break on action type", for example when an insert happens on a certain table. We will also be able to debug directly in the RTC. Not only that but we will be able to chose which session we debug. For example you can choose to debug a particular users session, or another cool option was the 'next session' to call the code you were wanting to debug. Finally we can at last choose to skip Codeunit 1 when debugging. We've all been there trying to step through endlessly Codeunit 1, and finally our prayers have been answered! Oh and I forgot to mention that breakpoints can be set to be conditional, so for example if x > 0 then breakpoint is activated... At last... Us developers look like we'll get a debugger that we deserve! Oh and on top of all of that you can debug a particular session without it locking out other users, so effectively allowing us to debug the live servers...
• There will be a NAS replacement delivered in NAV 7.0 and a new job queue. Finally this new job queue will be multi-threaded. We will be able to have, in theory, an unlimited number of job queues as well as a new MMC to administer all of this. A new 'Post in Background' option was also demonstrated posting a Sales Document via the Job Queue.
• We were shown a new Object type called "Query". I would predict that Microsoft have big plans for this little object and would predict that this object type will eventually be able to be re-used in reports and report design. This new object type will execute a single SQL query to return the data as opposed to the "loopy loopy" way we have seen happen in the past. In this new Query object we will be able to include all columns, or at last, select individual columns. It also uses terminology in its designer to build Joins, similar to what we are used to writing in normal SQL queries (inner join etc). When you run the Query object it displays a simple Page displaying your returned data. At this point you currently would have the option to send the data to a recipient or to get the data in to Word or Excel.
• NAV 7.0 will move towards the Office XML format and do away with COM...
• NAV Portal Framework (NPF) for SharePoint 2010 - this was, in my opinion, the absolute highlight of the whole 2 days. We had been promised this ability to have NAV Pages rendered in SharePoint. It is one of those things that makes absolute sense as an evolution with the new 3 tier architecture but I always felt that we would be left wanting. Well from what I saw I can say that Microsoft have truly delivered here! We were shown NAV Pages rendered and fully interactive in SharePoint 2010. It was... if I may say... very sexy! There are 2 options when it comes to getting your Pages in to SharePoint and these were to either have URLs to NAV application Pages or to build web parts in SharePoint to start building a Portal. We were told that currently 99% of Pages were done and Microsoft were aiming to get that to 100%, and I for one believe them. What is stopping them getting that 100% right now. From memory I believe they were still working on Assist Edits, Drill Down C/AL Trigger and the Navigate Page Type. Menusuites will not be supported. A point to remember is that NPF must be in SharePoint 2010 if you want to get this working as earlier versions of SharePoint don't support modal pop-ups... So bear that in mind for any SharePoint implementations you're currently undertaking or about to start. It was stressed that this SharePoint UI was not based on the NAV Web Services and was all handled within SharePoint. Not sure what that really means or if it will really affect us. I am however going to be interested in how easy it is to install and set all of this up. We were in fact shown, very quickly, the installer where you simply set a number of parameters to get all of this working... I hope it will be this easy! Microsoft were keen to stress that this was designed to be used by 'lite' and 'occasional' users and as an Intranet and not Extranet Web Portal. However, I do not, for one minute know how they can say that or why they would say that?! Firstly, who doesn't want a thin client version of NAV available? Also, why should it only be Intranet based - actually the demonstration we were shown I believe was connecting via an Extranet, so it must work! I racked my brains about why they might say this. Then the old cynic in me came out. There were, I believe, at least two vendors at TechDays pushing their own web based solutions for rendering NAV Pages in a web browser. They must have paid to have their stands in the Expo area and it would be pretty embarrassing for the organisers to show a solution that would make their fantastic products not really required going forward. But in my opinion this is exactly what happened and I for one would prefer to wait for the NAV Portal Framework to be delivered... I will write a future blog post about the NAV Portal Framework and my thoughts on this very soon... No idea on how the licensing will work with NPF at this stage...

That's probably all I'm allowed to blog about.

So what did I not see that I hoped might be mentioned...

• A new installer and tools for installing the NAV 3 tier environment, particularly across 3 computers. Maybe this will happen as it could be similar to the installer shown to us for the NPF.
• Any new ways to handle automatic fail over of NST instances and a different way to handle client connections to the NST from the RTC - load balancing, automatic failover to running NST instances should one instance stop and can't be restarted, and so on. This is such an issue for many of us and I would hope this "single point of failure" is addressed in NAV 7.0, but my fear is that it will be exactly the same.

So when will all of these lovely new developments and tools be released?! Absolutely no idea. There was no indication of a release date but my gut instinct is that it is a year away. I'm going to predict July/August next year... Personally, for me, it can't come soon enough!

An inspired SoberSmarties.

Read more...

In Part 2 of this 3 part blog marathon I am going to be following on from Part 1 of this blog and talking about the problems with CBD and defining a SoberSmarties CBD manifesto for a True Engineering Approach...

As you would have hopefully seen from Part 1 of this blog post CBD and re-use should make things a lot more cost efficient, easier to maintain, shorter development lifecycles and so on.

So if CBD was to be the holy grail then why did it evolve into the Service Oriented Architecture.

Well that's because as with everything that evolves, it is usually to fix previous problems.

There were a number of problems with CBD and these are listed below;

Lack of Standards
One of the major reasons why CBD was not adopted universally was initially because of a lack of standards. There were just too many different providers offering their own component standards. For example, Borland Delphi and thier use of object Pascal as DLL's, Visual Basic was promoting OCX's or ActiveX controls, Windows was using OLD, DDE, COM and DCOM (to name but a few), Java had their enterprise Java beans and so on. It should be said that all of that started to change for a number of reasons;

1) The development of CORBA as a standard for interoperability of components written in different languages and running on different platforms.
2) The promotion of Java an an object-oriented language with relatively straightforward mechanisms for producing software in packages to deliver different services.
3) The growth of the Internet and the World Wide Web, which has made it possible for people to make their software componenents easily available to a wide marketplace of potential re-users; for example, Web Services using the UDDI (Universal Description, Discovery and Integration) directory service to find services.

Lack of Expertise
Another reason why CBD struggled to take off was because of the lack of expertise and discipline when adopting such an approach. We usually begin coding applications after high level analysis has been performed. But this is not sufficient for a component based approach. We must break down the problem to its lowest level to identify reuse throughout the application. This requires a lot of knowledge and foresight, add to this the developers urge to quickly design and start coding and CBD will not work properly.

Choice of Project
Building the organisational structures to support reuse costs money, and that expense is only justified if the business can recoup some of that money. It has been said that there are four kinds of business which would be suitable for developing reusable components - clearly it's not suited to everybody. These four types of business are;

1) Large organisations which may maintain a massive information systems infrastructure and a portfolio of a number of projects which support business processes.
2) Organisations which may be producing hardware products that contain embedded software. For example companies such as Hewlett Packard.
3) Consultancy companies and software houses that develop software for external clients that have outsourced their IS development, particularly those companies in the same kind of business.
4) Large software product developers where components could be used across a large product range. For example companies such as Microsoft!

Hopefully the above shows that small one off projects in small businesses are unlikely to bring significant benefits in the long run, and therefore it would be very difficult to build reuse into their software development lifecycle.

Planning for reuse too late
Reuse needs to be planned into a project from the start and can not be something which is realised towards the end of the project (or even just after the project has begun!). Therefore, it is more often found that software which may have been reusable will have been incorrectly designed, so that we can not easily take it from the finished system. The people, tools and support, must be in place from the beginning of the project if reuse is to be supported.

Existing OO Design
As mentioned above, if reuse is planned too late, then more often than not, the code would have been designed and implemented in such a way in the final system, that is is not easy for developers to take it and use it in others systems.
For example, the coupling between different classes in an OO system can cause a massive problem. So often we end up implementing attributes and operations which tie them in to other classes in the particular application, of which they are a part of. Even if we have adhered to low coupling and high cohesion we can still find problems. For example, if the developer/analyst has split one piece of functionality between multiple use cases then this can lead to poor interaction coupling, and will prevent any reuse.

The NIH Syndrome
Another big reason why CBD was not taken up by everyone was because of the NIH syndrome, or "Not Invented Here" syndrome. This is a real problem and I myself have witnessed and experienced this problem. This can be very prominent amongst developers who particularly enjoy a technical challenge. Also some developers may have certain reasons for not trusting the work of others and can be often heard spouting off "... I don't trust other people's widgets - even those that appear to work, suit my purpose and are affordable - I want to invent my own widgets anyway."
This kind of thinking is something I believe we should take really seriously. Simple things like NIH syndrome can stop new technologies being adopted. Why re-invent the wheel? Let me ask you this ... if you want a new light bulb for your room, it does not seem very sensible to invent and build your own. Even if the knowledge and equipment are available to do so, the cost would be prohibitive.

SoberSmarties CBD Manifesto for a True Engineering Approach

Thou Shalt Characterise Objects

Components will be developed to have all the characteristics of objects (encapsulated, cohesive, polymorphic, well defined responsibilities, well defined interface) and so on... They will however differ from objects in the following 4 ways.

  1) Specialisation - the component will be a specialisation of an object. A component is an object, but an object isn't necessarily a component.

  2) Scale - the component will tend to encapsulate more than one object. They will be thought of as an aggregation of objects that exhibit a well known interface.

  3) Functional Responsibilities - the environment, within which the component lives will place certain responsibilities on it. These typically will be transactional control, persistence, and event handling that an object will not necessarily implement.

  4) Functional Limitations - the environment may impose restrictions on the functionality of the component. This may include such things as creating new threads of execution, or accessing the network and file system.

The component will be thought of as a sub-system encapsulating the functionality of more than a single class. This rule will allow the component to have a clear use (cohesiveness) and hence ability for reuse within other systems.

Thou Shalt Stand on Thy Own

The components developed should be able to exist in isolation (low coupling) from other components, except the framework components they may use.


This also means that a component can be developed, tested and deployed in complete isolation to other components within the system, even if it seems unlikely that the component ever will be deployed in isolation it should still be possible. This is important for testing and quality.


Thou Shalt be Common
The components in the software business should all have a fixed and common interface. All components in the software business will have a common interface, and this interface can be extended. This will in turn help the business adopt a true engineering approach. Mixing components with different interfaces will pose a problem to this true engineering approach. We can think of this as the plug in our home. In our houses (in the UK) we all have three point plugs. Most appliances use them, but some do not. For example, your electric toothbrush or electric razor will use a two pin plug. Now you have to go out and by another plug to convert your two pin plug to work with a three pin so you can use it in your house. This is a good analogy of the problems which could be faced when mixing the different interfaces in a component system.


Thou Shalt be Described
The components in the system shall be self describing. The interface to a component will describe enough to make it possible for clients to know how to use it. To be meaningful a component definition must involve the interface to that component since it is the interface that clients use to "work" the component. If the interface to a component can not be described then the component must be looked at as to whether or not it can be effectively re-used. If a component can be easily described then it will help promote re-use and in turn a true engineering approach will follow.


So here endeth part 2 of this 3 part blog... Next up we'll be taking a look at the evolution of CBD to SOA and the problems with CBD that a Service Oriented Architecture is trying to address. We'll also take a look at SOA and how it relates to Dynamics NAV.

Read more...

I'm always up for a get together with fellow peers and to "invest" a few hours talking NAV technology and the future of our beloved Microsoft Dynamics NAV.

Some of you may already know that on the 29th and 30th September 2011 in Antwerp (Belgium) the NAV TechDays conference will take place.

There are some great topics being discussed over the 2 days such as...

• Administering NAV 7.0 with Windows PowerShell 2.0
• Bug-free development in NAV
• Developer Tools
• Form Transformation
• Integration (CRM connector, Webservices, Windows Phone 7...)
• .NET and NAV Interop
• Reporting in NAV 7.0
• and many more!

Registration for this event, including agenda, speakers etc can be found here.

Hope to see some of you there!

SS

Read more...

Hello everyone!

So... if, like me, you "enjoy" reading all of the literature that Microsoft produce around Microsoft Dynamics NAV then you may have seen a few sentences on SOA, or if you like using words, the Service Oriented Architecture. So what exactly is it and why should we care?

In a 3 part blog marathon I am going to detail my thoughts on this subject. Now, I have to admit, there will be quite a lot of words (so if you prefer code only blog posts then this isn't for you... but stick with it if you can - you might learn something!), so that's why I've split it in to 3 parts! These 3 parts are as follows;

Part 1 - Component Based Architecture, where it came from and its advantages...
Part 2 - The Problems with CBD and a CBD manifesto for a True Engineering Approach...
Part 3 - CBD to SOA and NAV...


Well before I go on to talk about Service Orientation I think it is important to understand where it has come from. And for that, we must take one step back to Component Based Development (or Architecture if you wish...)

Ok, so firstly, what was (or is) the aim of component based development. Well... it was to allow off-the-shelf components to be quickly assembled into applications with functionality that does not need to be expensively re-implemented for each new system.

When the software industry first started there was a lot of 'Chaotic Development' taking place. There was no real structure to identify to the developer what should be done, or shouldn't be done. This is where 'Structured Development' entered the software industry. Structured analysis and design allowed the developer to decompose a particular problem into its smaller constituent parts. These smaller parts were further decomposed until the parts were simple enough to be implemented. 'Structured Development' meant that it was now possible to enter an age where complex programmes were now implementable (and testable!).

There were problems with the 'Structured' approach in the sense that the final implemented solution comprised of the decomposed parts, which were decomposed at the beginning of development. Therefore, if the requirements should change at any time then this initial decomposition would become invalid, or no longer be required. Another problem was the fact that this process didn't end up with code that modelled the real world problem domain accurately. This in turn has lead to problems in maintainability, extensibility, readability (and so on!) of the software.

An 'Object Oriented' approach began to emerge which would answer the problems of the 'Structured Approach'. The real advantage that object based solutions held was the clear traceability between analysis models of the problem domain, the designs, and the implementations of a solution. Now programmers were not having to design solutions around the way that the computer worked but instead could model their solution around the real world problem domain. This in turn helped lead to more maintainable, extensible and better documented systems.

Object Oriented systems have not been without their problems too. The technology itself has a sound basis but it requires highly skilled staff to get the object orientation to work correctly. To find correct abstractions proved to be very difficult for large systems because of the scope that these abstractions were having to cover. One complex object model had to suffice for the whole system and this lead to less robust software with poor extensibility and modifiability.

This is where the 'Component Based' Approach fits in.

So to re-cap we had;

+ Chaotic Development (with functional decomposition, functions with arguments and results)

+ Structured Development (modelling problem domain, encapsulating data and functionality)

+ Object Oriented Development (reduced coupling, abstracted interfaces, framework and business logic distinction)

+ Component Based Development (about to talk about!)

A Whistle Stop Tour of a Component

A component can be thought of as providing an individual set of functionality for a number of different applications. A component is an encapsulated, independent and physical part of the system. In component based systems then a complex system may consist of a number of small components, or cohesive systems. I like to think of a component as an object in a really smart suit! It's all dressed up and ready to go interact with the world!!

A component will consist of 4 essentials;

1) Component Interface - for Data Transfer, Commands and Events
2) Component Encapsulation - clients can only see the generic interface
3) Component Specifics - the essential business logic in objects
4) Component Infrastructure - housekeeping for persistence, lifecycle etc.

CBD - a True Engineering Approach?

For years people had argued as to whether or not software engineering was a true engineering approach. For example, when construction engineers build a building they may follow the same set of designs used for different buildings. They also don't make the bricks, or iron girders etc to construct the building. They re-use bricks which have already been made and tested by different suppliers. From learning about errors in previous constructions then they make improvements to the next buildings constructed (or go to a different supplier!). They are not constantly having to re-invent the wheel as we had previously been doing in software engineering. Utilising CBD it could be argued that software engineering is now closer to a true engineering approach.

One of the advantages of CBD is that of re-use, through the use of Object Orientation. With the advances made in rapid application development, shortened development times, and implementation times are becoming so fundamental that we must all start to re-use, rather than treating it as a nice to have.

So how do we define re-use?

"the ability of software elements to serve for the construction of many different applications"

[Meyer, 2000]

Of course, by re-using software components this in turn will save time and money during the development phase of a software project. So, the more components we can re-use the less code we are having to write. This in turn helps aid the ever more popular RAD approaches to software development.

Take the quote below for example;

"Lim (1994), describing the situation at HP, cites improved productivity, faster time to market for products, fewer defects and a return on investment of 215% on one project and 410% on another."

[Bennett et al., 2002]

This is turn means that the more applications we can re-use a component in then the more valuable that component will become to our business. By adopting a CBD approach a business will be able to re-use across the whole enterprise.

Component based development also enables developers to customize applications without high costs and longer development times. This could, in turn, allow a business to change their processes fast and according to conditions within their business at a particular time - and this then gives them that competitive edge.

In the early days IBM adopted a CBD approach for re-use and in those early years reportedly had re-use support centres that maintained libraries of roughly 500 zero defect components in Ada, PL/X and C++.

As you'll see from the above, re-used software components also have fewer bugs as they are being used more widely and more often. This in turn helps uncover errors and have them corrected along the way. Although this may not seem inherently important I believe that the elimination of bugs from software is an extremely important issue as highlighted in the quote below;

"Find and fix 1% of your software bugs, and 90% of your system problems go away..."

[Horowitz, A.S, 2003]

Finally, what do fewer bugs in the software imply? You got it - lower maintenance costs!

Congratulations! You've reached the end of Part 1 in our 3 part blog marathon! Next up we will be discussing the problems with CBD and I'll be detailing a CBD manifesto for a true engineering approach... Until next time......

Read more...

Ok, so we're not all like this guy...

It's been quite a while since I blogged... Times are really busy at work with clients implementing NAV just in time for the summer!! In the current market I can't complain.

I have some more techy blogs to post but thought this post would amuse some of you and these are simply some thoughts on this and that NAV.

I have worked with NAV for slightly shy of 10 years now. In that time I have seen many developers, all with different styles. Some of them have lasted, and some of them haven't. It got me thinking... What type of NAV developer am I and what types have I seen. This is meant to be light hearted and not taken too seriously... But have a read. Which category do you fit in to? Are there any types you have come across but I have missed here? Let me know...

The Resistor - This guy is old school. He has been working with NAV since "the good old days". He liked the DOS version best. He has never liked it since Microsoft took over - and he is a massive protester against the Role Tailored Client. For him it is all taking a step backward. A brilliant C/AL programmer, he is not interested in renewing and updating his skills. He will cling on to the old days until the end. Everyday he looks at his free Navision clock we all got sent many years ago - he didn't throw his at the mermaids in Denmark like some people did. Apparently.

The Talker - This guy has been around NAV for 3 to 5 years. He has heard a lot of people talking about problems and how they have fixed issues. However, they have not developed much C/AL or fixed many issues themselves. They talk a good game, and appear to know a lot, but when put under pressure they often come up short. Others will be blamed. The Talker does not last long in one job and moves around quite frequently - leaving a wake of dodgy, un-scalable and difficult to maintain solutions behind them.

Mr. Re-factor - This guy has learnt all about programming from a book. He knows the theory inside out. Often heard saying phrases like "high cohesion", "low coupling", "modularity" and so on. Spends most of the time re-writing everyone else's code. Much to their annoyance. Technically good, but finds it difficult to finish a task or get it to a level where he is happy for it to be delivered. Can quite easily turn 2 weeks work in to 3 months work. Nobody else understands it, and he hopes this gives him job protection.

The Buzz Worder - This guy is a developer but should probably be in sales. They are an average developer, but they are more interested in buzz words. They like to mention these buzz words to the boss quite a few times. This causes a nightmare for other developers as the boss keeps asking for these buzz words to be made a reality. Currently The Buzz Worder can be heard saying "The Cloud", "Dashboards" and "MVC"...

The Work Horse - This guy works his ass off. He will put the hours in when he needs to. He is technically a very good developer and is dependable. He is someone you want to hold on to as he is a genuine asset to the company. You would feel the pressure without him. He is capable of finding solutions and can be trusted to implement them.

Mr. Keep His Head Down - Sometimes you forget this guy is even there he is so quiet. He is a good developer and can be relied upon. You should really make more effort to speak to him, but as long as he has work to do he will get on with it ok. He is a bit of an enigma.

The SQL Boff - This guy has heard of NAV but wants to do everything in SQL. Never happier than when he is seeing what keys can be removed from tables and whether or not he can change the settings of SQL. The SQL boff is not convinced by SERIALIZABLE and wants to use REPEATABLE READ. He often ends up locking the whole database so nobody can save their objects. 

To be honest nobody is any of just one of the categories above. We will all pick up some of these traits from time to time. However, it is likely that you fall closer to one or two types than the rest. 

Read more...

In a series of SoberSmarties Posts I'm going to be taking a look at some of the new functionality available in Microsoft Dynamics NAV 2009 R2. There sure is plenty to look at, but in this first post we are going to start off relatively easy by looking at "Interop".

So when I saw some of the new features available this one immediately stuck out to me. Firstly because I wasn't quite clear what it meant, and secondly, I hoped it meant we could now plug in .NET assemblies to our C/AL code...

Firstly, what does it mean? Well I looked it up on the big wide world of the interweb and found the following;

Noun

interoperability

1. The capability of a product or system to interact and function with others.

Well I'm definitely up for a bit of that in our C/SIDE development! So how do we do it... Well luckily my second assumption was correct... *drum roll* - We can now consume (yum yum) .NET assemblies, whether they be Local or from the Global Assembly Cache (GAC).

Secondly, why have Microsoft made this available to us? Well NAV 2009 already runs in .NET anyway, so it probably wasn't too much work to open this up to us so we can get at .NET assemblies.

So where do we begin. Well firstly, let's take a look to see if we can see anything different in our C/SIDE environment (that we know and love so well).

If we take a look in our variable declarations we can see a new type called DotNet - not sure why, but I like how it is actually called DotNet as opposed to .NET.

[click picture for larger version]

When I select this and hit the AssistEdit on Subtype then I am presented with the following Form... Which actually isn't very interesting. Yet.

[click picture for larger version]

Perform the lookup next to "Assembly" and now we are presented with another Form. Mine looks like this but you may have something in the "Dynamics NAV" tab.

[click picture for larger version]

So what do these 2 tabs actually represent or mean on this Form? Well just look below for an answer;

--- "Dynamics NAV" - this option is used where the assembly is Local. This assembly will be found in the Add-ins folder of your Microsoft Dynamics NAV client installation (on my Windows 7 machine this is: C:\Program Files (x86)\Microsoft Dynamics NAV\60\Classic\Add-ins)

--- ".NET" - these are all assemblies registered in the Global Assembly Cache or GAC.

So what are some of the big advantages of now being able to use .NET assemblies from within our code? Well firstly it opens up a huge number of existing .NET libraries for us to start having a play with. Also, if you have never done anything with .NET before you can start to become familiar with some of the libraries available. As much as I liked using COM, it isn't as safe or as easy to implement as .NET assemblies. But, one thing COM was, was fast. However, don't be concerned because brief testing shows that utilising .NET assemblies is just as fast as COM.

So let's see if we can get something working!

First off I have created a brand new blank Codeunit. I have saved it as Codeunit 90001 and called it "ProcessChecker".

In my OnRun trigger I need to declare some local variables. Note that the scope used is that of the NAV scope and it will call the Dispose method of the .NET variable where available.

Firstly I will call my local variable MyProcess. It is of type DotNet and next I need to lookup to find my .NET  assembly that I wish to use. I am looking for System.Diagnostics.Process which I know is part of the System assembly. It is also available from the GAC. So I need to select the ".NET" tab (as mentioned above) and look for "System".

[click picture for larger version]

Once I have selected this I am looking for System.Diagnostic.Process. Find that and click on "OK". You'll see the Subtype column now reads "'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.System.Diagnostics.Process".

Next add a local variable called _processID and make it of type Integer. Your variable declaration should now look like this;

[click picture for larger version]

So now what?! Well firstly we need to have a little chat about Instance types. If you already programme in .NET then you will be familiar with this, but if not then stick with it. Us NAV developers are smart guys and girls so this will take us 5 seconds to understand, and pass on to other developers, as we're friendly folk!

--- "Instance Types" - these need a constructor before we can start working with them.

--- "Static Types" - these classes don't have a constructor and effectively we can start calling methods, without creating an instance. But be careful as they are shared between ALL sessions and this is important to remember if you run this code on the Server as opposed to the Client.

So is our "MyProcess" variable an Instance Type? It is quite easy to find out...

If I look in my C/AL Symbol Menu at my Variable and have a look under Constructors, then I can see I have one called Process. This means I am dealing with an Instance Type and need to create and Instance of my class (an object) before I can use it.

[click picture for larger version]

If I was dealing with a Static Type then I would not see anything in my Constructors.

Next I must find a Method that can help me create an Instance for me to work with. If I look in Methods I ill find one called GetProcessById. Actually you will see 2 of them, with a different number of parameters being accepted. I will use the one that simply accepts the ProcessId and not the MachineName. You can use the MachineName version (or IP address) to get a process running on a different computer if you wish. If I look a bit closer I will see the following on my C/AL Symbol Menu;

You can see from the above that this Method will create an instance of type Process. If you look at the properties of the MyProcess variable you have declared you will see a new property called RunOnClient.

This does exactly what it says on the tin! If you set this property to Yes then it will run, and look for the assembly on the Client that is calling it. Note that means for Local assemblies they would need to be installed on every client. I recommend trying to use the Server where you can, but be careful when using Static type classes.

So what about the code. Well a screen shot of that is shown below.

[click picture for larger version]

You will, being a good developer, noted my hard-coded process Id. I apologise, but I was a bit tight on time. I looked this up in the Windows Task Manager and searched for Microsoft.Dynamics.Nav.Server.

So how can I call this. Well I can not call it from the classic client so I need to call it from the Role Tailored Client. Using good old Page 76 I have added a new action called Get NAV Process.

When I click this I get the following message displayed.

So there we have it. We have consumed our first .NET assembly and ran it in C/AL!

What else could we use this for? Well a few off the top of my head...

--- We could write a new Page and use Interop to monitor our Dynamics NAV Server(s)

--- What if we did something cool like this by Duilio Tacconi and got our RTC to speak to our users, or even read out the error messages to them?! I am tempted to put this in to a separate blog post......

--- anything else you can think of

Some Points Worth Remembering

+ Only runs using the new 3 tier platform - RTC and Web Services

+ Assemblies can be Local or in the GAC

+ You would need to roll out the local assemblies where you are developing as the design is handled through the Classic Client

+ The Add-ins folder of your NAV 2009 installation is used for any Local Assemblies

+ You can currently only use assemblies which are part of the .NET Framework 3.5

+ When selecting which .NET assembly to use, you will often be presented with a 32bit and 64bit version. The 64 bit version will have x64 shown next to it. Remember we can only utilise the 32bit assemblies at present.

[click picture for larger version]

+ Remember you can choose to run on the client or the server. You need to set the new property RunOnClient (default is false) to get it running on the Client. Use the server if you can as the performance is likely to to be much better.

+ If you are running the .NET assembly on the Client then you are likely to see a security warning message. You will get this the first time the .NET assembly is used, and this is per session. So when the user logs off and starts up the client again they will get this prompt again. The screen showing the prompt the user will get is below.

+ The security warning message above will not be shown if you are authenticating using Kerberos with your Service Principal Names and Delegation configured correctly.

+ .NET is case sensitive

+ There are a large number of .NET assemblies available, and I doubt Microsoft have managed to test every single one, so be prepared for some problems and don't expect to be able to use all of them!

Read more...

In a previous blog post My Dynamics NAV Christmas Wishlist for Santa I mentioned it would be great to have example Code Snippets that we could plug in to Visusal Studio 2008/2010. This way we can have template classes, methods and code blocks easily available to start coding and building all our fantastic apps...

Well it has taken me a bit of time, but I eventually got there...

Firstly, I must say that these snippets are a first attempt. I have been using them at work and do find them useful. However, please post your comments about any feedback, modifications or snippets you'd like to see and I'll see what I can do.

If you don't know how to install code snippets then please take a look at this link here - http://msdn.microsoft.com/en-us/library/wy5tazc9.aspx. It's very easy to install the snippets. Basically you just need to put them in a folder and point the Code Snippet Manager in Visual Studio to the folder where they live.

The code snippets included in this blog post can be downloaded at the following links.

NAV_AddFilter.snippet
NAV_CreateNewRecord.snippet
NAV_DeleteARecord.snippet
NAV_FilterArrayAddFilter.snippet
NAV_ReadARecord.snippet
NAV_ReadMultipleRecords.snippet
NAV_ReadMultipleRecordsAndLoop.snippet

Once you have installed these in Visual Studio, then to actually use them simply type "NAV" and through the power of Intellisense they should automatically appear, as shown in the screenshot below.

If you scroll down through the code snippets then a tooltip will appear explaining the intended use of each one. To copy the code block from the snippet in to your application then just hit the TAB key on your keyboard twice. I thought I was going mad when first trying to do this as I was only hitting the TAB key once!

When you have added a code snippet to your code then you will see a number of highlighted replacement points. If you hover over these then you will see a ToolTip describing what to do with each replacement point. If you change the first instance of a replacement point then it will automatically update the other instances in the snippet. For more information then please read - http://msdn.microsoft.com/en-us/library/ms172677.aspx

So what is the purpose of each code snippet delivered in this blog post? Well... an explanation of each is given below...

NAVAddFilter - This code snippet is used to add an additional filter to a filter array variable. The assumption is that your array is called filterArray and that it is already defined. Perfect for adding additional filters before retrieving your collection from Dynamics NAV.

NAVCreateNewRecord - This code snippet is used to enter a skeleton method for creating a new NAV record through your web service. It takes two parameters in the method and sets these to two fields. Change these parameters as appropriate. You will want to change the method name as well as the names of the fields you are setting. Change the web service URL as appropriate.

NAVDeleteARecord - This code snippet is used to enter a skeleton method for deleting a NAV record through your web service. It takes two parameters in the method, which are assumed to be the primary key values. You will need to change these parameters as appropriate. Change the web service URL as appropriate.

NAVFilterArrayAddFilter - This code snippet is used to declare a filter array and add the first filter to the array. You should use NAVAddFilter for adding additional filters to the array.

NAVReadARecord - This code snippet is used to enter a skeleton method for reading a NAV record through your web service. It takes two parameters in the method, which are assumed to be the primary key values. You will need to change these parameters as appropriate. Change the web service URL as appropriate.

NAVReadMultipleRecords - This code snippet is used to enter a skeleton method for reading multiple records from NAV based on filters applied. It takes one parameter in the method, which is assumed to be the filter value. You will need to change or add to this parameter as appropriate. Change the web service URL as appropriate. If you need to add additional filters then use NAVAddFilter.

NAVReadMultipleRecordsLoop - Pretty much the same as NAVReadMultipleRecords but contains a loop through the records returned from NAV in your Collection.


An Example of Implementing a Code Snippet

So now we know what each code snippet is supposed to do then let us look at using one of them. In this example we will implement - NAVReadMultipleRecords.

I'm going to assume that you know how to create a new class in Visual Sudio and that you have added a Web Reference to your Visual Studio project.

In the example shown below I have exposed Page 21 as a web service called Customers.

Next, in Visual Studio I have my class waiting for some code and I have added a web reference pointing to the web service I have just published above.

Next I want to add a method to read in a Customer from my Dynamics NAV database. So first thing I think of is... "I must have a code snippet for this somewhere - thanks SoberSmarties!!"

It's ok if you can't remember the name of the code snippet, as if you just type "NAV" they will all be displayed. Scroll down to "NAVReadMultipleRecords" and read the information flyout regarding this code snippet. It should look like the one shown below (click picture for full image).

Now, hit the TAB key twice... and you should see the code snippet added to your class as shown below. Click the picture below to see a clearer image of the code entered.

Hopefully you will notice on the code just inserted that you have some areas highlighted in colour. These are your "replacement points". If you hover over the replacement points then you will get a ToolTip of what to do and the purpose of this replacement point.

Now, higlight the replacement point "ReadMultipleNAVRecords" and change this to, "GetCustomersByCountry". Hit the TAB key and you will automatically be on the replacement point "myPublishedwsName". We published this as Customers so type in "Customers" into this replacement point. Hit the TAB key and now change the URL as appropriate. TAB to the next replacement point and you will now be on "myFilter", so change this to "CountryFilter". You guessed it, TAB again and change the "FieldName" replacement point to the "Country_Region_Code" field. I find it easier at this point to have tabbed to the "FieldName" then hit backspace twice and type a "." and select the Field from Intellisense.

So you should have noticed other parts of the code automatically updating as you filled in the related replacement points. Your code should now look like this. Again, click the picture below to see a clearer image of the code.

I use code snippets quite frequently in my development and I hope that you can see how they can speed up development times. In NAV we have always been able to programme quickly, which can suffer when we move to other programming environments such as Visual Studio. I hope you have found this blog post useful and would appreciate any feedback. Likewise please let me know of any changes you'd like or bugs that you may have noticed.

Read more...