onsdag 13 augusti 2014

Workflows not triggering and how to trigger workflows without changing any data

I had a problem at a customer last week where a workflow wasn't triggering after I set the trigger field with a script. Very annoying troubleshooting of that one which lead to trying to set the field in pre execution plugin, post execution plugin and changing the field manually. Finally I found that the plugin was the culprit.

To begin with, it's not my code to begin with, and I'm not saying that to put blame on anyone more that I didn't fully see what was happeing. The problem looks as follows. There's a button in the ribbon of a CRM 2011 implementation that will create a printout and that button changes two fields, a optionset and a bool field. This is done in a plugin which reads the optionset and acts on the input value, then resets the optionset by doing a post execution update of the object with the optionset nulled.

Originally the workflow was triggering and checking the state of the optionset, however that field is changed in the entity plugin before the workflow is reading it so the logic didn't work. I chose to add the bool field and change that with the same script, now when I was looking in the audit the field obviously changed but the workflow didn't trigger.

Right, I toggled the bool field manually, which showed in the audit log, and this triggered the workflow. That bit did not do miracles to my mental healt I might add, but it got worse.
Next step in my troubleshooting was to add the bool field to the pre execution state plugin, that didn't help either so I did a final shot at doing it in the same step that was nulling the optionset and then updating the object,

Now the workflow was triggered, twice (back to mental health issues). At this time my colleague and boss Gustaf was back from vacation and we started talking about this. His advise was to turn off the plugins and see what happened, this did indeed work for the workflow triggering so now we had the culprit under the glass.

The code that did the nulling of the optionset looked something like this: which

target[optionset] = null;

which I changed to

Entity ent = new Entity(target.logicalname);
ent.Id = target.Id;
ent[optionset] = null;

this helped with the workflow triggering but I didn't like to save the object twice so I reworked it and reset the optionset in the pre execution step and moved the value that was interesting to the shared variables instead.

Now to the fun and games with workflows part. Can this be used? It might, but I'm not entirely sure of the application. 

I had to try this at home with a very simple plugin, I had done some setting up of a entity in our lab environment to see if there was a problem with changing field with scripts to trigger workflows, it wasn't.

I set up a workflow triggering on a bool field

I had the following code that I played around with a bit, this is the final incarnation.

public void Execute(IServiceProvider serviceProvider)
            if (context.InputParameters.Contains("Target") && context.InputParameters["Target"] is Entity)
                Entity entity = (Entity)context.InputParameters["Target"];
                if (context.Stage == 20)
                    RunPre(entity, service);
                else if (context.Stage == 40)
                    RunPost(entity, service);

        private void RunPre(Entity entity, IOrganizationService service)


        private void RunPost(Entity entity, IOrganizationService service)

            entity.Attributes.Add("crmk_testar_chkb", true);

With this code I reproduced the behaviour that the workflow isn't triggered, triggered once and triggered twice with the update of the bool field "crmk_testar_chkb". The rationale being the "entity.Attributes.Clear()" totally blocking the workflow, if clearing the attributes and then adding the field again giving one workflow triggered. Updaging the object with the field in the attributes giving two workflows.

Finally, when you're adding the field to the post execution step property bag funny stuff happens. The workflow gets triggered without any field change being entered into the database.

As you can see in the audits of 9.45 pm and onward, only the string field testar_strng is updated.

And here are the workflows triggered. The 9.45 one is triggered from a bool toggle at 9.45 in the audit but the following three are triggered by adding the field to the property bag in the post execution step plugin.

This may not be any news for some of you out there that know youre plugin execution pipeline chart on your five fingers, but it's not something I have run into earlier.

I have been thinking about if this is something that might be useful in some situation, I haven't found one yet since you probably can trigger the workflow anyway, byt there might be times when it's useful. It's also good to know that emptying the property bag will stop your workflows from triggering since that is done in the post execution step.

NB, this is verified in CRM 2011, but will probably behave the same in 2013.

Rickard Norström
Developer at CRM-Konsulterna

torsdag 7 augusti 2014

Problems installing CRM 2013

Installing a product like Microsoft Dynamics CRM 2013, or any other verison for that matter, might be a smooth trip down the newly paved highway, it can also be slightly bumpier. Today I've noted a few problems which might occur and how to resolve them.

In most of these cases, the problem is a result of different pre reqs that aren't quite in place, however the problems don't seem to occur due to these gaps in security or whatever the problem might be because unfortunately the error messages shown aren't exactly spot on at all times.

Username errors.
One issue that might occur is that you enter your service account uid and password correct, however you still get an error saying that the username or password is incorrect. This may be a result of a too long username. CRM seems to be using the Windows Server 2000 type usrename with domain\username look. That type has a max length of 20 characters in the username which will indeed create an incorrect username if you type a username of 20+ characters. The funny thing here is that the AD actually takes more than 20 characters and tries to verify it against a 20 character username that has been truncated.

SQL Server Agent is not running
This is another issue that might occur, and yes sometimes it's actually the SQL Server Agent service that is not running, this seems to be turned off and set as start manually as default if you don't do something about it. This may also be caused by having the firewall block certain ports that the SQL is using, this is default port 1433 but in some cases you might need 445 to be open.
If the firewall rules don't help one issue that can give this error is that the installing user isn't system administrator on the SQL server instance that you're installing CRM on, a pre req to install CRM but if you miss it this error message isn't exactly pointing you in the right direction.

Reporting Services not responding
This is an issue that I have run into too. This may of course be so simple as the reporting services part of SQL Server isn't installed, but it can also be that during the installation the settings were not set to default so no settings are available and the reporting services databases are not created. To fix this, start the Reporting Services Configuration Manager and pretty much just go through all the tabs and click apply which will set the default values unless you want to change something.

Hope this will help someone with these errors.

Rickard Norström
Developer at CRM-Konsulterna