I wanted to share some
information about how you can set up an efficient development environment for
your CRM project. Managing the solution synchronization among multiple
environments (Dev, Test, Prod, etc.) is not always straight forward and it
depends on multiple factors such as the scope of your project and the size of
your team.
What software and operating systems will Microsoft
Dynamics CRM 2013 support?
- Microsoft Exchange Server 2013
- Microsoft Outlook 2013
- Active Directory Federation Services (AD FS) 2.2
(ships with Windows Server 2012 R2)
What software and operating systems will Microsoft
Dynamics CRM 2013 no longer support?
- The Microsoft Dynamics CRM for Outlook or the web
application on Windows XP
- Microsoft Office 2003
- E-mail router will no longer support:
- Microsoft Exchange Server 2003
- Microsoft Exchange Server 2007 WebDAV protocol for
email routing and tracking (Microsoft Exchange Server 2007 Exchange Web
Services (EWS) will still be supported)
If you have
a multi-tenant CRM server you could host one or more of these environments in
the same box.
Setting
up CRM Environment: below set up applicable to large projects
Development machines (CRM DEV)
The development machines can be a developer’s laptop or work station with CRM development tools + a dedicated CRM organization for the developer (CRM Online or on premise). It can also be a full server (or VM) with CRM installed and dedicated to a single developer. These organizations are setup with a master configuration solution (more on this later) and smaller transport solutions to bring required components for development.
Developers use the various development tools to write code and to debug (attach to CRM services, attach to IIS, using Profiler, browsers debugging tools or using tracing).
When development items are completed, developers build temporary “transport solutions” containing the components they worked on and they push them to the Master Configuration organization. Developers must be careful and not make schema changes on their own development organizations. As the code is deployed to the master configuration, it should also be archived in the source control.
Master Configuration CRM Organization
There is only one Master Configuration environment. It contains the schema configuration and all schema changes should be made there. There is usually one or multiple “Master” solutions sitting in this organization based on how you decide to structure your deployments. You may want to have multiple solutions for various types of customizations (e.g. one for schema, one for plugins, one for web resources etc.), or based on functionality grouping.
When developers set up their organizations, they can pull the entire master solutions from the master configuration organization as unmanaged and install them in their development. They can also create temporary “transport solutions” to pull only the customizations they need.
A process (manual or automated) should be put in place to archive the master solutions on a regular basis (daily is recommended). Archiving could be saving the CRM solution files in source control, or even creating snapshots of the server and keep them around for a reasonable period of time.
Integration / Test CRM Organization
This organization receives the master solutions and is used to perform tests. It can be combined with the master configuration environment. The choice to go with a managed or unmanaged solution when going from master configuration to integration/UAT/Prod environment is a business and technical decision.
UAT / PRE PROD / PROD
These environments receive the master solution(s) after they have been tested and validated on the Integration/Test CRM organization.
Architecture and related
components for asynchronous and synchronous event
The following figure illustrates the overall architecture of the Microsoft Dynamics CRM platform with respect to both synchronous and asynchronous event processing.
While there are several Web services hosted by the Microsoft Dynamics CRM platform, only events triggered by the organization and OData endpoints can cause plug-ins to execute.
The event execution pipeline processes events either synchronously or asynchronously. The platform core operation and any plug-ins registered for synchronous execution are executed immediately. Synchronous plug-ins that is registered for the event is executed in a well-defined order. Plug-ins registered for asynchronous execution are queued by the Asynchronous Queue Agent and executed at a later time by the asynchronous service.
Event execution pipeline
The Microsoft Dynamics CRM event processing subsystem executes plug-ins based on a message pipeline execution model. A user action in the Microsoft Dynamics CRM Web application or an SDK method call by a plug-in or other application results in a message being sent to the organization Web service. The message contains business entity information and core operation information. The message is passed through the event execution pipeline where it can be read or modified by the platform core operation and any registered plug-ins.
Important
|
Regardless of whether a plug-in executes synchronously or
asynchronously, there’s a two-minute time limit imposed on the execution of a
(message) request. If the execution of your plug-in logic exceeds the time
limit, a System.TimeoutException is thrown. If a
plug-in needs more processing time than two minutes, consider using a workflow
or other background process to accomplish the intended task. This two-minute
time limit applies only to plug-ins registered to execute under partial
trust, also known as the sandbox.
|
Pipeline stages
The event pipeline is divided into multiple
stages, of which 4 are available to register custom developed or 3rd party
plug-ins. Multiple plug-ins that are registered in each stage can be further be
ordered (ranked) within that stage during plug-in registration.
Event
|
Stage name
|
Stage number
|
Description
|
||
Pre-Event
|
Pre-validation
|
10
|
Stage in the pipeline for plug-ins that are to execute before
the main system operation. Plug-ins registered in this stage may execute
outside the database transaction.
|
||
Pre-Event
|
Pre-operation
|
20
|
Stage in the pipeline for plug-ins that are to execute before
the main system operation. Plug-ins registered in this stage are executed
within the database transaction.
|
||
Platform Core Operation
|
MainOperation
|
30
|
In-transaction main operation of the system, such as create,
update, delete, and so on. No custom plug-ins can be registered in this
stage. For internal use only.
|
||
Post-Event
|
Post-operation
|
40
|
Stage in the pipeline for plug-ins which are to execute after
the main operation. Plug-ins registered in this stage are executed within the
database transaction.
|
Message processing
Whenever application code or a workflow
invokes a Microsoft Dynamics CRM Web service method, a state change in the
system occurs that raises an event. The information passed as a parameter to
the Web service method is internally packaged up into an OrganizationRequest message and processed by the pipeline. The
information in the OrganizationRequest
message is passed to the first plug-in registered for that event where it can
be read or modified before being passed to the next registered plug-in for that
event and so on. Plug-ins receives the message information in the form of
context that is passed to their Execute method. The message is also passed
to the platform core operation.
Plug-in registration
Plug-ins can be registered to execute before
or after the core platform operation. Pre-event registered plug-ins receives
the OrganizationRequest
message first and can modify the message information before the message is
passed to the core operation. After the core platform operation has completed,
the message is then known as the OrganizationResponse.
The response is passed to the registered post-event plug-ins. Post-event
plug-ins have the opportunity to modify the message before a copy of the
response is passed to any registered asynchronous plug-ins. Finally, the
response is returned to the application or workflow that invoked the original
Web service method call.
Because a single Microsoft Dynamics CRM
server can host more than one organization, the execution pipeline is
organization specific. There is a virtual pipeline for every organization.
Plug-ins registered with the pipeline can only process business data for a
single organization. A plug-in that is designed to work with multiple
organizations must be registered with each organization's execution pipeline.
Inclusion in database transactions
Plug-ins may or may not execute within the
database transaction of the Microsoft Dynamics CRM platform. Whether a plug-in
is part of the transaction is dependent on how the message request is processed
by the pipeline. You can check if the plug-in is executing in-transaction by
reading the IsInTransaction
property inherited by IPluginExecutionContext
that is passed to the plug-in. If a plug-in is executing in the database
transaction and allows an exception to be passed back to the platform, the
entire transaction will be rolled back. Stages 20 and 40 are guaranteed to be
part of the database transaction while stage 10 may be part of the transaction.
Any registered plug-in that executes during
the database transaction and that passes an exception back to the platform
cancels the core operation. This results in a rollback of the core operation.
In addition, any pre-event or post event registered plug-ins that have not yet
executed and any workflow that is triggered by the same event that the plug-in
was registered for will not execute.
No comments:
Post a Comment