AIF Services and the .Net BC - Where and When?

One of the sessions I attended at Convergence 2010, was the AXUG Software Architect SIG. The initial coverage post for that session, can be found at the following link.: Coverage of AXUG Software Architect SIG at Convergence 2010

In this, a good bit of topics were on the minds of the people who attended. One of them was around AIF Services and the .Net BC. What a good bit of discussion for this surrounded, was where and when to use either?

As promised in the above post, this is a start into digging deeper into the topics covered during that session. So for this When and Where should AIF Services or .Net BC be used, when connecting into a Dynamics AX instance?

This is a valid question actually, as both offer the ability to interact with Dynamics AX. Both offer different pro's and con's as well.

Lets look at the nature of these two different paths for interacting with Dynamics AX from an outside application, service or other LOB application.

First AIF Services. AIF Services are targeted specific end points for document exchange in and out of Dynamics AX, on a transactional, one off level. These services are generated from an AOT Query element, and make use of Axd* Classes, which in turn AX uses to generate the WCF Services that end up being hosted in IIS.

These are WCF services, and so when consumed by a .Net Application, BizTalk, or other LOB Application, will interact as such. These services represent Dynamics AX "Documents". Which could be reading a customer, a sales order, creating a purchase req, or any custom AIF Service you create.

From looking at past use, and desgined nature of AIF Services, these best serve the one-off, transactional calls. Meaning, if the nature of your integration is calling to create a Sales Order, or lookup a customer, then AIF Services are best suited for this type of interaction. Notice the key on "a" meaning singular interactions, with distinct returned result sets.

Moving on to the .Net BC, it offers a different type of access than the AIF Services. With the .Net BC, you get direct access to AOT objects. So you could in theory, access the Query object that a given AIF Service is created from, directly. Not sure why though, other than to look up information. :-)

With this direct access, that means you have direct access to X++ classes, tables, and business logic directly.

So the nature of the .Net BC, is meant to expose to .Net based code / assemblies, the AOT, for working with the AX AOT objects and business logic, directly from .Net.

AIF Services, there is a layer of Abstraction, and therefore a layer of possible extra validation, and context control over data, that would not actually exists through the .Net BC.

Looking at these two options for working with Dynamics AX, still we have the question of Where and when? Since we have a base understanding of the nature of these two choices, lets move forward in answering this question.

Since AIF Services are meant to act in the "a", singluar transactional nature, consuming a AIF Service is best for when you have calls in the nature and context of creating, reading, updating or deleting (CRUD) data, in the form of "Document" based information. This could include creating a sales order, a purhcase req, looking up information on a item, or a customer.

Comparing AIF Services, to the .Net BC for achieving this same need, I have seen the AIF performs better, and is best suited for this. Also using the AIF for these needs, you end up having that layer of abstraction that enables control of the how data is accessed, and the shaping possibly of that data in a uniformed control fashion.

The other benefit for using AIF Services, is was generated, enables the creation of composite applications, that include AX with an SOA type of architecture in mind.

Moving to the where and when for the .Net BC, lets say you have a need for pushing in a massive amount of data? Or you want direct access to maybe having a complex LOB application workflow, that is deeply tied to the business logic in Dynamics AX, that might actually live in X++, and want to expose and reuse that.

Then .Net BC is best suited for this type of integration, and performs better. It performs best with larger amounts of bulk data, or the need for exposing possibly complex workflows, or deep X++ business logic, or custom X++ business logic, and having that tie in with other LOB applications or Enterprise needs.

I hope the above helps answer some of this, and I welcome any comments from anyone on their own thoughts for this topic.

If we look forward with Dynamics AX, take a look at some of my past post. AX internally even will be making use of AIF Services for "document" level integration and data flow needs. Also AX moving forward is turning into a true Managed Code, at the kernel ERP package. This means tighter integration for the AOT into .Net, in a more native fashion will exists.

That's all for now, but check back soon, and again feel free to leave comments on this topic!

"Visit the Dynamics AX Community Page today!"

Dynamics AX 6, DotNet 4 and the WF Designer

A fellow blogger, Anass, over at AX4All.blogspot.com sent me a recent blog post he did, covering the Channel 9 video of Josh Honeyman (Principle Development lead for Dynamics AX workflow), that walks through the use of .Net 4.0, the Workflow Designer, and how it will be used in Dynamics AX 6.

Anass write up about this video can be found here.: Dynamics AX 6.0 and WF4

The video, can be seen here:


In this video we get to see Dynamics AX 6 in action with the .Net 4.0 Workflow designer being used to help create and manage business process workflows. This is highlighted to help reduce the need for code, and the transition into a more model drive development approach.

