locked
Confirm architecture of integration solution? RRS feed

  • Question

  • Hello,

    A customer has asked that I integrate the contact entity in CRM with their financial system. If someone can comment on the soundness of the approach I've architected, I'd be much obliged.

    I'll use a plugin to run on the post stage of the update and create event of the contact.

    1. Plugin will check the properties in the input parameters to see if they contain any of the fields that need to be integrated.
    2. If they do, the the plugin will get the field values from the PostEntityImage and pass them into the code to update the financial system.

    Pretty simple, but as I'm working with the financial system here, I want to make sure I think this through completely. Some gotchas I know to be aware of:

    *class-level variables - although I don't typically use these in plugins anyway, I know there are caching issues that could end up in sending the wrong info to the financial system. All variables will be at the method-level.
    *Input parameters - decided on this approach rather than comparing the PreEntityImages and the PostEntityImages for differences in the attributes. My understanding is that this is a pretty failsafe method of knowing what has changed - updated fields will always be included in the Input Parameters.
    *I'm not using any intermediate tables or CRM entities - the Update and Create events on the contact will call the financial system's web services directly. I thought about putting the info in a custom CRM entity with the old and new values for the record I'm updating, but it didn't seem like there was much value in doing so - just adding a step without adding much safety. Most integration systems I'm familiar with don't do that sort of thing.

    Any comments are appreciated! Thanks!

    Friday, August 6, 2010 5:13 PM

Answers

All replies