Reverse Engineering Microsoft Dynamics AX

The Reverse Engineering tool is a feature newly added to the integrated development environment (IDE) of Microsoft Dynamics AX. This tool replaces Visual MorphXplorer which has been removed in version 4.0.

As the name suggest, this tool helps us retrieve detail information on the structures and relationships of Microsoft Dynamics AX objects. The retrieved information is transformed to a visually readable format in Microsoft Office Visio UML model. Technically, Dynamics AX will create a Microsoft Office Visio Drawing file (.vsd) using the Visio application component and construct a UML model with Visio UML add-on programmatically. Therefore you will need Microsoft Office Visio 2003 or greater with Visio UML model installed in order to use this tool.

Scoping Your Model

Naturally scoping required to create useful models. This allows us the flexibility to define what we want to include. In my opinion, a model of the complete Dynamics AX application would be too huge to be useful if not too time consuming to generate and maintain.

Dynamics AX Reverse Engineering tool scopes the model through development projects either private or shared. So you must first create a project and include the elements that you would like in your model in the project in order to generate a model.

Types of Model

This tool is capable of generating two types of model; data model and object model. Let's see what does these models capture and how do they differ.

Data model mainly captures tables. Tables within the project as well as tables referenced by them are included in the model. Tables within the project are grouped by the AX TableGroup property. They are organized under groups named Main, Group, Miscellaneous, Parameter, Transaction, WorksheetHEader and WorksheetLine. Referred tables will be placed under the group External Classes.

You will also find relevant information such as fields and its data type, indexes, and relationship of each table in the generated model. The data type of these fields is modeled in Dynamics AX Extended Data Type. Dynamics AX Extended Data Type used by the model is included under the group External Data Type. This is the same for Dynamics AX Base Enums. The referenced enumeration with their members is captured under group Base Enums.

Due to the use of Visio UML model, each of these tables will be represented by a class and fields are modeled as attributes. However, table method is not included here. Table method is an important feature of Dynamics AX development platform but methods are not quite relevant for data model.

Those that would like to have the methods included could use the object model instead. However, that model will not have data model information such as relationship and index.

Object model will capture classes, tables, and interfaces relevant to the project. This includes referenced objects as well. Tables and classes within the project are generated under the main group without further grouping. Referenced objects are placed under group External Classes just like Data Model.

The properties and methods of the classes are modeled as attributes and methods in the class diagrams. Table entities are modeled the same way too. Information synonymous to object model such as class extends another class, class implementation of an interface and call between classes are found in this model.

Data type that the properties and methods uses in the form of Dynamics AX Extended Data Type are included in the model under Extended Data Type group. The same happens to Base Enums.

The table generated in Object Model will have table methods modeled as method unlike those in Data Model. Since this is an object model, you will not find information such as field index and table relationship in this model.

Information	Data model	Object model
Tables	Yes	Yes
Related tables	Yes	Yes
Table fields	Yes	Yes
Table methods	No	Yes
Table group property	Yes	No
Field index	Yes	No
Classes	No	Yes
Referenced classes	No	Yes
Extended Data Types	Yes	Yes
Base Enums	Yes	Yes
X++ Data Types	Yes	Yes

How to Generate

This feature is only accessible through the context menu. The following are the steps to generate a UML model using this tool.

1. Create a project and move the elements you would like in the model into this project.
2. Right click on the project and select Add-Ins>Reverse Engineer.
3. This will load a form named Visio Reverse Engineering. Enter the path and filename for the Visio drawing file.
4. Select the model you want to generate then press OK. You may generate either data model or object model.

Conclusion

This is good news for those that are already using Microsoft Office Visio for their modeling tasks and is familiar with Visio UML model. I have tried my hands on Visio UML model years ago but have never developed a liking for it.

Those that have already got used to generating data model with Visio Data Model Diagram might find the data model reverse engineering redundant. I agree that Visio Data Model produces excellent model but it reverse engineer at the database level. The challenge with AX is that a lot of information is not implemented at the database. AX relies heavily on extended data type and enumeration implemented at the application level. Another challenge is AX implementation of temporary table which does not appear in the database.

These challenges are addressed with the use of AX Reverse Engineering tool. Field data type will be represented in extended data types. Information regarding extended data types and base enums are included in the model too. Temporary tables could be included in the model. This is something that even the MorphXplorer does not support.

Is this better than MorphXplorer, the tool it replaced? I see much more information compared to MorphXplorer. The outcome is more professional too.

Download Demonstration Toolkit for Microsoft Dynamics AX 2009 Pre-Release

There has been much hype around the soon to be released Microsoft Dynamics AX 2009. Certain companies were given the privilege to get their hands on Microsoft Dynamics AX 5 Community Tech Preview 3 (CTP3). Do note that the name was the initially expected Microsoft Dynamics AX 5 instead of Microsoft Dynamics AX 2009 which it is currently called.

Demonstration Toolkit

It has been a common practice for Microsoft Dynamics to issue Demonstration Toolkit for Microsoft Dynamics AX in the form of Virtual PC (VPC) image. The Demonstration Toolkit for Microsoft Dynamics AX 4.0 SP1 for example was distributed in the form of two DVDs. The package comes with marketing material and presentation decks for different industries, and VPC Images for Microsoft Virtual Server as well as Microsoft Virtual PC.

Microsoft Dynamics has done the same for the Pre-Release of Microsoft Dynamics AX 2009. The Demonstration Toolkit for Microsoft Dynamics AX 2009 Pre-Release is available for download at Demonstration Toolkit for Microsoft Dynamics AX 2009 Pre-Release (requires PartnerSource login).

You will need Microsoft Virtual PC to use this toolkit. The good news is it is a freeware available for download. Get your free copy of Microsoft Virtual PC 2007 downloaded to run the Demonstration Toolkits.

