Why Wrap/Bridge/Tunnel CRM web services?
The layer called Wrap/Bridge/Tunnel and web service layer that I always built and I’m advising do to so to be used for CRM contains a proxy to help the development with some methods pre-create like get guids for certain accounts, validation on security rules, how the account should be inserted, what type of validation should be using, integration, in resume all the Business Logic will be built on this layer.
The reason for this?
1. We can separate what is black and white in terms of solutions and to know what will call what.
2. We can block any attempted to crush the CRM, because any call will use this layer will be stopped before reach the CRM and this will not allow to permit bad data to be written to the system. For this reason, it would be bad to expose it to untrusted clients/apps/services.
3. We can put application-level security over the services layer
4. We can get re-use of the business rule validations in the middle-tier.
Exposing a simple API for CRUD operations can also be achieved by directly connecting to the other database server (except CRM), so a web service layer over the top of this we can tunnel it through most firewalls.
While we could in theory expose CRUD operations through the CRM web service, there are some fairly good reasons not to do this and relatively little benefit to doing so.
When we develop an application that uses the Microsoft Dynamics CRM server, we use Web services to communicate with the underlying xRM platform layer. Microsoft Dynamics CRM uses a metadata driven architecture to provide the flexibility to create custom entities and additional system entity attributes and also to make upgrades and enable transportation of solutions easier. This allows for changes in the data structure without requiring any change to code in Microsoft Dynamics CRM.
The xRM platform does not impose business-specific logic. This layer imposes only generic constraints such as security. It contains the building blocks for an application, but by itself is nothing more than a collection of related objects. However, the interaction between those objects is used to implement more extensible logic such as the quote-to-order-to-invoice processing and pricing logic.
The xRM platform also controls access to data through security, controls access to the database, and raises events for workflow processes and custom business logic implementations (plug-ins). The platform layer provides for both incoming and outgoing email processing through Microsoft Exchange Server.
The reason for this?
1. We can separate what is black and white in terms of solutions and to know what will call what.
2. We can block any attempted to crush the CRM, because any call will use this layer will be stopped before reach the CRM and this will not allow to permit bad data to be written to the system. For this reason, it would be bad to expose it to untrusted clients/apps/services.
3. We can put application-level security over the services layer
4. We can get re-use of the business rule validations in the middle-tier.
Exposing a simple API for CRUD operations can also be achieved by directly connecting to the other database server (except CRM), so a web service layer over the top of this we can tunnel it through most firewalls.
While we could in theory expose CRUD operations through the CRM web service, there are some fairly good reasons not to do this and relatively little benefit to doing so.
When we develop an application that uses the Microsoft Dynamics CRM server, we use Web services to communicate with the underlying xRM platform layer. Microsoft Dynamics CRM uses a metadata driven architecture to provide the flexibility to create custom entities and additional system entity attributes and also to make upgrades and enable transportation of solutions easier. This allows for changes in the data structure without requiring any change to code in Microsoft Dynamics CRM.
The xRM platform does not impose business-specific logic. This layer imposes only generic constraints such as security. It contains the building blocks for an application, but by itself is nothing more than a collection of related objects. However, the interaction between those objects is used to implement more extensible logic such as the quote-to-order-to-invoice processing and pricing logic.
The xRM platform also controls access to data through security, controls access to the database, and raises events for workflow processes and custom business logic implementations (plug-ins). The platform layer provides for both incoming and outgoing email processing through Microsoft Exchange Server.
Comments
Post a Comment