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 Document Services

Recently I wrote about Microsoft Dynamics AX 2012 and a Dive into services. This article focused specifically on the different types of services that exists now with Microsoft Dynamics AX 2012 and what their intended uses are.

I followed that post up, with a Dive into System Services; Metadata Service, where I showed how the Metadata service could be called, and made use of from example C# code. Now today I want to continue that dive, and focus on Document Services.

As I wrote previously, and based on Microsoft recomendations, Document Services should be used for any complex CRUD operations. This means, any Create, Read, Update or Delete operations that are needed on any dataset within Microsoft Dynamics AX 2012, that is beyond simple data contract needs.

Document Services are not new actually for AX, however in this release they are improved greatly, and the ability to create document services, and get them up and running fast, is what's going to make all the diference in the world, from a development stand point. Beyond that, to administrate them, and in speed in which these now operate has been greatly improved, along with removing size limits for messages coming through the AIF Document Services.

So Lets get started and dive right into creating a Document Service. In order to do that, we will need a project, and to keep things straight forward, lets create a custom table, with two fields in it. Call this idbTestTable, and create two string fields, called IDB1 and IDB2.



Now that we have our custom table, lets move to create a new Query object that wraps this custom table. The major things about this query object, is once we have it created, and drag our table over to be it's datasource.



Now we can take and click on the properties of that datasource, and make sure the property of Update is set to Yes. What this will allow is our create, update & delete operations, to work through this query object.



Now that we have that set, lets move forward to the fields, and on the properties of the fields node itself, make sure and change the Property Dynamics to Yes.



What this does, is takes and when we add a field, the Query object will be updated automatically for us, making it to where we do not need to come touch every query that maybe referencing our table here, to make sure the fields are added for use.

There could be a case to where you don't want this to take place, but for now, lets set this anyway.

Since we have our Query Object, we can now take and right click on it, and click on the "AIF Document Service Wizard".



From here we want to make sure and enter our service name, and description, as well as make sure and check the operations we want, which cover our CRUD operations. The Find and FindKeys, we will cover in a later post.





Now that we have this, lets click OK, and see that Microsoft Dynamics AX creates us some classes, and a private project.



Lets move the objects of that Private Project into our project we already have going. Make sure everything compiles, and move to our next step, which is creating our service group. We will need a new ServceGroup, Group in our project, so lets create that, and then create our idbServiceGroup under it. After doing that, simply drag and drop the service node under it, as seen below.



Now that we have this simply right click on the service group, and left click on deploy.



We should seen an info log messages, that look similar to the following. Make sure there were no errors, and we are now ready to make use of the service.



Now that we have our service, lets take and consume that as a service reference from a VS2010, Windows Form Project. Simply go to the project, add a new service reference. Keep in mind the format is http://server:port/DynamicsAX/Services/idbServiceGroup. This will render the WSDL, and be used to generate our reference and proxy objects for us. You should have now a service reference that looks like the following in your project.



Now lets take and add a button to our Windows Form, and within the code of the button, lets add the needed C# to take and

call the service and add a record to our custom table through this document service. Your code should look similar to the following.



So here, I'm working with the Entity object that represents my service as well as my data contract, that enables me to fill, with possible multiple records, for our idbTest table. Then simply, I open the client, call the create, with a null context (more on that in a later post), and bang! We have records in our table in AX, through the use of Document services!



Just to show off the power of this, the same service can be called from within X++ code, to create records as well. I want get into all the details of this, however you will notice the use of the AfStronglyTypeDataContainerList object being used, as well as the use of the Marco that was generated for us by the Document Services Wizard. (More on this kind of example in a later post).

There are several new complex data structures in Microsoft Dynamics AX 2012, and the best way to interact with these, within AX or outside is going to be through these document services. I realize that this in itself, for people that have been working with AX for a while, is a new concept. However this is the desired goal of such services, in that business logic make use of them, specifically custom business logic.

One of the area's is around the new EcoResProduct, or Product Information Management data ( PIM / PDM ). Even within X++ because EcoResProduct is an abstract table, you don't ever work directly with that object. It's better to work with the abstracted way of making use of Document Services.

Now there will be times, when you need to still perform X++ SQL statements (XppSQL). So, you have to use your brain, to help let context, as usual, drive what your doing. However, if your creating products for example, within AX or outside of AX, it's Highly recommended the new EcoResProductService be made use of to achieve this process. Also mixing this with the InventItemService, and a few others to release products to a given legal entity for use.

A great write up was done recently by someone from the Microsoft team that talks you through exactly this process, from C#. You can find that write up here.: Product-item data management services

Now keep in mind, this same process can be done within X++, and AX internally as well. This changes how we think about importing and creating Master data in general with AX project, and it's very important to understand.

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 - MorphX Drag and Drop, but no fields?!

Alright, so one of the cool things that I wrote about recently, for Microsoft Dynamics AX 2012, was around the new Type Hierarchies, and the Type Hierarchy Broswer and it's use.

