Freaky Tech Friday - The Abyss Of Integration

Last week, we dared to enter into Freaky Tech Friday - It came from another Platform. This hellish post, covered the dark path of how other-worldy platform technologies could be used in a solution-stien way of creating offering that only igor could love. As part of that walk on the wild side, in which we highlighted the use of the ghoulish way in which services could be hosted as part of AX 2012 on IIS, for consumption not just be internet external consumers, but also by other technologies that could not consume net.tcp based service binding.



I warned you all, that if you dared to come back, we would move forward in our dark quest of knowledge and enter in to the abyss of integration. This is a place, truly of no return. Well maybe there are some returns, specifically deep and dark returns on investment actually.

The abyss of integration is covered with a cesspool of options, in which one would not dare use for enabling connections with AX 2012. I say not dare use, in that well, you actually might find neat and should use, when the time is right and the integration needs call for it. For those that want to brave this dark path, I have three area's to highlight for you.

First lest talk about Asynchronous integration needs. This requirement can sometimes real it's ugly head, and how do you defeat such a monster? Well You can employee several tools, other than just holy water, including BizTalk and the use of Message Queuing with AX 2012.

First lets start with BizTalk, which in it's devilish acts, can help enable both Synchronous and Asynchronous in nature integration's. The best place to start for this area, is the blessings found in the following white paper: Microsoft Dynamics AX 2012 White Paper: Using Microsoft BizTalk Server 2010 to Exchange Documents with Microsoft Dynamics AX. Without this guide, you will become yet another lost soul, on the road to the center of the abyss, never to be seen or heard from again.

This white paper will cover topics that include Enterprise Application Integration, Business to Business Integration as well as Application to Application integration concepts. The target audience should not be faint of heart, and should have knowledge about developing and administrating BizTalk, from a past life.



Others have braved this part of the abyss before, so thankfully there is a way forward, even beyond the whitepaper itself. The following is a good little post about catching faults from AX WCF Services, that might can help you live through the night, and survive long enough to face more of the abyss of integration.: Catching Faults from Dynamics AX 2012 WCF services

Moving own, and if you're still part of the living, then we can dare to look into the sea of nothingness, which is flat in the middle of this abyss we now call home. I refer to Message Queuing with AX 2012. Another holy script exists for this part of the journey as well, which can be found at the following location. Deploy Message Queuing for AIF [AX 2012]

A passage from this light in a dark place of Queuing:
"The MSMQ adapter for Microsoft Message Queuing is included with Microsoft Dynamics AX.

To send documents by using Message Queuing, you must install it on a computer on the network and create at least one public queue.

To receive documents by using Message Queuing, you must install Message Queuing and create at least one queue on a computer that has Application Object Server (AOS) installed, and that has been configured to run Application Integration Framework (AIF) batch jobs."

Well Ghosts and Ghouls, that's all for this freak feast. I'm glad to see you've survived this brief tour of the abyss of integration. Scare you next week, when we review Attack of the Zombie Processes! Scare you next time.




"Visit the Dynamics AX Community Page today!"

Do Not use the .Net Business Connector with AX 2012

With the release of Microsoft Dynamics AX 2012, a lot a great things have come about. One area that I have spent some time on now, is around integration. In the past, when integrating outside line of business (LOB) applications or custom software, the options for enabling this were either the use of AIF Document Services or the .Net Business Connector.

There is good reason not to use the .Net Business Connector, as I point out in the following post: Net Business Connector Not Recommend for AX 2012



A reader today, stated that they have read on the web, and with my blog post, to not use the .Net Business Connector with AX 2012 integration's, but they were not really clear why. I thought this would make for a good post, as to clear the air of sorts on this topic, and explain why.

First you see from the above AX 2012 system architecture image, that the .Net BC is actually used in a few places to enable different parts of the solution. With that said, and beyond this fact, the only reason the .Net BC exists in AX 2012, is to truly support backwards compatibility. Understand this, future versions of AX, beyond AX 2012 will not have the .Net BC as an option. This has been made very clear in the official Microsoft Documentation released on the subject.

This means, that anyone upgrading from previous versions, will still have their integration's developed using the .Net BC, will still work. However, planning should be made to make the switch to make use of services.

The desire behind this move, is to take away proprietary technology that the .Net BC represents, and the RPC protocol it implements, and use more true .Net technologies, like WCF. This move, not only takes a step towards true .Net native code execution, but also replaces the very chatty protocol of RPC, with the less chatty and more well formed protocol of WCF.

So the reasons, for not using .Net Business Connector in AX 2012 are.:

• 1. Microsoft will not support it beyond AX 2012
• 2. It using the RPC protocol for communication which is very chatty compared to WCF, and does not enable the vision of cloud computing Microsoft has for AX in version 7.0 and beyond

I started, on this list, to add more, but honestly the first reason in the list is point enough. Microsoft will not support the .Net BC after AX 2012. Since that is the case, any development done with it, or any integration that is not upgraded and changed to make use of WCF and Services in AX 2012 is a waste of time and money.

I hope that through the many efforts of those in the community, including myself, to point to the desired method of services with: Custom services and document services, that it's clear why the .Net BC should not be used. Upgrades are supported to AX 2012 that make use of this technology, however it's important to understand that such integration's have to be changed over for any version of AX beyond AX 2012.

With this, I believe we can move forward and all understand that any integration efforts between AX 2012 and the outside world, should reside around services. This is, as I've pointed out before, a true statement even within AX 2012. Services help abstract some of the complexities of AX 2012, and help empower the marketing term powerfully simple.

That's all for now, but check back soon as I continue with my dive into workflows, and many other great topics. Till next time!

Update: A fellow peer of mine pointed out that this post sounded a little harsh. That is never my intention at all, and I hope this is taking as a warning. The idea is to save you time, money and effort and help deliver a clear message that WCF and services are the way for extending and integrating with AX 2012.

"Visit the Dynamics AX Community Page today!"

.Net Business Connector Not Recommend for AX 2012

Yesterday, I posted the following.: Microsoft Dynamics AX 2012 - System Architecture Overview

In that post, I gave a link to the following Microsoft TechNet article.: Microsoft Dynamics AX 2012 - System Architecture

Well one of the things that I did not highlight, but I wanted to have for it's own post was the fact that the following stands out on that article for TechNet.:

Note:
Use services and AIF to interact with the Microsoft Dynamics AX application. We recommend against using the .NET Business Connector to integrate with the Microsoft Dynamics AX application.

