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!"
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!"
Labels: .Net, .Net 3.5, AIF, Dynamics AX, Integration, NameSpace, Service, Service Reference, WCF, WSDL, WWF
posted by brandon | 5:20 PM
2 Comments:
Hi,
Can you explain a bit about debugging the xml messages received back from the webservice in case of an error?
I would like to see the response stream.
Thank you.
There is another way also. Check the following:
http://axwonders.blogspot.com/2011/04/consume-currency-exchange-rates-web.html
Post a Comment
<< Home