AX 2012 and the value of Microsoft's Visual Studio LightSwitch

Recently, I posted an article on my column, for the Microsoft Dynamics Community site, in which I focused in on the Any Device ERP concept. The push towards this concept, enabling true mobile ERP, as I stated in the article, will actually help drive adoption of the Microsoft Windows 8 powered devices.



Also, including in this post, I highlighted and pointed to the use of Microsoft Visual Studio LightSwitch. I'm really stoked about this product, and the more and more I look at it, the more value I see it can bring to companies. The value, in which I'm referring to here is all about giving companies the ability to simply, and in a fast nature, create Line-Of-Business Applications quickly and easily. This means faster Time-to-Value for such solutions, that are needed by companies, which can extend from Microsoft Dynamics AX 2012.



We see, with AX 2012, a push for it being the central hub of business logic, operations, data and delivery of business intelligence. With this, we also see the move for exposing data, API's and business logic internal and external of AX 2012, via Services. Because of this, companies can use LightSwitch, and it's ability to quickly and easily create apps that extend AX for a company, and help create a more total solution.

This is done, via AX services, be that Document Services, or Custom Services and Service Operations. Taking this design approach then, of exposing Data and Business logic from AX via services, these services then themselves can be consumed within a LightSwitch Application. A great resource for walking through this, by example can be seen at the following location: MSDN: LightSwitch - Consuming Web Services

From the post: "The aim of this document is to show developers how you can easily configure LightSwitch to consume Web Services. This walk-through assumes you have a background knowledge of creating basic applications with LightSwitch."



Having this example, we can now extend AX 2012, with LightSwitch for internally hosted Line-Of-Business (LOB) applications, on IIS, and even quickly scale and create applications that are deployed to Microsoft's Cloud Offering, Azure. In order to enable the scaling to the cloud, we do need to deploy the AX 2012 Services, via IIS, so that they can be consumed externally by the outside world. Doing this, means then, that quickly and easily we can create a Hybrid cloud story, for AX customers, and quickly bring the value to a customer that the cloud brings with scale, agility, and exposing AX business logic and data for consumption through such LightSwitch created apps.

For those customers, that have invested in AX, working with LightSwitch from Visual Studio 2010, will seem familiar, in how it's ability to work with Entity Data Framework, ease of creating and working with services, as well as the Tree Style design of forms, and buttons, that feels similar to AX and how it's forms and UI elements are designed.



So, if your a Microsoft Dynamics AX Customer, I highly recommend looking into either having your Partner, or your staff work with Microsoft Visual Studio LightSwitch, and how it can be used to extend your AX investment, quickly, efficiently and fast. That's always the goal, and keep in mind Simple is King of value, and let me tell you LightSwitch is one heck of a product that truly simplifies the creation of Line-Of-Business (LOB) applications. It's all about Time-to-Value, and that is why LightSwitch is a tool that should be considered, for completing your companies / customers total solution.

These applications, can then be made a part of the AX story, either hosted externally in the cloud, or internally. After creating and deploying a LightSwitch App, it can be incorporated directly into the user experience, via links hosted within Role Center Pages, to the LightSwitch App UI, or hosted within the AX 2012 Rich Client Forms and UI.



Bringing this full circle and to have a little forward looking exercise here, I personally believe LightSwitch, which currently delivers it's UI via SilverLight, will quickly be updated, once Windows 8 comes out. I believe, that Microsoft will enable you the ability to choose your target UI, be that SilverLight, or XAML+HTML5+JavaScript. The idea, is that LightSwitch will still create the UI for you, and enable fast and easy creation of Apps, that target even the Metro Style UI of Windows 8, and therefore having company specific Win8 Metro Style Apps, that work directly with & extend a companies AX 2012 ERP investment.



The following links, are useful resources that are used throughout this blog post. I would strongly encourage spending time researching and learning from these resources, and others to see how Microsoft Visual Studio LightSwitch can help you drive the most value out of your AX 2012 investment.:

• Microsoft Visual Studio LightSwitch Home Page
• Guidelines for Creating WCF RIA Services for LightSwitch
• Walkthrough of a Real-World LightSwitch App used at Microsoft
• LightSwitch Metro Theme Extension Sample

Well that's all for now, I hope everyone has a great productive week. Check back soon as I have a lot of good post coming out, all around AX, the Ecosystem, Spotlights, Interviews and more! Till Next time!


