AX 2012 - EP Warranty Management - AOT, Package & Deploy

I hope everyone is off to a great start. I wanted to continue our series today, on Enterprise Portal Design & Development, with the functional scope of Warranty Management. So far, we have had two post that has really started this EP dive. First, we focused around creating a new page on our EP instance for warranty management. From there, we were able to move forward, and add the warranty page to the navigation of our EP instance.



So far we have focused our efforts on specific task around SharePoint for page management, as well as task within the AOT for adding our Warranty Page to the Home Web Module, as a sub-Web module. This had both SharePoint and AOT specific task to complete. It's important to understand as we press forward with the focus around our EP journey that management of different aspects happen either within SharePoint or the AOT. What's also important, is that we always try to do whatever we can within AOT. This allows for correct placement of things like business logic, and further allows for us to focus on management and deployment of such created artifacts.



With that in mind, the first part of today's post will focus on adding our EP page, to the AOT itself. The biggest reason for doing such a task, is to enable promotion, version control and deployment options of EP custom artifacts from Microsoft Dynamics AX 2012.

I always like to point out existing resources that help us build upon a topic of focus, and this specific one is not different. We have, on MSDN a nice walk through of adding custom pages for EP to the AOT. How to: Import Pages into the AOT [AX 2012].

From the article.:
"If a page in Enterprise Portal will be packaged and distributed to other Enterprise Portal installations, a copy of the page definition must be imported from SharePoint into the AOT. From the AOT, the page can be packaged for distribution to other Enterprise Portal installations."

As the above states, and why we care to focus on this point, in order to package and deploy a custom page from one instance of AX 2012 to another, we need to have the page's definition living as a part of the AOT. This is a paint point that existed before with EP, and now with AX 2012 - packaging and deployment of EP pages has become easier. Lets now take the time, and do a walk through for adding our custom idbWarrantyManagement page definition into the AOT.

This is a very straight forward task, and it builds upon having successfully tied a URL Web Menu Item, to our custom page. Having done this, we simply need to highlight our URL Web Menu item, right click and then left click on import page.



Having done this, we should now see our page living under the AOT / Web / Web Files / Page Definitions. Keeping with best practice's for Microsoft Dynamics AX we need to make sure and create a new project group, and place our page definition within our idb project, as shown below.



From this point, we are now able to promote the page, along with any other scope we create for our Warranty Management Enterprise Portal Solution. This allows for ease of deployment, to help close our this post we have another MSDN walk through.: How to: Deploy Pages from the AOT [AX 2012]

To finish this then, once we moved our project, via Model File, Model Store or XPO - to a target instance of AX 2012, we can simply highlight the page definition, right click and left click on deploy. It will use the web site information we have setup for Enterprise Portal, contained within the System Administration module.



That's all I wanted to cover on this part of the Enterprise Portal post. We will continue with this series, as we move forward and add tables, classes, and web forms in a View-Edit design pattern choice. This will be to manage our Warranty Management master & reference data. I hope everyone has a great and productive week. Check back soon as more to come! Till Next Time!
Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

AX 2012 - Common EP Development Task

I hope everyone is doing well this Friday! I wanted to spend just a little time this morning, to post and setup one of the next series of articles I will be focusing on. With the release of Microsoft Dynamics AX 2012, Enterprise Portal became a First Class Citizen client for the solution. It has a similar look and feel to Office as well as the Rich client, which helps create a unified user experience across the entire solution.



With this understanding, I wanted to start a series on Enterprise Portal Development, that will go along and merge with the focus I've had recently on Business Intelligence. The two will cross, as we move into Team based BI and Organizational BI.

To be able to kick this off properly, and make use of the great content Microsoft has provide to us, lets look at the following resource.: Common Enterprise Portal Development Tasks [AX 2012]

The above list gives some pretty good information on the common task that take place around the development processes and common task for EP development. This includes creating custom pages, custom forms, and even using workflow with EP! My plan around this series, is to make sure to reference into this resource pages, but also take and add value around it. Having screen shots, food for thought, and any gotcha's and planning points that you need to look at.



