Microsoft Dynamics Technical Conference, 2016 / Day 2 Session 5

My report from the technical conference.

 

This was the session where I mentioned ahead of time that I had a heart-rending decision to make. Fortunately, it was made for me.

 

I went to The new X++ compiler and the Microsoft Dynamics AX development platform with Peter Villadsen and Robert Badawy but it was completely full.

 

So I then went to Deep dive into Microsoft Dynamics AX packages and extensions with Joris de Gruyter. That had also been threatening to fill up, but they moved him to a bigger room.

 

 

Choice made, by default. I mean, everyone needs and wants this session! Go look it up!

 

 

 

Customizations = overlayering

Extensions

Some customers have reimplemented

 

Agenda

  • Model Store > Packages > Layers > Models
  • Customizations vs Extensions
  • Extension Scenarios
  • Upgrading to Extensions
  • Tips and Tricks
  • Extensions into the Future

 

 

 

Model Store > Packages > Layers > Models

  • Layers and models are a design-time concept only; they mean nothing at runtime
  • A package is one independent, individual set of layers and models; we are now compiling directly to dll’s
  • A package is a set of folders, consisting of XML files representing the objects; XMLs sit in a folder according to the package and model they’re in
  • A package as a whole translates 1:1 with a unit of compilation, i.e. an assembly (DLL)
  • Packages can have references to other packages, just like .NET assemblies can reference each other. But they cannot be circular
  • One or more packages combine into a deployable package, i.e. a unit of deployment

 

 

Demo: Packages, files and folders

“Model view” breaks it out by model

J:\AOSService\PackagesLocalDirectory\<Package>\<Model>

Descriptor folder is like the model manifest

 

Customizations vs Extensions

  • Customizing (“over-layering”)
    • Granularity of over-layering is down to the property level. So different customizations can change different properties on the same control. You’ll never want to over-layer a menu.
    • “Delta” files store changes only, with their original value
  • Models technically also “over-layer” each other
    • No more “traditional” model conflicts, only over-layering
    • Model conflicts don’t require changing the model’s contents
    • Over-layering granularity avoids most conflicts

 

Demo: Customizing, overlayering concepts, delta files

Project can only be in one model

Right click on the object and select customize or create extension

The XML stores both “original” and “yours” – if an ISV sends a hotfix, you now have a three way compare

Search bar: CF: = conflicts. Right click and resolve code conflicts

If you customize thru overlayering, upgrades will be far easier

 

Customizations vs extensions

  • Extensions are the new customizations (however going to pure extensions is near impossible)
  • Extension enablers
    • Events, metadata extension features, extension methods
  • Extension packages
    • Benefits on a code base short and long term
    • Package split impact on customizations
  • Change your extension suffix

 

Q: Can you turn an extension off? A: No
Demo: Extensions, capabilities

Everything extends platform, then foundation, then application suite

We use a lot of attributes

Name is: form.extension

Can rename to form.NewExtension

You can open an element in a specific project, package, etc. and that affects what you see.

Hierarchy of models? Last one installed wins

 

Extension Scenarios

  • Adding table fields, UI changes
    • Table extensions, form extensions, data entity extensions
  • Pre / post and other event handlers
    • Table event handlers, UI event handlers, traditional pre/post and [hookable]
  • Customization / extension hybrids
    • Customize based on extension artifacts, delegates
  • Plugins
    • Make your code extensible
  • “Package split” effects
    • Customize multiple packages
  • If a method is private, you can’t do event handlers on it unless you make it hookable.
  • Plugins are like the extension framework in 2012

 

 

Upgrading to Extensions

  • New artifacts vs customized artifacts
    • Moving new artifacts has consequences
  • Refactor vs upgrade
  • Current limitations
    • Queries (you can’t really extend a query), over-layering extensions
  • Security
    • Roles, duties – not privileges (you can’t extend privileges)

 

 

Tips and tricks

  • Metadata search
  • Go to form BaseForm
  • Quick way to move a control on a form is cut and paste
  • Tags
  • Visual Studio has bookmarks
  • Projects are not in your AOT; they’re just files in your file system
  • Reports don’t allow extensions
  • Element IDs are unnecessary now

 

Shout out to Yagesh! And sorry if I spelled your name wrong. Thanks for saying hi.

 

Happy DAXing!

 

Photo: Olympic Sculpture Park. Credit: me.

IMG_0806

Advertisements

About janeteblake

Dynamics AX developer
This entry was posted in ax 7, AX7, Dynamics AX and tagged , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s