Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03363.jsonl.gz/1515

Eine E-Mail mit Attachment versenden. Wie geht das?
Eigentlich ist es ganz einfach. Vorausgesetzt man weiss über das Folgende Bescheid:
Attachments sind eine eigene Entität Namens “ActivityMimeAttachment”
Attachments werden den E-Mails über eine 1:n Beziehung angehängt
Als erstes muss das E-Mail im CRM erstellt werden
E-Mail erstellen != E-Mail senden
Im Post von letzter Woche habe ich gezeigt wie sich ein E-Mail von einem Template erstellen lässt. Dieser Post hier baut darauf auf und geht davon aus, dass bereits eine E-Mail im CRM existiert (E-Mail Activity wurde erstellt aber noch nicht gesendet). Nun soll dieser E-Mail Attachment angehängt werden. Schlussendlich soll die E-Mail versendet werden.
Hinzufügen eines Attachments
Der Code ist simpel und spricht für sich alleine.
Wird ein Plug-In auf die “Close” Message eines Incidents registriert, wird das Plug-In gefeuert, sobald der Incident geschlossen wird. Die “PrimaryEntityId” des “IPluginExecutionContext” ist jedoch leer (Guid.Empty). Wie erhalte ich die Id des Incidents? Die Id des Incidents, welches die “Close” Message ausgelöst hat erhält man wie folgt:
var context = (IPluginExecutionContext)serviceProvider.GetService(typeof(IPluginExecutionContext));
var incidentResolutionEntity = (Entity)context.InputParameters["IncidentResolution"];
Guid incidentId = ((EntityReference)incidentResolutionEntity.Attributes["incidentid"]).Id;
Beim AaaS für Dynamics CRM hat man (verständlicherweise) mit einigen Limitationen zu kämpfen. Das wird gerade bei Enterprise Szenarien schmerzlich bewusst. Wenn zum Beispiel die folgende Anforderung gegeben ist “Jede halbe Stunde soll ein SAP Import laufen. Der SAP Import liefert jeweils viele Daten und die in das CRM zu schreiben dauert min. 10 Minuten. Hier stellt es gleich an zwei Stellen an. Erstens die infinite loop prevention (siehe Post “Dynamics CRM, Recurring Workflows und die Execution Depth”) und zweitens das Sandbox Timeout. Das Problem lässt sich also nicht oder nur umständlich mit Workflows lösen. Da kommt Azure ins Spiel.
Nach den Beiträgen “CRM Online Plugin auf Azure ausführen – Part 1, 2 und 3“, folgt nun der Beitrag “CRM Online Plugin auf Azure ausführen – Part 4” wo es ans eingemachte geht. Ich durfte in einem Projekt eine Workflow Activity auf Azure auslagern. Es war nicht sonderlich schwer aber trotzdem gab es das eine oder andere was ich gelernt habe. Continue reading →
Im Post “CRM Online Plugin auf Azure ausführen – Part 1” und “CRM Online Plugin auf Azure ausführen – Part 2” habe ich gezeigt wie man den ExecutionContext von Plugins auf den Azure Service Bus posten und mit einer WorkerRole abarbeiten kann. Somit lässt sich ein Plugin auslagern um z.B. die Sandbox-Restriktionen zu umgehen oder rechenintensive Aufgaben zu skalieren.
Im Post “CRM Online Plugin auf Azure ausführen – Part 1” habe ich gezeigt wie man den ExecutionContext von Plugins auf den Azure Service Bus posten kann.
Als Konsumenten habe ich eine lokale Konsolen-Applikation verwendet.
Nun wäre natürlich das Ziel, alles in der Cloud laufen zu lassen.
In diesem Post zeige ich, wie man eine Azure Worker Role erstellt und den Listener bzw. das Plugin dort hosten kann. Continue reading →
Die Restriktionen für Plugins und Custom Workflow-Activities auf CRM Online sind zum Teil sehr ärgerlich. Nicht zuletzt deshalb wäre es eine gute Sache, könnte man Plugins ausserhalb des CRMs laufen lassen. In diesem Blogpost zeige ich wie man das CRM dazu bringt den ExecutionContext eines Plugins auf den Azure Service Bus zu posten und wie sich diese Message mit den CRM SDK Samples konsumieren lässt. Continue reading →
Problem:
Das muss bei jedem Import gemacht werden.
Lösung:
1. Solution unmanaged exportieren.
2. Sicherstellen das folgende Zeilen im XML vorhanden sind: <internaljscriptfile src=”$webresource:Opportunity_main_system_library.js” />
3. Auf einem FRISCHEN ONLINE Mandanten importieren
4. Exportieren -> Das das fehlerhafte XML ist nicht mehr vorhanden
Sonstige amüsante Dinge:
– Das Problem lässt sich auch reproduzieren indem eine Unmanaged solution ohne <internaljscriptfile src=”$webresource:Opportunity_main_system_library.js” /> importiert wird
– Das customization.xml enthält auch andere Webresourcen die durch die Solution entfernt werden (so z.B. der Account) da tritt jedoch kein Problem auf
o Das lässt die Vermutung zu, dass die „reparierte“ Solution evtl. später Probleme machen könnte
– Eine defekte solution als unmanaged exportieren, anpassen und wieder auf demselben System importieren bringt nichts