I think this really needs to sink in for people, and that everyone needs to take special attention to this note. The idea, is that services and AIF, which their end points are services, is the desired goal for how AX with interact with the outside world, and other LOB applications.

So, if you have a LOB application, or custom app that you want to integrate and work with AX, and it's business logic, the .Net BC is not the method that is desired with Microsoft Dynamics AX 2012.

It's still around, and for good reason, supporting all that IP that is already been developed around the .Net BC. However, I believe we can start to see the writing on the wall for this, and the design pattern, in that the .Net BC, I doubt, will exists beyond AX 2012 for such use.

Just an example of how Microsoft Dynamics AX 2012 is going to change how we implement, integrate and work with AX.

I think it's a great move, and one that has been the moving direction for a while, make everything SOA / WOA based, through services. Everything connecting through services. This sets up for a whole future of hybrid mix possibilities for where services and software lives within a companies total solution.

That's all for now, however I wanted to point this out specifically, after starting with yesterday post. More to come, as we dive deeper and deeper into different aspects of AX 2012.

Till next time!

"Visit the Dynamics AX Community Page today!"

Microsoft Dynamics AX 2012 and the use of Claims Based Security

While at DAXCONF11 this past Jan. one of the sessions I attended was around security, and what is changing for Microsoft Dynamics AX 2012. There is actually a good bit to talk about in this area, and the topic I wanted to focus on for this post is around Microsoft Sharepoint 2010, and it's enabling of Claims Based Security.

The link above is a great resource, that gets to the point of Claims based security. In short, Claims based security is meant to address.:

• Claims based authentication addresses privacy and other compliance concerns


• Claims based authentication addresses integration of different systems

Now, looking at how this was demoed at the conference, we actually saw the fact that no longer does an AD user have to exist, for granting role based security rights within AX.

This is actually huge in what it enables. So for example, you can have say Windows Live ID, and make use of that to grant a Windows Live User ID access rights, and role based security for context, to the given Windows Live user id through the new Claims Based Security!

This means that your external customers, vendors and other business partners do not have to have an AD account, instead they could login to your portal and site through Windows Live, A Custome Security Login for your site, and many other third party security.

This is enabled through the use of Microsoft Office SharePoint 2010, Claims Based security.

Now that's the given, but what this also enables is the steps and move towards the Cloud for Microsoft Dynamics AX!

This is a huge step in helping make future AX versions move more securely to the cloud, as well as giving you instant usage with Microsoft Dynamics AX 2012 and cloud based properties / integrations.

Take a look at the following Ch. 9 Video, that is also a great overview and introduction to Microsoft Office SharePoint 2010 Claims Based Security.: Ch9: Introduction to Claims based Security

"Claims-based identity provides a common way for applications to acquire identity information from users inside their organization, in other organizations, and on the Internet. Identity information is contained in a security token, often simply called a token. A token contains one or more claims about the user. Think of it as metadata about the user that stays with them throughout their session."

I am sure, in looking at this, you can see that Microsoft is very serious about the use of SharePoint, as well as enabling Microsoft Dynamics AX for the cloud!

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

"Visit the Dynamics AX Community Page today!"

Update on the Connector for Microsoft Dynamics AX and CRM

This week, Microsoft released a new "out-of-the-box" connector for Microsoft Dynamics AX and Microsoft Dynamics CRM.

I covered this release, in the following blog post.: Out-of-the-box Connector for Dynamics AX and CRM

I had an open question to Microsoft, specifically around how the connrector would, or could be used for developing deeper or vertical specific integrations, or workflows. If the connector would be the base, or if a total custom integration would still have to exists.

I got feedback from Elizabeth Alexander, senior product manager, Microsoft Dynamics ERP, who is involved deeply with the Connector itself. This is the feedback she gave me.:

"Assuming what you’re asking is basically ‘can the connector be extended to cover customizations’, that the short answer is yes. The extent of work required depends on whether it's a case of adding fields to existing maps, creating entirely new maps, or new services need to be enabled in Microsoft Dynamics AX. The connector is a constant, it's the maps and integration components that get extended or created to support additional integration scenarios."

So we have our answer here to this, in that you extend this connector through it's integration components and field maps. This is what I was hoping would be the case, and so this new connector should be considered the base in which more complex workflows and integrations are designed between AX and CRM.

That's all for now, a big thanks to Angie L. for helping me get this answer. She is always so very helpful!

Till next time!

"Visit the Dynamics AX Community Page today!"

Out-of-the-box Connector for Dynamics AX and CRM

Today, Microsoft has a new press release focusing on some new tools that allow customers to possibly save time and money. The full press release can be found here.: New Microsoft Dynamics ERP Resources Save Customers Time and Money

"Microsoft Corp. (Nasdaq “MSFT”) today announced new resources to help improve productivity and save Microsoft Dynamics enterprise resource planning (ERP) customers time and money through new interoperable Microsoft technologies. The new resources include an out-of-the-box connector between Microsoft Dynamics CRM and Microsoft Dynamics AX and a Data Migration Assistant for Microsoft Dynamics AX customers moving from an Oracle database to Microsoft SQL Server.

“These offerings help enable Microsoft Dynamics ERP customers to take full advantage of the benefits of Microsoft Dynamics CRM and Microsoft SQL Server in an easy and cost- effective way,” said Guy Weismantel, director, Microsoft Dynamics ERP Product Marketing. “By offering out-of-the-box interoperability with these Microsoft technologies, as well as Microsoft Office 2010, Microsoft SharePoint 2010 and Microsoft Visual Studio 2010, we’re further supporting our customers’ path to becoming dynamic businesses.”"

Both are great moves by Microsoft, but for this post I want to focus on the out-of-the-box Connector between Microsoft Dynamics AX and CRM.

Before this official release, connectors between these two products where developed either by VAR, custom for a given customer, or where developed by third party ISV's that focused in a specific vertical expertise.

Now with this new out-of-the-box connector, we have a base level of integration between Microsoft Dynamics AX and Microsoft Dynamics CRM. Lets look at this closely though, and think about the nature of both CRM and AX.

Both are very flexible, and both can look way different from one customer to the next. What is being attempted is to offer a way for more standard integration to be achieved between these two products and their data.

This is great, and for a lot of customers this will most likely fit the bill for enabling the integration between the two products. There will still however be a need for custom integrations, workflows, and vertical / industry specific integrations that go deeper than what can be achieved with this new 'out-of-the-box' offering.

I bold this point, so that we can understand what this offers, and still want will exists within the Dynamics Ecosystem, in the form of need of services, and software that enable deeper integration for these two products and their respective datasets.

