locked
SSIS / MSCRM2011 RRS feed

  • Question

  • Hi

    I hope someone can give me some advice on a problem I'm having.

    I have an SQL2012 SSIS package that runs about 50 dataflows each following the same format.  OLE DB Source feeding in to a script component (this is just doing lots of different selects and then writes via the CRM webservices).

    The challenge I am having is that on some dataflows the code from the last run script component appears to run.

    Code from First Script Component

        public override void Input0_ProcessInputRow(Input0Buffer Row)
        {
            SetStateRequest setStateRequest = new SetStateRequest  
                {  
                    EntityMoniker = new EntityReference("lead", Row.leadid),  
                    State = new OptionSetValue(2),  
                    Status = new OptionSetValue(100000001),
                };  
            organizationservice.Execute(setStateRequest);
            setStateRequest = new SetStateRequest { };
        }

    Code from Second Script Component

        public override void Input0_ProcessInputRow(Input0Buffer Row)
        {
            Entity existingLeadNNR = new Entity("lead");

            existingLeadNNR["leadid"] = Row.leadid;

            OptionSetValue new_outcomeofcallNNR = new OptionSetValue();
            new_outcomeofcallNNR.Value = 100000006;
            existingLeadNNR.Attributes.Add("new_outcomeofcall", (OptionSetValue)new_outcomeofcallNNR);

            organizationserviceNNR.Update(existingLeadNNR);        
        }

    When the second code gets called the lead gets disabled....

    Friday, February 13, 2015 12:35 AM

Answers

  • Just for completeness...

    I have now found the issue and thankfully it was nothing to do with my code but more to do with how I had set up the dataflows.  I had copied the first dataflow I created and then modified as required however it would appear that in SSIS 2012 the ID (supposidly unique for every item) also gets copied so every script component had the same unique ID.  I have recreated the script components and everything looks okay now.

    Thanks for your suggestions.

    Matthew

     
    Friday, February 13, 2015 9:09 AM

All replies

  • Hi Matthew,

        Can you explain why you are setting the StatusCode to 100000001 in your first dataflow? I don't believe that is a valid StatusCode, as it also looks like you are setting the Lead to a disqualified state. 

    Also, is the Row.leadid the same value for both your first and second dataflows? if so, the first dataflow would disqualify the lead. That might explain the scenario you are seeing since the lead would be readonly at that point.


    John

    Friday, February 13, 2015 4:19 AM
  • I'm not sure I fully understand from your description what's going on. Is both the first and second bit of code being run for the same record ? If so, as per the previous post, it's the first set of code that'd disable the record

    If you're sure that only the second bit of code is being run for a record, and that record is disabled, the most likely cause is that you have a plugin or workflow that runs when new_outcomeofcall is set, and disables the record


    Microsoft CRM MVP - http://mscrmuk.blogspot.com/ http://www.excitation.co.uk

    Friday, February 13, 2015 9:00 AM
    Moderator
  • Hi John

    StatusCode 100000001 is a custom status reason.

    The two sets of code run on different data sets so it shouldn't disable one that fits with the second piece of code.

    Matthew

    Friday, February 13, 2015 9:07 AM
  • Just for completeness...

    I have now found the issue and thankfully it was nothing to do with my code but more to do with how I had set up the dataflows.  I had copied the first dataflow I created and then modified as required however it would appear that in SSIS 2012 the ID (supposidly unique for every item) also gets copied so every script component had the same unique ID.  I have recreated the script components and everything looks okay now.

    Thanks for your suggestions.

    Matthew

     
    Friday, February 13, 2015 9:09 AM