What are CRM CLR Stored Procedures?
CLR stored procedures are stored procedures that use the .Net framework. See
here
for details.
CRM CLR stored procedures call the Microsoft Dynamics CRM web service API to
manipulate data.
The stored procedures ship with a Management application that installs and
configures the application using a simple to use wizard.
Stored procedures can be generated tailored to specific attribues and specific
entities using the management application.
How does it work?
The CRM CLR stored procedures are deployed to a seperate database to the CRM application.
Typically the database is a staging database where data is landed before processing
into CRM.
The stored procedures call the CRM web services to process the data
What can I do with CRM CLR Stored Procedures?
- Create
- Read
- Update
- Delete
- FetchXML
- Set State (not implement in Beta)
- Change Owner (not implement in Beta)
- Create Relationship (not implement in Beta)
- Delete Relationship (not implement in Beta)
- and many more procedures coming soon ...
What are the system requirements for running CRM CLR Stored Procedures?
.Net Framework 2.0
A seperate SQL Server 2005 database
Microsoft Dynamics 4.0 Installation with valid licenses.
Does it support multiple languages?
Currently, the CRM CLR stored procedures use the language of the executing user.
We plan to change this in future.
Will it work with Dynamics CRM On-line?
No.
If we are inserting many records will it slow down the CRM Application?
Yes, any data import application will use the CRM web service to import
data. If this is an issue, then we recommend using a seperate CRM web
server to import the data
Why is it slow when I run it first time?
The CRM CLR Stored Procedures fetch the entity meta data and store it to
cache so that future requests are much quicker
What happens when I re-publish an entity?
The metadata cache is retrieved again. Any stored procedures generated
for specific entities may need to be regenerated also.
Are the stored procedures generic or entity specific?
There are several 'base' CRM CLR Stored Procedures that are generic across
all entities. Specific stored procedures can be generated from the
Management application
Can I update custom entities?
Yes.
Can I deploy on our development and test servers?
Yes, simply request another license here
How many licenses do I need?
During the application license verification process the application
checks the number of licenses equals or exceeds the number of CRM licensed users
How do I deploy CRM CLR Stored Procedures?
The CRM CLR Stored Procedures are deployed through the Management application
profile wizard
How do I create entity specific stored procedures?
The management application contains a wizard that will collect the
information in order to generate the stored procedures for the entity.
Why can't I update the state?
State updates and inserts are handled differently in CRM and should be updated
by using the SetState stored procedure
Why can't I update the owner?
Owner updates are handled differently in CRM and should be updated by
using the AssignOwner stored procedure
How do I create a relationship between entities?
Many-to-many relationships should be created using the CreateRelationship
stored procedure
What are the security implications of using CRM CLR Stored Procedures
The CRM CLR stored procedures MUST run in a different database to the CRM
server database - this is typically a data staging database. The CLR
stored procedures deploy tables, functions and stored procedures (CLR and non CLR) in
this staging database.
The SQL server instance must be configured to
enable
CLR IntegrationsDatabase connection strings are encrypted.
The CLR Stored procedures run under the credentials of the SQL Server Service
account or the credentials specified by the user (which must exist as a CRM
user)
The CLR stored procedures require external access to call the CRM web
service that you configure. The installation deploys the assemblies
using an asymmetric key and a specific security principal as directed by
Microsoft.
We can categorically state the CLR Stored Procedures do
NOT:
- call any other web services or access any other web sites, other than the CRM
web services
- access the file system
- access the registry
- access any other SQL database other than the SQL database specified
- perform any 'unsafe' or insecure actions that should cause you concern.