Follow Me @:
    

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

Microsoft Dynamics AX 2012 - A Dive into Services, Consuming Document Services

With the release of Microsoft Dynamics AX 2012, one of the topics I have been spending a lot of time talking about is around services. There is good reason for this, and we will continue to dive deeper and deeper into the concepts, the reasons for use, and examples of use.

Last I left off, we covered topics related to Custom Services. In this post, I want to take and cover concepts around the consumption of document services.

As I referenced in a previous blog post, there is a great write up already, that covers the technical steps needed to show off how to consume document services, specifically around the Product Data, or the EcoResProductService.

This write up, found here: Product-item data management services, focuses on the consumption of the EcoResProductService, among others, for creating product data, and even releasing that into a given legal entity. Since this is a very nice write up, I will not focus this post on repeating the same effort.

Instead, what I want to focus on, is consuming the EcoResProductService, from within X++, from within AX, for creating Product Master Data. So lets jump right into this.

First thing that we need is an instance of AX 2012, and a project. We will then need, within that project, a custom service group to deploy the out-of-the-box EcoResProductService via. After that, we will need a class, to contain the business logic, and finally for our example a job that kicks off that classes method, and therefore logic for creating our Product Master.



As you can see, from the above image, we have just that for our example. Now since there is nothing we need to really do to the EcoResProductService, lets move into the business logic for creating a Product Master record.

First we need to start with the variables that will be involved in, enabling this.:



You will notice, we have an EcoResProductService variable, which is used to perform the operations that are enabled for a given service, in this case document service, and for our need the create() function.

Next you will see we have a variable that presents the EcoResEcoResProduct object. This is what the EcoResProductService will accept in it's create call that we will see in a bit. This class extends from the AifDocument class, as you can see from the below image.



After that, we have EcoResEcoResProduct_Product_Master class, which is extends from the EcoResEcoResProduct_Product class, which further extends from the AfStronglyTypedDataContainer. You can see this as well, in the image below here.



From there we have variables that represent the EcoResEcoResProduct_Translation, EcoResEcoResProduct_Identifier & EcoResEcoResProduct_ProductDimGroup objects. All of which are used to help make up an EcoResEcoResProduct_Product_Master object.

Now all of that is a mouth full! The point is, we have, in order to work and create Product Master entries, via the Document Services concept, is six objects. These six objects in our example abstract the complexity of the new EcoResProduct data structure, and enable within AX for business logic to move away, from even working directly with the table objects within AX itself. This is very powerful, and very useful.

Now lets move forward, since we have an understanding of the objects that will enable us to create a Product Master record, and look into the code that enables this.



First part of the code, we see in the above image, our logic that initializes the service for use. Then we move towards creating a new instance of the EcoResEcoResProduct object. After that we are creating our Product Master object, and finally filling some of it's parameters, via the use of parameter methods, with values.



Next we are making use of the objects that make up our Product Master object, in the ProdMast variable, for creating the needed: Translation, Identifier and for our example the Product Dimension Group.

You will notice that the code to enable this is ProdMast.createTranslation().addNew(); In doing this, and for the other examples this is true as well, we are creating a new instance of the Translation object, and adding it to the AfStronglyTypeDataContainerList that is represented for the ProdMast variable.



Finally, we come to the bottom of the code block for this business logic, and see we are setting the Variant Configuration Technology. Then adding our ProdMast object to the Strongly Type List for the EcoResProd variable. Finally calling the create method of the service object, passing in our ProdMast variable.

On calling this logic, we get our Product Master record, as shown below.:


So with a total of 17 lines of code, and 6 objects, we are working with Document Services from within AX 2012 itself, and creating Product Master data, without having to work directly with the table objects themselves.

This can then lend itself to be re-used over and over again, and finds value in integration work, as well as data migration. You can also, now take and compare the differences between C# and X++ code for using these document services. They are similar, in theory, but different in syntax and possible approach of course.

That's all I wanted to cover for this series, and for the introduction to services in AX 2012 this just about wraps things up. I plan on doing a summary post, bringing together all the work I've done, all the work Microsoft has done, as well as other community contributors. Till next time!



"Visit the Dynamics AX Community Page today!"

Microsoft Dynamics AX 2012 - A Dive into Services, Custom Services (Part I)

Recently I have been doing a dive into all the services, and service design within Microsoft Dynamics AX 2012. I started with a dive into services, and from there covered systems services, with a focus on the Metadata Service, and followed with a look at Document Services.

