Dynamics AX
  RSS Feed  LinkedIn  Twitter
Want to turn you're data into a true asset? Ready to break free from the report factory?
Ready to gain true insights that are action focused for truly data informed decisions?
Want to do all of this across mutliple companies, instances of Dynamics and your other investments?
Hillstar Business Intelligence is the answer then! (www.HillstarBI.com)

Hillstar Business Intelligence for Microsoft Dynamics AX and NAV on Mobile, Desktop, Tablet


Let us prove to you how we can take the complexity out of the schema and truly enable users to answer the needed questions to run your business! Visit Hillstar Business Solutions at: www.HillstarBI.com

Wednesday, September 21, 2011

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


Labels: , , , , , , ,

0 Comments:

Post a Comment

<< Home


Copyright 2005-2011, J. Brandon George - All rights Reserved