I have not yet had a chance to dig deep technically into this new offering, and I have a pending question out to Microsoft if this is an open integration in which such deeper, vertical specific needs can be built on top or, or used to connfigure from. Once I have that answer I will let you know.

Needless to say this is a very right move, and will help enable the adoption of Microsoft Dynamics CRM for existing Microsoft Dynamics AX customers that might not already use CRM but want to move from the 'Sales & Marketing Module' within AX to a more robust CRM solution.

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

"Visit the Dynamics AX Community Page today!"

Microsoft Dynamics AX 2012, OData and EDM

Well as promised in my last post, this next post is going to focus on the move for Microsoft Dynamics AX 2012 to focus integration and access to data contained within an AX 2012 instance through OData feeds, and EDM. (Entity Data Model Framework).

Mike Ehrenberg, a Microsoft Technical Fellow for Microsoft Dynamics had to say:
"Consistent with that, Microsoft Dynamics AX '6' does provide its own model store -- and per the announcement, a very sophisticated one," Ehrenberg stated in an e-mailed response. "First, the model store has moved from the file system to SQL Server in this release, improving scalability, model reporting, and deployment. Layering in the model store allows efficient support of a base model, extended for localization, industry specialization, and on top of that, ISV vertical specialization, reseller and customer specialization, with the ability to model very granular changes and effectively manage the application deployment lifecycle from ISV through to customer and the upgrade process. We provide a service interface to the model store, and it is possible to layer ODATA or EDM on that service."

One of the things that I saw while at #DAXCONF11 was this concept in full working demo.

I saw a given Query Object be published as a service, and then having that service once published consumed as an OData feed, from within Microsoft PowerPivot, and easily working with the content and layout of the given Query.

To give a little more about OData, check out the following.: OData Home on the web



"The Open Data Protocol (OData) is a Web protocol for querying and updating data that provides a way to unlock your data and free it from silos that exist in applications today. OData does this by applying and building upon Web technologies such as HTTP, Atom Publishing Protocol (AtomPub) and JSON to provide access to information from a variety of applications, services, and stores. The protocol emerged from experiences implementing AtomPub clients and servers in a variety of products over the past several years. OData is being used to expose and access information from a variety of sources including, but not limited to, relational databases, file systems, content management systems and traditional Web sites."

Looking at PowerPivot, one needs simply open up Microsoft Office 2010, and make use of it's native support for OData feeds as a source for data for a given workbook.:



In doing this, we see the power of Office 2010 and Microsoft Dynamics AX 2012. To transform the complex integration needs, into a more simplified approach for creating a service, having it hosted within the AOS and WCF itself, which in turns allows for consumption of the service as an OData feed within Microsoft PowerPivot.

You can take now, and think a little further of having an employee self service page within Microsoft Dynamics AX 2012 EP, that would list possible feeds ready for consumption by users, and filtered by the users security context!

This is very powerful, and will change the way integrations are done within Microsoft Dynamics AX 2012 and the outside world!

Other area', that I will highlight is the EDM. You can find out more about the purpose and point of EDM here.: MSDN - Entity Data Model

"The Entity Data Model (EDM) is a specification for defining the data used by applications built on the Entity Framework. Applications using the EDM define entities and relationships in the domain of the application in a design schema. The design schema is used to build programmable classes used by application code. Storage structures that persist data for applications in this model are represented in another schema called the storage schema. A mapping specification connects the design schema and the storage schema."

The key here: define[s] entity and relationships in the domain of the application.

This would allow for more structured, domain specific data access within an more complex external service, and allow for more complex and "smarter" integrations with other LOB applications.

If you can take this in a pratical look, having a given external LOB application that can use EDM in such a way that would allow it to better understand the data model that it needs to understand for working with it's part of Microsoft Dynamics AX.

This equals more robust integrations, with less code, and less time!

Well that's all for now, check back soon as I continue the deeper dive of Microsoft Dynamics AX 2012. Next on the block is a deeper look at eventing!

"Visit the Dynamics AX Community Page today!"

Blog spotlight: Dilip's AX & Exchange Web Services

Recently, Dilip, a fellow blogger over at: Dilip's blog on DYNAMICS AX, wrote on the topic of integration Microsoft Dynamics AX with Exchange Web Services.

The article can be read here.: How to Read email and download attachment from AX (AOS) without Installing Outlook Client and using EWS Exchange Web Services

In this post Dilip describes how a company could interact with Email at the AOS level, including attachments, etc. and not have to worry about having any client side context integration via outlook, or through SMTP.

This is a great post, and I would like to thank Dilip for sharing. I really like this integration, as it shows how powerful service based integrations with Microsoft Dynamics AX can be.

This also shows a new way of integrating with email based processes and workflows, that a lot of companies have request to do at times.

Thanks Dilip, and keep posting that good stuff!

That's all for now, hope everyone is staying warm and toasty.. its getting down to 15 here tonight. For some that's no big deal, but I live in the Southeast part of the U.S., and for us... well it's VERY COLD! So can you Notherners please turn off the cold air for us?

Check back soon as more post coming this week, including an article for MSDynamicsWorld.com!

"Visit the Dynamics AX Community Page today!"

PTC Flex PLM and Dynamics AX - Dynamics Duo

Ok, so I admit the title is a throw back to the early Batman shows / cartoons. With that said however, I believe it's a good fit.

What I am talking about here is PTC's Flex PLM Solution. It's their flagship Product Lifecycle Management package, and it integrates well with Microsoft Dynamics AX ERP software. I have actually integrated this before, creating BOM's in AX from the output of the PTC Flex PLM package.

What's interesting about me talking to these two great packages now, is that Sunrise Technologies, the great VAR I am a part of, is now focusing efforts to sale and implement PTC Flex PLM!



Check out the offical press release about it here.: Sunrise Technologies to Resell PTC’s Leading PLM Solution for Customers in Retail, Apparel, Footwear, and Consumer Goods

From the PR.:
"Winston Salem, North Carolina – Sunrise Technologies a leading provider of Microsoft Dynamics AX for manufacturing, distribution, and retail, announced today that it has joined the PTC (Nasdaq: PMTC) Partner Program as a PTC Channel Advantage – Enterprise Solution Provider. Sunrise will resell and implement PTC’s FlexPLM® solution as part of the Windchill® PLM platform to customers in the retail, apparel, footwear, and consumer industries.

