If you need access to live-Dynamics-data from your 3rd party application or simply need to invoke business functionality synchronously then you must use AIF. But the primary problem with some legacy systems is that they are simply not designed for the modern world of WCF.
Out-of-the-box, Dynamics offers application integration through WCF using NetTcp (the default secure binary transport). This off course can be extended to operate using either the HTTP or MSMQ adapters (for synchronous communication). This opens the door to unnumerable integration possibilities; however, all integrators must still be windows based systems or systems that are capable of authenticating with active directory.
There are still legacy technologies in many large firms that are unable to speak the “right-language” to exchange data “synchronously” with Dynamics (e.g. Informix or Progress 4GL systems). Similarly, there are mobile applications operating on non-windows based platforms (like Android) that live outside of active directory or simply do not have any native support for it. In these cases, authentication needs to take place via intermediaries that marshal communication via AIF.
The common protocol (or language) for all internet capable devices is HTTP (the internet protocol); a mature and stable protocol that has been in use now for over four decades. The HTTP protocol uses standard and simple unified methods like GET, POST, PUT & DELETE against web resources (known as URI’s). Its robustness and scaleability make it an excellent choice for publishing material on the world-wide-web, but it can also be used to access and invoke business functionality. REST (Representational state transfer) is simply a design-paradigm based on this principle. It uses uses the features of the web in a simple and effective way to enable inter-application communication between systems where things like language/encoding/authorisation may be an issue.
- See Wikipedia article for more information on REST: [http://en.wikipedia.org/wiki/Representational_state_transfer]
Instead of the conventional URL requests that return HTML responses (web-pages), web-servers can be setup to receive parameters (appended onto URL’s) and return XML or JSON or any kind of response you like. No specific sequencing of parameters is required, no proxy classes to break and no validation on either the request or response end. In many ways, it’s very a “loose” mode of communication.
AIF actually allows for the implementation of REST based services, however, the conversion from WCF is complex, see article: [http://www.microsoft.com/en-gb/download/details.aspx?id=38413] and off course it is still strict (XML must confirm to an XSD that has been generated from a service data contact) and still requires active directory domain authentication (or federated services to be setup).
For those requiring a more flexible synchronous integrator that will work with pretty much anything within your firm, then designing an independant REST based service using IIS is the way to go. I’m planning on hooking up a simple ASP.NET 2.0 REST web-service to the Dynamic X++ AIF service that I created in an earlier blog post [https://community.dynamics.com/ax/b/dynamicsax_wpfandnetinnovations/archive/2013/09/14/possibly-the-last-service-you-ll-need.aspx]. This should allow me to create a universal service bus for a multitude of applications that will expose a generic simple interface. Theoretically, this interface will never need to be changed, regardless of how many new services are published or enhanced within the AOS (yes that right you heard it… never). Being a lazy developer, I like *not* having to maintain legacy code!
The service will need to field-calls from non-active-directory sources (like scripts, macros or even javascript) so anonymous authentication will be allowed and instead IP verification will be used primarily and then your own proprietary authentication system layered on top. This is necessary for things like legacy scripting engines that execute under specialised service accounts.
- Intermediaries are required for calls from server processes that operate under local admin service accounts that Dynamics will have no knowledge about. For example, making a HTTP call from an Informix or Progress system requires opening a socket from the server process itself. A direct call from this type of platform into Dynamics will fail unless the system operates under an active directory account that is mapped to a user within Dynamics: [http://knowledgebase.progress.com/articles/Article/P125506]
Additionally, you’ll see that once you have a REST based service up and running then the temptation to use it everywhere will become all to apparent. You’ll no longer have to create VSTO solutions in Visual Studio for MS Office that requires extensive coding, testing and deployment. Instead you can simply run a web-query within Excel that returns data directly into a worksheet cell (or VBA macro). Similary, REST based services allow you to overcome the difficulties of querying data between SQL servers when ODBC or Linked-Server connections are disabled directly against Dynamics data.
Over the next few articles, I’m going to demonstrate how to construct a very simple .Net 2.0 website that can receive and deserialise URL parameters to construct a method signature and invoke the Dynamic script AIF service. Since I won’t be using active directory, I’ll demonstrate how to use IP filtering to ensure that the requests come from verified sources. I’ll also implement some basic audit logging to track the source, nature and content of the requests and responses. Finally, I’ll do some demo’s to show how data can be uploaded or retrieved from a variety of applications and platforms without the need to write or deploy CLR modules.
REGARDS