Disk Space Requirement

Usually this toolkit is distributed in DVDs. Hence, do expect the download size to be huge. The files for this toolkit has been compressed and split into three archive files. The three files have a total size of 7 GB. The three files shall be downloaded into the same folder to be extracted. In other words, you will need an additional 7 GB or more to get the extracted files. So we are looking at no less than 14 GB of free hard disk space required to complete the task. Do note that the extracted files are all we need.

I have not the hard disk space to even download the files hence has not tried out. Those that have extracted the files could let us know how much space is required to extract the files.

Expiry Date

Another thing to take note is the expiry date of the VPC image. The Microsoft Dynamics AX 2009 CTP3 license in the VPC image will expire on August 31, 2008. The Windows of the VPC image on the other hand will expire on June 6, 2009.

What is in the VPC Image?

Apart from the Pre-Release version of Microsoft Dynamics AX 2009, there is a wealth of software installed and properly configured in the VPC image. Some of them are its pre-requisite whereas the rest are required to demonstrate the complete set of Microsoft Dynamics AX 2009 functionalities.

You will also find Microsoft Office Ultimate 2007, Microsoft Office Sharepoint Server 2007, Microsoft Silverlight, Microsoft Office Visio Professional 2007, Microsoft SQL Server 2005, and Microsoft Visual Studio 2008 Professional just to name a few. The complete list is available on its user guide.

Recommended Laptop Requirement

This demonstration toolkit is designed to allow us to perform demo to prospects. We are expected to run it on our laptop. I would like to note the system requirement for the computer that host the VPC image. Companies purchasing laptops for their team members could take the following into consideration.

Processor	Pentium 4 with 1.2 GHz processor or higher
RAM	2 GB minimum, 4 GB recommended
Hard disk space	30 GB minimum

Final Thoughts

I guess it is good to get our hands on Microsoft Dynamics AX 2009 if we have the capacity. Those that has not the luxury of Microsoft Dynamics AX 5 CTP3 installer should really find ways to get this Demonstration Toolkit to work. Although it is intended for demonstration, it is a completely working package.

My experience performing demonstration with the VPC image from Microsoft Dynamics AX 4.0 SP1 Toolkit has not been very pleasant. This should be due to my laptop not meeting the requirement stated above. It requires quite a bit of patience.

Service Log on Account - Local System, Network Service or Domain User Account

Service Log On account is an important yet often overlook configuration. Just as the account you login to your windows workstation determines your authority over resources, the service log on account defines what the service is capable of accessing.

Windows Service

Windows Services are long-running executable applications that run in their own Windows sessions. They are designed not to require user intervention hence do not show any user interface. Those working with Microsoft Dynamics Ax actually work directly with a few Windows Services. The Application Object Server (AOS) of Microsoft Dynamics Ax is implemented as a Windows Service. The database server be it Microsoft SQL Server or Oracle runs as Window Service.

You will find the list of Window Services installed on your computer from the Services Management Console. It is found under Administrative Tools > Services. The following image shows the Services Management Console.

Log On Account

When we configure a distributed system with Windows Services, Service Log On account is one thing we should pay ample attention to. We do not usually spend effort on this for a standalone all-in-one installation we usually have in our laptop for demo and some development. When the pieces of the software are installed over a few servers however, there will be resources over the network that we need the Windows Service to access.

Microsoft Dynamics Ax AOS for example could be installed on a separate server from the Application files. This is a common model in production environment where more than one AOS is necessary. In this case, the Service Log On Account for these AOS will need rights to the application files over the network. On top of that, the AOS gains access to the database server using this credential too. The rights over database objects are determined by this Log On account.

Apart from that, we would not want these services to interfere with resources within the server itself for security reason. Services for information system such as those database servers are rather prone to attack. It is important that the account that starts this type of Windows Service has sufficient rights over the resources it requires and no more than that.

The following figure illustrates an example of Service Log On Account setting. This is found on the Log On tab of the Service Property dialog box.

Account Options

You may choose among three types of accounts to start a Windows Service; the Local System Account, the Network Service Account, or a dedicated Domain User Account.

Local System Account

The local system account is a Windows operating system account that has full administrative rights on the local computer but has no network access rights. If your Windows Service interacts with network resources, this account is not an option. Moreover, this account has too many privileges on local computer. It is not recommended for use with Windows Services we are dealing with.

Network Service Account

The Network Service account is a special built-in system account that is similar to an authenticated user account. This account has the same level of access to system resources and objects as other members of the Users group. Services that log on under this account will use the credentials of the computer account to access network resources. This includes accessing database. You have the option to set database access rights using computer account only.

Apart from the issue in defining database access, this account has too many privileges for the services we are discussing here since it inherits the rights from the Users group.

Domain User Account

Domain user account is an account we create manually in the Active Directory. Privileges could be configured exactly to our needs. We may define resources rights across servers. We could even configure database access specific to the need of the Windows Service.

If we have multiple instances of Dynamics Ax AOS serving different purposes for example, we may have different accounts for the AOS services. This allows us to give rights to the correct set of application files and database only. We will not have to worry even if different teams of people are working on the instances.

This is the most widely used account for starting such service under production environment. It fulfills the requirement of giving all the rights required and not more.

Conclusion

Decision on what account to use very much depends on the environment. However, the general rule of thumb is to have domain user account for services such as Dynamics Ax AOS, SQL Server, SQL Server Agent, etc. in production environment. The flexibility and independence of this account type is helpful.

When you assign a user account to start a Windows Service, additional rights required for this purpose are assigned automatically. This is the case for Dynamics Ax AOS service. SQL Server services on the other hand require more setting than other services. The Log On account for them should be assigned during installation or through the SQL Server Configuration Manager in order to have those setting performed.