With this in mind, I wanted to reference back as well to what I lasted posted about for Enterprise Portal Page Interaction Patterns. We need to keep this in mind, around the design for EP focused development. In order to help start this focus around EP development for an instance of AX 2012 then, lets target our first focus, for what we will develop. With that in mind, lets start with the first page interaction design pattern of View & Edit interaction pattern.

We also need a functional scope that we are trying to achieve with this, to have some meat to this series, similar to what I've done so far with the personal BI series, with a focus on Customer Aging & PowerPivot. With that, lets focus on creating a basic Warranty Management solution for AX 2012 that is 100% focused for Enterprise Portal as it's target.

Well that's all for this Friday, I hope that everyone has a great weekend and your excited about diving into EP. Keep checking back as we continue our focus on BI, Development, Book Reviews, interviews and more for Dynamics AX and Dynamics in general! I will leave you with one more resource, which is the what's new for Enterprise Portal for AX 2012.: What's New: Enterprise Portal in Microsoft Dynamics AX 2012 [AX 2012]. Till Next Time!
Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

AX 2012 - AX-SSRS Report Design Concepts

Recently I have been focusing on the BI and reporting aspects that come as part of Microsoft Dynamics AX 2012. There is a lot of great resources for this topic, and it's a topic that drives a lot of value, when speaking about AX 2012.

Since this is the case, I wanted to continue my focus on reporting, with this blog post, focused on the two categories, if you will, of types of AX-SSRS reports. These are Model Driven Solutions and Code Driven Solutions.


Model Driven Solution Diagram

First up, lets talk about the model driven solution, in terms of AX-SSRS reports. When speaking about the model driven approach to AX-SSRS report development, the focus is around the use of Query objects, from the AOT, to model your report with. The idea, with such reports, in that very little X++ code is needed to enable them.

This path, should be favored as much as possible, as it's the least amount of TCO in terms of report development. With this approach, and with report design in general, we have the report itself, and surrounding it is the design, data and control aspects of the report.

When talking in terms of the model driven approach, the design, as you can see from above is created within Visual Studio 2010. Further, the data aspect, is represented via a Query object, and a good example of the control for such a designed report is ranges.

Keep in mind, when thinking about such design patterns, that the Query object is meant to be a re-usable API in AX 2012. The same query object that powers a AX-SSRS report design, could also enable a PowerPivot report, or could be used to help define and deliver Contextual BI elements, say for an InfoPart.

Moveing forward with this thought process, lets look to the next category, for AX-SSRS report design. This is the Code Driven Solution.


Code Driven Solution Diagram

With this concept, we have our basic design elements, or constructs for reference. It's the design, data and control points. Looking at the above diagram and comparing the code driven solution vs. the model driven, we see that at the heart of the design, is still Visual Studio 2010.

Beyond that though, these are much different than the Model driven solution, and the use of queries. The idea for this concept, is when code is needed to create the data behind a report. When this is the case, the data, for the above is represented by RDP, or Report Data Provider. This is a new class type for AX 2012, that enables the ability to design more complex reports, when the need to "mash" data from different sources arises.

Moving along with this concept, we also see that for the control, we have a Data Contract. This too is new to AX 2012, and we have seen some of these, in my coverage of services in AX 2012..

The data contract, when used in a design pattern that is laid out in the above, is meant to act as a simple class, that ties extended data types, that represent the data contract properties, to the report design itself. Enabling, therefore, the correct formatting of data, based on underlying table and data type designs.

With these two concepts in mind, we can start to move forward with report design. A big focus, and understanding point needs to be seen here. That is, you don't see the mention of BIDS, or Business Intelligence Development Studio. That is the standard SSRS design piece. The reason this is the case, is that VS2010 and a special project type are used to enable the creation of AX-SSRS reports. BIDS is actually hosted within VS2010, at least the design space is, so once in the VS2010 project, it's very familiar process for those use to using BIDS. However BIDS, and standard SSRS reports are not meant to be used in delivery data, with AX 2012.

To help you further, with learning these concepts, there are a couple of resources I would like to point you to. First, the Microsoft Dynamics AX BI team blog: Dynamics BI Team Blog. This is a resource I have highlighted before, and one I want to make sure everyone is aware of and makes use of.

Also, the same team, behind that blog, creates YouTube videos, at the following YouTube channel: Dynamics AX BI YouTube Channel. Here again, we have another great resource, in which the main topics of this post are discussed more fully, and taking to a deeper level. Some really great video's out there, so I highly recommend reviewing them, as you can.