In looking at this, however, I was questioned about the ability to be able to say, create a new Query object, and being able to drag fields over from the table, into the new Datasource. To help bring this topic home, lets look together and one of the new datasets in Microsoft Dynamics AX 2012, the EcoRes* tables.

If we go to the EcoResProduct table, right click and go to the type hierarchy browser for this table, we can see, that it extends from common, and from it extends the EcoResDistinctProduct table object.



Now, lets take and open an AOT window, and browse to the EcoResDistinctProduct table object, so that we can see what kind of fields we have to work with, directly from the object within the AOT tree itself.



As you can see from above, we have no fields actually, within the AOT object, that represents the EcoResDistinctProduct table, to actually reference directly or work with directly. So what can be done then, for dragging and dropping fields, on datasources for example?

To show this off, we will need a new custom Query object. This will be the same, however, for any datasource for a form, report, etc. etc. So lets take and create our new custom Query object. Once we have that, take and drag and drop the EcoResDistinctProduct table from the AOT window, into the datasources of the new custom Query as shown below.



In doing this, we see that we now have the EcoResDistinctProduct table as our datasource, and again no fields, when expanding the fields section under the Datasource node. Now here, you could manually add a new field, but that's no fun, now is it? Enter the power of AX 2012, and the continued use of MorphX!

Simply go back to the AOT window, and expand the fields of the EcoResProduct table, and drag over, say the DisplayProductNumber field. Drop it into the fields section of the EcoResDistinctProduct datasource, and bang! We now have the DisplayProductNumber field, for the EcoResDistinctProduct datasource and table, and not the EcoResProduct table.



Looking at the properties, below, you will see this is actually the case, as Morphx and the power of AX 2012 still handles this for us, and understands that we want that field, for the Distinct products, and not the products itself.



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

Microsoft Dynamics AX 2012 - Type Hierarchy

With the upcoming release of Microsoft Dynamics AX 2012, one of the rather interesting new elements about this release, is the introduction of table type hierarchies.

When you glance at this, just from a data layer level, it seems to be super normalization. That is actually correct, however, you must look at the total picture. That means, you must take and look at this from the data + application layers, together.

That is the only way, that this concept then actually works. In order to help understand this concept, and how the new data structures live within Microsoft Dynamics AX 2012, there is a new tool called the Type hierarchy browser.

You can get to this tool, from any object within AX actually. Classes, tables, etc. For this post, we will focus on tables, and how the tool can help us better understand the data structure.

Lets pick a new structure in Microsoft Dynamics AX 2012, EcoResProduct. This is part of the new Master Data Management (MDM) / Product Data Management (PDM), that will exists out of the box for this release of AX.

Once we have selected the EcoResProduct table, within the AOT, simply right click, add-ins, and then click on the 'Type hierarchy browser' menu item.



Once we do this, we then see the hierarchy that exists for the EcoResProduct table, which extends from the Common table object.



You will notice, that both Common and the EcoResProduct tables have RecId, revVersions & relationType. You will also notice that, DataAreaId is no longer listed. We will save that for another post.

In here we can see as well that the EcoResProduct table inherits methods, from the Common table object. Fields that exists at the EcoResProduct table, are marked with blue blocks, that exist beyond the Common table. We can also see that, in the tree view on the right hand side of the screen, that the hierarchy make up, that EcoResProduct is a part of.

Extending from the EcoResProduct table object, is the EcoResDistinctProduct, and the EcoResProductMaster. Extending from the EcoResDistinctProduct, is the EcoResDistinctProductVariant table object.

Now, if we step forward in the tree, and select the EcoResDistinctProduct, in the tree view, we should see something that looks like the following.



Now you will notice, that for the EcoResDistinctProduct table, the only fields it has, is the three system fields that we listed above. If you look at the data for this table, sure enough that's all that is there, from the data layer perspective.

What this suggests then, and shows, is that the actual field data that lives for a Distinct Product, vs. a Product, still lives within the EcoResProduct table. The EcoResDistinctProduct table inherits the fields for: SearchName, ProductType, InstanceRelationType, and DisplayProductNumber.

When the table is referenced within a form, or code, the EcoResDistinctProduct table has these fields as possible uses, becomes of the new way AX handles, allowing table structure hierarchy.

This does a lot of things for such structures, it cuts down, big time, on the amount of repeat data, size of databases, and enables the application layer, to be the only true way, of working with the data that lives within a Microsoft Dynamics AX 2012 instance.

With using the Type hierarchy browser, provided out-of-the-box for Microsoft Dynamics AX 2012, one can better understand the new data structures, and be able to connect all the new dots, that will exists with this release.

This is very powerful, and through the use of the application layer, the statement of Powerfully Simple, which is the tag term being used to describe Microsoft Dynamics AX 2012, is true!

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



"Visit the Dynamics AX Community Page today!"