My Review of "Microsoft Dynamics AX 2012 Services"

I hope everyone has had a great and productive Dynamics week thus far! I know it's a busy time of year for projects, and changes that a new year brings with it. I wanted to take the time and focus this week on a book I was asked to review. What I'm talking about, is the "Microsoft Dynamics AX 2012 Services" book that was recently released.



This was a book I was ready to see released, and one that I wanted to put to the test. It's a topic that needs understanding by anyone implementing Dynamics AX 2012. What is learned when truly diving into services with Microsoft Dynamics AX 2012 is a foundation for the future.



To help frame the importance of this topic, lets look at an Interview from the past. Doing so will help give meaning to the mention of how services are the foundation for the future of Microsoft Dynamics. Here, you will find my interview with Lachlan Cash from Microsoft.: Microsoft's strategy and vision for Dynamics AX and SOA.

This interview took place in March of 2009, nearly four years ago. However what is laid out in this vision interview is what we see today with Microsoft Dynamics AX 2012 & R2. The vision has become reality, and now it's time to embrace the changes that this foundation of services represents.

From the interview.:
"SOA has been about connecting systems together, we think that it has more a place with-in the application as a fundamental shift in the way business logic is written and designed. This is a long term strategy to make it easier for our customers and partners to adapt the business application to their needs and integrate with other line of business applications." - Lachlan Cash, Microsoft

With this understanding, and a blast from the past, lets look at the amazing job authors Klaas Deforche & Kenny Saelen did with this book. From start to finish it is well thought out, easy to find specific information about topics, and can take a newbie on a journey of services enlightenment.



Starting off, the concepts are covered very well, including basic concepts like "What are services and SOA?". Klass & Kenny advance the reader through a what's new section, and how this section is so important to grasp for those that have been working with Dynamics AX for many years.



All possible service types are covered very well, including the needed understanding for working with Collections, via the infamous AifCollectionTypeAttribute. The reader is throw into great examples that enforce basic concepts, while introducing the 'to-become' services jedi master!

As further proof of Klass & Kenny's understanding what services are in AX 2012, they devoted the entire Chapter 5 to the explain & explore the SysOperation Framework. The following is an excerpt from the that chapter.:
"The SysOperation framework is new in Microsoft Dynamics AX 2012, and is the preferred way of creating batch jobs. It replaces the RunBaseBatch framework, which remains available for backwards compatibility. When Microsoft Dynamics AX 2012 was released, the SysOperation framework was known as the Business Operation Framework or BOF."


Image from book comparing RunBase vs. SysOperation.

The authors also cover well the system services, uses of the system services, and giving full, tested examples throughout the book.

Like any book review, there is always something that can be added. A book, like a house, as any author or architect well knows, is never really finished. It's just a static version, or a version release for consumption and use. With that, there are a few area's that I would like to have seen including in this.

First one, which is near and dear to my heart, is the ODataQueryService. You can find out more about OData and Dynamics AX at the following.: AX-OData Queries.

This, is a very useful system service, that saw much improvements with the release of Dynamics AX 2012 R2. Further this service will continue to become more and more important to fully help complete the vision that was laid out by Lachlan Cash, in the above referenced interview.

Finally, the other area that is the biggest hole in this book is Debugging Services in AX 2012. The referenced link there, covers just the steps needed for getting started, but honestly this is a topic that needs some deep dives, to cover it well and understand the nuances of debugging services for AX 2012.

With this, I give the book a 4.25/5 possible score. Overall this is a really great book, and I would recommend anyone implementing Dynamics AX 2012 to have this as their go to services book.

Well that's it for this week. I plan to get back into the serious side of business insights next week! Check back soon, as more to come. Till Next Time!


Follow Me @:
       

"Visit the Dynamics AX Community Page today!"

Freaky Tech Friday - The Killing Zone

Well Ghosts and Ghouls, it seems you dare to return for the last and final Freaky Tech Friday post of this years haunting season. It came from Another Platform, didn't drive you away. Entering The Abyss of Integration didn't drive you mad, and your survived Attack of the Zombie Processes. Now let us enter, The Killing Zone.