The integrated PTC FlexPLM solution can help address both industry-specific challenges and everyday business pressures. FlexPLM offers a high-performance, Web-based platform that brings together globally distributed teams and provides line planning, specification management, merchandizing, and other essential PLM capabilities for managing your company’s complete assortment of products. Sunrise Technologies’ deep knowledge of the retail, apparel, footwear, and consumer industries processes are complimented by the ability to now provide customers with a comprehensive PLM solution that enhances the value of their Microsoft Dynamics AX ERP solution."

And, from PTC about Sunrise.:
""We believe that customers who choose to use Sunrise Technologies in conjunction with PTC's FlexPLM solution will benefit from increases in overall product development efficiencies and as a result improve time-to-market, control costs and drive competitive differentiation" said Rod Walters, Senior Vice President, Enterprise Partner Program, PTC."

This, I believe, is a great move and I am glad to see we will be offering this as a product, and services around this product to Dynamics AX customers, and also standalone customers needed just PTC Flex PLM.

Flex PLM really is a great fit with Dynamics AX, and helps extends Dynamics AX investment for companies that need a true and proven product lifecycle management package, and it 100% integrated with AX!

Look here for more about this in the future, and check back soon as next week will be filled with more post, more interviews, and continued coverage of Dynamics Ecosystem!

"Visit the Dynamics AX Community Page today!"

Dilips AIF Resource blog post

I thought I would pass this along. Dilip, from Dilip's blog about Dynamics AX, posted a nice entry covering different AIF handy web resources.

A direct link to that post, can be found here.: Dilip's AIF Links post

This goes right into the technical dive of working with AIF, which I talked about in my last post, covering when and where AIF should be used vs. the .Net BC.: AIF Services and the .Net BC - Where and When?

Thanks Dilip for a nice post there! Keep them coming!

"Visit the Dynamics AX Community Page today!"

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!"

ProISV Launches Version 1.0 of AX.NET

Today, ProISV is releasing version 1.0 of the AX.NET, minus the AX.NET Server peice, which is set to be released within the next two months.

This is a new offering, that I wrote about in the following blog post.:
Dynamics AX and .Net - A new technology offering from ProISV

As well as my CIO focused article on MSDynamicsWorld.com, found here.: MSDW: How AX.NET Extends a CIO's Integration Options

This covered the details of what AX.NET planned on offering and was bringing to the Dynamics AX, .Net table. Now, as of today, ProISV is releasing AX.NET, along with their new partner program.

For this launch, I interviewed ProISV team, Neils and Kaspar. Below is that interview.:

1.) What will be released as version 1, today, from the AX.NET offerings and what does this bring to customers and partners? (Niels)

"We are including a lot of functionality in our first AX.NET release. The core functionality creates a .NET version of AX, thereby enabling full .NET integration with Microsoft Dynamics AX business logic and data. Feedback from our now closed beta1 program and analysts is that we are closing a major gap in the Microsoft Dynamics AX technology base with the release of AX.NET.

So, today we are offering two different types of AX.NET licenses: AX.NET Developer System, which targets product developers and AX.NET Client, which is suitable for users on the system as well as internal AX development. The AX Developer System all inclusive license, unlimited developer users and Code Protection System, will retail at EUR 3,995, while the Client license retails as low as EUR 295 per user.

This means that developers can now write custom .NET code, while using the AX logic directly in Visual Studio, as well as use our Code Protection System to ensure that their intellectual property is fully managed and cannot be circumvented. The client license makes it possible to run the AX.NET applications at a low price, thereby enabling a much richer Microsoft Dynamics AX experience and at the same time reduce the cost dramatically. There are many fine details in our functionality, which is probably too much to all be mentioned here, but our website provides all the details as well as the differences in the license types: (ProISV license types link.)

Well worth mentioning though is that we are now also introducing our Partner Program, through which we will enable authorization for partners to distribute and resell AX.NET licensing. This is a very big revenue opportunity in addition to the significant cost savings of using AX.NET to develop applications. None of this would be meaningful though, without having a high quality product offering, so that has been our highest priority leading up to our product launch."

2.) To what do you attribute your ability to release a stable version 1 of the AX.NET offerings? (Niels)

"The key principle of all of our product development is that it is test driven, agile development, blended with our many years of experience in the field. This means we can quickly attain a very high level of quality in our products. The key purpose of our AX.NET beta1 program was to work with partners, get their feedback both in terms of quality and functionality. We had a very successful and productive beta1 program, which resulted in great new features and a very stable product, so we are obviously very happy for that and thankful to our beta partners for their active participation."

3.) Without getting into details, can you give us an idea of Customer and Partner involvement during the beta program that lead up to this April 7th release? (Niels)

"We had great feedback from our beta partners and some of them were giving us intensive feedback throughout the work days. This speaks to the fact that AX.NET really fills a major technology gap and the ability to finally work with a full .NET version of AX is something, which has been received with tremendous interest. We will now continue working with the beta partners and assist those, who have chosen to take a step further and use AX.NET commercially in their businesses. We were actually able to very quickly implement suggestions for product improvements as well, so that probably create great confidence in ProISV as a business partner"

4.) Can you talk about some of the improvements, with examples that took place during the beta program that helped refine and make AX.NET a better offering? (Kaspar)

"There have been many improvements during the beta program, and many suggestions from our Beta Program Partners have been implemented.
The most visible changes have been made to streamline the AX.NET Assembly Generator that is where all AX.NET development starts.

We have for example made it easy to connect the Microsoft Dynamics AX AOS using the Dynamics AX Client Configurations stored on the local computer.



When choosing the selection of tables, classes and enums to be included in the AX.NET Assembly, which shall constitute your .NET version of the AOT in Microsoft Dynamics AX, you can now define the selection by choosing private and shared projects from the selected Microsoft Dynamics AX.



This way it is easy for a business consultant to define in Dynamics AX, what should be included in the .NET representation of AX. A technical consultant can then build the AX.NET Assembly using the Microsoft Dynamics AX project.

During the Beta Program we improved the control over which elements actually are included in the AX.NET Assembly. When building the AX.NET Assembly, the AX.NET Assembly Generator uses the defined selection of elements, but AX.NET Assembly Generator also included a feature to automatically include depended elements.



So if I am creating an AX.NET Assembly with the CustTable table from Microsoft Dynamics AX, I would probably like to automatically include the classes and tables that the methods (business logic) on CustTable use as parameters. AX.NET enables this, and with the new features developed during the Beta Program, it is even now possible to define how many levels of dependencies should be included.