Finally, Microsoft recently published the Whats New: Reporting for Developers in AX 2012. This is a really great resource, espically for those that have done AX-SSRS report development in AX 2009. All the concepts contained within that page, need to be fully understood, so that you can take full advantage of all the great improvements Microsoft has given us with this release, around report development.

Well that's all for this post, check back soon though as there is a whole lot more to come.

Till next time!

Follow Me @:
    

"Visit the Dynamics AX Community Page today!"

AX 2012 Design Patterns: Instantiating Objects

Recently I created a resource blog post, focused on AX 2012 - Design Patterns Overview. There are a lot of things we need to understand about design patterns with Microsoft Dynamics AX 2012. The return, and value in understanding these, is being able to have correct designs, when working with custom scope.

With that, lets take a little look at some of these. First up is: Instantiating Application Objects Design Pattern. What's interesting about this design pattern, is the very first thing you read from the post on MSDN.:

"You must use menu items to open application objects instead of opening them directly. Menu items can be seen as APIs to the application. They are an abstract layer (interface) between the user and the actual application object that implements the functionality. Changes to application objects are automatically reflected in the user interface when menu items are used."

Menu Items, have always been used actually, around objects like Forms, Reports, and Action classes. These action classes, usually were focused around RunBase and RunBaseBatch. That is being replaced with the SysOperations Framework however. Still, the SysOperations Framework, or Business Operation Framework, artifacts are surfaced to the user and controlled by this API of menu items.

Once more, we have some nice Community content on this specific design pattern, from Martin Dráb.:

Notice that FormFunctionButtonControl class has a menuFunction() method. It allows to easily access MenuFunction instance on forms.
For example, you can define custom parameters in menuitembutton's clicked() in this way:

Args args = new Args();

if (something)
    args.record(ds1);
else
    args.record(ds2);

this.menuFunction().run(args); 

So the idea should be firm then, in that when possible Menu Items are what should be used to instantiate an object. Now there are other times, in which you need to instantiate and object that a menu item just does not fit the bill. In those times, you should use the ClassFacotry.

Doing this, will make sure any subclasses will fire correctly, and that the correct sequence of calling an object like a form, report or action style class is properly handled. There is a big note on this design pattern, that changes what has been used in the past for AX. That is: Never use the FormRun or ReportRun methods for directly instantiating an object.

A lot of developers, and customization's have been done in the manner in the past, and this is a big no no, now. Keep this in mind when doing actual development work. Of course, you still have custom class objects, and table objects within X++ code, that have a static create, or a new() call to work with them. However even with these concepts, if you can use the design pattern of making use of menu items for these scope and need as well, then you have a layer of abstraction that can be used to connect, and help drive parameter based callings of an object.

Well I hope this helps in our first dive into the design patterns in AX 2012. I think this is a very important one for developers to understand. The FormRun and ReportRun is something I've seen a lot, and in earlier versions of AX development I used myself.

That's all for now, check back soon as more to come. Till next time!

"Visit the Dynamics AX Community Page today!"

AX 2012 - Design Patterns Overview

With the release of Microsoft Dynamics AX 2012, there is a lot of wonderful new offerings that has come along with this release. One of the area's of major focus, that should be understood, by all technical personnel is around design patterns.

I wanted to take the time, to kick off this series of post, about design patterns, and review what resources we have from Microsoft, on these topics. Then I would like to dive into examples for each of the design patterns, talk pro's and con's, and finally value that each can add to a given implementation of AX.

Some design patterns will have deeper running affects, than others, however all are equally important to understand. To kick this off properly then, lets review the design patterns I will be covering in this series of post. First off, we have the official home on MSDN for AX 2012 Design Patterns: Microsoft Dynamics AX Design Patterns [AX 2012]

From there, we have the following list of design patterns, that need to be understood when considering techniques and approaches for technical solutions and designs.:

• Instantiating Application Objects Design Pattern


• Searching for Records Design Pattern


• static find Method Design Pattern


• static exist Method Design Pattern


• Parameter System Design Pattern


• Multiselection Design Pattern


• Searching for Multiple Occurrences Design Pattern


