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!"

Quick Post: Catching ClrErrors in X++

I wanted to do a quick post actually with some X++ code. I know this exists already on the web somewhere, but it's always handy code when working with .Net Assemblies, WCF Services, etc.

So the following is a great way to catch and see what all is going on with any .Net error being thrown.:


System.Execption ex;
str ClrErrCatch;
;

try
{

// Do some code work here...

}
catch (Exception::ClrError)
{

ex = ClrInterop::getLastException();

if (ex != null)
{
ClrErrCatch = ex.get_Message();
ClrErrCatch += ex.get_StackTrace();
ex = ex.get_InnerException();
if (ex != null)
{
ClrErrCatch += ex.ToString();
}
}

error(ClrErrCatch);

}



Now the above assumes your making correct use of CAS, or Code Access Security, with an InterOpPermission.Assert() going on.

The point with this post is to give a good template for working with Clr errors. This includes anytime you reference any of the System.* .Net Assemblies, your own custom .Net assemblies, and also Service references of any type, be that Web or WCF.

Check back soon, as more good post are coming on. Also this can be included in our WCF series of post going on as well.




"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!"

Consuming Service References in Dynamics AX 2009

As mentioned in the following blog post.:
Continued talks of Integrating Dynamics AX to the outside world

I plan on going through some of the integration options that exists with Dynamics AX 2009, and getting into some real examples of this. In order to dive right into this, lets look at Dynamics AX 2009 consuming service references.



Service references are new with Dynamics AX 2009, and map directly to service references that one would see in Visual Studio 2008.

This makes use of .Net 3.5 framework, through creating .Net 3.5 code for the given supplied Service WSDL, that acts as a consuming proxy. This is registered in the AOT, and can be accessed through the supplied .Net namespace from where the given service reference was created.



This can be a given web service, or a Microsoft WCF service adapter / end point. That means that all of what comes with the .Net 3.5 framework with WCF and WWF can be made use of with such integration points.

One of the given main examples that has been used to showcase this is hitting the Live API (I guess bing now!) for searching through it's publish service.

This is great to show case a technical ability of this, but what about functional wise?

Well such an integration point, of it self, is syncrhonous. Now the integration point can lead into a WCF service, that is hosting a WF Workflow, which drives through several different points, including asyncrhonous processes with MSMQ, etc. However the integration itself is synchronous because it expects a return on a given call out.

This means that typical integration for this would be to other System of Record applications or solutions, web services for feeding data from and consuming, external calculations like shipping, tax, etc.

What's great about this integration, is that in X++, the given .Net namespace is used with a preceeding dot (.) to get access to the given service, and any methods it might offer.

One thing I want to point out about that .Net namespace, if for example you have say three web services you want living in the same parent namespace. Well you need to make sure to do something as the following for that namespace.:


ParentNameSpace.ChildService1
ParentNameSpace.ChildService2
ParentNameSpace.ChildService3

You do this for each of the three services you want to live under a single parent namespace. So you would have registered 3 different AOT service references, and in the .Net namespace provided a structure as you see above.

Now when in X++, you reference ParentNameSpace. The three child services will be listed under this single parent Namespace. There will also be three .Net 3.5 Proxy Clients created, on the AOS, under the documents and settings of the given user id that is running the AOS service. They will be named as well.: ParentNameSpace.ChildService1.dll, "2.dll, "3.dll.

That is a good point to keep in mind, espcially for doing larger integrations and so forth.

These work great once setup, and there are some limits though. The following gives you a good idea of those limits, like data conversions, etc.

AIF Services and Primitive Data Type Conversions for XML and .NET Framework

Take a look at the chart for idea of the conversion of data types. Another good resource, is the 'How to: Consume a Web Service from X++'

One other thing I want to point out is that the service reference does not have a great management form for say, changing the WSDL URL or service name. The best approach I have found for doing this, and for deploying to other instances has been to take and export the Service Reference, and change the WSDL URL, and import into your instance of another instance and regenerate the service.

Sometimes you might run into file locking issues, if the service already existed. If this is the came, you will need to (a) take and stop the AOS (I know a pain), (b) delete the actual .Net file that AX is complaining is locked, (c) restart the AOS, (d) regenerate the service reference.

Doing this will allow for your updated WSDL URL, etc. to be read and made use of.

Thats all for now, and check back soon as more to come. August is wrapping up today, and that was delcared as Lean month. However I have some more great Lean based posted to wrap that Lean month up with.

See you next time!




"Visit the Dynamics AX Community Page today!"