I first covered this in the following post.:
Dynamics AX, SOA and Oslo on the mind

" In the very near future, [Dynamics AX] will be improved with .Net 4.0 and WF, along with a new designer for the workflow that will be Visio like. The workflows will be easier to manage and offer more flexibility, with less code."

That was over a year ago that I first wrote about .Net 4.0, WF and the Designer, and how it will change the way Dynamics AX processes are created and controlled, with the goal of less code. That same post also talked about Olso, now SQL Server Modeling.

So we can see all these technologies coming together, and how Microsoft leverages research in other products groups, to help Dynamics AX.

This was actually a big topic at Convergence 2010, how Microsoft Dynamics AX team gets to leverage the research in .Net, Office, SharePoint, SQL Server, and beyond.

The idea, as pointed out, is to make Dynamics AX deployments, use, modifications, upgrades, the entire ownership lifecycle of a Dynamics AX investment, for agile, and bottom line being.: Better, Faster, Cheaper

I would like to thank Anass for the post, and his insight, coverage of this video. This is also a topic well covered in the interview I held with Microsoft's Mike Ehrenberg.: Interview with Microsoft Distinguished Engineer - Mike Ehrenberg


The above is from the video, that is the Business User interface. That is not the developers interface. And it's the out of the box DSL, or Domain Specific Langauge (Ref: SQL Server Modeling).

This is some powerful stuff, and can't wait to see how this speeds up deployments of Dynamics AX 6 and beyond!

That's all for this post, however this still part of the coverage from Convergence, in which I have a lot more to post about, including another interview, focused on Dynamics AX team that I did while at Convergence.

Check back tommorrow, as more great post are coming!

"Visit the Dynamics AX Community Page today!"

Microsoft .Net 4.0 - Parrellel Computing Platform

Recently Microsoft released .Net 4.0 RC, along with Visual Studio 2010 RC. With .Net 4.0, there is a lot of improvements. One of the things I have found very interesting is the move for more native support in managed code to create and make use of parallel computing.

With .Net 4.0, Microsoft has released it's "Parrellel Computing Platform (PCP)".



With this, some very interesting new developments exists, including PLINQ or Parallel LINQ. The following link, is a MSDN resource for samples that can be downloaded and studied for how to make use of the new PCP.: Samples for Parallel Programming with the .NET Framework 4

From the link.:
"The .NET Framework 4 RC (Release Candidate) has been released and is available for download at Microsoft .Net 4.0 Framework Download. .NET 4 includes significant advancements for developers writing parallel and concurrent applications, including Parallel LINQ (PLINQ), the Task Parallel Library (TPL), new thread-safe collections, and a variety of new coordination and synchronization data structures."

Now lets put this into some meaningful scope for Dynamics AX. With Dynamics AX 2009, LINQ was really first being used and introduced, through the use of .Net 3.5 framework with Dynamics AX. This includes the enablement of Reporting Services reports, accessing Dynamics AX data and usage of the .Net BC.

The next release of Dynamics AX 6.0 or Dynamics AX 2011, set to be released now in the Q1 of 2011, will be more and more .Net native and enabled. And in actual it will be .Net native because the kernel of Dynamics AX 6.0 is being recompiled to IL or MSIL, which is what all .Net laungages are compiled down to and executed via the CLR.

With the upcoming Dynamics AX 2011, .Net 4.0 is going to be the .Net Framework of focus and use, and the ability to do Parrellel development in Dynamics AX, custom at that, is going to become more and more a need.

Just go back to a recent post of mine, focusing on Threads in Dynamics AX 2009.: Dynamics AX 2009 - X++ Thread Development

In that post I talk about how Threads can be used in Dynamics AX 2009 today, and give example of how, and what to look for in developing such threads. As we push further and further in Dynamics AX vNext versions, including Dynamics AX 2011, such technologies as .Net 4.0 and the Microsoft Parrellel Computing Platform (PCP), will become ready for use.

This means that the Entity Data Frameworks, LINQ, now PLINQ, and the alike will be possible for use with your given Dynamics AX solutions.

Now lets think about some examples in Parrellel needs? MRP? Forecasting? Data Imports? MDM? CPU, Disk and RAM heavy processes that could be developed with Parrellel Processing at the heart to take full advantage of the hardware of given Dynamics AX instance is on.

Of course this is just scratching the surface of the ability such a platform is going to offer Dynamics AX customers as we move closer and closer to Dynamics AX 6.0 and beyond.