There has also been made great progress in streamlining the AX.NET Framework to make it more intuitive and user friendly. We have for example changed the naming convention in the AX.NET Assembly, so the name of the .NET types in a generated AX.NET Assembly in most cases have exactly the same name as in Microsoft Dynamics AX.
This means that the Microsoft Dynamics AX class Map is now also called Map in an AX.NET Assembly, where it before was called IMap. Further the Microsoft Dynamics AX table CustTable is now called CustTable in an AX.NET Assembly, and a row in CustTable is called CustTableRow.

We believe that there has been made great progress and improvements during the Beta Program, and we really would like to thank our Beta Partners for providing us with their feedback. We will continue down the path with our next product offering, the AX.NET Server."

5.) What are your plans for the AX.NET Server offering? What will it target, and allow? (Niels)

"In short, AX.NET Server will enable the AX infrastructure to run in the Cloud as a modern age alternative to on premise or hosted servers in the traditional sense. Thereby new business models in line with Cloud computing can be introduced as well.

So with AX.NET Server, AX can be accessed through a web browser, just like any other Cloud service. AX.NET Server is fully compatible with all of the AX.NET features in the Developer System and Client License system, which means that applications developed today, can run as Cloud services, once we release AX.NET Server.

Obviously, delivering Microsoft Dynamics AX as a cloud service will eliminate many costs otherwise associated with deploying and maintaining AX."

6.) When is the AX.NET Server offering scheduled to be released as version 1? (Niels)

"We anticipate to release AX.NET Server Beta towards the end of April. The commercial release will depend on the beta program feedback. As was the case with AX.NET beta1, we will apply agile development and release when the product is ready. That means “fast”."

7.) What do you feel are some of the most important things that AX.NET brings to Customers and Partners? What is the, short version, of the case for AX.NET in a Dynamics AX implementation? (Kaspar)

"We believe that the release of AX.NET today marks the beginning of the next generation of .NET solutions for Microsoft Dynamics AX. AX.NET will enable customer to build custom .NET solutions that increase the value of their Microsoft Dynamics AX investment by enabling faster, cheaper and better support for development of web, mobile, smart client and integration solutions.

AX.NET can achieve this by enabling the full power of the newest version of Microsoft .NET Framework and Microsoft Visual Studio to be unleashed including support for LINQ (Language Integrated Query) and Intellicense (auto completion, inline documentation and compilation check) in Visual Studio.

Writing .NET solutions for Microsoft Dynamics AX by direct use of the Microsoft Dynamics AX Business Connector can almost be illustrated as writing your .NET code in notepad without any productivity or quality enhancing tools. AX.NET truly brings .NET development for Microsoft Dynamics AX into Visual Studio with everything it includes.

For AX.NET Partners we both provide a great business opportunity to resell AX.NET to the end-user, but we also provide special features for our ISV Partners developing solutions on top of AX.NET and selling them commercially.

When Partners buy the AX.NET ISV license (AX.NET Developer System), they get the possibility to use the AX.NET License System to protect their own Intellectual Property (IP). All AX.NET ISV will receive a digital certificate from ProISV that they can use to sign AX.NET Licenses. The AX.NET License System then allows them to specify, that their AX.NET solution only is allowed on an AX.NET installation with an AX.NET License digital signed by both ProISV and the ISV. Hereby the ISV is ensured that they receive the entire AX.NET License sale for their solution, and that there is no unauthorized use of their product."

8.) If you could pick one thing to really highlight about AX.NET, that maybe a lot of customers and partners might not appreciate fully when first looking at AX.NET, what would that be? (Kaspar)

"If you don’t have a technical background or are familiar with the life of a .NET developer working with Dynamics AX through the Microsoft Dynamics AX Business Connector, it can be easy to underestimate the effect of AX.NET on productivity, quality and moral. With AX.NET a Microsoft Dynamics AX .NET developer does not have to look envious at his colleague that is developing a pure .NET solution."

"The era where .NET development for Microsoft Dynamics AX was a difficult process has passed, and the future is racing towards us. The future is the Cloud, and AX.NET will take your there with AX.NET Server and Microsoft Azure very soon!"

I would like to thank Niels and Kaspar from the ProISV team for taking the time to do this interview. This is exciting news, and I recommend you check out what AX.NET can do for Dynamics AX implementations that need .Net based integration work.

A direct link to their website can be found here.: www.ProISV.com

That's all for now, but check back soon!




"Visit the Dynamics AX Community Page today!"

Integrating Third party VCS with Dynamics AX 2009

Just over a month ago, Microsoft released a new white paper which talks you through how they integrated Team Foundation Server, TFS, into Dynamics AX.

That white paper can be found here.:
Microsoft Dynamics AX 2009 White Paper: Integrating a Third Party Version Control System into Microsoft Dynamics AX 2009

"The MorphX Integrated Development Environment (IDE) can integrate various Version Control Systems (VCS). Team Foundation Server (TFS) is a newly integrated VCS with the MorphX IDE in Microsoft Dynamics AX 2009. This document provides detailed step-by-step instructions to integrate a VCS with the MorphX IDE, by using how TFS was included in Microsoft Dynamics AX 2009 as an example.

The Version Control Extensibility Framework was refactored in Microsoft Dynamics AX 2009, which is now used by the integration with TFS."



In looking at this I started looking around for cloud based VCS software, that was similar to Visual SourceSafe, and already integrated to work with Visual Studio. I came across the following.: www.DynmaSoft.com The product they have can be hosted in the cloud, on-premise, and has a published COM based SDK.

It already integrates with Visual Studio, and that was key for this, because in most Dynamics AX solutions, with 2009 and beyond, Visual Studio solutions and projects are very much a part of the Source Code that make up a given AX implementation.

So with this in mind, I started to dig a little deeper in what would it take to integrate this DynamSoft product into Dynamics AX.

After looking into this, I found of course you will need to sign up for at least a free account. Next you will need to download the following two items.:

• SourceAnywhere Hosted Server Manager - To remotely manage the users, groups, access rights and other configurations of the hosted server.


• SourceAnywhere Hosted COM SDK

After getting these two, of course make yourself familiar with the COM SDK, and then go through the steps listed in the Microsoft Whitepaper for enabling DynamSoft cloud based VCS with your given Dynamics AX instance.:

• 1. Add a new class that represents the VCS and implements the sysVersionControlFilebasedBackEnd interface.


• 2. Add a new base enumeration value to the SysVersionControlControlType base enumeration type. For TFS, the SysVersionControlTfs base enumeration value was added.


• 3. Add new class construction logic to the newType method of the SysVersionControlSystem class.


• 4. Implement the VCS setup methods. These methods are the bootstrap methods that are responsible for initializing the backend instance. Therefore, they must be implemented for each VCS.


