Announcements
How can an external web application send messages to MS Dynamics AX and integrate with it. The other web application may be non .NET application like Java or PHP web application.
*This post is locked for comments
There's different ways to integrate with AX. In a .NET application, you could call AX code directly over the business connector. You have AIF to integrate using SOAP (and in AX 2012 using nettcp and other WCF goodies, even flat files or various formats).
Or you could write a simple file loader in AX that runs at certain intervals and picks up files from a shared drive.
Check out the Integration options on MSDN: msdn.microsoft.com/.../aa877498(AX.50).aspx
Or, for AX 2012, check out: msdn.microsoft.com/.../aa877498.aspx
I think I need AIF here because it is Dynamics AX 2009 and non .NET application. Is there any builtin message queing in Dynamics AX 2009 or should I use MS message queue component
Ms message queue would be the way to go. The minor issue with AIF in Ax 2009 is it can only do XML.
We use PHP (on a LAMP stack) as are e-commerce code base to work with our AX 2009. Basically, we came up with these practices when working with AX.
[Note, if you use PHP on a WAMP stack, you could experiment with the experimental COM/NET components of PHP and see if you can work with the business connector for AX business logic instead of integrating web services]
1) For all read operations, use SQL and read the data from the database directly.
1a) because you're reading from the database directly you wont get AX logic for enums and other types. That means you'll have to write some PHP code to convert enum values [integers] into string readable versions. This is extra code that you'll need to maintain however it's worth it in the pure speed benefit of reading directly from the DB.
2) For write operations use web service integration
2a) Avoid web service integration where possible, every call to the web service has an overhead of at least 1 second execution time.
2b) Skip the existing web services/document passing format--they are garbage. Instead, write your own services--its super simple.
When you create a web service, use simple parameters it will save you a ton of trouble. If you use a complex parameter you'll need to generate SOAP wsdl complex types and that means you'll need to create extra PHP code to generate the parameter to pass to the service call. It's simpler to simply use string parameters (or "xml" parameters). A typical method for one of our web services might look like
// bscWebServiceOrder boolean addToCard(xml _serialized) { // _serialized is not really xml--its just a really great parameter type to work with as it gives you a nice big string to pass data with // decode _serialized into the parameters (lets say we are using JSON format) System.Collections.HashMap params = bscJsonClr.fromJson(_serialized); // now we can do some ax stuff with our parameters custTable custTable = custTable::find(map.get("custAccount")); // etc } Because the service call parameter is just a string, there's no way for the service to validate the data you're passing in. You need to either add the validation in your code, or just make sure you maintain both ends (php&ax) of the service so that you are always providing and receiving the correct data to the service. Again, extra maintenance but ultimately leads to better performance and faster up and running development time.
// bscWebServiceOrder
boolean addToCard(xml _serialized)
{
// _serialized is not really xml--its just a really great parameter type to work with as it gives you a nice big string to pass data with
// decode _serialized into the parameters (lets say we are using JSON format)
System.Collections.HashMap params = bscJsonClr.fromJson(_serialized);
// now we can do some ax stuff with our parameters
custTable custTable = custTable::find(map.get("custAccount"));
// etc
}
Because the service call parameter is just a string, there's no way for the service to validate the data you're passing in. You need to either add the validation in your code, or just make sure you maintain both ends (php&ax) of the service so that you are always providing and receiving the correct data to the service. Again, extra maintenance but ultimately leads to better performance and faster up and running development time.
Joris and Jeremy, thanks for your replies, both of you.
@Joris
is MS message queue functionaltiy builtin in Dynamics AX 2009 or should I install the component seperately on server.
@Jeremy
I also want to integrate a PHP e-commerce application with Dynamics. is message sending guaranteed in web services? what is some error occured in communication or network transfer? in your case the web service 'addToCard' is called from PHP side?
Can we also use MS message queue for the same purpose or is it the same thing as creting web service on Dynamics AX side and calling it?
@Jorris
I found the answer to my question on this link,
"If you use the Message Queuing or BizTalk adapters, you must have Message Queuing or BizTalk Server 2006 installed on the AIF gateway computer."
msdn.microsoft.com/.../aa877498(AX.50).aspx
Now another question remains unanswered for me. can i obtain two-way communication with MSMQ. I mean from my web application side I will be able to send guaranteed data to Dynamics AX. fine. But I also need the acknowledgement response from Dynamics AX back. is this functionality provided by MSMQ or will i need to implement it seperately in Dynamics AX.
One more question:
Should MSMQ be present on both sides? (receiving server and sending server)
@Nabeel Khan
We don't use message queuing at all, so I can't answer you there.
The web services are accessed via SOAP service calls, we use a nice soap wrapper from the Zend framework (http://framework.zend.com) to handle the dirty work. If there is a connection error the soap request will throw an exception which you can catch and handle appropriately in your PHP code.
You will need to have MSMQ installed on both sides to have the components (DLLs etc) available for your code to be able to put things on the queue. As far as creating a queue, you would only do that on one side, unless you want to send replies on a different queue, in which case you may do something like each receiving end owns a queue that it reads from.
The one difficult thing usually with MSMQ is security setup. Authentication and those sorts of things tend to be a challenge when you're first setting up your architecture.
As far as creating a queue, you would only do that on one side
Why is that.
If only one queue suffices, should it be made a public queue on receiving side and the sending application will directly access its PATH to send messages over network? or should the queue be created on sending side and the receiver application (Dynamics AX) be connecting this queue PATH over network to fetch messages?
Under review
Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.
Jump in, show your community spirit, and win prizes!
Expanding mentorship, skilling, and AI innovation
These are the community rock stars!
Stay up to date on forum activity by subscribing.
CP04-islander 16
Nagendra Varma K 4
Harisgillani 4
