“This post is the first of a series on XrmToolBox where I introduce new plugins and demonstrates the merits of meta programming and generic software developpments”
MSCRM is now truly a framework, it provides the tools to create tools. Developers and Business Analysts alike benefits from a variety of ways to extends MSCRM's core components. One of the great collection of tools, which can be considered as an extension to the web based built-in customization and configuration tools and those available in the SDK, is the XrmToolBox.
In short, XrmToolBox is an open source project for a desktop application providing an excellent container for plugins which can be developed separately by a developers and shared as a NuGet package. Every-time the application is started it checks for new Plugins or updates and gives the option to install. All these plugins (or at least it was the intent) have one thing in common: they don't work on the business data, they are created to view and change the Metadata.
In this post I will introduce the CRM Workflow Explorer, a plugin I developed which is available now in the tool.
The need for a Workflow Explorer
Workflows are essential in any automation process. MSCRM provides a complete, reliable and very flexible workflow manager and a set of tools to design them. It's so popular and easy to use that any mature implementation of CRM ends up having hundreds of them. This create a new chanlenge: how keep track of the underlying design. This is especialy true if the Agile is the development method since it takes more time to document the workflow than creating it. MSCRM out of the box tools are good at tracking workflows, editing and troubleshooting them but it doesn't provide an easy way to get an overview of what's really there. This plugin is an attempt to fill that gap.
You can find a good reference for an introduction to workflows in CRM here.
The plugin at a glance
If you don't have XrmToolBox installed, download it from here
The set of icons used are as below:
"w" : workflow or child workflow
"e" : entity
"p" : workflow activity om a plugin assembly
"a" : activity
Plugin assemblies may have more than one workflow activity. To simplify the diagrammed and you can hide the workflow activities.
The diagramme doesn't show the plugins. This will be added in a future update.
Workflow Explorer Implementation detail
I will provide more information on the implementation and especially the algorithm used to display the graph in the next post but I will provide an overview here:
Discovering the relationships
As you know everything in CRM is an object (or component) identified with a GUID. Workflows, plugin assemblies, data records, attributes, reports....all are objects with attributes stored in the database. This plugin exploits the dependencies between these components to discover all components involved in the implementation of a Workflow or Activity and link together. Any time you edit an component and use another component inside, a new dependency component is created giving you all the information you need to draw an architecture/components diagram.
To discover the related components, there are 2 types of requests you can use, RetrieveDependentComponents and RetrieveRequiredComponents, depending on the algorithm you use and how you traverse the graph, from top to bottom or vise-versa In this plugin, the diagram is constructed from top to bottom and the RetrieveRequiredComponents is used.
First you start by retrieving the list of all the top components you are interested in, namely the workflows and actions.
https://<your-org-url>/api/data/v8.1/dependencies?$top=1
The resulting set of components are organized by entity in the a TreeView structure. You just start from the top components, retrieve the primary entities and construct the tree from top to bottom.
In CRM workflows sometimes a child workflow or an activity is used more than once in a given path. This is a kind of structural infinite loop and we need to be able to stop when it occurs. While constructing the tree I check if the component that I am about to run a recursive call on haven't been visiting. This information can be obtained by traversing the tree in reverse (checking the parent, the parent's parent...etc)
There is no data structure for trees included in the .Net core classes, because there are so many ways to implement one and so many different algorithms each one for a different purpose (how it meant to be traversed). It's also no difficult to make your own if you want just some basic functionality for the tree. The TreeView graphical component provided in the Visual studio has a inner tree data structure you can use.
Drawing the diagram
The goal is to draw a rectangle of equal dimenssions for each component in the tree and then relate them. The drawing area is an bmp image (you can use html and divs too) and all we need to do is to find the cordinates of the upper -left corner of the rectangle. A given component's coordinates is dependent on these 3 elements of information:
- the position of it's parent
- the position of it's previous sibling
- the size of the area required by all it's children to be drawn
Other applications
This plugin was essentially developed to represent relationships between 2 types of components, workflows and plugin types. There many other types of components in the CRM architecture, 59 in total and they are all linked together.
So basically you can pick any component and discover all other components related to it. You can then use one of the algorithms provided in this post to draw a graph.
As a future feature of this plugin I will add the CRM Plugins and the Plugin steps. It’s very crucial to any CRM designer to know what are the plugins that fire when a state of an entity record changes.
Another useful graph we can draw is that of an Entity. An entity is an important node in the components’ architecture. It can use many other types of components like Forms, Views, Charts, Fields, Keys, Relationships…etc.
In CRM the classification of components is made based on meta properties and data properties they share. The architect had this optimization problem in mind when trying to pick between different types of classifications: which one will yield the minimal number of properties.
In some components we have also a another level of classification. For example, workflows come in 5 flavors or categories: Workflow, Dialog, Business Rule, Action and Business Process Flow. Some components can be related to only selected categories of other components types. While the objective of the design was to minimize the number of properties, there was a need to classify the components based on their business functionality. Workflows, Dialogs and Actions could be used from an entity record a set of transformations on an entity record and it’s related records from the server side, while Business Rules and Business Process Flows are client side types of workflows and need to be associated with a form.
Conclusion
There are many types of components in CRM having all kind of relationships between each other. It’s not easy to discover those relationship in large implementations using the web based solution designer. This tool provided a visual way to view those relationships for a subset of components, namely workflows, and an algorithm to be able to draw in other types of relationships among the many existing in MSCRM.
Please refer to my next post: XrmToolBox – Making your own Plugin
Happy CRMing
No comments:
Post a Comment