Tuesday, 30 September 2008

Calling Web Services in the Marketing Beta of NAV 2009

My first experience of using web services in the Marketing Release (CTP4) for Dynamics NAV 2009 resulted in a couple of errors. The first one I experienced was a bit of confusion over the way Visual Studio 2008 handles web services.

If I had read through Lars Lohndorf-Larsen’s blog post on how to consume a web service properly this wouldn’t have been a problem, but basically if you want to add a web service in VS 2008, it’s a little different.

When I went to add my service, there was no add web reference option.



I thought, hey that’s cool they’ve changed the name and updated the user interface, so I just selected this option and put in my address. But when I came to use the web service I got the shock of my life when none of my methods were there. Now I had to go back and read Lars’ post and this time I was determined to follow it step by step to see what I was doing wrong.

Sure enough Lars does say:

2) This step depends a bit on whether you use VS2005 or 2008. In VS2005, just rightclick on "References" in the Solution Explorer, and select "Add Web Reference". In VS2008, to get to the same place, rightclick on "References", then select "Add Service Reference", then click the Advanced button, and then click the "Add Web Reference" button.

So when you see this screen:



Click the Advanced button and then click the Add Web Reference button.



Now we’re back in familiar territory and everything works as it did previously.

Except – my console app didn’t work! I kept getting this error: "Path property must be set before calling the Send method."

I think this problem only happens when you are adding multiple web references to a single project (not uncommon) and I’m really not sure why it happens – maybe someone who knows a bit more about .NET and visual studio 2008 could add a comment as to why this happens.

Even though the URL property is set on the web reference, for some reason the service doesn’t know the URL, so I needed to explicitly set it within the code.

Here’s an example.

SSRef.SystemService SysServ = new SSRef.SystemService();
SysServ.Url = "http://localhost:7047/DynamicsNAV/ws/SystemService";
SysServ.UseDefaultCredentials = true;

I guess this is my first blog post on NAV 2009 although, like many people, I’ve been working with it a lot since the CTP3 release. I have to say that this is an amazing product and I really can’t wait to start using this for real. Nice one Microsoft!

Sunday, 28 September 2008

Everybody Lies

The Dr. House approach to requirements analysis
This posting was first published on the Intergen Blog Site on the 26th September.

Gregory House M.D. is a maverick medical genius who, in each TV episode, heads a team of diagnosticians in their attempts to diagnose an unfortunate patient’s mystery illness. House’s signature phrase is “Everybody lies” although, for his character, it’s more than just a saying, it’s a philosophy. In this article, I’ll demonstrate how the “everybody lies” approach can be applied to requirements analysis in order to reduce costs and improve overall project quality.

It seems odd to claim that everybody lies. Just as there’s no good reason for a patient to lie to a physician who is trying to save their life, we don’t expect a business person to lie when we’re gathering requirements. The modern-day philosopher, Homer Simpson, has this to say on the subject of lying: “Marge, it takes two to lie. One to lie and one to listen.” Homer’s insight helps us understand the fundamental problem: the users must tell us the truth but as analysts we are equally responsible for finding it.

Before I try to convince you of my rather tongue-in-cheek methodology, you should first understand that getting requirements right is a serious business. Research from Barry Boehm and Philip Papaccio has shown that defects introduced early in a project, such as in the requirements analysis phase, can cost 50 to 200 times more to fix later in the project than if they had been corrected close to the point at which they were introduced. 50 to 200 times – that’s a staggering difference!

Gathering requirements means capturing business problems, not computer problems. You don’t need to be Sherlock Holmes (or Gregory House for that matter) to understand that the first step in solving a problem is to clearly identify what the actual problem is. Building a solution based on the wrong requirements can be a costly mistake to make, but how exactly can we apply our new “everyone lies” approach to requirements analysis and avoid getting it wrong? One approach could be to shout “liar” every time a user describes a requirement, but some may find this a little disturbing. First we need to understand the nature of the lies and how to avoid them.

The first problem I have discovered is that people like to describe solutions and not requirements. If I had a signature phrase for requirements analysis it would be, “That’s not a requirement, it’s a solution!” I’ll admit it’s not as catchy as “everybody lies” but the sentiment’s the same.

A requirement is the answer to a “what” type of question and should always be expressed in business terms. A solution is more of an answer to a “how” type question. There’s an easy way to tell the difference between requirements and solutions: if you can implement it, it’s a solution.

Writing down a solution instead of a requirement happens frequently, but most of the time we get away with it because it just so happens that the solution we’ve written is correct. No harm, no foul; but what happens when the solution isn’t correct? Remember that equation we had before? 50 to 200 times more expensive to fix. That’s why we get the requirements signed off to make sure they’re correct, because no-one would sign off on requirements when they’re not correct. Or would they?

Having a signed off requirements document means nothing if the requirements are wrong – we’re still going to need to fix the defects and our goal is to reduce the project costs, not just our costs. Let’s assume that no one would sign off requirements that they know to be wrong, so it must be that they’re not understood, but this raises a new mystery: why do people agree to requirements when they don’t understand them?

The problem starts when we use the wrong language to describe requirements. If we’re not using business terms, we’re putting the business users at a disadvantage. It can typically go one of two ways: either the business user says, “Hey I’m sorry but I don’t understand this requirement so I can’t agree to it”, or they say, “I don’t understand this requirement but the consultant seems pretty confident that he’s right, so I’ll just keep quiet. If it’s wrong someone else will pick it up later on.”

So the next time you find yourself writing a requirements document, remember that you’re a detective and not a secretary. It’s your job to find the real problems in business terms and not simply record what you’re told. When people tell you that the captured requirements are correct, ask them to explain them to you, just to check they’re not lying.

In my next post, I’ll explore the “Tourette’s Syndrome” approach to handling support calls.

Thursday, 25 September 2008

SQL Code Beautifier

It's funny - I've looked for some kind of "improve my layout" type function in SQL Management Studio loads of times but never found it. Then (and I don't know why I never tried this before) I searched for SQL Code Beautifier in Live Search and came to this site: http://www.ubitsoft.com/products/t-sql-beautifier/index.php.

The resulting code looks great, AND you can get an HTML rendering to post in your blog posts. Nice!

Why did I need to beautify my code - well the first time I needed it was when I had to edit someone else's SQL that believed carriage returns were not necessary. The second time (that prompted me today) was when I wanted to see the result from creating a dynamic SQL command - I printed the command but it came out as a single line of text, so I wanted to see what it looked like to be able to check for errors.

This nice tool is definintely going to save me heaps of time. Maybe someone should write a C/AL code beautifier.

When Ctrl+C, Ctrl+V Fails--Send to Excel Saves the Day!

The other day a very scary thing happened to me-copy and paste from NAV failed! I was on a sales order and I copied the sales lines to the clipboard and pasted them to Excel. Nothing new there, we've been able to do this for years and it's been a pretty cool feature of NAV but when I came to check the totals, I was horrified to see that a few of my sales lines were missing!

I tried again and still they were missing. After some investigation, I found the cause of the problem was that some of my items had a double quote in the description for the items. This is not uncommon, especially when you have descriptions with inch sizing in the description. The problem seems to be when the very start of a field is a double quote and there is no double quote at the end. Excel was taking from the start of the double quote to the next double quote as being a full description field (so one of my fields included 10 or so sales lines in the field.)

I was about to log this with Microsoft as a problem with NAV when I saw that if I typed similar data into a text file and copied and pasted into Excel, exactly the same thing happened.

Thankfully the new (version 5.0 new) send to Excel feature saved the day as the XML approach copes with the double quotes without a problem.