• Change Company Design Pattern


• Partner Hooks Design Pattern


• Pack-Unpack Design Pattern


• Use the Type System Design Pattern


• Storno Design Pattern


• Persistent Data Storage Design Pattern


• Data Validation Design Pattern

With the above list, I plan on diving into each of these design patterns, referencing back to this post and each of the official homes on MSDN for each topic. Some of these design patterns I have already touched on, like the un-pack and pack, etc.

I can't stress enough the importance of understanding each of these design patterns, and why I plan on spending weeks, covering these in several, several post. Some are easy and straight forward, therefore I will combine a few design patterns per post. What I hope to get to, as I mentioned above, is to talk about the design pattern, some real world example code in how it's applied, some pro's and con's and then value.

Just looking into some of these, you can see Microsoft is trying to implement software designs that have worked well in other places, as well as some of these patterns continue us down the path of abstraction away from being so close to the source, when we do modifications.

That's all for now, but check back soon as a whole lot more to come! Till next time!

"Visit the Dynamics AX Community Page today!"

AX 2012 Reporting Architecture Model Review

With the release of Microsoft Dynamics AX 2012, so many great improvements have taking. One of these area's that has improved greatly is the reporting model used.

In AX 2009, there were two reporting model options really, the X++ reports, and SSRS reports. The option for SSRS reports however had some limits. For example, sub-reports would not work correctly. Also, the ability to use Query objects as the default datasource was limited by the fact of now being able to do outer joins easily with the Query object designer for MorphX.

This is changed however, AX 2012 has a single reporting model, which it uses SSRS for all reports. Now, let me state it is true the older X++ MorphX reporting model is still technically in AX 2012. It's Only there however for backwards compatibility, and is not meant for supporting new development efforts.

Looking at what we have now, there is a very nice, and straight forward MSDN article, that walks through the reporting Architecture from Menu Item, to Report Viewer rendering of the report data. MSDN: Reporting architecture [AX 2012]



We can see that, in the reporting model for AX 2012, SSRS is at the core of reporting. Also, with the improvements that exists with AX 2012, for example adding the keyword having and it's use within Query objects, as well as the ability to have left and right outer joins, easily setup as part of Query objects, the hurdles that existed for SSRS and AX 2009 are all but gone.