I continue my series, with this post, focusing on Custom Services. This is actually pretty new for AX, and has a lot of great possibilities when it comes to exposing business logic, that can be used within and externally of Microsoft Dynamics AX 2012.

Now let me state, that the intent of custom services is to represent simple DataContracts, and custom business logic. For any complex data entity needs, Document Services is the right path.

It's not to say the custom services, and document services can't be used together, in a scope of work. Encapsulated, and combine to offer abstraction --- were such concepts make sense. However the point to not be taking lightly. The reality of this goes back to what I was trying to point out, in my recent article on Just because you can, doesn't mean you should.

With that aside, lets look at the make up of a custom service example. To start, a custom service itself, is made up of three things.: X++ Class, with one-to-many SysEntryPointAttribute tagged methods,a Service Node with operations representing the given SysEntryPointAttribute tagged methods and finally a Service Group in which the Service Node is a part of and deployed ready for consumption.



Now, lets take a look at the class object in a little more detail, since this is where we start with custom services. With this class, one thing that is important to point out is the fact that this should have it's property of RunOn set to Server.



Doing this makes sure the scope of execution for the given entry points are actually set correctly. This is a must, since this code will be running on the server.

Moving from there, lets take a look at what a given SysEntryPointAttribute, metadata tagged method looks like.



The above is a really simple method, is simply takes a string parameter, and then combines that and returns back a string. The point to see here is the tag area, in which we tell AX 2012 that this is a Service Operation through the use of the SysEntryPointAttribute metadata tag.

From here, now we can move on to the service node, set it's properties to point to our given custom class, so we can see what operations we can make use of.





Now that we have set this, we can go back to the Operations for the given service, right click, and then left click on add operation.





If we now take and select to add the getHello operation from the list, and click add, we will then see this now show up under the possible operations for use with the given custom service.



Now that we have this service operation to make use of, we can add this service to our given custom service group, publish it, and then make use of it from within AX 2012 or outside of AX 2012.



Now with this, we see simply and quickly we can get a custom service up and running, with really little effort. It's all about the metadata Attributes that now exists in Microsoft Dynamics AX 2012 that enables this whole framework to take place.

For now that it's on the topic. I'm doing this part of dive into services as a series. There is a lot to cover in this area, with a lot being very, very new, so I want to make sure and have this broken into easily managed post. I will be linking back to this post, with Part II, when we dive into the use of DataContracts.

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 - 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 - Business Operations Framework and the start of Services Abstraction with AX

With Microsoft Dynamics AX 2012, a new system service type exists. This is the Business Operation Framework (BOF) [AX 2012]

From the MSDN Home:
"The Business Operation Framework service is one of the system services exposed by Microsoft Dynamics AX and that adheres to the Windows Communication Foundation (WCF) protocols and standards. This service enables you to ... "

I love the "..." because, this shows the MSDN home for the new Business Operations Framework (BOF), is not actually complete. What's important to understand however is what this represents.

This is the start of what I talked about years ago with Lachlan Cash for Microsoft, with the following post.: WCF: The Enterprise Service Bus for Dynamics AX and the rest of the Microsoft Stack.

What I mean by this, is the fact, that the new Business Operation Framework it the fruit of all the work that Microsoft has invested in being able to have SOA communication between modules, and specifically between elements of code within Microsoft Dynamics AX 2012 and beyond.

This is making use of AIF, and Services, within the context of AX itself, and doing so, is the stepping stones to enabling the future flexibility of being able to have a true hybrid cloud that takes and enables bits and parts of AX to live on-premise, or in the cloud, and to the end user they have no clue which is which, because it does not matter to that level.

Understanding the impact of what this new development means, and what this offering can enable, is so very important today. This means, that new development, can take advantage of such offerings, and there is much more benefit than just future enabling your scope of work.

Check out the following MSDN articles.:

• Business Operation Framework (BOF) [AX 2012] - Home on MSDN
• Walkthrough: Creating and Deploying a Business Operation Framework Service [AX 2012]
• Walkthrough: Running a Business Operation Framework Service [AX 2012]

Just check this out.:
"Business Operation Framework (BOF) lets you run services on Microsoft Dynamics AX using the Windows Communication Foundation (WCF) framework. Business Operation Framework services have a clear separation of responsibilities between tiers. Dialog boxes are presented on the client tier, execution occurs on the server tier, and parameters can be accessed by both the client and server tiers. Business Operation Framework services can also increase efficiency by reducing round trips between client and server. "

