Monday, October 16, 2017

More Auto Numbering features

In my previous article I described the details of the new Auto Number attributes feature of Microsoft Dynamics 365, and how to manage them using Auto Number Manager for XrmToolBox.

Since this article, a few new possibilities have been verified to be supported.


Adding Auto Numbering to existing attributes

The most important new feature is the possibility to apply numbering to existing attributes!

This means that you can now apply your own completely custom numbering to standard attributes such as Case Ticket Number, Account Number, and so on.

image

Friday, October 6, 2017

Auto Number attributes in Microsoft Dynamics 365

With the release of Microsoft Dynamics 365 Customer Engagement October service update (v9.0), two of the most requested customization features were finally implemented in the platform:

  • Multi-select optionsets
  • Custom auto numbered attributes
The first one has full customization features available in the UI out of the box, but to create and manage auto numbering attributes you have to write code utilizing SDK-functions.

This article will describe how to use the Auto Number Manager tool for XrmToolBox giving an intuitive UI to access SDK-only features for auto numbering.

image

Auto Number Features

The Auto Number attributes support three different types of placeholders – sequential numbers, random text, and date/time in different formats.

Syntax

Sequential number:

  {SEQNUM:n} where n is the minimum number of digits.

Random text:

  {RANDSTRING:n} where n is the number of characters in the random string. Maximum value for n is 6.

Date/time:

  {DATETIMEUTC:fff} where fff is a standard datetime format string. See documentation.

Other text:

    Any other text may be included in the number format. This text will be used as is.

Sunday, September 24, 2017

A canary in CRM

canaryHave you ever faced a situation when you don’t know why your Microsoft Dynamics 365 Customer Engagement system behaves the way it does, or why your own plugins behave the way they do?

If you have, this might be a good time to put a canary in your system.

- A what?
- A canary.

You know when we were manually laboring down the coal mines, it happened that drilling into the rock inadvertently let out poisonous gas. So we brought in cages with canary birds putting their life at stake, to save our coal miners’ lives. The canaries were signaling the content of the atmosphere long before the coal miners would detect something dangerous. They did this by suddenly being upside down, instead of happily chattering.

As a plugin developer of many years, I have added extra tracing to my plugins more times than I can count and sometimes even added steps for more messages than necessary, and I am sure most of you reading this post have too, in one way or another.

Wednesday, June 21, 2017

Public Preview: Build and Deploy Microsoft Dynamics 365 projects using VSTS

Recently I posted a series of three articles describing our approach to DevOps for Microsoft Dynamics 365, and the technology behind it.
After giving a session on this topic at CRM Saturday in Madrid, Spain, it is now time to announce “public preview” of our tools.

If you want the full story – these are the articles describing the background and technology behind our tools:

Part I – Background and how our DevOps tools evolved before we knew about it
Part II – Automation of the build and deploy process using custom VSTS Build Tasks
Part III – Demo of complete build and release definitions taking you from A to Z

Thursday, April 20, 2017

Build and Deploy Microsoft Dynamics 365 projects using VSTS – part III

This is the third and last article telling the tale of our own DevOps for Microsoft Dynamics 365, and the technology behind it.

Part I – Background and how our DevOps tools evolved before we knew about it
Part II – Automation of the build and deploy process using custom VSTS Build Tasks
Part III – Demo of complete build and release definitions taking you from A to Z


After the first two articles we have now got a handful custom VSTS Build Tasks to help us take the build and deployment automation all the way. This final article demonstrates how we do that with VSTS builds and releases. Finally raising the questions of why we did all this and where to go from here.


A complete VSTS Build for Microsoft Dynamics 365


Below is a sample of a full build process that not only builds and packs a new CRM solution, but updates the individual assemblies and webresources in DEV environment, exports solutions and data, and then publishes the files exported from DEV together with Shuffle Definitions and Package Definition, which is the resulting build artifact.

Build and Deploy Microsoft Dynamics 365 projects using VSTS – part II

This is the second article of three telling the tale of our own DevOps for Microsoft Dynamics 365, and the technology behind it.

Part I – Background and how our DevOps tools evolved before we knew about it
Part II – Automation of the build and deploy process using custom VSTS Build Tasks
Part III – Demo of complete build and release definitions taking you from A to Z

In the previous article I described the background of our struggles with moving configuration data and later scripted export and import of solutions and the CRM Deployer tool. This article takes these features to the next level by packing those and some other missing features into custom VSTS Build Tasks.

 

Automating the Build Process

