Die Windows Worflow Foundation in Microsoft Dynamics CRM 4.0 zu integrieren, hat sichtlich gut getan. Viele Aufgaben lassen sich mit Workflows vereinfachen oder gar komplett automatisieren. Und eine weitere herausragende Möglichkeit ist, den Workflows über Custom Assemblies weitere Funktionen "beibringen" zu können. Viele von Euch fragen mich, ob ich hierzu nicht ein paar Beispielcodes hätte oder ob es nicht eine Code-Bibliothek gibt, unter der sich Workflow-Assemblies finden lassen.

Anbei möchte ich Euch daher mit einem Praxis-Beispiel die Workflow Assemblies näher bringen. Zunächst zur Ausgangssituation: In einem Projekt ging es darum, die durch den Import erzeugten bzw. aktualisierten Datensätze einer übergeordneten Firma zuzuweisen, sofern der besagte Datensatz eine Filiale einer Firma war. Um dies zu identifizieren, arbeitet der Kunde mit zwei Nummern: Der Firmennummer - dem von Haus aus bekannten Standard-Feld und einer Filialnummer - einem benutzerdefinierten Attribut "new_branchsiteaccountnumber". Eine Filiale hat dabei exakt die gleiche Firmennummer, wie der Hauptsitz, jedoch ist die Filialnummer unterschiedlich. Am Hauptsitz hingegen ist die Filialnummer immer "0".

Da sich die Daten automatisch über eine zeitgesteuerte Import-Routine aus einem Fremdprogramm aktualisierten, galt es eine Routine zu schaffen, die den Prozess der Zuweisung der "übergeordneten Firma" automatisch übernimmt. Und genau hierfür kommt die Windows Workflow Foundation zum Einsatz.

Das Attribut "Übergeordnete Firma" ist ein Lookup Feld, wie sich schnell ermitteln lässt. Ich benötige zur Aktualisierung des Feldes also gezielt eine DatensatzID - und zwar diejenige, bei dem die Firmennummer = der Firmennummer des aktuellen Datensatzen und die Filialnummer = 0 ist.

Zunächst erweitern wir unsere VisualStudio-Anwendung, sofern noch nicht geschehen, um  die Erweiterungen für .NET Framework 3.0.

Als Resultat haben wir einige neue Projekttypen in VisualStudio 2005 zur Verfügung. Und bevor ich noch weiter in die Tiefe einsteige: Unter http://www.stunnware.com/crm2/topic.aspx?id=CustomWorkflowActivity findet sich für den Einsteiger alles notwendige, für die Entwicklung und Einrichtung.

Zunächst schaffen wir uns also die erforderlichen Verweise im Projekt:

using System;

using System.Workflow.Activities;

using System.Workflow.ComponentModel;

using Microsoft.Crm.Sdk;

using Microsoft.Crm.SdkTypeProxy;

using Microsoft.Crm.Workflow;

using Microsoft.Crm.Sdk.Query;

using System.Workflow.Runtime;

using System.Data;

using System.Xml;

using System.Xml.Linq;

Nun müssen beschäftigen wir uns mit der 1. Anforderung - wir benötigen eine erste Eingabemöglichkeit: Die Firmennummer

namespace FindAccountbyAccountnumber

{

    [CrmWorkflowActivity("Finde Firma zu Firmennummer & Filialnummer")]

    public class MatchAccountby :

    System.Workflow.Activities.SequenceActivity