• 5. Implement the basic VCS operation methods in the new class such as the fileGetVersion, fileSetCheckIn, fileCheckout, fileAddToVersionControl, and fileDelete methods.


• 6. Use the advanced VCS methods to implement additional VCS features. The framework also defines a list of runtime surrogate methods to let the VCS notify the framework whether these features are supported by the VCS. These features are optional.


• 7. Implement the plumbing methods that are required by the framework.

I have plans to now take the above information, a free account and actually develop this and place in an XPO project for sharing. I wanted to get this out here though, making this a part 1 in this series, to help bring into focus Change Management possibilities that exists with Dynamics AX, specifically related to VCS options.

With what Microsoft has given us here, we now have the ability to really integrate Dynamics AX 2009, with near any VCS solution we desire. Be that Cloud based, on-premise, Custom, Open Source, or purchased.

I think this shows the flexibility of Dynamics AX, and also gives customers choices in their VCS options.

There is something technical you need to keep in mind, in regards to VCS solutions with Dynamics AX. This is designed so each developer has their own AOS installed on their developer workstation.

With what we have in this white paper, however, we have the ability to create a server side integration into a VCS that will work, with having a single AOS and 1 to 1,000+ developers! I will save that for a later post on this subject.

Hopefully this post has you thinking, and hopefully you have plans or already have in place change management policies, that include management of code.

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




"Visit the Dynamics AX Community Page today!"

Dynamics AX and .Net - A new technology offering from ProISV

Recently I had someone contact me from ProISV, a Mr. Kaspar Bomholtz. With this, Kaspar asked me to check out a new technology that ProISV was developing for Dynamics AX and .Net. I was amazed at what I saw, and actually had thought about doing something similar in the past.

I am sure others have thought as doing such as well, but ProISV has taken working with Dynamics AX business logic and objects from .Net to a new level.

Because I was really impressed with Kaspar and his team's work at ProISV, I asked if he would do an interview with me about what ProISV is offering. The following is that interview.:


1.) With ProISV offering, what all will a customer get with making the choice of going with the new AX.NET from ProISV?

For many years it has been possible to integrate with Microsoft Dynamics AX through the .NET Business Connector and earlier the COM client, but it is time consuming and inefficient. Now with AX.NET, a seamless integration to the business logic and data model in Microsoft Dynamics AX exists. So how does this benefit the customer?

By using AX.NET ISVs can now build richer and more flexible applications for their customers utilizing the power of Microsoft Dynamics AX and the rich user interface of .NET Win Forms, Windows Presentation Foundation (.NET WPF) and ASP.NET (including SharePoint).

AX.NET will also enable ISVs to ship custom .NET dll library together with their Microsoft Dynamics AX ISV solution. By building using the AX.NET technology it will enable full .NET integration to their Microsoft Dynamics AX application. Just by adding a reference to their project in Visual Studio, customers and 3rd party will be able to build custom solutions easily, which fit the specific local business needs.

With the coming introduction of the AX.NET Proxy technology, it will no longer be needed to install the Business Connector on clients. All that is needed is the standard .NET Framework which is also available on mobile devices running Windows Mobile. For years, connectivity has been a problem when integrating with Microsoft Dynamics AX, but with the AX.NET Proxy all you need is a single web service delivering access to the entire Microsoft Dynamics AX out of the box. The AX.NET technology therefore enables Microsoft Dynamics AX to run as a real Cloud service.

2.) How flexible is AX.NET really going to be?

AX.NET is extremely flexible because the AX.NET "AOT" is generated by the AX.NET Framework to the exact configuration of any Microsoft Dynamics AX Application. By using the .NET assembly generation tool, a .NET assembly representing any Microsoft Dynamics AX application can be built in minutes. It all happens automatically and includes the possibility to mirror the entire AOT, a specified area or layer.

Because your Microsoft Dynamics AX classes, tables and enums now become .NET objects, you can utilize the power of the entire .NET Framework to build your application. The AX.NET even includes support for retrieving and manipulating data in AX using .NET LINQ, which is very similar to the embedded SQL statements in X++.

Easy generation of the .NET "AOT" with AX.NET to fit a specific application. With a few clicks the Assembly Generator automatically generates a .NET Assembly containing your custom .NET "AOT".



Here are a few code examples of the applicability:

Selecting customer of type Person.



Creating, updating and deleting a customer.



Browsing the "AOT" in AX.NET using Intellicense in Visual Studio.



Methods are also available on tables and classes.



You can even use AX.NET to create Unit Tests in Visual Studio for Microsoft Dynamics AX. Here is an example:



As you can see the Microsoft Dynamics AX classes Map, Set, SetEnumerator have been automatically generated by AX.NET into the .NET interface IMap, ISet, ISetEnumerator. Even the Types enum in Microsoft Dynamics AX have been converted into a .NET Enum.

The possibilities for application of AX.NET are endless.

3.) So if a Partner was tasked at doing a good bit of .Net development for a customer, what will drive the Partner to use AX.NET, vs. building the same features out themselves?

One of the major benefits with using AX.NET is that ability to use standard .NET technologies known by most .NET developers to create rich applications that integrate with Microsoft Dynamics AX. Many .NET developers already know technologies like LINQ and Data Binding in .NET from working with data sources like Microsoft SQL Server. Now they can use the same technologies with Microsoft Dynamics AX using AX.NET out of the box, which makes it easier to find development resources.

AX.NET also improves development efficiency by support Intellicense for classes, tables and enums in Visual Studio. AX.NET also provides compile time validation of the integration towards Microsoft Dynamics AX. This can drastically reduce the amount of development and QA time used, because errors found during compilation by the developer can easily be detected and corrected during development.
If the Partner is using Team Foundation Server from Microsoft, they can use Continuous Integration to build and verify the .NET solution including the integration to Microsoft Dynamics AX on every check-in of code.

Having a development background I personally know, that all the mentioned improvements of the development experience not only make it more interesting to be a developer, but also saves a significant amount of time and thereby money.
Maintenance of a .NET solution integrating with Microsoft Dynamics AX is also greatly improved by using AX.NET. If changes are made to the Microsoft Dynamics AX application, compile errors are generated in the .NET solution instead of runtime errors that are much more difficult to diagnose.

In the next version of AX.NET the communication between AX.NET and Microsoft Dynamics AX can be tunneled through a single web service interface that we call AX.NET Proxy. Hereby the need to install the Business Connector on the local client is removed, as well as the requirement for being on the same domain. This will make implementations of .NET solutions that integrate with Microsoft Dynamics AX much easier and far more flexible.