We now had the tools we needed to automate the central parts of the build/deploy process. But it still involved lots of manual or script based steps. To describe it simply, the following steps were required to produce a full deploy of a Customer Solution (CS) that has a prerequisite in one of our Product Solutions (PS), assuming we wanted the latest available code and customizations for both PS and CS.

  1. Build PS
    1. Define new PS version number
    2. Set version number for assemblies
    3. Compile assemblies
    4. Use Plugin Registration to update PS DEV assemblies
    5. Minify webresources (scripted post build event)
    6. Use Web Resource Utility to update webresources in PS DEV
      (scripted post build event using modified version from SDK, that allows command line execution w/o user interaction)
    7. Run Shuffle scripts that export PS solutions and data from PS DEV
  2. Build CS
    1. Run scripts that import PS to CS DEV
    2. Define new CS version number
    3. Set version number for assemblies
    4. Compile assemblies
    5. Use Plugin Registration to update CS DEV assemblies
    6. Minify webresources
    7. Use Web Resource Utility to update webresources in CS DEV
    8. Run Shuffle scripts that export CS solutions and data from CS DEV
  3. Create package (by running a script)
    1. Collect all required definitions, solutions and data files from PS and CS exports
    2. Execute CRM Deployer with cdpkg file and a flag to create cdzip archive

The missing pieces

Some of the steps above would be possible to encapsulate a bit more with scripting or tailored tools, and some of them possible to perform using Microsoft’s Developer Toolkit, Jason Lattimer’s CRM Developer Extensions or Wael Hamze’s CI FrameWork. But with the legacy of our Shuffle and later the CRM Deployer, that both have well proven technology and still save us literally hundreds of hours every month, we decided to add the few missing pieces in our puzzle ourselves.

Build and Deploy Microsoft Dynamics 365 projects using VSTS – part I

During my eight years as a Microsoft Dynamics CRM / 365 developer, I have felt a strong pain every time it was time to package and distribute a customer or product implementation.

Over the years our tools have evolved to now support a complete automated process; from source repository via compilation, updating dev environment, exporting solutions and configuration, collecting the artifacts and compose deployment packages to be installed manually or by VSTS release management.

This is the first article of three telling the tale of our own DevOps for Microsoft Dynamics 365, and the technology behind it.

Part I – Background and how our DevOps tools evolved before we knew about it
Part II – Automation of the build and deploy process using custom VSTS Build Tasks
Part III – Demo of complete build and release definitions taking you from A to Z

 

My hope is that these articles will inspire you to take your delivery process to the next stage by implementing automation through CI and what is usually called DevOps. If you are already there, these articles should provide an alternative solution, which may or may not suit your needs today, but might be worth considering.

 

It started with the data

Back in the days of CRM 4.0 we started delivering systems that were based more and more on generic configurable functionality. The benefit of having an automated way of delivering and moving configuration data between CRM environments was becoming increasingly obvious.

This was long before utilities like the Configuration Migration Tool, so we started to draw the blueprints to develop the functionality we needed. Basically, what we needed was to grab a bunch of data from a source environment to persist it in a file, and later push it into another CRM organization.

Monday, March 20, 2017

Developing plugins for analysis – part IV

At the eXtreme365 conference in Lisbon, Portugal I did a session on plugin development with focus on adapting your code to empower the tracing and investigation features available in the Microsoft Dynamics 365 platform.
In this final article from that session I will dig deeper into how use the Correlation Id to trace plugin execution chains.

Missed the previous articles? Read the first, the second and the third.

 

Correlation

The Plugin Trace Log offers possibilities to track how execution of different plugins correlate to each other. This is done by identifying log records with same GUID in field Correlation Id.

The correlation id is described in the documentation as GUID for tracking plug-in or custom workflow activity execution, with remark used by the platform for infinite loop prevention, in most cases this property can be ignored.

This means that all trace log records originating form the same request to the platform will have the same Correlation Id. That information is very valuable during plugin analysis as you can follow exactly which user action that led to which plugins executing, and which plugins that executed as a result of the first plugins, and so on.

Sunday, March 19, 2017

Developing plugins for analysis – part III

At the eXtreme365 conference in Lisbon, Portugal I did a session on plugin development with focus on adapting your code to empower the tracing and investigation features available in the Microsoft Dynamics 365 platform.
This is the third article from that session where the Plugin Trace Viewer is explained.

Missed the first articles? Read the first and the second.

 

The Plugin Trace Viewer

This tool in the “industry standard” XrmToolBox was created to make the potential power of the Plugin Trace Log available to anyone.