    {

        // Input property

        public static DependencyProperty senderProperty = DependencyProperty.Register("sender", typeof(string), typeof(MatchAccountby));

        [CrmInput("Firmennummer")]

        public string sender

        {

            get

            {

                return (string)base.GetValue(senderProperty);

            }

            set

            {

                base.SetValue(senderProperty, value);

            }

        }

Da wir ebenfalls noch eine Filialnummer übergeben wollen, benötigen wir eine zweite Eingabemöglichkeit: Die Filialnummer

public static DependencyProperty sender2Property = DependencyProperty.Register("sender2", typeof(string), typeof(MatchAccountby));

[CrmInput("Filialnummer")]

public string sender2

{

    get

    {

        return (string)base.GetValue(sender2Property);

    }

    set

    {

        base.SetValue(sender2Property, value);

    }

}

Als Ausgabe möchten wir die AccountID des gefundenen Datensatzes zurückgeliefert bekommen.

// Output property

public static DependencyProperty accountIdProperty = DependencyProperty.Register("accountId", typeof(Lookup), typeof(MatchAccountby));

[CrmOutput("accountId")]

[CrmReferenceTarget("account")]

public Lookup accountId

{

    get

    {

        return (Lookup)base.GetValue(accountIdProperty);

    }

    set

    {

        base.SetValue(accountIdProperty, value);

    }

}

Jetzt hilft ein Blick in das aktuelle SDK, um die verschiedenen Methodiken abzuwägen, mit denen es möglich ist, die Suche innerhalb der Datenbank durchzuführen. Meine Wahl fiel in diesem Fall auf QueryByAttribute

private Guid MatchAccountbyAccountnumber(ICrmService crmService, string fromAccountnumber, string fromBranchsitenumber)

{

    // Retrieve Accounts from Entity with "fromAccountnumber" & "fromBranchsiteaccountnumber"

    QueryByAttribute query = new QueryByAttribute();

    query.ColumnSet = new AllColumns();

    query.EntityName = EntityName.account.ToString();

    query.Attributes = new string[] { "accountnumber", "new_branchsiteaccountnumber" };

    query.Values = new object[] { fromAccountnumber, fromBranchsitenumber };

    RetrieveMultipleRequest retrieveMultipleRequest = new RetrieveMultipleRequest();

    retrieveMultipleRequest.Query = query;

    retrieveMultipleRequest.ReturnDynamicEntities = true;

    RetrieveMultipleResponse retrieveMultipleResponse = (RetrieveMultipleResponse)crmService.Execute(retrieveMultipleRequest);

    BusinessEntityCollection retrieved = crmService.RetrieveMultiple(query);

    Guid accountId = Guid.Empty;

    foreach (BusinessEntity busEntity in retrieveMultipleResponse.BusinessEntityCollection.BusinessEntities)

    {

        // Pick the first accountid.

        accountId = ((Key)((DynamicEntity)busEntity)["accountid"]).Value;

        break;

    }

    return accountId;

}

Soweit also zur Abfrage der Datensätze. Da ich nach einer Übereinstimmung von Firmennummer und Filialnummer suche, wird definitiv nur ein Datensatz zurückgeliefert. Diesen gilt es nunmehr an die Workflow Routine zu übergeben.

protected override System.Workflow.ComponentModel.ActivityExecutionStatus Execute(System.Workflow.ComponentModel.ActivityExecutionContext executionContext)

{

    IContextService contextService = (IContextService)executionContext.GetService(typeof(IContextService));

    IWorkflowContext context = contextService.Context;

    // Obtain IcrmService so we can call into CRM SDK to retrieve accounts

    ICrmService crmService = context.CreateCrmService();

    // this.sender property will have the accountnumber that needs to be matched.

    // this.sender2 property will have the branchsiteaccountnumber that needs to be matched.

    Guid accountId = MatchAccountbyAccountnumber(crmService, this.sender, this.sender2);

    // Set the accountId output property to return this data back to the calling workflow

    this.accountId = new Lookup("account", accountId);

    return ActivityExecutionStatus.Closed;

}

    }

}

Soweit zum Quellcode. Diesen gilt es nunmehr zu kompilieren und die resultierende .dll-Datei mit Hilfe des aktuellen Plug-In-Registration-Werkzeuges in der Datenbank zu registrieren.

Im Anschluss an die erfolgreiche Registrierung, steht uns die neue Option als "Schritt" in den Workflows zur Verfügung.

Diesen gilt es nunmehr wie folgt aufzusetzen:

Zunächst prüfen wir die Filialnummer dahingehend, dass der Workflow nur ausgeführt wird, wenn die Filialnummer nicht "0" entspricht. Schließlich wollen wir der Hauptfiliale nicht sich selbst zuweisen.

Im Anschluss daran bestimmen wir unsere Firmennummer & Filialnummer.

Die Firmennummer holen wir uns dabei als dynamischen Wert aus dem aktuellen Datensatz und die Filialnummer geben wir als "0" vor. Im Anschluss daran fügen wir im einen weiteren Schritt eine Datensatzaktualisierung durch. Hier aktualisieren wir das Feld "Übergeordnete Firma" mit dem durch unsere Routine zurückgelieferten Wert - der AccountID. Und fertig...

Wie Ihr den Bildern entnehmen könnt, ist in meinem Beispiel die Entität "Firma" in "Betrieb" umbenannt worden.

Natürlich kann der Workflow auch noch verbessert werden und z.B. vorweg ein kleiner "TimeOut" als "Warte bis"-Schritt hinzugefügt werden, um zu verhindern, dass der Workflow unmittelbar nach Erstellung mit der Arbeit beginnt. Weiterhin kann der Bereich auch auf "Organisation" umgestellt werden. Meine Wahl "Benutzer" hängt lediglich mit meiner Präsentationsmaschine zusammen.

Wer von Euch nun etwas mehr über Workflow Assemblies wissen möchte, dem seien nachfolgende Blog-Beiträge als Ersatz zu einer Bibliothek empfohlen:

- http://www.stunnware.com/crm2/topic.aspx?id=CustomWorkflowActivity

- http://danishmscrm.blogspot.com/2008/03/example-of-custom-workflow-activity-crm.html

