Skip to content
* / softthoughts

Use AIF features or AMM features for integration?

When we are in a situation in which we need to integrate an Ax module with other Ax modules, or the Dynamics Ax application with other applications some solutions arise and some considerations need to be made.

(Some comparisons are made between the AIF and the AMM but with no intention to fully clarify the differences.)

One solution is the Ax Messaging Module (AMM). Generally speaking it tackles integration on a fine scale.

  • Ax modules can be integrated without direct knowledge of one another and without predefined processors or processing types (sync/async).
  • An Ax module can be integrated with other applictions like MSMQ, Biztalk, or … also without direct knowledge of one another and without predefined processors or processing types (sync/async).
  • A class message definition is the core definition for integration. A message doesn’t need to be mapped with a business enity. It can be of any type: a full customer entity, a processing status, an execution command… 
  • When message handlers process a message and an exception occurs, an exception message can be send just like any other message in the AMM. Because all kinds of message handlers can be subscribed to exception messages the exceptions can be brought visible easily.

All these aspects show some light weight characteristic of the AMM and put it in a strong position to provide a uniform way to introduce the messaging concept in the Ax application and cross applications.

The Application Integration Frame (AIF) also tackles integration but in a more coarse grained way than the AMM.

  • The focus of the AIF is mainly on providing and consuming services between applications like MSMQ, Biztalk, Web service providers…
    • Compared to the AMM: Integrating  different Ax modules with loose coupling is not easy in the AIF. The focus of the AIF is on application integration.
  • Services that Ax modules provided can be called from x++ in a strong coupling manner.
    • Compared to the AMM: In the AMM no knowledge is required of other modules. The business logic of other modules can be called in a very loose coupling manner.
  • (Document/Web) Services are responsible of adding, deleting, quering, or changing data in the Dynamics Ax database. A table is the core definition for integration.
    • Compared to the AMM: In the AMM the core definition for integration is a class instead of a table.
  • AIF provides an easy way to provide quickly (no coding) services for other applications so they can do CRUD operations on the Ax tables  (enitities). 
    • Compared to the AMM: The AMM provides no quick way to do these operations on tables. The AMM is a frame where tables are not positioned as important data containers, classes are. Providing those services requires coding them for every table. Delivering data of one or more Ax tables (mostly business data) to another application is in the AMM less flexible than the AIF.
  • In the standard Ax package the focus of exchanging data is on business entities. This is the most important data of a business to exchange between applications.
    • Compared to the AMM: Any data that needs to be exchanged can be exchanged inside or outside Ax easily with the AMM without using tables and so table operations.

The post about Event Driven Architecture describes how events  (messages) can be seen as extensions of services. In the same way the AMM can be seen as an extension to the AIF. Although AMM certainly doesn’t replace the AIF at all. It is just a different way to tackle problems and so with different design characteristics. With the AMM a shift is made from tables as the main data containers (AIF) to classes as the main data containers (AMM). The message data in the AMM is not data that essentially is required to be queried. In the AIF the data are mainly business entities which probably need to be used at different moments in time and for maybe different business processes. In the AMM it are just messages with a short life span, with in its essence no intention to have its data to be stored for flexible querying. The AMM is a frame for carrying messages and processing messages, like the temporary messages in our nervous system which carry information and initiate activities.

* / softthoughts

Microsoft Architecture

For those among us who wants to bring the architect’s mind more explicit into projects, Microsoft published very interesting information about how they see what architecture means in their world and what the architectural aspects will be with/in the cloud:

* / softthoughts

Event Driven Architecture

Event Driven Architecture is brought into attention in the (latest) Microsoft architecture journal 17 and more specifically in the article: Using Events in Highly Distributed Architectures. David Chou points out that SOA can be nicely extended with the event principle and gives some extra general quality advantages provided in the application when using events (others are described here in the context of the AMM) :

  • Effective data integration
  • Reduced information latency
  • Enablement of accurate responce
  • Improved scalability, managebility, reliability, flexibility…
  • Improved business agility

