Dynamics AX 2009: Hotfix 981339 for Consuming external WCF Web service

I wanted to highlight a specific Hotfix that was released and is part of RU5 and RU6 for Microsoft Dynamics AX 2009. This was actually released just before RU5 was compiled and set ready for downloading and installing last year.

This specific KB is: 981339, and you can find a detail list of the latest fixes for Microsoft Dynamics AX 2009 through PartnerSource or CustomerSource found here.: Hot Fixes Released For Microsoft Dynamics AX 2009

The list was last updated this past March 15th, so it's a list that is keep up with on a regular basis.

Now for this specific hot fix, it addresses the issue to where when you consume an External WCF service from a service reference within Microsoft Dynamics AX 2009, and the communication with the service does not close properly or enters a faulted state.

With this faulted state, before this fix the only thing you could do was restart the AOS. Now with this fix, it addresses the proper openning and closing of the service client the service reference generates, and therefore is closer to how a client in C# would act.

This is a great fix, and one that you can get directly just for that KB through a ticket request through Microsoft Support, or one that you can get through applying RU6.

This is just another example of the value of staying current with your Dynamics AX investment, including looking and reviewing when RU are released. I highlight this in, the case for staying current and upgrading in the following two post.:

• Guest Column: The Value of Upgrading
  
• A Case study for the value of upgrading

Thanks to a fellow Sunriser's John F. & Debra D. for bringing this hot fix to light. I thought it was for sure something that should be posted about, and also help enforce the fact that as a company one of the ways to ensure long term ROI is the continued upgrade and staying current process.

That's all for now, but check back soon as more to come! Till Next time!

"Visit the Dynamics AX Community Page today!"

Dynamics AX and WCF Service - Part II

Ok, so recently I wrote the following blog entry.: Dynamics AX 2009 - Service Reference to Custom WCF Service

In that post, I showed a custom Foo WCF Service, some ServiceContracts, OperationContracts and DataContracts. I also talked about how to reference this in Dynamics AX, make use of the objects, including how to make use of .Net List.

Now if we look at the Xpp Code, that I took a screen shot of, we can start our next post.:


So if you took exactly what I did and tried to implement it, you would get an error message inside Dynamics AX. A ClrError, stating the ClrObject could not be created.

The reason why is that the above screen shot, the code is executed where ran, which is typically the client.

Any Service Reference Xpp code, that calls a service reference at all, must be done at the Server Tier. This is actually well covered in a lot of different blog post, and something that most anyone that has done this kind of integration has ran into.

So this actually starts us into the next real section that I wanted to cover when working with WCF Services that one might create and want to work with from within a Dynamics AX implementation.

There are actually several different gotchas and points of interest someone would want to look for. So the following is an attempt to list those, and try to help out anyone going this route.

So one thing to note, is during the development of your custom WCF service or services, you will most likely be changing that code a good bit. It's always a good thing to create a console or windows form test project to make sure what your sending into the WCF is working and that the WCF code you wrote is working as expected.

The wonderful thing about such an approach you can catch unhandled exceptions during debug mode, where in Xpp this is not possible. You get a general message about the ExeceptionDetails is not serializable.

Now moving forward another note on developing WCF Services. Let say you have a good start, you make your reference in Dynamics AX, and start coding Xpp code. Then you realize another WCF OperationContract would be great. Go ahead and add that WCF OperationContract and make sure the Interface the Service makes use of, is updated correctly.

Then Go to the Service refernec in AX, right click, select regenerate, get the error messages, close the client, restart the AOS, and then restart the client. The new method should show up.

Only during this process, with the regenerate and restart of the AOS, does your WCF service change reflect in Dynamcis AX for use.

I will leave you here. There is actually some more points in this area. Also keep in mind with all these little gotchas, the flexbility offered with WCF Services is well worth the effort.

I plan on moving forward with more things to watch out for, and also why choose WCF Services over standard Web Services.

Thanks for reading, and check back soon!




"Visit the Dynamics AX Community Page today!"

Dynamics AX 2009 - Service Reference to Custom WCF Service

Alright, so making use of Service References in Dynamics AX 2009 has been out for a little while. In the past I have done post talking about white papers, and how-to's. Talking about the design of such services.

Well I wanted to take a little time and spend a little bit with creating custom WCF services, and then consuming those services within Dynamics AX.

This is not the first such tutorial on the web. There was some earlier one's done when Dynamics AX 2009 first came out. What I want to address however is details for creating a simple service, in general terms. Talk about the different aspects of these general concepts. Then in later post move through wht WCF services, over other options, and also common issues found when scaling services, promoting to other instances like production, etc.

