Book Image

Mastering Microsoft Dynamics AX 2012 R3 Programming

By : Simon Buxton, Mat Fergusson
Book Image

Mastering Microsoft Dynamics AX 2012 R3 Programming

By: Simon Buxton, Mat Fergusson

Overview of this book

<p>Due to its interesting capabilities such as finance and supply chain management, business intelligence and reporting, project management, and so on, Microsoft Dynamics is one of the most widely used solutions adopted by many organizations across the globe. This book is a step-by-step tutorial that covers elements from the initial design through to development. Each concept is fully explained and demonstrated by the creation of a real-world project. You will learn some really useful, advanced development techniques such as extending your code with metadata and exception handling.</p> <p>This book is an invaluable tutorial if you are moving from another ERP system or language, or if you are a technical consultant with a desire to create efficient functional designs and business solutions.</p>
Table of Contents (21 chapters)
Mastering Microsoft Dynamics AX 2012 R3 Programming
Credits
About the Authors
About the Reviewers
www.PacktPub.com
Preface
Index

Working with version control


We can add any object, such as a table or class, to source control as long as it is modified in the current layer and not in a higher layer.

Adding a model to version control

When we created the models in Chapter 1, Preparing Our Solution, we added them to source control. This can be done afterwards by following these steps:

  1. Navigate to Version Control | Add model to version control.

  2. The Check-in description field is Check in by default and is usually suitable, but this can be changed if required.

  3. Select the model ID to add to source control.

    Note

    The Model repository folder field must be changed so that the last part is a folder for this model (you may have to create the folder).

  4. Ensure that a folder exists for the model under the folder set by navigating to Version Control | Version Control Parameters. If the Repository folder is C:\Projects\VCS\AX and the application root folder is 3579GettingStarted, create the folder under C:\Projects\VCS\AX\3579GettingStarted. Use the model's name as the folder name.

  5. Enter or select the folder in the Model repository folder, as shown in the following screenshot:

Managing AOT elements with version control

The integration with TFS from AX is done by importing and exporting XPOs of the changed parts of an element. If we add a method to the table TMSParameters and add it to source control, it will create a file called TMSParameters.xpo, which only contains that method. Let's take a look at the following code example:

Exportfile for AOT version 1.0 or later
Formatversion: 1

***Element: DBT
; Microsoft Dynamics AX Table : TMSParameters unloaded
; --------------------------------------------------------------------------------
  TABLEVERSION 1
  
  TABLE #TMSParameters
    EnforceFKRelation 0
    FIELDS
    ENDFIELDS
    GROUPS
    ENDGROUPS
    
    INDICES
    ENDINDICES
    FULLTEXTINDICES
    ENDFULLTEXTINDICES
    REFERENCES
    ENDREFERENCES
    
    METHODS
      SOURCE #conFMSNumRefConFMSVehicleId
        #server static NumberSequenceReference conFMSNumRefConFMSVehicleId()
        #{
        #    return NumberSeqReference::findReference(extendedTypeNum(ConFMSVehicleId));
        #}
      ENDSOURCE
    ENDMETHODS
  ENDTABLE
***Element: END

Handling whether an object is checked in or out is done by telling TFS to check in and check out the XPO. AX understands whether the element is checked in or not by requesting the status for the file stored in the TFS repository. There is no table that holds this reference; it is done purely using the folder structure we configured in the version control settings.

Once source control is active, we get six new options available to us in the context/right-click menu:

Option

Action

Add to Version Control

This adds the element to source control and exports an XPO of the changes in the element to the TFS folder structure. The element is marked as checked out and won't be available to the team until checked in.

This is only available if the element is modified in the current layer, and not in a higher layer.

Check In

This will export the element as an XPO to the appropriate folder within TFS and send a request to TFS to check it in to the main repository.

Check Out

This instructs the source control system to check out the element. This simply tells TFS to mark the XPO in its folder structure as checked out.

This is only visible when the element is not already checked out.

Undo Check Out

This will reverse the check-out process by importing the XPO from the TFS folder structure, thus reverting the changes made since check out.

History

This opens the check in history and also allows you to compare the versions using the compare tool.

Get Latest

This will get the latest version of the XPO from the TFS repository and import it.

These options are also available on the toolbar ribbon on the AOT and project windows.

Version control options

We also have some useful tools on the Version Control option from the main menu.

Changes

The Changes option lists all change sets that have been checked in to TFS, and by whom. You can view the contents of each change set and compare the change to the current version or prior versions.

Pending Objects

The Pending Objects option lists all objects that are pending to be checked in. This can be to add, edit, or delete from TFS. You can start the check in from this form. You can also create a project, which is useful when we wish to export the changes in case they need to be shelved.

Synchronise

The Synchronise option will synchronize the TFS repository with your local environment, applying all changes made by other developers; this includes any deleted elements, and this option does so without any warning. This may sound scary, but it is no different from a developer deleting an element in a shared development environment, except for the fact that we can get it back!

This can be run with a Force option that will fetch everything, and not just the changes made since the last synchronization.

When we start this, we are asked which model we need to synchronize, and will default to the layer. We must always change this to the model we are working with, and repeat the process for each model we wish to synchronize with.

Synchronisation log

The Synchronisation log option shows a list of the elements affected by the last synchronization and is worth checking in case an element did not synchronize. You can see this by the Completed field on the list. You can reprocess the incomplete items using the Process button. Each synchronization will be added to this list, so we should use the Clean up log (all records for the current synchronization) or Clean all button to clear this. The following screenshot shows this:

Note

The main reason for a failure is that the element has been modified in a higher layer.