- http://blogs.msdn.com/jim_glass/archive/2008/04/30/calling-a-net-assembly-in-mscrm-4-0-workflows.aspx

- http://msdn.microsoft.com/en-us/library/cc151142.aspx

- http://blogs.msdn.com/crm/archive/2008/01/11/part-2-happy-birthday-via-workflow-using-custom-workflow-activity.aspx

- https://community.dynamics.com/blogs/crmteam/archive/2008/02/19/e-mail-to-case-lead-using-crm-4-workflow.aspx

- http://blogs.msdn.com/ukcrm/archive/2008/06/12/e-mail-to-case-using-workflow-update.aspx

- http://blogs.msdn.com/ukcrm/archive/2008/04/27/creating-sharepoint-sites-with-crm-workflow.aspx

Viel Spass und

vielleicht gibt es schon bald eine Bibliothek auf MSDN

Mittlerweile haben einige Kollegen hier im Netz Wege aufgezeigt, wie sich die Aktivitätenansichten durch Anpassungen beeinflussen lassen. In meinen Projekten habe ich mich mit zwei Varianten (supported) näher auseinandergesetzt. Der Methode, die Micheal Höhne (stunnware) unter http://www.stunnware.com/crm2/topic.aspx?id=js11 veröffentlicht hat bzw. dem Update des Codes für 4.0 unter http://www.stunnware.com/crm2/topic.aspx?id=JS33, den er von Jonathan Briggs zugesandt bekommen hat und einem weiteren Ansatz von Adi Katz, der unter http://mscrm4ever.blogspot.com/2008/07/changing-activity-history-default-view.html zu finden ist.

Letzteren fand ich insbesondere spannend, da in einer Routine, sowohl die Ansicht der Aktivitäten, als auch die Ansicht der historischen Aktivitäten zu beeinflussen ist. In meinen Projekten, sorgte der Einsatz jedoch für einen Script-Fehler. Und zwar immer dann, wenn ich das Register wechselte. Dies hatte zur Folge, dass beim Verlassen des Datensatzes über Abbruch ohne Speichern oder auch mit Speichern der Anwender eine unschöne Fehlermeldung erhält.

...

var _loadarea = loadArea;

loadArea = function(areaid)

{

//load the iframe 

_loadarea(areaid);

//create the iframe object 

var iframe = document.getElementById(areaid + "Frame");

//wait until the iframe is fully loaded ("complete") 

iframe.onreadystatechange = function()

{

if( iframe.readyState == "complete")

{

...

Nachdem ich den Code analysiert hatte, fiel mir auf, das beim Wechsel des Registers die Variable iframe mit einem NULL-Wert belegt werden könnte.
Hier also der komplette Code mit einer Fehler-Abfrage zum NULL-Wert:

   1: //Activity scheduledend options 

   2: var ActivityOptions =

   3: {

   4: Overdue :"Overdue",

   5: Today :"Today",

   6: Tomorrow :"Tomorrow",

   7: Next7Days :"NextXDays;7",

   8: Next30Days :"NextXDays;30",

   9: Next90Days :"NextXDays;90",

  10: Next6Months :"NextXMonths;6"

  11: }

  12: //Activity History actualend options 

  13: var HistoryOptions =

  14: {

  15: Today : "Today",

  16: Yesterday : "Yesterday",

  17: Last7Days : "LastXDays;7",

  18: Last30Days : "LastXDays;30",

  19: Last90Days : "LastXDays;90",

  20: Last6Months : "LastXMonths;6",

  21: Last12Months: "LastXMonths;12"

  22: }

  23:  

  24: var _loadarea = loadArea;

  25: loadArea = function(areaid)

  26: {

  27: //load the iframe 

  28: _loadarea(areaid);

  29: //create the iframe object 

  30: var iframe = document.getElementById(areaid + "Frame");

  31: // added code to avoid NULL value

  32: if( iframe != null)

  33: {

  34: //wait until the iframe is fully loaded ("complete") 

  35: iframe.onreadystatechange = function()

  36: {

  37: if( iframe.readyState == "complete")

  38: {

  39: var picklist,option;

  40: //reference to the iframe document 

  41: var iframeDoc = iframe.contentWindow.document;

  42: switch(areaid)

  43: {

  44: case "areaActivityHistory":

  45: picklist = iframeDoc.all.actualend[0];

  46: /* change to suit your needs */

  47: option = HistoryOptions.Last90Days;

  48: break;

  49: case "areaActivities":

  50: picklist = iframeDoc.all.scheduledend[0];

  51: /* change to suit your needs */

  52: option = ActivityOptions.Next7Days;

  53: break;

  54: default: return;

  55: }

  56: picklist.value = option;

  57: picklist.FireOnChange();

  58: }

  59: }

  60: }

  61: } 

Damit gehört der Script-Fehler der Vergangenheit an. Viel Spass !