0
votes

How should data be pushed into CRM 2011 from another system?
I would like to pass the data to a web service.

I have thought of 2 options so far:

  • Create a custom entity and create records of this entity by calling the Organization service from the other system. A workflow can handle everything from that point.
  • Create a WCF service and host it somewhere. The other system passes data to this service and the service interacts with CRM.

The client will just pass us records, so validation must happen on the CRM side.

EDIT:
If the client is an old system (in Cobol or something) is it still possible to connect to the CRM service?

3

3 Answers

1
votes

Just to expand on Predro's answer:

I have actually done both with CRM 4. I would highly reccommend that you create your own sevice for the client to call which in turn calls the CRM services.

This gives you an extra layer of abstraction for when things change later - and they will.

If your client calls the CRM services directly it will be difficult/impossible for you to change your internal data structures or move servers around in the farm. Esecially true if you currently use a singer-server infrastructre.

Also don't map the service you create directly to the entity data structure, use an intermidiate model.

So if you wanted the client to pass Account details in, have your service expect an XML document that you convert in to an Account Entity, rather than expose the Account Entity and have your client submit that.

1
votes

The second choice for me is the best way to handle with this situation, because you can control and validate everything in your side. You can host the WCF service in the same server of CRM Dynamics or in another server with access to CRM Dynamics and interact with with CRM through CRM Web Services. I think you don't have any better solution.

1
votes

Assuming the client has a login to your CRM system, I would actually go with the option #1 first. Why?

  • You can still validate the data in the Pre-Validation plugin stage.
  • This is by far the easiest and fastest way to get going. Will things change? Maybe! But:
    • You are going to spend lots and lots of hours getting a custom WCF service up and running
    • Somebody has to deploy it
    • Somebody has to maintain it
    • Your client has to learn how to connect to a proprietary WCF service instead of saying "Here's a bunch of published info on how to connect to CRM's webservices."
    • It becomes a "hidden silo" of business logic instead of it all existing in CRM. Any good CRM developer would be able to work on option number one. Number two requires additional skills.
  • If it really does change over time so much that it needs its own WCF service, you haven't really wasted that much time. All your business logic would be ported from a plugin to the WCF service. But it is much harder to go from the more complex solution (#2) to the simpler solution (#1) if it turns out that you don't need it.
  • I promise you that your customer wants this done faster and simpler (cheaper) rather than longer and more complex (expensive).