4.) What is the planned Road Map for AX.NET, when will v1.0 be ready to go?

We are planning to release AX.NET v1.0beta in Q1 of this year. After that we are planning to validate and optimize AX.NET using feedback from pilot customers in Q2, and then release AX.NET v1.0 hereafter. We plan to license AX.NET based on a license per Microsoft Dynamics AX license and one per user. Since we plan for AX.NET to become a defacto technology, we anticipate to also price accordingly.

Where v1.0 uses the Business Connector directly to access Microsoft Dynamics AX, we are planning to include the AX.NET Proxy feature in v2.0 towards the end of 2010. The AX.NET Proxy technology will provide the same seamless integration to Microsoft Dynamics AX as AX.NET, but it will use web service technology as the link between AX.NET and Microsoft Dynamics AX instead of using the Business Connector directly as in v1.0. This will greatly increase the connectivity of AX.NET by proving integration to Microsoft Dynamics AX over the internet and across networks separated by firewalls, thus taking Microsoft Dynamics AX all the way to be truly Cloud enabled.

5.) What kind of support will exist for Partners who sell AX.NET as part of their implementations?

We are planning to provide training and support through online webinars and training sessions and will have a support channel available on proisv.com to handle the support process. It is our ambition to establish a community, which both AX and .NET developers will be able to use and provide content to as well, such as code examples, Q&A’s and other ideas to inspire the AX.NET community.

6.) What kind of training program is being developed, and what kind of certification will be required for Partners to sale and implement AX.NET?

Online training sessions will be available through the upcoming partner section of our website, proisv.com, from which our AX.NET users can learn about the technology. As such the fundamental prerequisite is to be a solid .NET developer as well as to know the business logic and objects in Microsoft Dynamics AX. So, if you know how to develop in .NET you can also use AX.NET, assisted by our online training material as well as the upcoming developer community on our website.

7.) Will you be present at Convergence, and be able to show off AX.NET there?

We are not currently planning to be present at Convergence. In the first haft of this year, we will be focusing all our energy on product development and to get pilot projects up and running. Sadly I don't think they are going to postpone Convergence for our sake. More likely though, we will participate at the Microsoft World Wide Partner Conference in July.

8.) Finally, what is the coolest feature about AX.NET that you think will really wow Partners and Customers?

The coolest feature must be the seamless integration to Microsoft Dynamics AX. The fact that elements from the AOT in Microsoft Dynamics AX now can automatically be accessed as real .NET objects without any custom code. With AX.NET it is now possible to browse through the generated "AOT" object in AX.NET seeing all the tables, classes and methods automatically available for easy access. We know this is something Microsoft really wanted to do, but we figured out how to get it done.

I would like to thank Kaspar and ProISV for the time with doing this interview. I am very excited about getting my hands on this new offering, and wanting to see how performance is with this new offering. How well it scales, etc.

Feel free to check out ProISV at thier website, located here.: ProISV Website

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





"Visit the Dynamics AX Community Page today!"

Tips for Creating Services in Microsoft Dynamics AX 2009 - White Paper

While staying on the topic of integrations for Dynamics AX 2009, I wanted to give a link to a great resource that was first released in June of this year.

That is the Tips for Creating Services in Microsoft Dynamics AX 2009 - White Paper

The previous post, of consuming services inside Dynamics AX 2009 was taking and bring in data or working with serviecs from the point of Dynamics AX 2009 to the outside world.

This white paper goes into great details, helps, do's and dont's for creating Services that expose Dynamics AX 2009 to the outside world.

These services can then be consumed by the outside world for working with process, data, and business logic inside Dynamics AX.

Before this white paper came out, there was good help on the web with great blog entries, etc. However this white paper is recommended for anyone that is working with AIF, or will be working with AIF to expose Dynamics AX to the outside world.

From the white paper.:
"Microsoft Dynamics AX services are designed and implemented in the Application Object Tree (AOT) using X++. A service is defined once, but can be exposed via different transport protocols, such as a Web Service, an MSMQ adapter, a BizTalk adapter, or a file system adapter. Microsoft Dynamics AX tools and wizards are available to expose and deploy services to these different environments, leaving the application developer to focus on the service definition and implementation.

The application developer uses tools and wizards to generate and deploy the X++ service as a Windows Communication Foundation (WCF) service hosted in Internet Information Services (IIS). After a service has been implemented, any requests made to that service are forwarded from IIS and run on the Application Object Server (AOS). These generation tools create the service definition in the form of XML Schema Definitions (XSDs) and managed assemblies. From a high level, service requests are made to the managed assemblies that delegate them to the X++ service implementation using .NET Business Connector. The incoming message is not deserialized inside the managed assembly to increase performance."

AIF, in Dynamics AX 2009, comes as part of the base package and should be used for exposing business logic, data and processes to the outside world.

That's all for now, check back soon!




"Visit the Dynamics AX Community Page today!"

Consuming Service References in Dynamics AX 2009

As mentioned in the following blog post.:
Continued talks of Integrating Dynamics AX to the outside world

I plan on going through some of the integration options that exists with Dynamics AX 2009, and getting into some real examples of this. In order to dive right into this, lets look at Dynamics AX 2009 consuming service references.



Service references are new with Dynamics AX 2009, and map directly to service references that one would see in Visual Studio 2008.

This makes use of .Net 3.5 framework, through creating .Net 3.5 code for the given supplied Service WSDL, that acts as a consuming proxy. This is registered in the AOT, and can be accessed through the supplied .Net namespace from where the given service reference was created.



This can be a given web service, or a Microsoft WCF service adapter / end point. That means that all of what comes with the .Net 3.5 framework with WCF and WWF can be made use of with such integration points.

One of the given main examples that has been used to showcase this is hitting the Live API (I guess bing now!) for searching through it's publish service.

This is great to show case a technical ability of this, but what about functional wise?

Well such an integration point, of it self, is syncrhonous. Now the integration point can lead into a WCF service, that is hosting a WF Workflow, which drives through several different points, including asyncrhonous processes with MSMQ, etc. However the integration itself is synchronous because it expects a return on a given call out.

This means that typical integration for this would be to other System of Record applications or solutions, web services for feeding data from and consuming, external calculations like shipping, tax, etc.

What's great about this integration, is that in X++, the given .Net namespace is used with a preceeding dot (.) to get access to the given service, and any methods it might offer.

One thing I want to point out about that .Net namespace, if for example you have say three web services you want living in the same parent namespace. Well you need to make sure to do something as the following for that namespace.:


ParentNameSpace.ChildService1
ParentNameSpace.ChildService2
ParentNameSpace.ChildService3

You do this for each of the three services you want to live under a single parent namespace. So you would have registered 3 different AOT service references, and in the .Net namespace provided a structure as you see above.

Now when in X++, you reference ParentNameSpace. The three child services will be listed under this single parent Namespace. There will also be three .Net 3.5 Proxy Clients created, on the AOS, under the documents and settings of the given user id that is running the AOS service. They will be named as well.: ParentNameSpace.ChildService1.dll, "2.dll, "3.dll.

That is a good point to keep in mind, espcially for doing larger integrations and so forth.

These work great once setup, and there are some limits though. The following gives you a good idea of those limits, like data conversions, etc.

AIF Services and Primitive Data Type Conversions for XML and .NET Framework

Take a look at the chart for idea of the conversion of data types. Another good resource, is the 'How to: Consume a Web Service from X++'

One other thing I want to point out is that the service reference does not have a great management form for say, changing the WSDL URL or service name. The best approach I have found for doing this, and for deploying to other instances has been to take and export the Service Reference, and change the WSDL URL, and import into your instance of another instance and regenerate the service.

Sometimes you might run into file locking issues, if the service already existed. If this is the came, you will need to (a) take and stop the AOS (I know a pain), (b) delete the actual .Net file that AX is complaining is locked, (c) restart the AOS, (d) regenerate the service reference.

Doing this will allow for your updated WSDL URL, etc. to be read and made use of.

Thats all for now, and check back soon as more to come. August is wrapping up today, and that was delcared as Lean month. However I have some more great Lean based posted to wrap that Lean month up with.

See you 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!"

Integrating Dynamics AX 2009 with the outside world

One topic I wanted to start really spending some time on, in the next few months is Integration options for Dynamics AX 2009.

There are several ways for doing this, and what I want to take and look at each. Go over some pro's and con's, and when should the different approaches be used.

So the following is a list of ways you can integrate Dynamics AX 2009 with the rest of the world.:

Outbound Integration

• Calling a COM Object - Server and Client Context


• Calling a .Net Assembly - Server and Client Context


• Calling a Web Service through a .Net Wrapper


• Calling a Web Service or WCF Service through Service Reference in AOT


• Out of the Box AIF Outbound End Points


• Custom AIF End Points - (MSMQ, File Transfer, Web Service, FTP)


• AIF End Points for BizTalk - BizTalk then offers a wide range of options once inside it's scope


• Your own custom or Third party developed framework that lives inside Dynamics AX 2009

So the above list can be sliced upon into sections of itself. Like Server or Client context, AIF, Web Services, etc.

The approach I want to take is now take the above list, on my next post, and talk about the pro's and con's of each type. After that, take the same list, and talk about when each of the types would be used, and what would be driven factors to use those.

Hopefully by the time we cover these options a solid understanding of what all exist for integration Dynamics AX 2009 out to the rest of the Microsoft stack, and world can be understood and we can move forward with inbound integrations.

I also plan on giving examples of some of these. Like the Reporting Options in Dynamics AX 2009, the integration options are many. And there is specific factors that drive you to choose different paths.

That's all for now, check back as more to come. August is Lean month, so another post tomorrow on the LCE, and interviews are coming up. See you then!




"Visit the Dynamics AX Community Page today!"

X++ Team blog: Enter Sales Order via Speech Server and a phone

Well the X++ Team blog is something that I find very interesting, and have since they started posting. I went to catch up with the blog the other day, and found this very interesting article: 'Entering a Sales Order over the Phone'

This article details, how the author took the Office Communications 2007 Speech Server SDK, and created a demo integration with Dynamics AX for allowing customers to call into the line, and interact with the Speec Server to actually enter in orders. For sure there is some benefit for customers fo Dynamics AX who would like to make use of this, as it is a pratical solution. What I found most interesting in this article was the author from the X++ team blog, was searching for new ways to integrat with Dynamics AX, beyond the current offerings. :-)

So thanks X++ Team bloggers! Keep it up, and check back soon here as I continue to post!


Find a job at: www.DynamicsAXJobs.com

.Net Adapter and why?

Alright something that I have discussed a good bit with some clients, as well as associates is the need for creating .Net Assemblies that act as wrappers or better Adapters for connecting Dynamics AX to third part services / software. So I thought I would take a little break from the .Net Custom C# examples and write about this for a post.

Alright so say you have either a COM application or a .Net Assembly that you want to make use of inside Dynamics AX 4.01? Why not since both COM and .Net can now be referenced and used. Well some of the first things that you will run into in this is that X++ can not handle complex data types and return outs from given called COM methods or .Net Assembly methods. What does this mean? Let take for example you have a COM object that you want to make use. Say for example the COM API tells you something as the following:

COMObject.SomeMethod(STR VAR1, STR VAR2, OUT INT STATUS);
VAR1 = Some Variable
VAR2 = Some other variable
STATUS = Out supplied variable, returned at end of Method call

Now looking at the above, right off the bat we notice an OUT variable as being part of the method header / call. In X++ such a variable qualifer or call does not exists. If this is the case, then that means the given COM object method can not be used, and there goes your nifty idea... Not really. Enter the powerful world of .Net Wrappers / Adapters!

In order to allow for Dynamics AX to make use of the above COM object method call, you need to create an adapter that consumes the "complex" data type / method calls and Adapts them into a suitable form that X++ calls can make use of. So in our example we would create a C# .Net Class, that would live in an assembly (.DLL file) and have it call the above with VAR1, and VAR2 passed in. Then we would have an Internal to the .NetClassObject.Method(string Var1, string Var2) method call that would take and call the above as stated. The OUT int varible inside the .Net method call would then set a property of the .Net class equal to the value that was sent out, or return the value as the returned value for the .Net Method call.

But what if we did it the first way, set a property of the .Net Class / Object? well if that is the case [possibly multiple OUT vars] then you would have to create getClassProp() methods that could be called from X++ because even custom properties of a .NetClassObject can not be used from with X++.
So now we have the why, and basics of how for a .Net adapter. The point is to take complex calls and data types, consume them with the .Net Adapter you create, and expose via simple data types and simple method calls that can be used from within X++. The wonderful thing about this approach is the only time your developed .Net adapter changes is when the version of your Third Party software does!

Well check back soon as I continue my talks about .Net Custom code and using the .Net Business Connector for Dynamics AX 4.0.

Find a job at: www.DynamicsAXJobs.com