If you want to learn more about the upcoming release of Microsoft Dynamics NAV 2013, and you are from Zagreb, or don’t mind coming to it, the next community event of Microsoft Dynamics Community Adriatics will be fully dedicated to NAV 2013.

There are going to be two presentations. In the first one on the topic of “What’s new in application functionality”, hosted by Ivan Koletić, a member of Microsoft Dynamics NAV product team, who will give an overview of new application features in NAV 2013, and by now you should already know there are plenty.

The second presentation will be about “What’s new in technology”, and will be hosted by me. I won’t be doing any deep-dive this time, and I’ll provide a cloud-perspective overview of a myriad of architecture changes and technology improvements in NAV 2013.

Both of these presentations are merely going to be an introduction in the series of the presentations that will follow over the next several community events. It’s going to be an exciting summer and fall.

If you would like to attend, then please register your attendance (for free, of course) at the event homepage. We are looking forward to seeing you there!

.NET Framework is full of programming conceptual gems, that are now at the fingertips of us poor C/AL folks. One of those is generics. However, the C/AL support for generics at the first glance seems rather limited, and the help file says that you can’t specify data types, and that all generics will be instantiated with System.Object as their type.

However, with Microsoft Dynamics NAV 2013, there is a very simple way which allows you to use generics with other data types, as well. So, if .NET Framework Interoperability interests you a slightest bit, here’s a solution.

The example below will be for the System.Collections.Generic.Dictionary<,>, and I will show how to use instances of the Dictionary<,> object with any desired data type, without having to pull in any external assemblies.

The Solution

Before I show the example, I’ll first explain the solution.

Declaratively, you can’t declare a generic variable, and specify the type. C/SIDE is just not (yet) that flexible. But that doesn’t matter, because .NET Framework includes a nice feature which allows you to create instances of any type on the fly: Reflection.

By using reflection, you can create an instance of a generic type, and specify which type(s) it should use, all with very little coding. In the examples that follow, I’ll create an instance of Dictionary<string,int>.

The whole process in C# would look, more or less, like this:

Dictionary<string, int> dict =

    Activator.CreateInstance(

        typeof(Dictionary<,>).MakeGenericType(

            new Type[]

                {

                    typeof (string), 

                    typeof (int)

                })) as Dictionary<string, int>;

// Step 1

Type[] types =

    new Type[]

        {

            typeof (string),

            typeof (int)

        };

 

// Step 2

Type dictionaryType = typeof (Dictionary<,>).MakeGenericType(types);

 

// Step 3

Dictionary<string, int> dict = 

    Activator.CreateInstance(dictionaryType) as

        Dictionary<string, int>;

Step 1 creates an instance of a 2-element array of Type. This is needed for creating a generic type using reflection.

Step 2 uses reflection to create a generic type of specified types. The types are specified in the array we created in the step 1.

Step 3 uses reflection to create an instance of the type created in step 2.

Now that we’ve seen it in C#, let’s map the same to C/AL.

1. Declaration

Let’s get it straight, you can’t declare a DotNet variable of a generic type, and specify the actual type (or types) it generalizes. The C/SIDE simply doesn’t allow that. But, don’t worry. Go ahead, and declare the following variables:

Of course, all of the above are DotNet, except for the last one, which is Integer.

2. Creating an instance of an array

To declare an instance of an array of type Type, we can call the CreateInstance method of the Array class, by providing the type of System.Type. Then we populate the array with the types of System.String, and System.Int32:

Arr := Arr.CreateInstance(GETDOTNETTYPE(Type),2);

Arr.SetValue(GETDOTNETTYPE(String),0);

Arr.SetValue(GETDOTNETTYPE(Int),1);

This isn’t nearly as elegant as in C#, but accomplishes the goal quite as nicely. Take a note of the GETDOTNETTYPE function – a new gem in C/AL, the equivalent of the typeof keyword in C#.

3. Creating the dictionary type

To create the type for the Dictionary<string,int> that we need, we have two steps. First is to get the type of Dictionary, and the second is to use that type to reflect out the actual Dictionary type that we need, based on types specified in the array:

Type := GETDOTNETTYPE(Dict);

Type := Type.MakeGenericType(Arr);

Again, it can’t be a single line in C/AL, because the syntax of C/AL does not treat the result of the GETDOTNETTYPE as an object.

4. Creating an actual instance

Finally, we create an actual instance of the Dictionary<string,int> object, exactly as we would in C# (except we do it in C/AL):