And...
"Business Operation Framework services are flexible. BOF services can be executed in a job, as menu items, and as batch operations. BOF Services can also be executed synchronously or asychronously. "

I plan on taking this topic a lot further, with giving some real world examples, and comparisons with this approach, vs. standard development and execution. I hope this has really peaked your interest, and this design approach should be consider for use with anyone doing any development work within Microsoft Dynamics AX 2012.

That's all for now, but check back soon, as so much more to come! Till Next Time!



"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 - System Architecture Overview

As we draw closer and closer to the release of Microsoft Dynamics AX 2012, I plan to continue and dive deeper and deeper into all area's of the new release.

With that in mind, lets take a look at what resources we have on Microsoft TechNet.: Microsoft Dynamics AX 2012 - System Architecture



As we can see there is quite a bit of new roles, and also new ways old roles will interact, function, and what they run on.

Starting at the bottom of the diagram, we see that SQL Server of course, plays a major role in a given Microsoft Dynamics AX 2012 solution. To this database point, SQL Server, when AX 2012 is released, will be the only Database Software that Microsoft Dynamics AX will run on. Bye-Bye Oracle option!

You will noticed that we have similar databases here before, like SSRS, SharePoint and SSAS. What's important to understand is that the Dynamics AX database, will take and have both the Transactional Data, as well as the model store for which all Dynamics AX Objects live in.

This is where the AOT moved from the file system, and into the database, and reason why there is a new utility for moving .axmodel files, from one instance of AX into another.

Moving up the stack, we have the AOS and .Net, and within that .Net 4.0 applications, AX Services like the Metadata Service, Query Service and more. Here a lot of changes has taking place, and really openning up Microsoft Dynamics AX 2012, as was laid out in the past post I did some years back with Lachlan Cash.: WCF: The Enterprise Service Bus for Dynamics AX and the rest of the Microsoft Stack

All of these new blocks you see, mixed in, and being hosted by old one's like the AOS, help enable this vision laid out throughout the series of post, including the one mentioned above, that helped describe what the future of AX held. That future is becoming today, with the release of Microsoft Dynamics AX 2012 soon.

There is also a lot more to cover with this, and I recommend taking the time and reviewing each section of the system Architecture. Take a deep dive into the TechNet pages that already exist for Microsoft Dynamics AX 2012.

How we plan installs, how we do modifications, how we extend AX, all is going to change is some degree or another with this release, and it's important to understand the impact of these changes, and how much they enable for a business that will be making use of them.

That's all for now, I will continue this dive next week, with looking into comparing AX 2009 and AX 2012 in this area, and talking about some of the benefits, from this move being made.

Check back soon, as more to come!

"Visit the Dynamics AX Community Page today!"

Dynamics AX 2009: Hotfix 981339 for Consuming external WCF Web service

I wanted to highlight a specific Hotfix that was released and is part of RU5 and RU6 for Microsoft Dynamics AX 2009. This was actually released just before RU5 was compiled and set ready for downloading and installing last year.

This specific KB is: 981339, and you can find a detail list of the latest fixes for Microsoft Dynamics AX 2009 through PartnerSource or CustomerSource found here.: Hot Fixes Released For Microsoft Dynamics AX 2009

The list was last updated this past March 15th, so it's a list that is keep up with on a regular basis.

Now for this specific hot fix, it addresses the issue to where when you consume an External WCF service from a service reference within Microsoft Dynamics AX 2009, and the communication with the service does not close properly or enters a faulted state.

With this faulted state, before this fix the only thing you could do was restart the AOS. Now with this fix, it addresses the proper openning and closing of the service client the service reference generates, and therefore is closer to how a client in C# would act.

This is a great fix, and one that you can get directly just for that KB through a ticket request through Microsoft Support, or one that you can get through applying RU6.

This is just another example of the value of staying current with your Dynamics AX investment, including looking and reviewing when RU are released. I highlight this in, the case for staying current and upgrading in the following two post.:

• Guest Column: The Value of Upgrading
  
• A Case study for the value of upgrading

Thanks to a fellow Sunriser's John F. & Debra D. for bringing this hot fix to light. I thought it was for sure something that should be posted about, and also help enforce the fact that as a company one of the ways to ensure long term ROI is the continued upgrade and staying current process.

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

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