So first lets look at a custom WCF Service. The following is such a service.

1.) A DataContract.:


2.) A ServiceContract, Defined in an Interface


3.) The underlying class that implements the given ServiceContract Interface and it's underlying OperationContract's


And


So the above show's a TestBed namespace, that includes a Class with an interface. That interface is what defines the ServiceContract and underlying OperationContracts. These are used to define what endpoints exists for consumption by a WCF client.

The DataContract, FooData, is used to define a complex (though simple example) user defined type, with properties that exist to describe what a FooData object is.

Once these are defined, I recommend actually first testing by consuming in .Net. Maybe through a Console app or .Net Windows Form. This will help to get rid of any security issues that might exists for IIS, etc.

Once this is tested, now we can move forward with consuming this within Dynamics AX.
Simply create a new project, add a new group for references, right click, add new Service reference, point to the URL where the FooSvc.svc is being hosted, and AX will create a client, used by the AOS to interact and consume this WCF custom service.

Once that is done, then you can do something similar to the following X++ code, that calls, interact, and works with the WCF Service, Operations and DataContract.:


Now lets disect some of this, and look into the details. So before this WCF Service could be consumed, it had to be created, and then published to a place where AX could consume it.

Since the idea it to talk in general terms, the Foo code concept was used, in order to be general.

So this Foo based C# .Net 3.5 code example shows a simple example of a Foo Class, that has an interface. It's important to understand that this is very similar to typical interfaces for classes. It governs how outside clients, consumers and code can interact with the class and create instances of it.

What different about this interface is the meta tag information, used by the WCF hosting .Net code to define what the given interface, and methods are. That is a ServiceContract, and OperationContract's. Or what's also know as endpoints.

These endpoints, are what AX consumes and works with. As you can see in the X++ code, .GetFooDataList(5); and .GetFooString(fooData);.

The actual code that does operate on the calls, and parameters variables sent in, lives in the public class Foo : IFoo {...}. The IFoo is familiar to anyone that has worked with C# code before.

Now to generate this interface, and class approach, simply add a new WCF Service and the wizard creates a shell for you.

Lets move forward, a look at the DataContract. Now this is different than what we have seen before in working with straight .Net Code, and .Net code through Dynamics AX, X++.

This is used to define a complex custom type, that can be passed between the WCF service code, and a consuming client. This includes Dynamics AX.

Now note, that the DataContract, FooData, is made up of simple data types, for it's DataMembers. However with this defined, and once a service reference is made from within AX, then the give FooData DataContract class, can now be passed back and forth between Dynamics AX X++ and C#.

You can see in the X++ example, that once I get the FooData based List, that I can call a method from WCF C# service, and send it a .Net object defined in that service as FooData. This can be filled with information, passed in and then operated on within the WCF service. The return, note is a simple return.

Let's also take a step back here, and look at how I get my FooData object. I am working with what appears to be an Array of FooData[]. And what I am working with is actually a List. You can see the return type for .GetDataList(5); method call.

Notice how I create an instace of the System.Collections.IEnumerator, and use that to Enumerate through the List of FooData objects.

I think it's very important to understand that you can work with List's, and specific Genrics based list that define a List with specific types that are contained within.

It's actually a pain point, if your not familiar with working with Arrays and List with WCF in general, and much less with WCF Services consumed with Dynamics AX. So this is a very good example of proven code that works for working with List of not just simple strings, etc. but actual custom complex types.

So what we have here is some basic concepts of a simple WCF C# service, that has a few OperationContracts, for our Foo.svc ServiceContract. It also has a custom DataContract used in both the X++ and C# code. And this complex type can be sent between the two.

Now one could take this simple example, and really make use of it for creating needing code in a WCF service layer. Maybe for working with other LOB, line of business, applications. Maybe for working with legacy code, or objects, or an enterprise sevice bus, with middleware message needs.

What I do want to point out, is there are certain Dynamics AX Service Reference settings, gotchas, watch outs, etc. Espically when you move from Dev to Production. Or if you need to change the WCF service and regenerate the reference inside Dynamics AX.

I plan on going over those details a little later, and taking this post further into real world solutions.

I hope this gets you thinking though about WCF services, and the power of WCF Services. As i mentioned at the start of this post, I plan on covering WCF Services vs. Web Services and why choose WCF services. Also in that next post I will cover the gotchas and watch outs I mentioned above.

See you next time!

P.S. In the meantime if you have specific questions, issues, something you would like to see with this, please leave me a comment or shoot me an email.




"Visit the Dynamics AX Community Page today!"