image

The log contains so much information that can make plugin analysis a lot easier, if presented in an intelligent way.

Friday, March 17, 2017

Developing plugins for analysis – part II

At the eXtreme365 conference in Lisbon, Portugal I did a session on plugin development with focus on adapting your code to empower the tracing and investigation features available in the Microsoft Dynamics 365 platform.
This is the second article in a series to describe the essence of that session.

Missed the first article? Read it here.

 

The Plugin Trace Log

The Plugin Trace Log is basically an entity in CRM. One trace log record contains details about one plugin execution.

The entity has a number of fields that describes some “hard facts” about the execution, such as start time, duration, entity and message that triggered the execution and other details from the execution pipeline.

It also contains a field called Message Block, and this is where your own custom logging information ends up. This is where you tailor your style of logging, this is where it gets interesting.

Developing plugins for analysis – part I

At the eXtreme365 conference in Lisbon, Portugal I did a session on plugin development with focus on adapting your code to empower the tracing and investigation features available in the Microsoft Dynamics 365 platform.
ICYMI: This article is the first in a series to describe the essence of that session.

image

I was quite surprised to see a crowd of about 60 attendants, of which most were developers already focusing on plugin development.
There is evidently a demand for the deep techy sessions at events such as eXtreme365, where most sessions have a distinctly “higher” perspective on the platform. The fact that this session attracted more people than my competitors on the technical track in this time slot (three sessions led by Matt Barbour, Roger Gilchrist and Julie Yack) makes it even more obvious – “nerdy” sessions like this are really appreciated!

Sunday, March 5, 2017

I get by with a little help from my [base class]

Developing plugins for Microsoft Dynamics 365 (CRM) only using bare SDK libraries make you do the same stuff over and over.
This is why one of the first things I did when starting to work with the platform was to create a helping hand in the form of a plugin base class, implementing IPlugin.

This class soon evolved to a library implementing our own organization service, custom file logging, encapsulate our translation and configuration management entities, and tons of other useful stuff that helps me and my colleagues develop plugins and integration services so much faster and easier than without it. Development speed aside, it makes our code more readable and easier to follow, as most of the background activities are performed in the same way.

Another benefit is that if optimizations to the backing libraries are possible, we can ship the improvements with a few simple clicks to all of our products and customer projects by just publishing a new version of our private NuGet packages, instantly available to any and all consumers.

As these libraries have evolved over the versions, beginning with Microsoft Dynamics CRM 4.0, they quite naturally contain some technical debt, which for me as responsible developer translates to bad sleeping patterns and a nagging feeling that one day I want to rip it all out and rewrite everything. In our day to day work, we improve on the libraries, but want to keep breaking changes to a minimum, which by definition can only increase the debt.

 

I saw the light

Monday, January 30, 2017

CRM Saturday – XrmToolBox with Jonas Rapp

CRM Saturday is a recurring event where Microsoft Dynamics CRM/365 experts and MVPs gather for a day filled with sessions from both strategic and technical perspectives on everything from user adoption to plugin unit testing to IoT and intelligent analysis.

On Saturday January 28 the event was held in London, UK at the Microsoft offices in Paddington.

As a “senior contributor” to the world famous XrmToolBox by MVP Tanguy Touzard I was invited to do a session on simplifying development using XrmToolBox.

image

My session covered a brief XrmToolBox background, examples of my own favorite tools, and deep dive demos of FetchXML Builder and Plugin Trace Viewer. Of course you cannot do a demo with some customizations and plugins without using a few other XrmToolBox tools, so I did not only cover my own block busters…

The presentation from the event is now available here: CRM Saturday – XrmToolBox with Jonas Rapp

This contains the full presentation, and also step by step details on the demos performed, as well as some bonus demos that did not fit the tight session schedule.

Note that the presentation also contains reference to a free to use GitHub repository with a simple plugin base class, that can be inherited instead of simply implementing the SDK interface IPlugin to greatly simplify plugin development and logging to the Tracing Service.

The repository is available here: https://github.com/rappen/JonasPluginBase

If you would like to dig even deeper into the tracing service, XrmToolBox and the Plugin Trace Viewer – join me on my session on this topic during eXtreme365 for Partners in Lisbon, Portugal that takes place March 13-15 2017 !

 

If you have any questions regarding the presentation, demo or the plugin base class, don’t hesitate to contact me!

 

More information on CRM Saturday: http://crmsaturday.com
More information on eXtreme365: http://extremecrm.com