Further, the CRM middletier has all "knowledge" of the CRM metadata in the Org database, and knows
exactly on how to handle it (DML: update, insert, delete, select, plus DDL: create, drop statements etc..)
The forementioned two databases are critical for the operation of CRM.
Backup and Restore of databases is usually the task of the DBA. You might want to know how the databases
are backupped. Best is to ask the DBA.
Also, before any update or rollup is applied to CRM, make sure you have recent backups of the databases.
2.3 A few words on the middle tier: CRM Application Server.
Fig. 2: "Jip and Janneke" figure, showing some of the Internal components of CRM and their relation.
Source: My own "Jip and Janneke" figure.
A few keywords here, will "type" CRM to a certain measure:
To large extent, CRM is "message" based, for exchange of data, or for calling "methods" (functions of other objects).
Since messages are central, a "event execution pipeline" makes sure that the messages are handled,
and the requests "in" those messages, are executed by the webservices.
Thus, a Core component are "webservices". Other code, like custom PlugIn's (or standard PlugIn's), "consume"
certain functionality of those webservices. Or, in other words, the PlugIn's call the methods of such services.
Such a call results in an "event" and a corresponding "message". Sometimes, the words event and message
are used interchangebly, is my impression.
It's important to understand that the "webservices" are indeed those services as in the SOA specifications.
Ofcourse, the stack is layered, so the webservices with the underlying business logic, need to use data access services,
for example to access the metadata and Org databases. This then holds for the "Organization Data service".
Depending on the CRM version, some core webservices are implemented. As of 365, the service "Web Api" will
take over much functionality from other services, most notably the "Organization service".
However, still for 365 (in august 2018), 2016, and lower versions down to 2011, we have the webservices:
-The "Organization service" which would communicate with .Net additional code (additional customized code, like PlugIns).
To access it, the SOAP protocol was/is used.
-The "Organization Data service" is more geared towards CRUD operations, which means in SQL language
SELECT, INSERT, UPDATE, DELETE (DML) and DDL, whereas CRUD means Create, Read/Retrieve, Update and Delete.
These are implemented as methods in the "Organization Data service".
It's compatible with the OData or REST protocol to access it's functionality.
-The "Discovery Service".
Each of those services have a URL, to which you can connect to, like for example:
Organization Service URL (on premises): http[s]://hostname[:port]/XRMServices/2011/Organization.svc
It's just an example, for CRM 2011 up to CRM 2016.
You can check your URL's by using the CRM webinterface and check: Settings/Customizations/Developer Resources.
As said before, the 365 "Web Api" will (eventually) fully replace the "Organization service", and if I understood it correctly,
the "Organization Data service" as well.
Since some time, the "Windows Communication Foundation (WCF)" is used for the implementation of the Webservices,
and thus lowering the dependency on e.g. http.
A good idea of the Server components, or Server "roles", in CRM can be obtained by simply inspecting
one of the CRM 2015/2016 (on premises) setup screens, like the one shown below:
Fig. 3: A CRM 2015/2016 setup screen, showing the different Server components:
3. Overview developing in CRM.
3.1 Test environment and Sandboxes.
CRM is multi-tenant, meaning that you can have more than 1 Organization under the same CRM install.You even can create an Organization for the purpose of a Test environment.
In many articles, you will see such an arrangement.
If you would have one or more of such additional Organizations, then they are also often called "sandboxes".
So, you can have an additional seperate and isolated "organization" (including it's own database), in the same
CRM installation. The CRM documentation often speaks of the Produktion "instance", and possibly
additional "sandbox" instances. Since they are all isolated from each other, the CRM docs speaks of "sandboxes",
which is a generic term for isolated environments (isolated "organizations").
But they all reside under the same one CRM installation.
Since a sandbox is isolated, you can use it for Test/Developing purposes. It seems that many folks
indeed follow such practice. Usually, I recommend a seperate Test environment, but such undertaking
is by no means an easy task.
To create a seperate Test environment on different machines, is not an easy task. CRM is namely integrated in "active directory",
and if you would try to create a true seperate Test network, then you need a DC with Active Directory as well, which might present
it's own challenges.
Then you would need to have copies of the machines (or VM's) having SQL Server, and the application Server running CRM and IIS.
And indeed, if it's truly seperate, an AD instance as well.
Personally, I would recommend a seperate environment, over the use of Sandboxes.
Managing Instances, or managing Organizations:
You can manage Organizations using the "Deployment Manager" (Microsoft.Crm.DeploymentManager.exe).
Using this tool, you can create, delete, and import Organizations.
In a default "on premises" install, you may find the "Deployment Manager" in:
[drive:]\Program Files\Microsoft Dynamics CRM\tools
Such a discussion as above, is probably part of a dicussion on the "release process", or the way
you would handle custom software releases. So, this also relates to "source control".
If you will manage CRM, or you are part of such a team, you need to invest quite some time to find the best solution
for your organization. Interesting stuff for sure, but unfortunately not so very trivial either.
3.2 Managed vs Unmanaged code, or, Managed vs Unmanaged solutions .
As you will see below, you can develop a single PlugIn, or a Javascript, and register it into CRM.So, you are not forced to use "solutions" as shown below. However, the "default solution" will always be the collection
of objects you will work with. It's possible to solely work with components in the "default solution" only.
However, using other solutions have some advantages.
A solution is a group of such components, which can be managed "together", or in other words, can be managed "as a whole".
This especially is then relevant in exporting and importing (or deploying) the solution.
Using solutions, you can create, and manage, a "deployment strategy". Note that this is related to section 3.1 as well.
Indeed, it is possible to import or export a solution. If you export it, you will indeed have a series of files (in a .zip).
Note that the idea of solutions is an administative convienience. The default solution will still contain everything.
However, your particular objects in a particular solution, is "as if" it was being "tagged", and may operate "as if" it is an
independent collection. It can also be tagged as managed or unmanaged.
It looks like it is "outside" the default solution. As such, you can export that solution, and do other operations.
It takes a while to get used to the "CRM way of doing stuff...".
This way, we can have other solutions (collections) which all look independently.
A "managed solution" ("inside" CRM) cannot be overwritten, so it is protected from any modifications.
However, it is possible to set the property of a certain component "to allow customization".
A solution can have more items than just programmatic entities. For example, CRM, "just out of the box", delivers you
the "default solution" which is about everyting in CRM, like entities, reports, forms, roles, webresources etc.. etc..
However, you can create another solution, which is just an additional package of certain objects. Indeed, very often these
will be programmatic entities like JScripts or PlugIns.
If you want to take a look at the entities in the default solution, or view other solutions, from the CRM interface, use:
Settings → Customizations → Customize the System
Settings → Customizations → Solutions
Following is the screen you might see if you would go to the default solution using Settings → Customizations → Customize the System
Fig. 4: Showing the components in the "default solution":
Source: Simply a CRM screenshot (in browser), after choosen the menu option "Customize the System".
At least the following components might be part of a solution (and is part of the default solution):
Application Ribbon, Article Template, Business Rule, Chart
Connection Role, Contract Template, Dashboard, Email Template
Entity (a table in SQL Server), Entity Relationship
Field (column in a table, also might show up on certain "forms")
Field Security Profile, Form, Mail Merge Template, Message
Option Set, Plug-in Assembly, Process, Report
Sdk Message Processing Step, Security Role, Service Endpoint, Site Map
Web Resource (like a JScript)
Note that an external ASP.NET construct, with aspx files and Website, does not seem to be part of a "solution"
in the context we have seen above. That's not so strange, since these are IIS deployments and are external to CRM.
Ofcourse, such aspx entities can connect to the CRM system, and thus appears to be "integrated".
It's probably best to review a Microsoft MSDN article on solutions, which you will find here.
All of the above in this section, still is no more than a rather high-level view on solutions.
Especially the "in and outs" of managed vs unmanaged solutions, could have been done better.
Fortunately, good articles are on the Web. If you are interrested in more information on "managed vs unmanaged" solutions,
in combination with deployments on Dev/Test/UAT/Prod, and lifecycles etc.., then take a look at the following article:
Managed Vs Unmanaged Solutions (www.crmconsultants.co.uk)
3.3 Overview Customizations/Developing.
There are several ways, with various levels of effort, in how you can customize CRM to fit you business needs.However, CRM is CRM. That's rather trivial ofcourse, but if you go way out of that scope, one can wonder
how benificial that is, and will remain to stay so. I have seen a system where financials plus invoicing
plus lots more, was added to CRM, using inhouse programmers. That might be fine, but that also depends on how clever this
all was set up, which determines how easy or how difficult it is, to maintain and support the system.
In customizing CRM, (at least) the following area's can be distinguished. The following is my "interpretation":
(1): Relatively easy: Creating "webresources" as HTML files.
(2): Relatively easy: Creating standard Workflows.
(3): Relatively spicy: Adjusting Ribbons (menu bars).
(4): More elaborate activities: Programming Jscript (javascript) webresources, and associate them with Forms.
(5): More elaborate activities: Creating Plugins, using Visual Studio (C#, VB.NET).
(6): More elaborate activities: Creating aspx, and new websites, for specialized tasks, integrated in CRM.
Note on Workflows: standard workflows can be created using configuration dialogboxes.
which are available in the CRM interface. However, advanced "custom" workflows must be developed
using Visual Studio and in fact closely resemble PlugIns.
About (1) and (2):
In section 2.1, I referred to another site which has published a tutorial on CRM.
They indeed managed to illustrate the subjects (1) and (2) from my listing above, in a really nice way.
So, for those subjects, please read the corresponding chapters from that tutorial, which are:
HTML Web Resources
Microsoft CRM - Workflow Processes
About (3):
Although altering the Ribbon (e.g. adding "buttons", shorcuts, Yes/No for showing options etc..) certainly can
be useful, I leave it out from this note.
About (4), (5), and (6):
Yes, I like to present a high-level overview on these subjects, with their scope in CRM, their usual purposes,
and some basic sample code.
3.4 Developing PlugIn's.
Here is some basic information on PlugIn's. It should be sufficient to understand it's scopeand basic functionality.
Typically, a PlugIn is a somewhat smaller code unit, created for DOT NET, with a very specific functionality.
Since it's created for DOT NET, it is an "assembly", which physically is a .exe or .dll file.
In CRM, library assemblies (.dll) are implemented.
A PlugIn is "server-side" code, meaning it runs om the App Server, and it's integrated into
the CRM business logic. Or, maybe it's better to say that a PlugIn extents the business logic.
This is contrary to JScript (MS Javascript), which runs on the client.
Typically, a PlugIn does not have a "face", and does not interact with the user. It simply does the task
it was designed for.
Most often, a PlugIn is like a handler for a certain event. Again, most often, such an event (the trigger)
is a modification of some field of a certain table. Or, it's triggered by an insert, update, delete
event on a certain table.
The action of the PlugIn then might be an update on another table. Very often, the PlugIn is needed
because custom tables (entities) were added to the system, and modifications on one table then implies
certain modifications on other entities.
However, PlugIns are not only usable for the sort of functionalities sketched above.
For example, it might perform a financial calculation of some sort.
A new PlugIn must be registered into CRM, before it can be used. Often, the "Plugin Registration Tool"
from the SDK is used.
The main purpose of registering a Plugin, is to let "CRM know", that a handler (the Plugin) for a certain event
is available, and which must be fired when that event occurs.
⇒ The main actions you perform in "Registering" are:
-registering the .dll (the assembly) and specify where it is located.
-next specify where you want it stored: in the Database, or Global Assembly Cache, or disk.
-next specify if the PlugIn is associated with an "entity" (that's a table), and specify that table.
If that is indeed so, then the code in the PlugIn has ofcouse the statement(s) to "do something" with
that table or another table.
-next, specify the "pipeline stage of execution", which can be Post operation or Pre operation.
If indeed a table transaction is involved, then should the PlugIn act before, or after the transaction?
-next, specify if the PlugIn should work Synchronously, or Asynchronously.
⇒ Synchronous, or Asynchronous execution mode:
-If code should work in Async mode, it will be placed in a queue and will be executed when the queue Manager
has handled any other actions which were already placed in the Queue previously.
Async is great for any code which does not need to be executed "right now", and such mode can significantly
reduce the load on the system, where many users (and many PlugIns, workflows etc..) are involved.
-If code should go to work "right now", then it should be defined to work in Synchronous execution mode.
Obviously, since PlugIns often are bound to tables, and do an update/insert/delete on another table,
the execution mode is often Synchronous.
However, if the PlugIn is only designed to send an email (classical example of a PlugIn), then "there is no hurry",
and it's best to specify the Async mode.
You might like to review figure 2 again, to see the relation of PlugIns and the execution pipeline queue.
The process of Registering a PlugIn is completely graphical if you would indeed use the "Plugin Registration Tool" from the SDK.
It's not very difficult, although the corresponding dialogboxes require a lot of information to fill in.
Ofcourse, writing the PlugIn (the coding process itself), requires quite a bit of understanding
of C# or VB.NET.
⇒ The namespaces, or classes, you need:
Java, DOT NET, and other OO developing environments, have large hierarchical trees of classes,
containing reusable code, which you can "import" (or register, or extent) in your own new code.
So, you do not need to "invent the wheel" all the time, since so much classes are already available.
Therefore, before you start any typing of code, you select the classes you need for the job you want done.
The class "Microsoft.Xrm.Sdk.IPlugin" contains almost everything you need to let your code interface to the right
execution context in CRM.
It's called the "Iplugin Interface". It exposes the "Execute(IserviceProvider)" method which is the basic code
to respond to CRM events.
As you see from it's name, it comes from the SDK. By the way, if you really start coding for CRM,
you need the SDK anyway, so it's best to download the SDK for your CRM version.
A little info on .Net namespaces:
The dot Net framework also consists of a large library of classes (say: code of objects with methods and properties).
These are organized into hierarchical "namespaces".
We might have a certain namespace, and another namespace which looks like something like
a child namespace "below it", like for example:
System.Net
System.Net.Sockets
The first one only includes the types and names declared for Sockets. It does not bring in or contain
the full classes with the exact code and declarations and methods etc.., contained inside Sockets.
That's why at the top of a Dot Net source code, most often a number of "using" directives are listed.
So you might see for example:
using A
using A.B
where the latter means that you want to use the namespace "B" under "A", and not another "B" namespace.
So, you must use "using" for a certain namespace (classes), to bring it into the scope of your application.
That's why a developer also carefully selects what he/she needs for a certain application.
⇒ Simple PlugIn example in pseudocode:
I think that PlugIn's are not really the most easy ones (of the family of DOT NET codes)
to understand, or write. One reason is, that they use quite specialized objects/methods
for performing their task, and it does not look very intuitive, if you would ask me.
In any plugin, you must set the "execution context" and get it from the execution pipeline.
Thanks to have registered the PlugIn, CRM knows the enviroment to hand over to the PlugIn.
That's why most PlugIn's have statements, high-up in the source code, like:
IPluginExecutionContext context = (IPluginExecutionContext)
serviceProvider.GetService(typeof(IPluginExecutionContext));
One very important parameter, is the entity that the PlugIn uses for it's business logic.
As you know, an entity is actually the table in SQL Server, and here, in this code, this specific property
is called "Target".
Don't forget that most PlugIns are designed to "fire" when certain tables are modified.
if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is EntityReference)
Usually, more intial code is needed, but this text is more about pseudo code than a real PlugIn.
Once the Target is know, and other parameters as well, like the values of certain fields of the entity,
the actual business code gets to work.
Below you see an example of a certain calculation based on some table fields:
if (context.InputParameters != null)
{
Entity entity = context.PostEntityImages["PostImage"];
List_price = (Float)entity.Attributes["price"];
units = (int)entity.Attributes["units"];
Total_P = new Float(price * units);
"PostImage" means that we have retrieved the data after the database transaction was done.
That is, the database transaction occurred anyway, whether or not a PlugIn is around.
So, we used the "image" of values "afterwards or post event".
Now something useful has to followup, like lowering the "in_stock" field
of some table, or any other useful action.
Ofcourse, some sort of Exception Handling should be there as well. That's why the business code
often is written inside the "try ... catch" block.
Section 3.4 is nothing more than the absolute minimum of information on PlugIns, but I hope
that it helped to establish the general idea on PlugIn's.
3.5 Overview Developing using JScript (MS Javascript) for CRM.
I think this is more common in CRM, compared to developing PlugIns.It's certainly less difficult to pick it up, and get Up and Running in Jscript.
MS Jscript is around for many years now. The original Jscript looks a lot like Javascript.
It's OO, meaning that classes and instantiated objects, methods, properties are to be used, alongside
the usual constructs like variables, arrays, decision logic (e.g. if..then.. else) etc..
You could use it on your PC, or on a Server, or any place where an interpreter/engine is present.
However, Jscript for CRM seems a bit different, which becomes increasingly clearer as the
CRM version gets more recent. The later JScript implementations for CRM, are pretty much tied
to the CRM objectmodel (XRM.Page).
That's why JScript in CRM, is a bit "different" from the general JScript implementation (I think).
In the following I will exclusively refer to "JScript in CRM", and not the "general" JScript implementation.
Javascript and Jscript are (originally) both "client side", meaning that it's executed on the client,
and is downloaded from a Server to that client.
However, in principle, wherever a Javascript "Engine" runs, it can run Javascript.
So, where javascript actually runs might be any device. But usually, typically, it runs on clients.
By the way, other Java variants like "servlets", runs on a Server and create the documents
which are send to the client browsers.
Or in the MS realm, you might think of Javascript in ASP.NET, or node.js implementations.
Original Javascript, is a little different from the Microsoft JScript implementation.
There is much in common in both worlds, but there are quite a few essential differences as well.
Maybe they both look quite similar in syntax and scope, but remember that MS Jscript is not Java or Javascript.
=> Javascript is mainly tied to HTML programming, that is, to get, read, create, or manipulate HTML
document objects, and properties of those objects.
At some point, the W3.org produced a standard of the namespace, describing the objects,
and hierarchy of the objects, and properties of those objects, which are present "in" the HTML document.
As such, Javascript is able to access all objects and properties.
The model was called the "DOM" (document object model), and represents the document as a hierarchy of nodes (objects).
The model is "constructed" by the browser, and as a consequence, a programming language as Javascript
can access the objects and properties.
=> MS Jscript often deals with CRM Webresources like Forms. To get, read, create, or manipulate
the corresponding objects and properties, the XRM.Page namespace (or objectmodel) was implemented.
Also, for example elements as table fields (entity fields) can be accessed and modified.
So the area's where JScript operates on, is actually a bit different from Javascript.
Depending on your view on matters, fortunately or unfortunately, the model where JScript operates on,
have varied slightly among CRM versions as well. So there are some differences when you are going from CRM4 to CRM 2011.
Then there are some differences from CRM 2011 to CRM 2013. And there are some differences from CRM 2013 to CRM 2015/2016.
In general you may also say that support for DOM objects and methods, declined as the CRM version
went more recent.
In good tutorials you will find many recommendations and good practices for writing Jscript.
One recommendation is not using DOM, but to try to adhere to the XRM.Page model as much as possible.
A few notes on Jscript development:
You can apply JScript in many area's of CRM, but the three most prominent ones are:
- Via OData or SOAP endpoints, scripts can interact with web services.
- Ribbon customazation (working at the "ribbon menu system", like a function call associated with a button).
- The most used category: Interacting with forms, and form "event handlers".
Typically, a .js script contains one or more "functions" like:
function myfunction()
{
..
statements
..
}
If the script has two or more functions, it is often called a function library.
Ofcourse, such functions in the one same script should be related to the same subject, like
a library dealing with the account entity, and the related forms, in CRM.
The usual programming techniques can be used, like declaring "global" variables which are
defined outside the functions (at the top of the script).
And ofcourse "descision logic" can be used like if.. then.. else.. blocks.
All in all, it looks pretty much like most common programming environments.
However, the objects (classes), methods, and properties that you will use in your statements,
must be from the XRM.Page namespace (or objectmodel).
But, since JScript was quite heavily used in e.g. CRM4 or earlier, and CRM 2011, the DOM objects
are almost inevitable if you are dealing with a system originating from CRM 2011 or earlier.
Once, I needed to upgrade a CRM 2013 system to CRM 2016 (via CRM 2015). That system was even migrated
a long time ago from 2011 to 2013. So, the Jscripts used a lot of DOM objects, and were full of unsupported objects and properties.
Indeed, once on 2016, quite a few produced errors, or simply did not worked anymore.
Amazingly, by replacing the statements as shown below, it was possible to get quite a few of them
in a runnable state in 2016. (There were many exceptions to the rule, and required more effort).
-document.getElementById(); replace by: parent.document.getElementById();
-context.getServerUrl; replace by: Xrm.Page.context.getClientUrl();
-disableViewPicker; replace by: Xrm.Page.ui.controls.get("").setDisabled(true);
-crmForm.FormType(); replace by: Xrm.Page.ui.getFormType()
But the replacement of "document.getElementById();" by "parent.document.getElementById();",
was probably only helpful up to CRM 2015 (from CRM 2011/2013).
Other statements were problematic too. So, I still had not a fully functioning system. Those statements were like:
-Certain Statements using "attachEvent()"
-Certain properties or methods related to "padding".
-Amazingly, also statements like "field".style.fontStyle = 'italic'; /or other font.
For about the latter three: I could not always replace them, and had to write other code,
to get the same functionality.
Note: Since Dynamics 365, it might be fair to ask in how much XRM.Page will still be fully
supported in later versions.
Sure, it will be supported for a long time from now, but a newer objectmodel might get preference
in the not too far away future.
See Appendix 6 for an overview of converting DOM to XRM models.
Then there were quite some errors which turned out to be related to JQuery.
I had a hard time figuring this out, and I never completed to find the real source of errors,
and how to correct it. In my case, lots of JQuery parts still worked, but others did not, like for example
AJAX routines. I did not solved it, but simply took another road. So, I cannot tell you how to handle
a migration CRM 2011/2013 to CRM 2016 with respect to JQuery.
However, Microsoft states that JQuery for usage in forms, is unsupported. This is certainly observable
as of CRM 2015 SP1.
But, although I found other ways to more or less achieve the same results, maybe in your case, if migrating
from CRM 2011 / 2013 to 2016, you might try to use a newer JQuery library.
I observed some good results in upgrading JQuery_1.9.1 to version 2.xx or 3.xx.
But, on a whole, I still had too much errors and I migrated as much as possible to using "XMLHttpRequest".
But if you are migrating as well, you might simply also try a newer JQuery library.
As I understood at a later moment, JQuery "should be better", since it wraps pure XMLHttpRequest
into a more generic call. Strangely, that is not what I observed. However, every customized CRM system
has it own quirks, and it might be so that JQuery works better in general.
So, XMLHttpRequest is what the browser wants to see to make the request. JQuery is just a library,
and the $.ajax method is used to make the raw XMLHttpRequest.
A lot of original Javascript DOM statements still remained present in the scripts. Not all statements
adhered to the Xrm model, and there still remained plenty of usage of the DOM model.
But, as you can see above, there were about 8 types of statements which absolutely needed to be converted
to the Xrm model, to make it work. At least, that's my experience.
In my case, in CRM 2016, I also tried the legacy form rendering emulation (like in CRM 2011/2013) which
you can set in CRM 2015/2016. I believe that this option temporarily might help some shops.
See also Appendix 5 for more tips with respect to reverting to the 2011/2013 "legacy form rendering".
Ofcourse, this is certainly not a solution, and must only be regarded as a temporary workaround.
Note: To make a system "runnable" is quite different ofcourse from making it really compatible with future
versions of CRM. The best thing ofcourse is to make the scripts fully compliant to the latest object model.
But that's not to say that workarounds (like "legacy form rendering") are not helpful.
3.6 World's smallest and incomplete tutorial on JScript (MS Javascript) for CRM.
This section is not a full tutorial on JScript programming. It only shows you some basic idea's.It deals on CRM 2013 up to 2016, and the early Dynamics 365 versions, which all are using the Xrm.Page model.
For later Dynamics 365 versions, it seems that MS urges us to use the FormContext model,
as of Dynamics 365 v. 9, thereby (more or less) leaving the Xrm.Page model.
A form generally also displays database data (from tables/entities like "Account").
The data is displayed in fields on the form, and this data is generally called "Attributes".
"Controls" exists too, associated with "attributes", for example whether an attribute should be visible or not.
In such a case, the corresponding field on the form is visible or is not visible.
Generally, multiple controls may be associated with an attribute (data element/field).
Controls generally are forms, tabs, and fields on those forms/tabs. When it is about fields, then
it will contain data (attributes), where controls may affect how it is displayed.
Most js programming probably involves about event handling, that is, responses on actions
of the user on form data and elements.
Any form has three major events: OnLoad, OnSave, OnChange.
You "tie" a js library function to such an event.
If you want to do that, or create javascript, to "tie" that js to a form related to an entity,
you might want to navigate within the CRM userinterface, to the following path:
Settings → Customizations → Customize the System → select the Entity (like Contact) →
select the Form (like Main Form) → Select "Form Properties"
You can try that, with any entity. Ofcourse, not all will be associated with Jscripts.In my case, there are additional entities in CRM, for example associated with invoicing. So, when I navigate
using a path as shown above, I might see the following Form Properties:
Fig. 5: Example "Form Properties" in CRM 2011/2013/2015/2016/365:
I am working with a Dutch version of CRM 2016, so that's why you see dutch in the figure above.
But in your language, you should see a similar figure.
Note that in my case, the javascript "Invoice_main_library.js" is associated with this form.
Furthermore, all that Jscript code, is available when the Form loads.
Since JScript is OO, the object's methods and properties, have a "object_name.method_name()" or "class_name.method_name()"
way of calling them in your code. It's all about a hierarchical namespace, so statements go in
the form "Xrm.Page.class.method()" way of writing it down.
There are three main classes under Xrm.Page:
Xrm.Page.context
Xrm.Page.data
Xrm.Page.ui
Officially, those three are called namespaces. Below that, are "objects". We are not going to be
very formal in this text.
So, you might think that any call to a function (method) will always use such a path as a start.
But the "root", that is Xrm.Page, has callable methods as well, like e.g. "Xrm.Page.getAttribute()",
if the the context of the data already is obvious.
As it turns out, Xrm.Page.getAttribute() and Xrm.Page.getControl(), are indeed important means to access
data and controls.
-For example, If you want to access Data (an attribute), then you might formulate a statement like:
"Xrm.Page.data.entity.attributes.some method()" or for example "Xrm.Page.some method()".
-For example, If you want to a User interface element, then you might formulate a statement like:
"Xrm.Page.ui.controls.some method()" or "Xrm.Page.some method()".
However, there are more "paths" to Controls, and it takes a bit of experience to get along with them.
Since this is World's smallest tutorial, I will now show some (hopefully) representative examples.
But remember that JScript is a full language. You can go about and declare variables and arrays etc..,
much like the old style in doing things, and program the traditional way.
Here I only show some examples using the classes, objects, and methods in the Xrm.Page model.
(1). Connect to the "context": Xrm.Page.Context
"Context" should contain info on "where you are in CRM", or about your logged-on credentials,and much more other stuff. The following code should illustrate it:
if (Xrm.Page.context.getUserId() == "{3EF40CE1-3DE4-CA91-45E3-100BCD8149C4}")
{
alert(msg); //This is comment, using the two slashes. Msg is defined elsewhere.
}
The getUserId() function has determined that I am working, and that my ID is represented
by that long GUI string. So, if the code runs while I am working with the form, the "msg" is printed,
but not for other users when they are working with that form.
Also note that "=" (is, isequal), is represented by "==".
Note: the equaltity determination in Javascript, is a tiny bit complicated, like what exactly means
"==" or "===" etc.., but that is not relevant for this text at all.
(2). Connect to an "attribute" and connect to a "control":
There are multiple ways here.(2.1) Xrm.Page.getAttribute() and Xrm.Page.getControl().
Let's first see about Xrm.Page.getAttribute() and Xrm.Page.getControl().Those methods provides for getting a handle to data or control objects.
To indeed use it, you must provide the "logical name", or string, or qualifier,
which represents that attribute or control.
Take a look at this:
var lookupItem = new Array;
lookupItem = Xrm.Page.getAttribute("CustomerID").getValue();
Here you first declare a variable (var lookupItem), which is about to store real CustomerID's.
Those will be placed in an array (sort of row of values), called "lookupItem".
The whole point here is that you see how "Xrm.Page.getAttribute("CustomerID").getValue()" is used.
Ok, using "Xrm.Page.getAttribute("CustomerID")" will provide access to the CustomerID, but
using the method "getValue()" actually retrieves the data.
As another example:
var firstName=Xrm.Page.getAttribute("firstname").getValue();
The above also demonstrates the getValue() method.
The "setValue()" method ofcourse "sets" or assigns a value to an attribute, like some
field in a database table (an entity).
We need to illustrate that as well. Here is an example. Suppose the Order table
has the numberordered, price, and totalprice columns. Suppose the first two are known.
Then we can construct the "totalprice", like so:
var numberOrdered=Xrm.Page.getAttribute("numberordered").getValue();
var itemPrice=Xrm.Page.getAttribute("price").getValue();
var totalPrice= numberOrdered * itemPrice;
Xrm.Page.getAttribute("totalprice").setValue(totalPrice);
(2.2) Xrm.Page.data.entity
As an example of such a path, take a look at this:var InvoiceId = Xrm.Page.data.entity.getId();
Or as another example of using the "extended path":
if (Xrm.Page.data.entity.attributes.get("item").getValue() == "bike")
{
if (Xrm.Page.data.entity.attributes.get("price").getValue() == null)
{
Xrm.Page.data.entity.attributes.get("price").setValue(100);
Xrm.Page.data.entity.save();
}
}
Note: many folks say that Xrm.Page.getAttribute() is actually a "shortcut" for
Xrm.Page.data.entity.attributes.get().
The same is true for Xrm.Page.ui.controls.get() and it's shortcut version Xrm.Page.getControl().
3.7 A few words on iFrames, JQuery, Ajax, REST, oData and stuff.
1. What is an iFrame?:
An iframe is used to display, sort of, a web page within a web page. Like an advertisementwithin your page, or used as an "area" from another source.
-Within pure HTML, you may use the "iframe" tags to define the other source.
-With JScript, you might use code which resembles something like listed below.
However, I often have difficulties in using "specials" in JScript. But something like
sketched below, should provide a pointer in how to approach this.
if (Xrm.Page.ui.getFormType() != CRM_FORM_TYPE_CREATE) //note that != means "not equal".
{
//There is no creation, no new invoice, so we must be dealing with a known invoiceid.
Xrm.Page.getControl("IFRAME_ListingInvoices"). //continue the statement below.
setSrc('https://antapex.org/administration/overview_invoice.aspx?id=' + Xrm.Page.data.entity.getId());
}
Note that with an iFrame, you can have a sort of "independent" piece of information
(autonomous) on your main page. But it could also be a listing of articles, or invoices etc..
2. What is JQuery (within JScript for CRM)?:
It seems that Microsoft does not recommend using jQuery in form scripts and ribbon commands.But, for accessing/manipulation in HTML resources, it is fine.
The upper statement "seems" indeed true. This almost seems to suggest to abandon JQuery
with CRM Form programming. But it's very good to use it with HTML and such webresources.
So, it's OK with HTML webresources, but not with a Form and it associated JScripts.
Wait a bit, it's too soon for conclusions. Even with more recent versions of CRM,
form programming with JScript, and JQuery, and Ajax, may produces good results.
(We have to wait a bit, until more theory has been covered in the next sections.)
I do not want to put you on the wrong legs, but MS always says that with Jscript development
with "Forms", JQuery is not supported.
I have seen JQuery (associated with forms) to work in CRM 2011/2013, and 2015.
However, it almost "seems" (?) as if 2015 Update 1, had a large impact on the fact
whether JQuery was still usable in Form scripts.
Indeed, quite a bit of code, like DOM based, and JQuery, seems not to work anymore
as of CRM 2015 Update 1.
It's likely to do with the "new form rendering", as of 2015 Update 1.
But, there exists code in JScript, using JQuery, which "works" when doing Form programming,
so please do not consider this issue from a strickt black/white perspective.
Note: in CRM 2015/2016 you might always try "Legacy Form Rendering". See one of the appendices
for more information. Ofcourse "Legacy Form Rendering" is a step backwards, but if it helps
to get code running again, it might be worth it.
Whether we use it, or not, what is JQuery anyway?
- What is JQuery?:
JQuery is a javascript library. The whole idea behind it, is that for many tasks,
it already has code available (in that library), that acts as a "wrapper" for
more elaborate javascript code. So, you simply "call" the wrapper functions in your code,
to make life a bit easier.
The "Query" part in the name, may have put you on the wrong legs, by thinking that it was especially
for database access.
-A main objective for JQuery is that it might help to minimise efforts in selecting (query)
HTML/DOM/CSS elements and perform all sorts of "actions" on these elemenrs.
-Another main objective, is that you can use it for AJAX, asynchronous routines, that
update element(s) on your webbased form, without needing a full refresh.
You thus might say that JQuery is not a programming language, but rather a toolbox which makes JavaScript
easier to use for accessing all sorts of objects, since that code is already in the library.
But "to put JQuery to work", needs a special syntax, so, in that respect, it's looks like programming again.
Or, maybe better, in your code, you need to use the syntax for the JQuery API, before it can do useful work.
Thus is it actually programming? Yes, I think.
There are slight differences in the usage (syntax) when comparing the Web World (HTML/DOM/CSS), and JScript
for use in CRM.
- To register it for use in your Form JScript code:
- download the latest prod version (or recent version), like "jquery-3.1.1.min.js"
- Open your Solution or open the Default Solution, and upload the library, and publish it.
To use it:
- Go to form properties, en register it in the form, just like an ordinary Jscript.
- Now it's ready for use, in your JScripts, associated with that Form.
Before you publish anything, or a Solution, make sure you understand that process,
because e.g. the difference between "managed" and "unmanaged" solutions are important to understand.
- A JQuery example in JScript (or javascript, actually):
jQuery is called with the $(selector).action() syntax.
The "selector" identifies the object or class, and "action" is indeed the function or method
which we want to execute.
In HTML, or webresource, you might have the statement $("#test").hide() which makes the object
identified by "test", invisible. Note that if it is an object, you need the "#" symbol, to prefix the ID.
It is good use, to start the JQuery code by $(document).ready which makes sure (more so if we deal with HTML),
that the document is fully loaded, before JQuery starts. So, here we have an example:
$(document).ready(function ()
{
$('#TimeSheetButton').hide();
});
You can use such code, anywhere in your JScript. As long as you understand, it is not supported.
It's likely not to work anyway in JScript, but in 2015/2016 you can try "Legacy Form Rendering" (see appendices).
3. What is AJAX (within JScript using JQuery, for CRM)?:
The nice feature of AJAX is, that it allows for asynchrounsly retrieving data, and updating just parts of a web page,or a part of a Form. So, the page does not need to be fully refreshed.
AJAX is short for "Asynchronous JavaScript and XML".
It's a technique, that at it's core uses the raw XMLHttpRequest. You may call Ajax a protocol, or technique, or something,
but you need to use it within an environment like Javascript (Web, DOM), or JScript (Xrm.Page, CRM).
In most cases, the Ajax protocol runs in your Browser, and get's data from a Server. The exchange of data,
goes using the JSON or XML representation of data (the application data is "packaged", or formatted, according
to the JSON or XML standards).
As said before, you can use Ajax in Javascript, or Jscript, and many other platforms.
If you use JScript, then JQuery provides the library function. So indeed, it's a part of JQuery.
It's in effect (per default) an asynchronous HTTP (Ajax) request.
In it's most condensed form, it looks like:
$.ajax(url[, options]) //Call to Ajax routine from JQuery.
Where "url" specifies the Server application, and [,options] consists of a series of options like for example
the formatting of the data (like JSON, XML) etc..
- An example (partial) Ajax call from JScript (using JQuery):
$.ajax({
type: "GET",
async: false,
contentType: "application/json; charset=utf-8",
datatype: "json",
url: oDataSelect,
beforeSend: function (XMLHttpRequest)
...more options are needed here..., just mentioned a few basic ones...
Note that in this example, the async option is put to "false", so in this case we want a synchroneous request,
the formatting is "json", and the Server app is oDataSelect, which may seem as a strange url.
However, in this case, it is the designation of an endpoint to a webservice, like CRM's internal "OrganizationData.svc".
However, we know that JQuery is not supported in Form programming. Since Ajax is part of the library,
it seems to follow that Ajax is not supported too, in Form programming using JScript.
It's indeed somewhat confusing, considering the whole lot of options. But....:
However, the use of Ajax and the oData service endpoint, works. Is sounds strange maybe, but
it flows without errors, as I have seen in a few occasions in CRM 2015/2016/365.
A nice illustration of JQuery and Ajax, is the following article:
query dynamics 365 using Jquery+Ajax (carldesouza.com)
4. Some other noteworthy subjects, like REST, JSON, oData etc..:
SOAP:SOAP (Simple Object Access Protocol) is a protocol used to "envelope" XML data, which resulting format then can
be send to a destination, using a high-level protocol as "http".
It's indeed highly oriented on XML data, that is, the "envelope" with metadata, and the actual data,
is structured in XML.
SOAP nowadays is considered to be somewhat less usable compared to it's modern "rival", namely REST.
It's not only a protocol to envelope data. It indeed enables a high-level message exchange, and passing,
but it's also used at registering of services, and calling methods (functions) of webservices.
But also the last few parts of the above sentence, can be seen as part of "message exchange".
So, it's having a specific, strict, protocol and can be used for transferring messages (usually data,
but might also be a payload as a Remote procedure call.
Below you can find a simplyfied example of a data message:
<env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
(some header stuff... Optional, might contain header blocks for intermediate nodes.)
</env:Header>
<env:Body>
<p:itinerary xmlns:p="http://antapex.org/reservations">
<p:article>Racing Bike</p:article>
<p:numberof>5</p:numberof>
<p:totalprice>5000</p:totalprice>
</p:itinerary>
</env:Body>
</env:Envelope>
While the text above, said something about the "format", (web)services also expose a SOAP API
with a structured methodology, which client apps must use.
REST:
Here too, we may speak of the REST API, that is, how clients and server services
are suppose to connect, and exchange messages.
Ofcourse, just as with SOAP, we have rules on how formatting of data takes place.
REST is an architecture that "de facto" is associated with webservices (like SOAP is too).
Then we might as well say, that it is also often tied to HTTP, and in that case GET and POST
(and other) methods are in use.
So, HTTP is the most often transfer protocol.
REST is thus about accessing webservices, and as a part of that, exchange of messages.
Those message formats can be various, like an XML format, but absolutely most often in the JSON format.
Since JSON format is so common, we will see about that in the next section.
As with SOAP, and REST too, clients and Servers only need to adhere to the protocol (follow
the corresponding rules), and the exchange of data is Universal, that is, the same everywhere.
In weblanguage, it is also often said that the client uses the REST webservice's "endpoint".
In a REST request, one identifier is the URI. Both URL and URI, are often heard terms.
URI - Uniform Resource Identifier (URI) to identify the true resource on a server.
URL - Uniform Resource Locator (URL) to identify the "location".
The two are really quite close, but there is a difference. The URI should identify
the service by it's name, or path, or possibly via "query" (or anything else that identifies the Instance).
However, the terms are often used interchanginly.
For example, one of the CRM URI's (for 2011/2013/2015/2016) could be:
https://antapex.org/ICTSolutions/XRMServices/2011/Organization.svc
CRM uses the "RESTful" API, using HTTP methods, and JSON format for messages requests/returns.
If you would need to "build the whole REST stuff", then you would be involved in:
define request and response headers, status codes, HTTP methods, URL conventions, media types, payload formats,
how to address such media types, all posible formats, checks etc..., query options, etc.. etc..
That's why a builder, or tool, can be put to use, which greatly simplyfies your code.
For CRM, "oData" is heavily used. In such case, you only need to locate the service (URI),
and specify a number of options (what you want to get done) in your JScript code.
JSON:
JSON is short for JavaScript Object Notation.
It's a format for data, exchanged between clients and webservices.
It can be viewed as an alternative for XML formatting.
For example, the REST Api uses JSON messages.
Ofcourse, the envelope and inner structure should be created according to the JSON specs.
The main structure, looks like a "stack" of "key:value" pairs (or also often typed as
"attribute:value" pairs), just like any "record" would show you.
Such a "stack" of pairs, sits between "{" and "}" symbols. If an array is an element too,
then it's values are between square brackets "[" and "]".
Not only data might be the constituents, but function calls are possible too, making
such message a JSON-RPC (remote procedure call) message.Mbr>
Just for illustrational purposes, a simple example is shown below:
{
"$schema": "http://json-schema.org/schema#",
"name": "Carla",
"city": "Amsterdam",
"sports": ["skating", "karate", "rugby"]
}
Attaching to a WebService like CRM:
4. Some other stuff in CRM.
4.1 Integrating CRM with email.
Instead of a bunch of local email stores, calendars, appointments etc.., the important business infoshould be centrally stored, and be accessable by users, as it should be in real collaboration.
This is a very important feature of CRM.
CRM itself does not have the capabilities of a true email Server. That's why additional components are required.
However, it gives the impression that it does have the functions of an email Server:
-From the webinterface, there are options where you can send mail.
-An customized PlugIn, which is serverside code, may send mail.
-A Workflow, Campaigns, may result in sending mail.
etc..
However, a component "in the middle" with email Forwarding capabilities (to the mail Server) is required.
But, indeed, in the most simple setup, the CRM Outlook clients itself can act as the component that takes care
of all the inbound and outbound emails for CRM. But this scenario has drawbacks.
For example, for emails and appointments etc.., the client has controls to enable "Track in CRM".
There are in fact 3 options which make mail possible:
(1). Using Outlook, with the additional "CRM for Outlook" (Outlook client) software.
(2). The traditional "email Router" component which sits between CRM and the email Server (like Exchange).
(3). Using "Server Side Sync" (SSS) available as of CRM 2013, but more common as of CRM 2015.
(2) and (3) have a central server component, handling email to, and from, CRM.
Note that this also equates to the statement that (2) and (3) enables CRM to communicate
to the ouside world, and not being dependend on Outlook clients.
⇒ SSS:
As of CRM 2015, Server-Side sync (SSS) is a server-side process, in the CRM instance, for synchronizing appointments,
contacts, tasks (ACTs), and email messages between Exchange Server and Microsoft Dynamics CRM Server.
SSS is a module in the Asynchronous Processing Service, and runs on the same Server as the other modules
of CRM does.
⇒ Outlook + CRM for Outlook:
Traditionally, SSS, or also the "email Router", can be omitted. This time, the Outlook clients configured
with a CRM add on (CRM for Outlook), will be the middle component for messages between CRM and Exchange.
⇒ The traditional "email Router":
This module sits between CRM and Exchange (or other pop3/SMTP mail server).
It's a seperate component, which must be downloaded (or run from the Web), and installed on
any suitable machine in your domain, or on the CRM Server itself.
The "email router" will be installed as a windows service, and a GUI will also be installed.
Microsoft claims that this module is depreciated as of the December 2016 update for Dynamics 365.
From the download, run the SetupEmailRouter.exe file ( from ..\EmailRouter\amd64 for 64-bit or ..\EmailRouter\i386 for 32-bit),
under administrative privileges.
Setup will install the CRM Email Router Service. It also installs the Email Router Configuration Manager.
Using this Configuration Manager, you need to create an Incoming- and Outgoing email profile at this router.
This also must specify the location of the Echange Server and how to access the mailboxes.
Impression of configuring the "Email Router" or "SSS" or CRM:
Let's study a few nice articles/blogs:
Config Email Router or SSS:
Configure email router with Exchange Online (1)
Configure email router with Exchange Online (2)
CRM:
If you use the email Router, or SSS, also in CRM itself you must configure that.
Using "Settings->Email configuration->Email Server Profiles" and click "New".
This gives you the option to create an Email Server profile.
Then, you can configure each mailbox with information like:
-Server Profile: Select the server profile which you just created.
-Incoming Email: Set this option to "CRM for Outlook" or "Microsoft Dynamics 365 for Outlook".
-Outgoing Email: Set this option to Server Side Synchronization or Email Router.
-Appointments, Contacts and Tasks: "CRM for Outlook" or "Microsoft Dynamics 365 for Outlook".
4.2 CRM and the Report Server SSRS.
You need to have the "SQL Server Report Server" (SSRS) around, if you want to use CRM (on premises).Usually, SSRS is installed on the same machine where SQL Server itself is installed.
I cleary say "usually", since SSRS can be installed on any suitable Server. Ofcourse SSRS needs
access to it's own report databases on some SQL Server instance.
CRM is a rather large application, and this note, simply just scratches a few, from a large number of topics.
But SSRS is interesting, and it's "not so very trivial" to troubleshoot if errors occurs.
(1). Microsoft Dynamics CRM Reporting Extensions:
During the setup of CRM (like CRM 2016) you also need to install the "Microsoft Dynamics CRM Reporting Extensions"
on the Server which runs the SQL Server Reporting Services.
Again, it is essential to know that this needs to be installed on the server where the SSRS is installed.
It is mainly used at authenticating CRM to SSRS, so that "delegation" and that sort of stuff, can be avoided.
It's effectively a data processing extension which attaches itself to the SSRS server and accepts
the authentications from the CRM server and passes it to the SSRS server.
In former CRM versions, there were authentication problem when trying to access and run reports
due to Kerberos or other authentication issues.
(2). SRS Data Connector:
This is effectively the same as (1). That is, formerly, folks called it the "SSRS Data Connector",
but in later CRM versions it is called "Microsoft Dynamics CRM Reporting Extensions".
So, it's basically the same sort of thing.
(3). Setting the SQL Server Report Server URL in CRM:
There might be multiple ways to do that, but the following one works too. It uses the "Deployment Manager".
If you want to use it, you must go to the CRM Application Server itself (thus where CRM runs on),
and browse for the executable file. It's probably in a location similar to:
C:\Program Files\Microsoft Dynamics CRM\tools\Microsoft.Crm.DeploymentManager
Select your Organization database (there could be more than one), and check the "properties".
Note that there exists an option to change the URL.
The URL should be of the form: "http://computername/reportserver".
This concludes my simple note on CRM.
I must say that I started to like the MS CRM system. I had some previous exposure to other CRM systems,
but MS CRM is generally quite OK. However, it's also a bit freaky here and there, and I am sure that
folks who manage it at a system level, will agree that there are quite a few odd things in that system.
That even holds for CRM 2016, or Dynamics 365.
But, I have to say: it really works...
Appendices:
Sometimes, items will be added in this Appendix.1. Error reporting dialog box in CRM 2016.
Especially in CRM 2016, you cannot disable the "error reporting" DialogBox in a intuitive manner,using the interface. Here I mean the following dreaded dialog box:
Fig. 6: General Error Dialog box which may pop up all the time:
In former versions, like CRM 2015 and lower, you could disable it on a Global level,
thus for all users.
The point is that this dialogbox may show at non critical issues, for example with a functional Java script,
but where the methods are not in line with the Microsoft XRM model.
Although repairing the source of the error is the best practice, but since CRM still works OK, you might
consider disabling the error reporting on a global level (for all users).
For jscript and form related errors: see appendix 5.
If the errors bother you users to a level where they are seriously hindered in their work, you may
try the following methods:
1. Xrmtoolbox.
From "https://www.xrmtoolbox.com/" you can download the Xrmtoolbox, which provides you many
easy configuration tasks for CRM.
It also includes disabling the error dialogs on a system level.
Xrmtoolbox provides many options, and its best to try it and see it's capabilities in a Test environment.
2. Calling the hidden preferences/configuration page in CRM 2016.
From the site:
https://community.dynamics.com/crm/b/magnetismsolutionscrmblog/archive/2017/11/14/how-to-globally-define-error-reporting-preferences-in-microsoft-dynamics-crm-2016
You will find an alternative for the Xrmtoolbox, and some further explanation.
In essence, Paste the following in your CRM webinterface:
javascript:var frame = document.getElementById("InlineDialog_Iframe");
if (frame == null) { alert("Click Privacy Preferences before executing this code."); } else
{ frame.contentWindow.document.getElementById("privacy").style.display = ""; }void(0);
Credits for this method must go to user "Magnetism", on "community.dynamics.com".
This will then show you the preferences Page, as it used to show in CRM 2015 / CRM 2013.
2. CRM 2013/2015/2016/365 error codes.
CRM 2013:https://docs.microsoft.com/en-us/previous-versions/dynamicscrm-2013/developers-guide/gg328182(v=crm.6)
CRM 2015/2016:
https://docs.microsoft.com/nl-nl/previous-versions/dynamicscrm-2016/developers-guide/gg328182(v=crm.8)
CRM 365:
https://docs.microsoft.com/en-us/dynamics365/customer-engagement/developer/org-service/web-service-error-codes
An error which may appear in a Dialog box, or logfile, may have to be converted to Hex first, before you can
look it up in the above links.
If you have a certain code, then paste in into calculator, and let it be represented in Hex.
Then, if needed, ignore all F's which might be present in front of the code, and then you will have codes
as listed in the links above.
3. Listing of CRM build numbers and service packs, rollups's etc...
The following site, presents a good overview on CRM builds, service packs etc..CRM builds, service packs etc.. (buildnumbers.wordpress.com/crm/)
4. Some links describing errors and how to resolve them.
Nice link 1: from "dynamicsessentials.net"Nice link 2: from "cloudfronts.com"
5. Under CRM 2015 or 2016: use "Legacy form rendering" again, instead of turbo forms.
In CRM 2015 and later, the rendering of "forms" has been changed, compared to CRM 2013 / 2011.It could happen that you have customized the CRM 2013 / 2011 system in a large extend, including event handlers
using javascript, using objects and methods which are (partly) not supported anymore in CRM 2015 and later.
It might be to such an extend, that you users are severly hindered in their work.
The errors shown are often javascript errors (like on load events), form error messages etc..
The following is not a solution, but might be seen as a temporary fix. Under CRM 2015 or 2016, and later,
it's possible to revert to the older (or legacy) rendering of CRM 2013 / 2011.
Ofcourse, you should always invest time to adjust your customized forms and scripts, to make them compliant again.
However, you might try the "fix" to see if it helps you.
From the CRM webinterface in CRM 2015/2016/365, use the menu system:
Settings -> Administration -> System settings.
Fig. 7: Setup Legacy Form Rendering (the 2013/2011 model) in CRM 2015/2016:
6. Rami's CRM 2013 API cheatsheet:
It's really nice work, the following pdf's, which summarizes the Xrm.Page namespaces, objects,and methods.
Please see the docs by Rami Mounla:
Rami Mounla's summary of the CRM 2013 API
7. A few pointers for Replacing Javascript DOM objects/methods
to MS JScript XRM/Page objects/methods or D365 ExecutionContext methods.
First, use a capital letter where required in any object-, or method-, or property name.That is for example, do not use "getelementbyid()", but instead use "getElementByID()".
Maybe it sounds silly, but it helps.
Following is a short list of incompatible DOM statements (or objects/methods) which
will not work anymore as of CRM2015 Update 1.
Maybe the suggestions in the right column of the table, can be helpful.
| DOM | XRM or D365 ExecutionContext |
| document.getElementById() | parent.document.getElementById() or window.parent.document.getElementById() Remark: this is still DOM, and only "more qualified", or a call to the "parent" object (which might help). However, it's likely not going to work for versions above CRM 2015 Update 1. See the paragraph "more on document.getElementById()" below. Microsoft Dynamics has "disabled" this for > 2015 Update 1, meaning document.getElementById (and implmentations of it in jQuery) does not provide access to the "DOM element" in Forms (but in Web/HTML: yes). Use implementations of: Xrm.Page.getControl().appropriate_method() Xrm.Page.getAttribute().appropriate_method() |
| context.getServerUrl | Xrm.Page.context.getClientUrl() |
| disableViewPicker | Xrm.Page.ui.controls.get("").setDisabled(true) |
| crmForm.FormType() | Xrm.Page.ui.getFormType() |
| control.attachEvent("onclick" , CallFunction ) | formContext.getAttribute(arg).addOnChange(myFunction) |
| padding | no simple equivalent statement: fully rewrite (I think) |
| field.style.fontStyle | no simple equivalent statement: Amazingly, sometimes this produces an error in XRM.Page |
| if(Xrm.Page.getAttribute("parentaccountid").getValue() != null) | if(formContext.getAttribute("parentaccountid").getValue() != null) for D365 later versions |
More on the Javascript method (window.parent.document.)getElementById().
This one in particular, can be very nasty in Upgrades from CRM 2011/2013 to CRM 2015/2016/365.What exactly is it in Javascript? It provides a "handle" to the object referred to
in this function.
Let's study it in some detail:
How it is used in HTML DOM:
At www.w3schools.com, you can find an example like shown in the figure below.Go to www.w3schools.com (https://www.w3schools.com/jsref/tryit.asp?filename=tryjsref_document_getelementbyid2):
Go to that place, and try the button and see what happens. An explanation is given below.
Fig. 8: HTML code plus the javascript method getElementById() :
In the code above, you see that the paragraph (between the "p" and "/p" tags), is assigned
the ID (or name) "demo", in that HTML document.
From that moment on, in the DOM model, we can refer to that object with it's ID, namely "demo".
Between the script and "/script" tags, we see the javascript code. As usual, it's a function.
You can see that a variable "var x" is assigned with "document.getElementById("demo")", and that's
exactly equal to the string in that paragraph: "Click the button to change the color of this paragraph.".
The button control, when clicked, will call the function, and as a result the text will turn red,
since the statement "x.style.color = "red"" will see to it, that the property "x.style.color = "black"
will change into the property "red".
As another illustration: you could also avoid the button, and simply used the statement "document.write(x);",
which would print the string on your screen.
This is a very simple, and adequate example of how getElementById("TheID_of_the_object"),
is applied in HTML DOM.
It's very useful, but it's a DOM method, and not Xrm.Page. It never was Xrm.Page.
That it still worked in CRM 2013, is that MS not entirely killed it, in 2013 and earlier versions,
and kept javascript code compatible in JScript. But in my
How it is used in JScript (earlier versions and 2011/2013):
Here are a few typical examples (I think):// 1. Get through a listing by using "getElementsByTagName("SomeInput")";
var all = document.getElementsByTagName("SomeInput");
var Element;
for (var i = 0; i < all.length; i++)
{
Element = all[i]; //other statements
}
// 2. Get the handle to the object (field) identified by "to".
parent.document.getElementById("to").setAttribute("defaulttype", "2");
It seems that the code in (2) can be replaced by "Xrm.Page.getControl("to")".
// 3. Get a handle to "customerid"
parent.document.getElementById('customerid').title = 'This field is Inactive.'
// 4. Get a value.
var discountpercentage = parent.document.getElementById('discountpercentage');
msgNotation = parent.document.getElementById('new_name').title;
It seems that the code in (4) can be replaced by "Xrm.Page.getAttribute("discountamount").getValue()".
Well, at least, we now have a reasonably good idea on what "getElementId()" is about.
8. How to enable Tracing in CRM 2013/2015/2016/365 On Premises.
1. Basic Tracing: App Server componentsOn the CRM App Server:
1. Create or reserve a suitable trace location (directory), like "C:\CRMtrace" or "F:\CRMtrace".
2. Start "regedit".
3. Navigate to:
HKLM\Software\Microsoft\MSCRM
-Add Key: TraceEnabled DWORD value:1
-Add Key: TraceDirectory STRING value: C:\CRMTrace (or what you selected in step 1.).
This type of tracing focusess on CRM services and webservices, and not as much on custom code.
Tracing will slightly impact performance, and over time, consume diskspace, unless you clear out older logs.
In certain cases, the above "seems" to be ignored. It can be worth while, if needed,
to take a look in "Drive:\Program Files\Microsoft Dynamics CRM\Trace", if there a recent trace file
would be present. Ofcourse "Drive" is the partition where you have installed CRM, like "C:" or "D:" etc..
2. A way to trace PlugIns from within CRM:
The PlugIn Trace facility as of 2015 Update 1, and later:
Please see:
1. Article at powerobjects.com (2016)
2. Article at magnetismsolutions.com (2015))
3. Basic Tracing: Audit table in SQL Server.
Per default, a level of auditing is applied into a SQL Server table.
In the "Organization_MSCRM" database, we have the table "AuditBase" which might
give some additional information. However, it is focussed on "auditing".
4. General code tracing, debugging:
Preferably, you should perform any development using Visual Studio. It's a bit trivial to say ofcourse,
but VS gives you pointers for tracing/debugging.
5. JScript debugging:
One way to debug JScripts, is placing the "debugger;" statement within your JScript code.
As from that point, debugging begins.
Since CRM is webbased, and Javascripts are download to your workstation, the debugging info
can be traced from your browser, often activated by the F12 key.
So, in your JScript, you would change it like in this example:
function abc()
{
//statements
debugger;
//statements
}