Dict := Activator.CreateInstance(Type);

There. And now we are ready to use it.

5. Testing if it really is what we need

Testing generics is easy – if you pass on to it the arguments of invalid type, they’d complain loudly. So, let’s try to pass some valid ones, and an invalid one:

Dict.Add('first',1);

Dict.Add('second',2);

Dict.Add('third','three');

Here, at the 3rd line, it fails with the following message, exactly as expected: This message is for C/AL programmers: A call to System.Collections.Generic.Dictionary`2[System.String,System.Int32].Add failed with this message: The type of one or more arguments does not match the method’s parameter type.

So, obviously, we have an actual instance of the Dictionary<string,int> which receives exactly those elements, and behaves exactly as we would expect from a true .NET Framework generic class: if we try to pass a value of incorrect type, it’s not going to be happy.

6. And now for something completely different

If you know anything about generics, at this moment you should be puzzled, as I was when I first tried this out. All of the C/AL voodoo above is the equivalent of this code in C#:

Dictionary<object, object> dict =

    Activator.CreateInstance(

        typeof (Dictionary<,>).MakeGenericType(

            new Type[]

                {

                    typeof (string),

                    typeof (int)

                })) as Dictionary<object, object>;

No need to try running it, it fails. Actually, it doesn’t fail, it returns null. The problem is, being strongly typed, the .NET runtime can’t cast Dictionary<string,int> as Dictionary<object,object>, and the declared type of Dictionary<object,object> can’t hold a value of Dictionary<string,int>. It’s apples and oranges—even though both are instances of the same generic type, it’s not the same actual type, and they are not typecast compatible.

When you declare a DotNet of a generic type, in this case the Dictionary type, it’s declaratively Dictionary<object,object>, so how in the earth did we manage to stuff Dictionary<string,int> into it?

As a matter of fact, we never did that. I can’t say for sure, but I’ll give an educated guess here. DotNet is never actually the exact type we declare, but a wrapper class around just about anything. I assume it actually wraps around System.Object, and then uses reflection to access the members of the actual object it wraps.

But in the end, why do we care? It does what we need it to do.

你好，世界！გამარჯობა, მსოფლიო! હેલો, વિશ્વ! مرحبا، العالم! שלום, עולם! नमस्ते, दुनिया! こんにちは世界 ಹಲೋ, ವಿಶ್ವದ! 안녕하세요, 세계! Γεια σου, κόσμε! Привет, мир! வணக்கம், உலக! హలో, ప్రపంచం! สวัสดีโลก!

No, no, I didn’t go fully crazy yet, but I’m surely closing in. Maybe it’s not at all such a big deal as I see it, but the new Unicode support in Microsoft Dynamics NAV 2013 is just blowing my socks off. After a quarter century of being tied to a single code page of choice, NAV has finally been freed of it’s single byte per character legacy.

So, the scribble above is not just me showing off with my ability to use Google translate, it’s a playground for you to copy select pieces of it and paste it all over NAV text fields in your NAV 2013 installation. You have one, don’t you? If not, go grab your copy!

This Unicode thingy, it was obvious this was coming. It was not exactly officially confirmed earlier, but with the good riddance of the Classic stack, and having the whole new stack built entirely upon .NET Framework and SQL Server (which had Unicode since ages), retaining ASCII would actually required far more work than simply adding the so much desired n in front of all those varchars in the database. In memory, everything was Unicode already anyway and if you have been in Antwerp at NAV TechDays last year, you may remember this presentation with the demo.

With NAV 2013 beta out, the sheer number of news is frightening, and I hope I just get enough time to blog as much as I’d love to. But I’m sure my colleagues would kick-off as well, and there will be oceans of useful information about NAV 2013 pouring in. That I can promise.

I don’t know about you, but I think today is a great day: Microsoft Dynamics NAV 2013 Beta has been published on PartnerSource, and if you have access, you can download it from here.

I’ve been playing around with CTPs for more quite a while, and even though I can’t share any specifics, I can assure you: this is definitely the best release ever, technically, architecturally, functionally and from business value perspective. Whatever angle you take – this release is massive.

I believe I don’t exaggerate if I say that 2013 brings more news in comparison with 2009 R2, than 2009 brought in comparison with 5.0 SP1.

If you want to check more about what exactly is new, I suggest you read the white paper and accompanying documentation at the NAV 2013 launch portal, and I hope the MVPs soon get the clearance to blog about specific features. There are just so many fantastically exciting to-dos for this blog, about NAV 2013, that I’ll probably eat my fingernails – heck, the whole fingers! – in anticipation to be able to start.

It’s the fourth year of DynamicsWorld’s Microsoft Dynamics Most Influential People Top 100 list, and it’s the nomination time. Last year I’ve somehow found my way onto this list (and I certainly didn’t nominate myself), and it seems somebody has nominated me this year too (and again, it wasn’t me).

Now, I don’t want to influence you to put me on this list in 2012 again, but if you think I deserve it, I’d appreciate if you took time and voted for me. You can do it by sending an e-mail to top100@dynamicsworld.co.uk, tweeting my name with #dwtop100 hash-tag, commenting on Facebook, or posting on LinkedIn. Or you can do all of the above

Even though there is a lot of criticism of this list, it is still an indicator of person’s standing in the Dynamics community. I’ve heard people say “I don’t have a clue who this or that" is” on the list, but that’s hardly a valid argument. The list doesn’t differentiate between CRM or ERP, let alone between different flavors of ERP, so of course not everybody will know everybody, and I also don’t have a clue who half of the list is, but still I bet they deserved to get there.

So, show me your support for my blog and my work in the Dynamics community by voting for me! Thanks in advance!

Passing strongly-typed data to NAV Web services can be trickier than it seems. If you are lucky, you can make your method accept strongly-typed parameters, and you are good to go. However, if you just can’t avoid sending text data, your text must be encoded in EN-US format, otherwise it will cause problems (see this).

What the heck, just encode the data as EN-US, right? Not quite. There are a myriad of reasons why data can come in non-EN-US encoding, one of which is this: it’s the Web services, for Pete’s sake – anyone or anything can call them.

Are there real-life scenarios for this?

Actually, there are. The most common one, which we have encountered in Stratus as well (but I’ve seen it on Mibuso, as well), is that you might need to pass an obscene amount of data between NAV and the consumer, and sometimes that data contains a variable number of parameters. Values for all the fields of any table, for example. Natural way of passing such data is through XML, and the only way to pass XML is through text.

And there we are – the only way in NAV to obtain decimals, or integers, or dates, or strongly-typed data in general, from text, is to call EVALUATE. And this naughty little function unfortunately isn’t as smart as being able to apply any format. It can only apply the format of the currently active language, and in Web services it defaults to EN-US.

To switch from theory to practice, if you receive the string ‘1.000’ in HR (or apparently ES) locales, it would get EVALUATEd to 1, whereas the value actually meant 1000 in HR or ES locales. If you pass the date ‘13-08-2012’ in NL locale, you would apparently get an invalid date error, and EVALUATE would fail.

Not really something you’d like to have in your database.

How to pass the strongly typed data, then?

The best way to pass large chunks of variable-structured data to NAV is by using XML, which is text, and is prone to problems with EVALUATE’s dependency on the actual locale.

So, how to get around it? By using .NET interop.

.NET comes with a great capability which is called serialization. Serialization allows any object in memory (okay – this any comes with a disclaimer) to be streamed into binary or XML representation, which can then be deserialized, i.e. to instantiate the same object with the same state, from that binary or XML representation. Of course, serialization can work with other formats, as well, but binary and XML are the most common.

Imagine this:

And you then use this class in a function:

Serialization can turn this into the following XML:

Beauty of this is that it can be deserialized back into an instance of class Person, without losing any information, and without having to worry about current regional settings.

Serialization is a much more complex topic than just what I’m going to show, but to make it serializable, the only thing you need to do with your class is this:

Then simply call Serialize to return the string, or Deserialize to return an instance from the string.

How that you have that class, deploy it as a .NET add-in into your NAV instance, and write a function such as this:

Then simply test to make sure it really does exactly what it says on the tin:

You can download the .NET project and the required FOB file by clicking here.

I hope this was helpful. Please share your thoughts.

If you thought “here he comes again” with the bugs and stuff, no – this is not about it. This is just about a new sales campaign launched by PACKT Publishing, the good guys who published my and Dave’s book three years ago, and plenty other good books thereafter, as well.

So, if you haven’t purchased my book yet, or any other cool Dynamics book, now is the time: during February, PACKT is giving 10% to 30% percent discount on all of its Dynamics books and offerings. Printed books are 20% off, e-books are 30% off, so this might be a good time to support us poor guys who have to make a living from literary efforts

Find more about the offer here http://www.packtpub.com/news/microsoft-dynamics-mayhem.

Fasten your seatbelts, you are in for the next round of Web Reference vs. Service Reference, which brings an unexpected twist to the story. After giving reasons why not to use Web References, I’ll now put my devil’s advocate’s hat on, and try to have you change your mind.

It’s simple: there are situations where Service Reference won’t work as expected, and Web Service will.

This time, you don’t need to create new objects, you can simply run what’s already there in NAV. Just publish the page 7002 Sales Prices as a Web service, then call ReadMultiple on that Web service both through a Web Reference and a Service Reference.

Okay – before you do that – you’ll want to delete (or change) the name of the Currency Code Filter control – it can’t have the same name as the Sales Type Filter Control – Web services won’t allow that (why does RTC not complain about this, beats me royally).

Also, if any of the calls returned no data, which is what a virgin Cronus database would do, feed some sales prices into it first, then call ReadMultiple.

Now observe the results. The Web Reference code actually returned all the data as expected. The Service Reference is funny: every row returned will simply have the Key property populated with correct data, all other fields will simply be either null (if nullable) or their default value (if not nullable). Unbelievable, isn’t it?

Looking at the XML passed on by NAV as a SOAP response, you can see that it actually contains all the data, just as expected. So what is it, then?

Figuring this one out is not as difficult as it might seem at first. Of course, the problem is not in NAV (actually, there is a problem in NAV, but not that NAV doesn’t return the correct info, it’s something else, that I’ll talk about later) – the problem is actually in how Web Reference and Service Reference deserialize the XML.

To understand how each of them do that, you need to check the source code of the generated proxy class. You can do it either by

a) right-clicking the proxy class name in any place in the code where it is used and choosing Go To Definition (or Go To Declaration, if you are using Resharper);

b) by clicking the Show All Files in Solution Explorer

then locating the reference source (always called Reference.cs):

The Reference.cs file contains all the classes needed for handling the SalesPrice Web service, and inspecting the SalesPrice class itself, which is the class representing the NAV Sales Price record, inspecting the serialization attributes will reveal the culprit in a split second:

Do you see what I see?

It’s the Order=x parameter of the XmlElementAttribute. An innocent looking thing, yet it causes such a disaster in deserialization of the data. What it does is that it basically instructs the XML deserializer to only continue deserializing the XML as long as the order of elements in the SOAP message is correct. If elements come out of order, deserialization doesn’t fail, but it simply ignores all the elements that come at, or after the position, of the first element which violated the order.

The Order parameter, as well as all of the serialization attributes, are present in the Service Reference proxy classes, but not present in Web Reference ones. That simply means that deserialization of the SOAP message will not take the order of the elements into account for Web References, whereas it will do so for the Service References.

Which in fact means there must be something wrong with the SOAP response. Why doesn’t it return the elements in the required order?

To figure that out, let’s inspect the message, and compare it to the WSDL definition of the Web service.

This is what WSDL defines:

And this is what the SOAP response contains (I use Fiddler to catch stuff like this):

And there you go. Since Key property did deserialize well, and since the proxy class said it needed it at position 0, s’il vous plait, then it must be whatever came at position 1 that made the deserialization give up.

See it? The SalesTypeFilter element, which is present in the SOAP response, is nowhere to be seen in the WSDL definition. All other elements come in order (please note that Order will only make the deserialization fail if elements are out of order, or extra elements are present – it won’t fail if an element is not present, but the elements that are present are in order).

Why this SalesTypeFilter found its way into SOAP, but was too shy to show up in WSDL, is a mystery to me, so I attribute it to a bug in Web services. And since it’s the Web services that returned that element, you can’t do much about it.

So, is this a dead-end, then? I mean, you must use Service Reference because it can fail at reading XML representation of unprintable characters, and you can’t use Service Reference because it can fail at ordering at deserialization.

Fortunately, it’s not that bad.

The workaround here is simple. You simply take out all Order parameters of every single XmlElementAttribute attribute (yes, you can edit the Reference.cs and modify the definition of a proxy class!), and all of a sudden the Service Reference deserializes the SOAP as happily as any Web Reference.

There are two problems with this solution: first, you absolutely must not update the Service Reference, because it would stick those Order parameters back where they were, and second, you must do this for every single class if you want to be sure it will work. But hey – at least you can work around this.

Conclusion

As much as Web services as a technology are consumer-agnostic, it seems that consumers themselves are pretty religious about what they do. Two different consumption approaches in .NET, and both behave in specific ways, causing you trouble if you don’t pay attention.

Which one would I use? Service Reference, any day. Getting rid of the Order parameter is as simple as this regular expression: (\s*Order=\d+\s*\,?\s*)|(\,?\s*Order=\d+\s*) (thanks, same to you, too!) (and yes – please feel free to point out how bat it is or to improve it, it was just impromptued here, I didn’t make any attempt to optimize it)

… and an Appendix

Talking about SOAP, let’s make a soap opera here. I won’t end this Web Reference vs. Service Reference here. I’ve given you two very practical arguments about what’s wrong and what’s not about these two approaches. I’m going to write another post, rather scholarly, where I’ll theorize on some less obvious aspect of a major difference between those two approaches, which actually affects anything that you do, if you want to use generic Web service approach, rather than specifically referencing every Web service you intend to use.

See you soon.

A beauty of Web services is that they don’t need to care at all about who’s consuming them. Whether there is .NET on Windows, Java on Linux or some proprietary stuff on an iPad on the other end, they do exactly the same stuff.

To make it short: if something works on one platform and fails on another platform, it’s not the fault of the Web service being called, it’s the fault of the caller platform.

As I said in the last post, there are two ways, or platforms if you wish, native to .NET Framework, which you can use to connect to any Web services. And they don’t work exactly the same.

The first scenario which I am going to present doesn’t work if called from a .NET application through a Web Reference approach, while it works quite happily if called through a Service Reference.

Create a new Codeunit, create one single method there, and have it do this:

If you see from far away that this will fail – you are absolutely right. But the point here is that there are two ways for this code to fail: the right way, and the wrong way.

The right way for this to fail is this:

The wrong way for this to fail is if you call through a Web-Referenced Web service.

So, publish the codeunit as a web service, create new Windows Forms application in Visual Studio, and have it call this Web service. You’ll be surprised that the error message you get is something completely different: the error message reads “Response is not well-formed XML.”

That’s not what you need, though. And the XML is pretty much well-formed, thank you very much! The InnerException will tell you that there is a problem with source XML, and will specify the allegedly scrambled data which couldn’t be parsed as XML.

A failure is a failure, right? Not quite. The error that this has returned has nothing to do with an error that actually happened. Actually, you don’t have a clue if an error happened. Try changing the demo codeunit you’ve written above into this:

If you call Foo2, no runtime error will occur in NAV, and it will either return the last error message or an okay message.

Still, calling it from a Web Reference gives this: There is an error in XML document (1, 163).

At the same time, calling Foo Service Reference, throws the runtime error: “You cannot base a date calculation on an undefined date.  Date: 0D Formula: 1", whereas calling Foo2 simply returns the expected text, without a runtime error. Just as expected.

So, what went wrong here? We have two different .NET ways of calling the same stuff, yet one fails, and one succeeds.

Taking the postulate from the beginning of this post, that NAV Web service did and returned exactly the same stuff (you can easily verify that by capturing the XML traffic), something must be failing at client side.

That something, in this specific case, is deserialization of XML-encoded binary information.

If you inspect the XML which NAV Web service sent as a response to the SOAP request of either of the approaches above, it included the date formula represented as 1&#x5;. 1 is the same as it was, it’s the M part which was, internall in NAV, encoded as ASCII character 5, which is unprintable, therefore translated into it’s hexadecimal representation x5, and XML encoded as &#x5;. The problem is that it was properly deserialized in case of a Service Reference, and not understood in case of a Web Reference.

In fact – that’s a problem in .NET itself, not in NAV. If you take the analysis further, you’ll realize that you can’t have any control whatsoever over the deserialization process in case of a Web Reference, as it happens within the SoapClientProtocol class, which is a built-in .NET object. In other words: there is nothing you can do about this.

Conclusion

If, for whatever reason, Web services you are calling return unformmatted DateFormulas or other binary data which would require XML encoding, don’t use Web References as they will not be able to deserialize such information.

The only workaround is to use Service References, which have no issues there.

Once upon a time, Freddy has delivered a great series on connecting to NAV Web Services from a smorgasbord of technology flavors. If you are a .NET enthusiast, like me, the obvious choice is to connect through the tools that are at your disposal in Visual Studio: the proxy classes.

A proxy class is a class which wraps a Web service functionality into a strongly-typed .NET object, and allows simpler communication through Web services. It hides away all intricacies of SOAP communication, authentication, serialization and deserialization, and exposes simple, easy-to-use objects. Every NAV Web service results in a series of proxy classes, and in Visual Studio the generation of those classes is as simple as clicking a mouse a couple of times.

There are two types of proxy classes, and they get generated through two different technical choices: Web References or Service Reference.

As Freddy explains:

Add Web Reference is a wrapper over wsdl.exe and can be used to create proxies for .NET 1.1 or 2.0 clients. Of course this means when you are pointing to a WCF service you have to be pointing to an endpoint that uses basicHttpBinding.

Add Service Reference is a wrapper over svcutil.exe and also creates clients proxies. These proxies, however, can only be consumed by .NET 3.5 clients.

Beyond that, there are no obvious differences, and neither of them seems to provide an obvious benefit over the other. NAV Web services doesn’t care who consumes them and in which way – so performance on NAV side is not affected by the choice between these two. Difference in performance on client side has never been proven to exist (at least to my knowledge), so as long as dependency on .NET framework being used is the only constraint, you should be safe to go with either of these.

Well, not quite so. There are considerations, and in the next two blog posts I’ll talk about two specific ones, one of which will definitely convince you to use Service Reference approach; and the other one which would have you consider using Web Reference approach instead.

Just in case you wondered if I have completed my “bug theater” series – I have not. What I decided to do is to give it a more practical aspect, and actually talk about Web services in a more generic way, focusing on solutions, rather than problems. So, the series of Web Reference vs. Service Reference will be just that – explanation of practical aspects of NAV Web services consumption, which explains certain issues in NAV Web services, and what effects they have on your choice of the type of proxy classes you’d use.

It’s Friday afternoon, and I want to keep it suspenseful (at least for those few who would read this ) – so see you all on Monday, when you can read about the first type of difference between Service Reference and Web Reference approaches from the point of view of a consumer.

Last Monday I’ve attended my second daughter’s birth, and then spent the week trying to relieve my wife as much as possible from anything but breastfeeding.

As a matter of fact, I’d like to keep doing it, it was not only a great break from daily worries, but also a fantastic occasion to spend all the time available with my closest and dearest, which I am not sure when I will have next.

It seems that there is life to keep going on, so I’ll now try to be back with my work and my blog.

Let me introduce bug #5: fields within a FixedLayout control.

Problem

If you have Field controls under a Group of type FixedLayout, at any nesting sub-level, such Field controls wouldn’t be accessible through Web services.

It’s simple to repeat: just publish page 151 Customer Statistics as a web service, and you can see that only the fields belonging to the first group (General) are visible in the WSDL, while any fields from Sales group are not present.

Microsoft has confirmed this problem, but as far as I know, no hotfix has been released to fix this specific issue yet.

Workaround

You can argue that there is no need to access Statistics pages through Web services, so this might seem not a big problem after all. However, this is not only about Statistics pages – it is about any kind of pages where FixedLayout is used, and another example is Journals.

For example, you might want to know if your journal balances to 0 before posting – if fields in FixedLayout would be accessible, it would be a simple task. Without it, you have to keep track of it outside NAV, which means that you must implement all NAVs logic about document numbers, balancing accounts, etc.

In any case, there is no straightforward way to access those fields. The workaround we used is to simply create a new group, make it invisible, and re-add all the fields present under a FixedLayout there. This makes all the data in a page accessible to Web services consumers, while hiding them from front-end users (to avoid confusion).

There is a trick here – because hiding something from front-end users is not as simple as setting the Visible property to FALSE. This would still enable users to show it through Customize This Page functionality. But since this has nothing to do with this specific issue, I’ll blog about it when I get to Web services Tips & Tricks part of this series. For now, let’s keep talking about bugs and workarounds.

In my country, there’s a saying: “A good horse has a hundred flaws; a bad one has only one.” It’s bad.

People have asked me why I am doing this, and if I hate Web services because I’m blogging about their flaws. In fact, I love Web services, and as I said in the first post in this series – they are great. They are a good horse. A winner.

The reason why I am doing this is because I want to share the problems I encountered over months of working with Web services intensively, as well as the solutions or workarounds I identified.

Today, on the repertoire we have another security-related glitch, which has been confirmed to me by Microsoft, but as far as I know there has not yet been a hotfix for this.

Bug #4: accessing Web services in multi-company scenarios.

Problem

This problem might seem similar to the one I blogged about last time, but it’s not the same thing.

Take a database with multiple companies in it, then add a Windows login which only has company-level access. It may have access to one company, or to all companies (explicitly). It may be SUPER in those companies it has access to, doesn’t matter. What matters is that it must not have database-wide access in any role (meaning no role without company name specified).

Okay, now that you have that user in place, try accessing a Web service. Any Web service.

You’ll get this error: “You do not have permission to read the Company table.”

To make it short: a user without database-wide access cannot use Web services.

Workaround

You might believe you can work around this problem with simple trial and error approach. The error message is pretty useful at this, and you will quickly realize that the only thing you need to do to “fix” the issue is to create a new security role with the following permissions:

1. Table: Company, with Execute permission.
2. TableData: Company with Read permission.

You then assign this role to every user, without specifying which company the role belongs to, and all users will now be able to access all Web services to which they have proper security access through their roles.

However, as Eric Sevareid said: The chief cause of problems is solutions.

So, if you apply this solution, you’ve created another problem: now every user in the company can see all other companies in the database. Big deal. Or?

In a multi-company database, this might be a real big deal. And it’s twofold:

• When users try to open another company, they will see all the companies, not only those that they truly have access to. And if they actually try entering one of those that they don’t have any access other than thru this new workaround role, they will get funny “you don’t have permission to this or that” errors.
• When you want to hide which other companies are there in the database from users who don’t really need to know this (because this may easily be a privacy issue in multi-tenant scenarios), then you will have a big issue.

Okay, let’s be honest: scenarios when there are multiple companies in the same database, and the users must not know which other companies there are apart from their own, are rare.

But still, if it happens that you have one of those rare scenarios, then there is absolutely nothing you can do, but wait for a hotfix.

Does anybody know if it was released yet?

Soren has taught me yesterday that some of the bugs I encountered have been properly disinsected by Microsoft, so other than the workarounds I suggested, there is an option to apply the hotfix and forget about that one.

Today, I’ll explain a not so critical bug, as the one yesterday, but depending on what exactly you do with Web services, it may be more than just a nuisance.

Hello, bug #3: accessing WSDL without database-wide permissions.

Problem

This one is very simple to repeat, and you don’t need any coding. You simply need to have a Windows login which only has roles assigned for a single company.

Follow these steps:

1. Add a Windows login to your NAV database, assign it to SUPER role, and specify company for that role. For example:
   
2. Synchronize the login, if necessary.
3. Publish a page as a Web service, say 21 Customer Card, call it whatever
4. Restart the NST (the Web services part).
5. Open the browser as the user you defined in step 1.
6. Navigate to the WSDL of the Web service defined in step 3, e.g. http://localhost:7047/DynamicsNAV/WS/Page/Customer

At this point, this is what the server returns: “The remote server returned an error: (500) Internal Server Error.”

Now do a funny thing. Access the same Web service, but as a user who has database-wide SUPER role (SUPER without a company name specified).

Now you get WSDL as expected.

Now repeat the same as the user with only company-level SUPER role. Guess what – no more errors. The server happily returns the WSDL.

So, a one-sentence description of symptoms is this: a user with only company-level access cannot read WSDL of a Web service unless a user with database-wide SUPER access has previously read the WSDL of the same service.

I can’t tell exactly what’s happening under the hood, but I imagine it’s some security glitch which prevents the user to read WSDL unless the user has database-wide SUPER access. If a database-wide SUPERman has already read the WSDL, it seems to be cached, and returned to anybody else from cache, regardless of their security permission.

So, it may be that accessing WSDL without database-wide SUPER role is prohibited by design, in which case WSDL shouldn’t be returned from cache. Or it may be that anybody should read the WSDL as long as they have proper access to the underlying object(s), in which case there is a bug in returning the WSDL back to the user.

In any case, not good.

Workaround

Well, there is none I could identify. The only thing you can do is access WSDL as a superman, then consuming the service as whoever.

However… (there must be a however)

What if you had a generic application (and I know of at least three of such) which must access WSDL in runtime, and that WSDL might be accessed by a mere mortal?

There are several possible options:

1. If objects are not expected to change, access WSDL once for each needed service during setup, and cache the WSDL description.
2. If objects are expected to change, create a Windows service which runs as a superman, and accesses WSDL on behalf of mortals.
3. As an alternative to above, you may store credentials of a superman (of course, you should use some strong encryption here, e.g. the one Windows uses for storing credentials of Windows services), then if reading of the WSDL fails for the error seen earlier, you retry as superman and see if it works.
4. Despair.

I understand this might not be a big problem for most of Web services applications, primarily those that are custom-built for a single customer. But if you have any ISV application which is not specific to an installation, but can run under many different installations of NAV, then this problem might hurt you a bit, in which case I hope you read this post before you actually deploy the application to hundreds of customers.

If you have some thoughts about this problem, or are aware of a hotfix which solves it, please contribute.

The bug with which I started this series is nothing critical. It manifests rarely, you can easily work around it. It’s in the “so what” category.

But the one I’ll talk about today is a tough beast, with not-so-easy workarounds that cause as much headache as the bug itself.

So, here comes bug #2: setting a date to 0D.

Problem

Try it. Expose a page, which includes a date field, as a web service, then try setting it to 0D value. No way you can do it.

Consider this:

SalesOrder_Service svc = new SalesOrder_Service();

svc.UseDefaultCredentials();

SalesOrder order = svc.Read("1000");

order.Posting_Date = DateTime.MinValue;

order.Posting_DateSpecified = true;

svc.Update(ref order);

This won’t work, and yet, it’s the equivalent of writing this in C/AL:

SalesHeader.VALIDATE("Posting Date",0D);

Workaround

Well, obviously you’ll need to write some kind of a function which you can call, and tell it which date field in which table, for which record, should be set to 0D. But as there are a hundred ways to skin a cat (no animals were harmed during writing of this post), there are a hundred ways to set a date to 0D.

One of the obvious ones might be to publish a codeunit with a method which receives the RecordID of the row which must be updated, and the ID of the date field which must be set to 0D. This seems the simplest, because it’s easy to pass the RecordID (thanks to GetRecIdFromKey method of any page Web service), and it could be generic – covering all date fields of all tables with a single function.

Then this piece of code would do the trick:

// RecID is a RecordID variable

// tRecID is a text parameter

EVALUATE(RecID,tRecID);

RecRef := RecID.GETRECORD;

// iFldID is an integer parameter

FldRef := RecRef.FIELD(iFldID);

FldRef.VALIDATE(0D);

RecRef.MODIFY;

Well, at least, it will do a trick. Not the one you expected, though.

Trust me, you are not ready for what this thing will do to your data. It will set the date to 0D alright, but it will also reset all the non-key fields of the record to their default values. Now that’s something.

So, that having been eliminated, what else can you do?

You could try with RecordRef, creating a more complex way to tell this generic function which date field in which table you want to update, and for which record, because – interestingly – the code above wouldn’t make a mess if RecordRef was obtained through GETTABLE or OPEN functions. It only happens if it was obtained through RecordID.

In Stratus, we didn’t want to gamble with RecordRef for 0D, so we’ve skinned the cat a different way around. We’ve utilized our extension codeunit builder, and automatically built an extension codeunit which has as many functions as there are date fields that we wanted to update, each of which explicitly sets this or that specific date field in this or that specific table to 0D.

If you have a better workaround, please don’t be shy, share it here (or elsewhere).

If something, Stratus has taught me how buggy the implementation of Web services in Microsoft Dynamics NAV is. Let me be clear from the onset: Web services are a great functionality in NAV, one of the best additions (together with .NET interop) to NAV stack in a long while. But it’s buggy.

Being buggy doesn’t mean it doesn’t work. It only means you need to twist and bend your code to achieve things which you would expect to work out of the box. During development of Stratus, we had to make a series of workarounds in Web services to achieve simple goals, and I decided to share those bugs (and workarounds) with you, to help you be more productive in your Web services based projects.

So, here we go for bug #1: lowercase codes in primary key.

Problem

Check this out:

Customer_Service svc = new Customer_Service();

svc.UseDefaultCredentials = true;

Customer cust = new Customer { No = "test" };

svc.Create(ref cust);

ERROR('Gotcha %1!',"No.");

Well, you get the ‘Gotcha!’ error. Inserting a lowercase value into a code field actually first insert the lowercase value, then renames it to an uppercase value. Pretty cool, eh?

Funny thing – this cannot be done through RTC. OnRename never gets triggered if you insert a lowercase code value to a key field through RTC. This is how Web services should actually behave as well.

Workaround

Not much you can do here. Make sure you uppercase your codes before shipping them over to NAV. RTC seems to do just that.