The message pipeline concept is implemented in the CRM platform as an event pipeline. The event pipeline performs sequential (synchronous) processing of a message and returns the result (called a response) to the platform. The term sequential processing is used because there are several points in the pipeline where business logic is executed as shown in the following diagram.
In the pipeline is the core platform operation. This is where the actual entity information processing (such as create, update, or delete) takes place. Immediately before and after the core platform operation are registration points where plug-ins containing custom code can be registered to execute. A plug-in that is registered for a pre-event, meaning before the core operation event, has the ability to modify the context (entity data) passed to the plug-in’s Execute method before passing the context on to the core operation. A pre-event plug-in can also prevent (cancel) the core operation. A plug-in that is registered for a post-event, meaning after the core operation event, has the ability to alter the context returned from the core operation and the response returned from the platform to the Web service caller. A plug-in registered asynchronously is a post-event plug-in that it is queued to be executed by the Asynchronous Service at a later time.
The event pipeline architecture provides the capability for a pipeline to initiate the execution of one or more subordinate pipelines in order to process an SDK request. The originating pipeline is known as the parent while each subordinate pipeline is called the child. Web service method calls, such as Execute, start a parent pipeline while internal platform calls start a child pipeline.
Let us look at an example of how this parent/child pipeline design works. For example, a parent pipeline that processes a CompoundUpdateRequest to update a salesorderdetail quantity would invoke a child pipeline to update the salesorderdetail and another child pipeline to update the associated salesorder total. However, even a simple request, such as CreateRequest for an account, can result in a child pipeline being executed.
When a complex request is processed by a pipeline, the pipeline first executes any registered pre-event plug-ins and the core platform operation. Next, the pipeline starts a child pipeline and temporarily suspends processing until the child pipeline has finished processing its request. After the child pipeline has completed, the parent pipeline can complete its post-event processing.
- Pipeline A : pre-events are processed.
- Pipeline A : core platform operation, child pipeline B executed.
- Pipeline B executes
- Pipeline B : pre-events are processed.
- Pipeline B : core platform operation.
- Pipeline B : post-events are processed.
- Pipeline A : post-events are processed.
As a plug-in developer, the significance of this parent/child pipeline design is that you must decide which pipeline your plug-in is to be registered with in order to accomplish the plug-in’s intended functionality. The parent pipeline processes the Web service message request. Child pipelines only process Create, Update, or Delete messages as required by the platform to process the parent pipeline’s message. To determine which message is being processed by a child pipeline, you must enable tracing in Microsoft Dynamics CRM. Information about how to enable tracing can be found in the Microsoft Dynamics CRM 4.0 Implementation Guide.
