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

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

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

I wanted to continue today, with my dive into services, for Microsoft Dynamics AX 2012, where I left of with Microsoft Dynamics AX 2012 - A Dive into Services, Custom Services (Part I).

Today's focus for this area, will be around DataContracts, a look into a simple one, as well as working with collections through SysEntryPoint methods, or Operations of service contracts, for DataContracts.

With that, we left of in Part I, with the showing the basic parts that make up a given custom service. This includes: an X++/Xpp class, that represents the logic of exposed business logic through SysEntryPoint tagged methods. Then we have a service node, that is tied to said class, with the ability to turn SysEntryPoint methods into operations. Finally we have a Service Group node, that the new custom service resides in, as a publishing point so the service can be consumed.

Now that we have this base understanding, lets look at what we would most likely be making use of, through such SysEntryPoint service operations.

When you think of Services, and specifically WCF services, then you start to also think in terms of DataContracts. This did not exists prior to AX 2012, however has been a major part and concept of WCF, since WCF was introduced back in .Net 3.0 days.

It's a similar concept, in that the point of a DataContract is what the name implies, to offer a Contract, with set Properties or Attributes, that govern the interaction of the consumer and the service, for exchanging data. Mouth full huh?

So lets look at what enables a basic DataContract. First, a DataContract is an X++ class. Like the SysEntryPoint metadata tag for service operations, there are several metadata tags that enable a DataContract to exists. These metadata tags, or attribute tags define to AX what the purpose and point of a class, and it's methods are meant to be.

In turn AX 2012 can use this information, when the times comes to generate the Artifacts that enable the usage of said elements.

So lets look at a simple example. What we will do is create a DataContract class, and set that is has two Attributes or Properties, Name, Account. To do this, we need to create a new class, and within the Class declaration add DataContractAttribute metadata tag, as shown below.



Simply adding that given tag, will now enable this class to be used as a DataContract within AX 2012 and outside of AX 2012, when being exposed as part of a Service Operation.

Since we need to attributes, lets now take and add two class scope, private variables to the class declaration of our new DataContract.



Now that we have our class context, private Str variables, we can reference these in creating our attributes for the DataContract, as shown below.





You will notice that for each of these, we have to declare the give methods as DataMemberAttribute, so that for the given generation of the WCF Artifacts and WSDL, AX can know which methods on the DataContract are meant to act as such, and which are not.

On this same topic, you will also notice I supplied the Name, and Account in text as part of the DataMemberAttribute tag. The reason I do this, is so that those consumes outside of AX will see these as properties of the DataContract as Name and Account, vs. parmName and parmAccount.

Since properties don't exist in AX, we make use of the parm method concept that you see in the above pictures.

Now looking at our class from a higher level, we see that we declared the given element as a DataContractAttribute at it's class declaration, and then each property or DataMemberAttribute is declared using the parm Method concept.



That's It! Now you have a DataContract that can be used within a given AX Service Operation.

Lets do exactly that, with taking and creating a Service class, a SysEntryPoint that will represent an operation, and have it to where the DataContract is the required parameter of the method signature.



Now, if we took and deployed this as a service, contained within a service group, we would have a service operation called doWork that would require us to pass in the idbDataContract to operate off of.

That's pretty straight forward and easy huh? What about working with a collection, say a List of DataContracts? Now that is not as well documented yet, however very possible. This is enabled through the use of the AifCollectionTypeAttribute, as shown below.



Now, first thing you should notice is that we can have multiple metadata attributes applied to a given method, using , (commas) to separate the attribute tags. Next this AifCollectionTypeAttribute is an animal of it's own, lets me say that.

So what we are doing here is declaring the Parameter Name that will be used as part of this collection. Second, we are declaring the type of the parameter, which happens to be a class and finally we are telling AX what will live in this list, which happens to be our idbDataContract we created earlier.



The idea that this whole AifCollectionTypeAttribute enables, is because of the fact that X++ is not a strongly typed language, however when working with collections we have to give a strongly type collection. This is what we are doing when we work with the AifCollectionTypeAttribute. We are giving the generator of the artifacts a way to describe and create for use by external consumers, to interact with collection types, from X++.

So there you go, we now know how to take and create a basic custom service, a data contract and work with a collection of data contracts within AX and to expose that to the outside world.

My part of this series, I will show how these are called from within AX and outside of AX, and look at the differences and some other important supporting information in this area.

I hope you can see too, that this is the build up that we first touch upon as the vision some years ago in this post, Microsoft's strategy and vision for Dynamics AX and SOA, and one that we have been covering ever since.

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



"Visit the Dynamics AX Community Page today!"