This tale, is one of great suspense, and danger, focused around the fact that if the new design patterns, thought processes and concepts that come as part of AX 2012 are not fully understood and used, you will not make it out of the Killing Zone alive. You will end up dead! Or at least at a dead end with your Dynamics AX, and it's ROI. This is an easy place to survive if your new the the Dynamics AX world, however for those of us that have been working with the product since it earlier days, to quote "The Times, they are a changing".

To this point, they have changed, with so many different things to understand. One hot topic I keep talking about is around Workflows in AX 2012, and how it should be used to model business processes. There are several other area's however, from how you integrat with AX, making use of the SysOperations Framework, vs. RunBasebatch, and even planning for the new delcrative engine that empowers the new option for configuration needs that a customer might have for it's products.



I've not spent much time on this topic yet, however the new configurator within AX 2012 is based on Microsoft Solver Foundation technology, which is a declarative based decision engine, vs. the current Product Builder, rules based engine. Not to get to deep on this specific topic, as it well deserves many, many post.

Some Area's that need special attention, if you are to avoid having your final resting place be within the killing zone, are.:

• XDS vs. RLS - Record Level Security still exists in AX 2012, and is meant to support upgrades. However any new scope, should not use RLS, but instead make use of the new Extensible Data Security Framework
• RunBaseBatch & RunBaseReport - Again, here we have these in place and still used by out-of-the-box scope from Microsoft. With that, any new development should use the SysOperations Framework, or Business Operations Framework. It is true that this framework ends up, specifically for Batch using the underlying batch classes. However those are clearly marked as legacy code and will be ripped out in the next version as replaced. This is why it's important to use the new Design Concept and not get trapped into old habbits.
• Avoid the .Net BC - This is important one to really understand and take advantage of. For any new scope the .Net BC Should not be used. Instead the focus should be around services development in AX 2012, for internal and external of AX consumption and usage.

There are a lot of other, specific's that can trap you into falling into the killing Zone, and killing your chances of maximizing your ROI, and getting some great new use cases that come as part of what is offered now in AX 2012.

There are cases, specifically related to upgrades from older to version of AX to AX 2012, that you have to use the older concepts. As the value is not there maybe to change a bunch of code, as part of the upgrade, just to use the new frameworks. However, before AX 7 takes shape for such cases, those area's will have to be addressed. Also, when upgrading is the focus, still keep in mind that anything new, or anything that must change, should change and use the new concepts, vs. the older ones.

Well Ghosts and Ghouls, take heed to these warnings, and avoid having the killing zone be your final resting place. That's all the haunting post for this season of terror, stay safe and if you dare return, we shall be waiting here, ready to scare you next year.

Tell next time!

"Visit the Dynamics AX Community Page today!"

IL Compile and some things to understand for AX 2012

One thing I wanted to make sure and point out, with all this talk about Microsoft Dynamics AX 2012, Services, and Complex Data Contract concepts, is around the need for proper IL generation of Xpp / X++ code artifacts.

The image above is not technically correct for AX 2012, but it's a quick snag image, to capture the point of this post, in that there are some steps you have to take, in order for AX 2012 to make sure it can properly execute your service code.

I mentioned the use of SysOperations Framework, as well as Reliable Asynchronous execution mode for operating on more complex data contract concepts in the previous post. With that focus, and around the focus of any services that you deploy, AX must have in it's "Server/[AX AOS Service Name]/bin/XppIL" the correct and most recently compiled Xpp into IL code artifacts.

If, for example, you start running into strange issues, when using the SysOpeartions Framework, for Reliable Asynchronous execution, were messages appear in the batch job history for said job executions ending in error, make sure to follow these steps, so that you can be sure your instances XppIL is correctly up-to-date.

• 1. Click on the Incremental IL Compile button, within a Developer workspace
• 2. Restart your AOS

Doing this, ensures that the specific changes you might have made within an instance of AX and Xpp has correctly refreshed the XppIL artifacts for the given instance of AX, for the specific AOS(es).

I wanted to make sure and point this out for this morning as I'm sure quite a few of you might run into such issues. Doing this, will save you some unneeded research time, because most likely your issue is with a not so up to date XppIL Artifacts for a specific AOS.

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

"Visit the Dynamics AX Community Page today!"

Continued look at AX 2012 and more Complex Concepts for Data Contract Usage

