Tag Archives: crm2013

Dynamics CRM API: E-Mail mit attachment versenden

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.

  1. Hinzufügen eines Attachments
    Der Code ist simpel und spricht für sich alleine.
private void AddAttachment(Email email, string fileName, string mimeType, byte[] content)
{
    var activityMimeAttachment = new ActivityMimeAttachment
    {
        FileName = fileName,
        Body = Convert.ToBase64String(content),
        MimeType = mimeType,
        ObjectTypeCode = email.EntityLogicalName,
        ObjectId = email.ToEntityReference()
    };

    organizationService.Create(activityMimeAttachment);
}
  1. Senden der E-Mail
private void SendEmail(Guid emailId)
{
    var reqSendEmail = new SendEmailRequest
    {
        EmailId = emailId,
        TrackingToken = string.Empty,
        IssueSend = true
    };

    organizationService.Execute(reqSendEmail);
}

Plug-In auf Close Message eines Incidents – wo ist die Incident Id?

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;

Access is denied beim async Solution Import (ImportSolutionRequest & ExecuteAsyncRequest )

Der Versuch eine Solution “ImportSolutionRequest” mit dem “ExecuteAsyncRequest” zu importieren scheitert mit folgendem Fehler:

“Solution Import Failed: 31 Unhandled Exception: System.ServiceModel.FaultException`1[[Microsoft.Xrm.Sdk.OrganizationServiceFault, Microsoft.Xrm.Sdk, Version=6.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35]]: Access is denied. Detail: <OrganizationServiceFault xmlns:i=”http://www.w3.org/2001/XMLSchema-instance” xmlns=”http://schemas.microsoft.com/xrm/2011/Contracts”> <ErrorCode>-2147187707</ErrorCode> <ErrorDetails xmlns:d2p1=”http://schemas.datacontract.org/2004/07/System.Coll
ections.Generic” /> <Message>Access is denied.</Message><Timestamp>2014-08-22T12:31:53.4691706Z</Timestamp>”.

Continue reading

Reliable Import Job für CRM mit Azure und MVC WebAPI

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.

Continue reading

CRM Online Plugin auf Azure ausführen – Part 4

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

CRM Online Plugin auf Azure ausführen – Part 3

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.

In diesem Post geht es um die Kosten.
Continue reading

CRM Online Plugin auf Azure ausführen – Part 2

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

CRM Online Plugin auf Azure ausführen – Part 1

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

CRM 2013 Online Error:Object doesn’t support property or method ‘Form_onload’

Fehler:

Message from webpage

There was an error with this field’s customized event.

Field:window

Event:onload

Error:Object doesn’t support property or method ‘Form_onload’

OK

Ursache:
Die Managed Solution enthält folgendes XML:
<clientincludes>
<internaljscriptfile src=”$webresource:Opportunity_main_system_library.js” solutionaction=”Removed” />
</clientincludes>

Workaround:
XML aus managed Solution löschen.

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