When we look to the Dynamics Ax messaging module we see that it fits in the EAD as the intermediary flow manager (message broker). It propagates events in the Dynamics Ax EPR system to modules (partially) isolated by separation of concern and to applications outside the system. Also events from outside Dynamics Ax can be propagated to modules inside the system.

The events outside Dynamics Ax can use the SOA communication infrastructure or any other infrastructure. Inside Dynamics Ax all events are event objects in the object oriented architecture. The mapping of event formats and the propagation of these events is done automatically in the message broker with the use of the necessary channel adapters.

* / softthoughts

Linq for Dynamics Ax blog

The team who developed a Linq provider for Dynamics Ax commented today on a previous post and announced their product features and their new blog. Because I can only fully support every step forward in better quality providing techniques and tools 🙂 I want to explicitly point out here their comment.

Over the next few weeks we will be launching a blog where we hope to demonstrate some of the cool features of the product, as you point out it makes integration with Ax super easy.

Some features of the provider; Follows the Linq to SQL model, exposure of the Dynamics dictionary via .Net objects, VS ‘AxMetal’ Addin for generating the data contexts, Create, Update and Delete support for single and multiple row instances, full support of Ax transactions and of course retrieving data via the Linq syntax.

If anyone has any questions about the provider then please feel free to contact me.

Jonathan

If you want to download a trial version you can find it here. In my current project at AWW the use of the product is on the table for (future) evaluation.

* / softthoughts

Advanced Ax Batch

Advanced Ax Batch is a nice batching frame for Ax 3.0 and Ax 4.0 with some very interesting design goals:

1. Remove the need for a running Dynamics Ax client. Job execution is service based with better security and the ability to run in the background.
2. Increased stability by integrating Ax with the powerful built in windows scheduling service (Scheduled tasks). The integration is based on Windows communication foundation (WCF).
3. Deep integration with the event log. This gives the ability to monitor the scheduling system with event log monitoring systems.
4. Performance counters ads the ability to monitor the health of the system.
5. Manageability. Configuration and setup is Ax based with seamless integration of external services.
6. Job sequences. Execute a batch group or class depending on the result of a previous steps.
7. Highly extensible event system adds event monitoring to the job scheduling system.
8. Reduced cost by using Com users instead of regular Ax users.
9. Advanced notification through email when a job succeedes, fails or times out with detailed information from the infolog and eventlog included in the mail.

There is also a demo.

* / softthoughts

Linq for Dynamics Ax

Linq is one of .Net 3.5 most interesting new feature. It is an abstraction layer in .Net that makes all kind of data accessing more uniform, and brings understandability and declarative programming more easily into your coding.

There are Linq provides for Sql, Xml, objects… and now there is a Linq provider for Dynamics Ax. They have a nice demo that shows how easy it is and how beautifull it fits inside other .Net code. This compared with the standard way of using only the business connector framework to read data from a Dynamics Ax table.

* / softthoughts

Methodology or Method?

In the previous post I referred to a post that points out that there is a clear distinction between method and methodology, and that methodology means the study of scientific methods. After looking to wikipedia’s definition of methodology and more specific the following definition:

“Another key (though arguably imprecise) usage for methodology does not refer to research or to the specific analysis techniques. This often refers to anything and everything that can be encapsulated for a discipline or a series of processes, activities and tasks. Examples of this are found in software development, project management and business process fields. This use of the term is typified by the outline who, what, where, when, and why. In the documentation of the processes that make up the discipline, that is being supported by “this” methodology, that is where we would find the “methods” or processes. The processes themselves are only part of the methodology along with the identification and usage of the standards, policies, rules, etc.” 

I have to say that the literature I read uses the word methodology a lot in this context. Although the software literature doesn’t follow the distinction this post describes, the definition of the word methodology nowadays includes the use of word in the software community. And so our vocabulary grows with probably people for and against it. 🙂