Business needs and processes across multi-sites, locations, timeszones, all the processes that make a business run, will have a new tool to help make those processes possibly run faster, connect faster, interact faster, and overall be faster. (I think I said faster right? ;-) )

I will note that this Parrellel Computing Platform was first really spotted in the Microsoft Robitcs SDK, and that was one of the reasons that SDK got so much attention. Now we have this, and I recommend checking it out, and start thinking in terms of what this will and can offer for Dynamics AX business needs.

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

Update:
I wanted to give a quick update. After looking at some of the sample applications, I was able to see, that for the babies example, if you have a quad core machine, executing the standard seq. LINQ query, and run a query that takes 5 seconds for example to return.

If you notice only a single core is used for this processing. Now if you run the same query, except it uses PLINQ for example, the same query takes only 1.5 seconds. That's a 70% improvement! And guess what? The code is nearly the same, and same amount of lines.

This is an amazing ability for code performance, and I can't wait to see how this might can be used and affect Dynamics AX 6.0!




"Visit the Dynamics AX Community Page today!"

Quick Post: Catching ClrErrors in X++

I wanted to do a quick post actually with some X++ code. I know this exists already on the web somewhere, but it's always handy code when working with .Net Assemblies, WCF Services, etc.

So the following is a great way to catch and see what all is going on with any .Net error being thrown.:


System.Execption ex;
str ClrErrCatch;
;

try
{

// Do some code work here...

}
catch (Exception::ClrError)
{

ex = ClrInterop::getLastException();

if (ex != null)
{
ClrErrCatch = ex.get_Message();
ClrErrCatch += ex.get_StackTrace();
ex = ex.get_InnerException();
if (ex != null)
{
ClrErrCatch += ex.ToString();
}
}

error(ClrErrCatch);

}



Now the above assumes your making correct use of CAS, or Code Access Security, with an InterOpPermission.Assert() going on.

The point with this post is to give a good template for working with Clr errors. This includes anytime you reference any of the System.* .Net Assemblies, your own custom .Net assemblies, and also Service references of any type, be that Web or WCF.

Check back soon, as more good post are coming on. Also this can be included in our WCF series of post going on as well.




"Visit the Dynamics AX Community Page today!"

DotNet Reactive Framework (Rx)

Since DotNet / .Net is very much a part of Dynamics AX in 2009 and even more so in 2011 version, I thought it would be nice to take deeper steps into the .Net world, and learn some new ways to achieve things that might help you in your development efforts.

In these .Net post, I plan on doing pratical post about things that can be used in today's world, and also future talks.

Something that call my eye, for a not-to-distant future .Net framework, is the .Net Reactive Framework (Rx)

That link will take you to a Microsoft Ch. 9 posting for an Expert-to-Expert video on the Rx Framework.

From the site.:
"The .NET Reactive Framework (Rx) is the mathematical dual of LINQ to Objects. It consists of a pair of interfaces IObserver/IObservable that represent push-based, or observable, collections, plus a library of extension methods that implement the LINQ Standard Query Operators and other useful stream transformation functions."

A mouthful I know... worth the time to watch the video. In short it adds to one's desire's to make use of LINQ for event based development needs, vs. traditional coding.

Check back soon!




"Visit the Dynamics AX Community Page today!"

Microsoft Interoperability Labs

Do you find yourself in an enterprise or environment where it’s not just 100% Microsoft platform, but a host of different databases, applications, programming languages, frameworks, etc.?

Also your staring down this new road of the 'Cloud', and everything ‘Must work on any device from any level, being that cloud, on site, mobile or at home’ And wonder how that can be the case when there are so many different languages, platforms, etc?

Check this out: Microsoft Interoperability Labs

This is the Microsoft Interop Bridge Labs page, that goes into examples. Just check some of these: Azure SDK for Java - .Net services, PHP for Azure, etc. etc.



These are some of the bridges, and technology interops that can be looked into and developed with. Deployed for just such ‘how’s’ were you are faced with an enterprise that does not have a common platform. Where technology need to bridge systems that span different programming concepts, langauges and even approachs.

There is plenty to look into on that Lab site. The thing that I want you to think about here, is the possibilities or support that exist for when you have, say a Dynamics AX instance that needs to connect to a Java custom package, and there is a PHP driven ECommerce site. This can be bridged, and exist, and this Microsoft lab is there to help in such needs arise.

It worth the time to check out, and keep an eye on from time to time, as you never know when such SDK's, libraries and bridge technologies can be used to help you out.

Well that's all for now, check back soon!




"Visit the Dynamics AX Community Page today!"