This also means, that those who chose to use a hybrid approach for report design in AX 2009 and SSRS, where as the report design included going straight to the Database, creating a new for duplicate security models, no longer is a need. You should never, ever, ever, ever, ever --- ever go directly to the Databases for anything in AX 2012. (hope that's clear!)

If you did go directly to the database, then my recent article on the use of XDS would break as it would not be applied. In AX 2012, if a user does not have access to a field that is part of a report, and the report is rendered correctly through AX+SSRS, then the data for that field will not appear in the rendered report.

I think this is a huge improvement, and there are some really great MSDN articles as well as video's that cover all kinds of reporting examples with the new Reporting model concepts. This area is for sure right on the marketing tag line of Powerfully Simple, as this is a vast improved area over previous versions of AX.

Well that's all for now, check back soon as we continue to dive into AX 2012, get into more Workflows, Security Model, Neat X++ things, as well as launching a new series this October of post, "Freaky Tech Friday's". Till next time!

"Visit the Dynamics AX Community Page today!"

MSDW: Getting Ready for Development with Microsoft Dynamics AX 2012 - Part Three: Approach

With the release of Microsoft Dynamics AX 2012, a lot of focus in around the new ways things can be achieved. Specifically around development. A lot of great technologies, and new ways to achieve solutions to business issues do exists.

Because of this, I started on MSDynamicsWorld.com, a series of articles called: Getting Ready for Development with Microsoft Dynamics AX 2012.

In this series, I started with the Vision, and from there went into the Training, and now I have the latest entry in this series over at MSDW: Getting Ready for Development with Microsoft Dynamics AX 2012 - Part Three: Approach

In this latest article, I try to make a very clear point: Use Common sense, and let business requirements, along with best value, drive design and development task.

As I point out in the article, there is no way in a single post, or series even, that I could cover the different aspects and points of approach for Development in AX 2012. This deserves an entire book, or multiple books.

I hope you agree with my statements, and think about the business value for the technical task that are being suggested, and the approach / path that is desired.

That's all for now, till next time!



"Visit the Dynamics AX Community Page today!"

Microsoft Dynamics AX 2012 - A Dive Into Services

With the release of Microsoft Dynamics AX 2012, services are a key role that enable many parts of AX. This includes from Office, to internal use, to extending and working with complex datasets, and even to expose custom busienss logic.

To help better understand services in AX 2012, lets first take and understand what services means. There are three distinct service context, which are.:

• System Services - These are services that come as part of AX 2012 offering,
  like the Metadata Service, User Session Service & Query Service
• Document Service - This carries similar concepts and design on previous version of AX, in that a document service is meant to wrap complex datasets, for CRUD based operations. There are some differences now, and we will review these.
• Custom Services - These are meant to wrap simple datacontract needs, or to expose custom business logic. I will note here: These are never recommend to handle complex data operations. Use Document services for that.

System Services
System Services are meant to give a window into the Dynamics AX 2012 world. Part of that world involves Query Service, as well as the Metadata Service. These two services are meant to be very specific uses. The Query Service is meant to take and offer an ad-hoc ability to query datasets, from AX 2012. Now I must say this should be used with caution. If this query, or integration is meant to be re-used in any fashion, you should build a query object, and create a document service from it.

There is a pretty decent example on MSDN, that shows how to use a Windows Form, and Dataviews / grids, for showing off the power of AX 2012, and the Query Service, located here.: Walkthrough: Calling the Query Service with a User-Defined Query [AX 2012]

The meta data service is meant to give the ability for other LOB applications to query against to allow AX 2012 to self describe information about objects that reside within the system. Here again, the use should be limited.

Document Services
Document Services are meant to truly be the path, in which any real complex operations of CRUD, or Create, Read, Update & Delete, operations are meant to be executed via. The idea here, is that a Query Object, or set of Query objects created within the AOT, represent a document service, that is deployed, and consumed by either AX itself, or other LOB systems.

This includes both master data, like EcoResProduct (or Products), as well as Customer, Vendors, and event transactional data like Sales Orders and purchase orders. This has improved a lot since a AX 2009, and the ability to quickly deploy such services in AX 2012 is now such an easy task.

Custom Services
Custom services represent, to most C# developers, something that has been common for a little while. This is, DataContracts, and Service Oeprations. As mentioned above, this is not meant to represent complex data opertaions, but instead, to expose simple data contracts, as well as custom business logic through service operations.

Finally, There are some guidelines when thinking in terms of use of services, which include design patterns around "chatty" services and integrations.

Where possible, it should always be considered, to take and perform the least amount of calls as possible. This means instead of sending a single Entity Object that represents a Document Service create, for example, for a given table, per service call, the better approach would be to build up a collection of said objects, with a single call for the entire collection.

Of course, this might not be always applicable, where you look to transactional data needs, where the very nature of the integration leans towards possible one-off single calls. Still having this kind of design approach in mind, will help in *not* creating possible performance issues around your services related integrations and needs.

There are also other topics, that I will continue to dive into from this post, including the use of Query Objects being represented as OData feeds, and a deeper dive into the Business Operations Framework and the use of the SysOperations for enabling service use to replace the RunBaseBatch framework for business logic and reports.

That's all for now, but check back soon as I dive deeper into each of these topics, and show off real world examples for each. Just keep in mind, the idea is to abstract and extend via SOA, or service-oriented architecture. There should never be a reason, now, to ever go driectly to the AX 2012 database. All interactions, should always take place via the application layer, and typically through services.

Well that's all for now, but check back soon, as more to come! Till Next time!



"Visit the Dynamics AX Community Page today!"

Microsoft Dynamics AX 2012 - At your Service

Yesterday, I talked about Business Operations Framework for Microsoft Dynamics AX 2012.

This touched on a new concept, that will take us away from RunBaseBatch, and other concepts in AX, and move us towards some of the new features, that have never existed before, with the SysOperations Framework, and into true SOA approaches within, and extending AX.

Today, a new post from Microsoft, that continues a series well into the launch event for Microsoft Dynamics AX 2012, has arrived. I'm talking about the following post.: At Your Service: Microsoft Dynamics AX2012 Integration and Web Services


Caption: In Microsoft Dynamics AX 2012, inbound ports provide a logical grouping of services, which model specific integration points between the ERP solution and an external system.

From the post.:
"Standards-based web services are undoubtedly the programming model with the widest possible reach across platform boundaries. In Microsoft Dynamics AX 2012, we have greatly emphasized the role of services, both in integration with other line-of-business applications and as a programming model to expose the rich functionality of the application. We believe these enhancements will benefit our customers by significantly reducing the time it takes to develop custom applications and by enabling the enterprise resource planning (ERP) system to reach the entire organization."

Service are for sure the future with development, inside Dynamics AX, as well as extending AX, and other LOB applications reaching into AX. This is the vision and the desired goal.

Embracing this now, as an Architect, Developer, and general AX consultant or company, will help you and your clients reach their full Dynamic Potential that drives business value, while taking advantages of the latest technology advancements.

Is critical, that we take into consideration all that Microsoft Dynamics AX 2012 brings to the table. Doing so will help shape the business world, from the older, strict, and cumbersome business systems of the 90's that so many Dynamics Competitors shove down their clients throats, and bring to the forefront what end users, and business users need, today. Dynamic, Flexible & Scalable business processes, that adapt and grow, as the business that implement and need them.

That's all for now, but check back soon, as a whole lot more to come, including interviews, blog spotlights, continued dives into AX 2012, and more! Till next time!



"Visit the Dynamics AX Community Page today!"

Development Choices with Microsoft Dynamics AX 2012

One of the current white papers that has been released as part of the public beta for Microsoft Dynamics AX 2012, is around your choice as a partner or customer, and how you develop and customize AX.

A direct link to that PDF white paper can be found here.: Selecting the Best Development Technology for Your Application Development Scenario in Microsoft Dynamics AX 2012

This is a really good white paper, and helps further cement the fact that with Microsoft Dynamics AX 2012, you really do have a choice in how you develop ISV offerings, and even customize AX for your unique needs as a customer.

It shows the power of Microsoft Dynamics Tools for Visual Studio, single repository, and the fact that X++ compiles down to CIL, which is the runtime language base for all .Net managed code.



I will point out the fact, that this paper does take and try to make a point that X++ is harder to learn for C# developers. This is not at all true and honestly I'm a little disappointed in the authors in making this statment.

X++ by far is a super easy sytnax to learn, and it being harder to learn over C# is not a valid arguement.

The biggest learning curve with AX that exists, and has always existed is where to put things. With AX, you can place code and business logic elements at the data, business and user layers through table methods, classes and forms.

What should be taken away, and what helps really shape where and why you should choose X++ over, say C#, is all about context. What is the context and nature of your mod, it's designed usage, and it's scale need.

If, for example you are developing a new business logic that will be used with Microsoft Dynamics AX 2012, as well as other LOB apps, and maybe some web based use, then C# WCF service that can run on-premise or in Azure is the best choice.

However, if your doing code changes to some core aspects of AX, adding a totally new module, then pure X++, or at least some X++ with hooks and events firing into C# will be your route.

From a technical aspect, it is important to understand that with Microsoft Dynamics AX 2012, there is a true interop and native calls between X++ and C#, as well as vice versa. This does open the door to all kinds of possible new ways of achieving business value add.

The bottom line, for anything to do with an ERP platform, should be governed and driven by business value add, and really not at all by technology.

If you don't have a known ROI for doing something, then you should not do it. X++, C# or anything.

So this is a great white paper, that helps highlight some good facts and context of why a pure .Net language like C# might be choosen to use over X++, still it should be tempered with real business value add, as well as the fact that both X++ and C# are tools used to create a means to an end. That end, is very Dynamic and ever growing, and the end is bottom line dollars to you as a customer, or your customers.

That's all for now, check back soon though as more to come!

"Visit the Dynamics AX Community Page today!"

MSDW: Getting Ready for Development with Microsoft Dynamics AX 2012 – Part One: The Vision

Well as I promised last week, my next focus for coverage of Microsoft Dynamics AX 2012 would be around Development.

When I started to sit down and write about this, I realized very quickly this would be best served as a four part series. I also am using MSDynamicsWorld.com to write this series of articles on.

So the first in the series in on Vision, and a direct link to that first series in the article set can be found here.: MSDW: Getting Ready for Development with Microsoft Dynamics AX 2012 – Part One: The Vision

This is not meant to be a total encompassing technical coverage of development within AX 2012, but rather to help set the stage for the Vision for Developemnt with Microsoft Dynamics AX 2012.

From here I will continue the series with: Training, Approach, & Execution.

When the series is complete, I hope that a better understanding will exists from a higher level, that will help us all be ready to take advantage, and continue to extend our ROI for what we are already doing with AX.

Enjoy and till next time!

"Visit the Dynamics AX Community Page today!"

Continued talks of Integrating Dynamics AX to the outside world

Recently I posted the following blog entry.:
Integrating Dynamics AX 2009 with the outside world

This was the start of looking at all the different ways you can integrate the current version of Dynamics AX to the outside world.

As I said in that post, I wanted to move forward which each different type, talk about real world examples, and what I have seen fail and work.

A reader posted a comment on that blog entry, asking.:
"... more and more data needs to be shipped to and from Dynamics AX. What options have been more successful for you when implementing ..."
- Nathan

Nathan, you have great point there, and that is why I wanted to start talking more in depth about this topic. You see, like all things there is a lot of different ways to achieve something. The best answer, or correct answer, has a lot of inputs to reach that.

Same as the cloud conversation, common sense and functional ends should drive the means. This is true also for integration, though integration, it terms of pure integration is mostly technical.

Still the functional ends, should be the driving factor. And what do I mean by that, in this case?

Lets look at some examples. If for example, you have desperate, decoupled older systems that need to talk with Dynamics AX. And this 'conversation' or integration needs to happen in an asynchronous manor, with sometimes queue delivery of data and information. Then looking to middleware, like MSMQ might be something that is considered.

Taking the route of MSMQ, though, brings is on set of enabling functions, and limits with size, performance, and timing.

I have seen a good MSMQ integration work before, but I have seen more bad MSMQ integrations developed for integration into Dynamics AX than good actually. And maybe bad and good are wrong terms. Instead of bad, because MSMQ did what it was told to do, it's more the implemnetations driving functional ends did not really call or have to have an asynchronous integration to reach those ends. Only a part of it did, and since a part of it did, the entire thing was feed through that same channel.

That brings me to another point, a lot of the times a single channel for intergation is not always the best option. Sometimes, depedning on the functional ends or nature of a given process, it could be that a system to system intergation needs more than one channel for communication.

So for the truly needed asynchronous integration point, of queue data, MSMQ be used. But for the other integration path that can handle synchronous, event based integration points, .Net Services / Web Services would be the best approach.

Sometimes technology is the limiting factor, and when that is the case, you have to take the best route for the given limit. For example, it could be the only way to integrate with a given older system is through COM objects.

If this is the case, and you wanted to design some kind of workflow driven, 'smart' integration that could handle errors, routing, and failures. Things that come with newer technologies. Then it might make sense to wrap those given COM objects in .Net Workflow based Service. Where the .Net Service is the exposed integration to Dynamics AX, and it wraps the needed COM objects.

To wrap this conversation up, for now, and get directly to Nathan's question. 'What options have been more successful', I personally have seen many of the mentioned options both suceed with high and low degrees of sucess, and fail as well. It all goes back to the functional ends.

I guess it would be better to change the question, just a little bit, to say which one's have I seen fail the least. That, because of the nature of the integration, would be synchronous integration points. Be that Flat file, .Net Services / Web Services, direct calls to COM or .Net assemblies, etc. These are usually very event driven, easier to debug, understand, and don't usually have as many layers of abstraction.

That's also not to say that layers of abstartction are bad. In designs, if done correctly, the right amount of abstraction is a good thing. This is also not to say that asynchronous should not be used. I am not saying that at all. I am just trying to get across that what should be used, should only be used, based on the functional ends. If a functional ends, or technology limiting means extist and drives to an asyncrhonous type of intergation, where MSMQ or some other form of middleware, message delivery system is needed. Then a correct design and implementation of that, will help make that a success.

That's all for now, thanks for the question Nathan, and check back soon everyone. More great post are coming out.

See you then!




"Visit the Dynamics AX Community Page today!"