I started a new, mini-series, if you will, on Microsoft Dynamics AX 2012 and a deeper dive into more complex concepts for Data Contract usage this week. I state this as a mini-series, as it's not the typical series of post in which I finished up for services earlier this month, and like I currently have on-going for workflows in AX 2012, because of the limited scope I want to keep for this focus.

There is a lot more actually that could be covered, but I want to preface the complex concepts with the fact that the nature and design of Data Contracts for AX 2012 is not actually to be to complex. For complex data needs, document services and their use are intended for addressing such needs. However, the level in which we are talking about, I personally believe, is well within the vision in which Microsoft has for AX 2012 and custom data contracts.

With the above stated, I did want to continue tonight, with a focus on this topic. We covered in the first post, of this mini-series, about how a specific Data Contract, could have a list of related child data contracts as part of it's make up. That post talked about the enabling meta-data attribute tags that are used, to tell AX enough about a list, so that is could be consumed and used as a strongly type collection.

To take this further, lets assume that you want to make use of the SysOperations Framework, in order to enable Reliable Asynchronous processing of said data contracts. This is a valid need, that could enable safe threaded execution against such contracts, that would bring value by decreasing the time needed to process a lot of these contracts.

The idea's and concepts of the SysOperations framework actually are the evolution of the RunBase framework, and technically still use some of the underlying technology that enabled the RunBase and RunBaseBatch concepts in earlier versions of AX. It's clear, however, that any new development needs to follow the design patterns of the SysOperations framework, and nothing new in AX 2012 should be developed, with direct reference to any RunBase anything.

With this said, if we took the artifacts from my previous post, in this mini-series, and tried to submit a parent contract, that had a list of child contracts as part of it's make up, the SysOperations for Reliable Asynchronous operations would fail. This would be seen in the Batch Job History form, under the Administration module in AX 2012. Why would this fail, you may ask?

The reason this would fail, is the simple fact around AX 2012 need for such operations, that involve collections within data contracts to adhere to the pack / unpack design pattern. You can get a glimpse about this topic, from the following MSDN Article: MSDN: Pack / Unpack Design Patterns.

As I mentioned in my previous post, we will dive deeper into this topic, including making use of the SysPackable interface for AX 2012. Well this is exactly what is needed to enable such complex data contract concepts to exists and execute in AX. We have to make use of the SysPackable Interface.

To help show this off, lets look at a class declaration that implements the SysPackable Interface.

[DataContractAttribute]
class idbChildDC implements SysPackable
{
     str _someValue;
    
    #DEFINE.CurrentVersion(1)
    #LOCALMACRO.CurrentList
        _someValue
    #ENDMACRO    
}

We can see, from the above class declaration, that our focus for enabling the collection to get processed correctly and make use of the stated SysPackable interface, is around the child data contract. Why is this? Because, this is what is contained within the list. Since this is the case, we have to make the specific objects within the list, idbChildDC in our case, packable.

We have done the first part in this requirement, which is implement the SysPackable interface. However in doing this, we have three other methods we must supply, that fully enable the SysOperations Framework to execute on our custom child data contract, in a Reliable Asynchronous fashion. Those three needed methods are.: pack, unpack and a public static create metthod. Lets take a look at the makup of each.

First we have the Pack method.:

container pack()
{

     return  [#CurrentVersion,#CurrentList];

}

The above, we see a simple, and straight forward pack method. This is nothing special and the standard pack method that you would apply, based on implementing the SysPackable interface. Next we have the unpack method.:

public boolean unpack(container _packedClass)
{

    int version = conPeek(_packedClass,1);

    switch (version)
    {
        case #CurrentVersion:
            [version,#CurrentList] = _packedClass;
            break;
        default:
            return false;
    }
    return true;

}

Here, once again, we see a very generic and common unpack method. Nothing special, but must exists in order to enable such desired processing, as Reliable Asynchronous. Moving forward, the final required method that enables a collection of custom data contracts to be properly processed is the public static create method.:

public static Create(container _child)
{

    idbChildDC child = new idbChildDC();
    ;

    child.unpack(_child);
    return child;

}

Now that we have applied the SysPackable interface, as well as the above needed methods, when a list of idbChildDC data contract objects is processed as part of the SysOperations Framework, with the execution mode set to Reliable Asynchronous, proper processing will take place.

The reason this is the case, is that doing the above such actions allows the collection of idbChildDC objects to be serialized and deserialized so that the state data that represents the list of objects can be reinitialized, and business logic performed on.

With this post, and the first post, combined, so really neat, and possible great business value aspects, can be driven from the use of these more complex data contract concepts.

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

"Visit the Dynamics AX Community Page today!"

AX 2012 and a look at some more complex Datacontract concepts and usage

With the release of Microsoft Dynamics AX 2012, one topic that I have been covering a good bit is around Services. There is good reason, and why a lot of other Dynamics Community bloggers and thought leaders have spent a lot of time talking about this topic. That reason, is the design importance that exists around services, and it's usage for an AX implementation. This is the new reality, and part of what makes AX 2012 Powerfully Simple.

As stated before, services are meant to be used internally and externally, with an AX 2012 solution. They enable some really great possibilities, and it's easier than ever to create, modify, and administer services than ever before.

One of the topics, I wanted to spend a little time on this evening, is around some more complex concepts for Data contracts, and the intended use within AX 2012.

There are a couple of points to cover here, and the first one is the proper code syntax for enabling a data contract, to have a property that is a list of child data contracts.

So to get to the meat of this area, the idea here is that you have a data contract. Within this data contract, you want to have a few properties that make up the contract, as well as a collection of other data contracts, that represent some business value, directly associated and therefore related to the parent data contract. I've mentioned before, in Microsoft Dynamics AX 2012 - A Dive into Services, Custom Services (Part II) post, about the use of Attributes to define data contracts with.

To enable this more complex need, Attributes in AX 2012 are very much a need in this case. To help set the stage for this review, we need a project, and two X++ classes.



You see in the above image, a project and two classes. A Parent and Child Data Contract X++ class. This is stated, visibly through the names of this classes, however, lets take a look at the make up of said classes.

First we need a parent class, this is the starting data contract, and so the following is the makeup of the parent data contract. I would like to point out that the following is not an image, but text, with some nice CSS that color and font the X++ to look like you see in the MorphX IDE.

So first we have the parent Class Declaration.:

[DataContractAttribute]
class idbParentDC
{
    List _children;
    str _someField;    
}

After that we have two other methods we need to look at. This is a simple DataAttribute method, and then the more complex method that enables the storage of a collection, in our case a list, of Child data contracts.

[DataMemberAttribute("SomeField")]
public str parmSomeField(str s=_someField)
{

     _someField = s;
    return _someField;

}

So the above uses a simple DataMemberAttribute tag, that sets the property name of this given data contract, for the parmSomeField, equal to "SomeField". This is a very simple datatype of str, and therefore not much is needed in order to describe this method to AX so the proper WSDL is created.

Enter the more complex need, of working with collections. Since Microsoft Dynamics AX 2012 is not a strongly typed language, however it interacts with XML and WCF Services that demand collections be strongly typed a bridge or ability to create strongly typed collections must exist. What to do?

Here we continue the use of Attribute meta tags that are new to AX 2012, that define to the AX what the collection type is for coming into the class, and represented in being sent back for consumption back to the consuming entity of the given data contract.

So we have the following.:

[DataMemberAttribute("Children"),
 AifCollectionTypeAttribute("l",Types::Class, classStr(idbChildDC)),
 AifCollectionTypeAttribute("return",Types::Class, classStr(idbChildDC))]
public List parmChildren(List l =_Children)
{
      _Children = l;
      return _Children;  
}

With the above we see the use of the AifCollectionTypeAttribute. This is being used to define the collection type, of list, containing a collection of idbChildDC objects. Also, since this method returns a collection, a List of object, the AifCollectionTypeAttribute, in turn is also used to describe the list of objects returned.

If you want to use such a concept, the above is a must. AX 2012 does not offer any flexibility in this regard, and if you don't correctly supply these AifCollectionTypeAttribute tags, the client will shut down on you.

Well that's all for now for this topic. With the above, you should be able to easily work with more complex concepts for Data Contracts in AX 2012. I will continue this mini-series of post, if you will, with taking the above and running it through the SysOperations Framework, and working with the SysPackable interface in AX 2012. That's all for now, till next time!

"Visit the Dynamics AX Community Page today!"