Direkt zum Hauptbereich

Email Versand

Mit einer interessanten, aber auch ziemlich komplizierten Aufgabe habe ich mich in den letzten Tagen beschäftigt.
Aufgabenstellung: sobald ein Ticket(Case) eine Eskalationsstufe erreicht, müssen alle relevanten Benutzer per Email informiert werden.

Eigentlich ganz einfach, dachte ich. Die Lotus Notes Platform bietet in Bezug auf die Email-Generierung und Versand vielfältige Möglichkeiten. Mit Salesforce sind die Grenzen klar definiert.

Nun zur Umsetzung:
1) Einen Trigger programmiert, der beim Aktualisieren von Cases die Methode "informUsersOnCaseEscalation()" aus der "helper" Klasse aufruft.

trigger CaseTrigger on Case (before insert, before update) {
 //BEFORE INSERT or UPDATE
 if(Trigger.isBefore){
  //... initialize ...
  CaseTriggerHelper helper = new CaseTriggerHelper(Trigger.new, Trigger.oldMap);
  if(Trigger.isUpdate){
   helper.informUsersOnCaseEscalation(); //send mass email to queue members on case escalation
  }
 }
} 

2) Ich verzichte auf die Darstellung und Beschreibung des Konstruktors aus der helper-Klasse und zeige nur die für den Email-Versand relevanten Ausschnitte.

Die folgende Methode baut eine Liste mit Emails zusammen und versendet diese anschließend.


public void informUsersOnCaseEscalation(){
 List<Messaging.SingleEmailMessage> emailsSingle = new List<Messaging.SingleEmailMessage>();
 String Errors = '';

 for(Case c : lstCases){
  if(escalationLevel > 0){
   emailsSingle.add(NewSingleEmail(lstRecipients, c));
  }
 }
 if(!emailsSingle.isEmpty())
  sendEmailsSingle(emailsSingle);
}


Warum SingleEmailMessage und nicht MassEmailMessage?
Ohne sich ausreichend mit der Doku zu beschäftigen, habe ich angefangen, zu programmieren. Ist ja logisch, einfacher Email-Versand. Wer braucht da schon die Doku ;-)
Da die Anzahl der Email-Empfänger unbekannt ist, habe ich mich für die MassEmailMessage (MEM) Methode entschieden, außerdem bringt sie einige Features mit, die ich brauche.
Zum Beispiel, es gibt ein Email Template mit dem vorkonfigurierten Text, der auch Formeln enthält. Dieses Template soll benutzt werden.
Während der Umsetzung stellte ich fest, dass die MEM Methode nicht geeignet ist.

Und hier sind die Gründe:
a) die Formeln aus dem Email Template werden vom System entfernt, weil die Verbindung zu Cases nicht hergestellt werden kann:
Mit setTemplateID teile ich dem System das Email Template mit.
Mit setTargetObjectIds werden die Empfänger bekannt gegeben.
Mit setWhatIds stelle ich die Verbindung zu Cases <- und genau hier klemmt es. Dieser Parameter lässt sich nur dann benutzen, wenn man Emails an Kontakt-Objekte adressiert (und nicht an User-Objekte).
zu a) Man könnte temporär Kontakte erzeugen, die Email-Adressen aus den User-Objekten übertragen, Emails versenden und dann die Kontakte löschen. Eine sehr traurige Angelegenheit. Zudem werden solche Aktionen im Chatter protokolliert: "Neuer Kontakt erstellt..."

b) Eine andere Möglichkeit wäre, Email-Subject und Body aus dem Template übernehmen und alle Platzhalter durch gültige Werte ersetzen.
zu b) Leider auch unmöglich. Die MEM Methode ermöglicht das Befüllen von Subject (von Salesforce undokumentiert), aber nicht das Befüllen des Body-Feldes.

Folgend ist die implementierte SingleEmailMessage Methode (SEM). Diese Methode ist etwas mächtiger. Hier müssen allerdings SMTP-Email-Adressen benutzt werden, anstatt von UserIDs. Diese lassen sich aber per SOQL Query berechnen.


/***** NewSingleEmail() *****/
/*+++++++++++++++++++++++++++++++++++++++++++++++++*/
private Messaging.SingleEmailMessage NewSingleEmail(List<Id> lstRecipients, Case caseObj){
 //Build a list with all Email Addresses to send emails to
 List<String> lstEmailAdr = new List<String>();
 for(Id idUser : lstRecipients){
  String emailAdr = mapQueueMemberEmails.get(idUser);
  lstEmailAdr.add(emailAdr);
 }
 // Build EMAIL -----------------------------------------
 Messaging.SingleEmailMessage mail = new Messaging.SingleEmailMessage();
 mail.setUseSignature(false);
 mail.setSaveAsActivity(false);
 mail.setToAddresses(lstEmailAdr);
 setSubjectAndBody(mail, caseObj);

 return mail;
}


Da das Email Template einige Formeln enthält, lassen sich diese mit Hilfe von regular expressions finden und ersetzen. Und damit werden Subject und Body gesetzt:

***** setSubjectAndBody() *****/
/*+++++++++++++++++++++++++++++++++++++++++++++++++*/
private void setSubjectAndBody(Messaging.SingleEmailMessage mail, Case caseObj){
 // Subject and Body of Email Template
 String sSubjectOut = emailTemplateEscalation.Subject;
 String sBodyOut = emailTemplateEscalation.Body;

 // Regex pattern to get Field Names from Email Template
 Pattern p = Pattern.compile('\\{([^}]*)\\}');
 String caseField;
 String replaceWhat;
 String replaceWith;

 //Build SUBJECT -----------------------------------------
 Matcher m = p.matcher(sSubjectOut);
 while (m.find()){
  caseField = m.group(1);
  caseField = caseField.substringAfter('.');
  replaceWhat = '{!Case.' + caseField + '}';
  replaceWith = String.valueof(caseObj.get(caseField));
  sSubjectOut = sSubjectOut.replace(replaceWhat, replaceWith);
 }

 //Build BODY -----------------------------------------
 m = p.matcher(sBodyOut);
 while (m.find()){
  caseField = m.group(1);
  caseField = caseField.substringAfter('.');
  replaceWhat = '{!Case.' + caseField + '}';

  if(caseField == 'Link') replaceWith = URL.getSalesforceBaseUrl().toExternalForm() + '/' + caseObj.Id;
  else if(caseField == 'OwnerFullName') replaceWith = mapQueueMembersNames.get(caseObj.OwnerId);
  else replaceWith = String.valueof(caseObj.get(caseField));

  if(replaceWith == '' || replaceWith == null) replaceWith = caseField;

  sBodyOut = sBodyOut.replace(replaceWhat, replaceWith);
 }
 mail.setSubject(sSubjectOut);
 mail.setPlainTextBody(sBodyOut);
}



Kommentare

Beliebte Posts aus diesem Blog

Salesforce Community URL Settings

Ich habe mich in den letzten Tagen etwas ausführlicher mit Salesforce Communities in Kombination mit der API beschäftigt. Ein Problem dabei war, den richtigen Endpoint zu berechnen, wie im letzten Beitrag beschrieben API im Salesforce Partner Portal. Um die Weichen im Code für Community Benutzer einzubauen, muss während der Laufzeit berechnet werden, in welchem Context sich der aktuell eingeloggte Benutzer befindet. Dabei muss man sich zwangsweise mit den Fragen folgender Art beschäftigen: ist der eingeloggte Benuter ein Community Benutzer? ob und welche Community ist gerade aktiv? wie sieht die definierte Community URL aus? Antwort auf die Frage 1: private Boolean isCommunityUser(){         Boolean bIsCommunityUser = false;         String sUserType = UserInfo.getUserType();         sUserType = sUserType.toUpperCase();         if(sUserType == 'STANDARD')                 bIsCommunityUser = false;         if(sUserType == 'PARTNER')                  bIsCommunity

Salesforce APEX Techniken

Mal auf die Schnelle zusammenbasteln „Das kann doch nicht so schwer sein!“ Das ist vermutlich einer der berühmtesten Sätze, mit dem ein (Salesforce) Entwickler konfrontiert wird.  Diese Aussage wird vor allem als Waffe benutzt, um den vom Entwickler geschätzten Aufwand und die damit verbundenen Kosten zu reduzieren. Ein mutiger "Angreifer" mit wenig Entwicklungs- und Prozess-Know-how ergreift nicht zu selten die Initiative und stellt selbst triumphierend das Produkt seiner Wünsche her. Es ist in der Tat nicht schwer, schnell das gewünschte Ergebnis zum Beispiel in Form eines Triggers zu erzielen. Im Internet kursieren viele Beispiele dazu. Die mächtige Salesforce Community unterstützt im Problemfall. Einige Lösungen aus dieser Kategorie durfte ich in den letzten Jahren begutachten. Sie alle haben eine Gemeinsamkeit: sie funktionieren nicht (lange)! Da fühlt man sich manchmal wie die Stiftung Warentest, die ein chinesisches Billigprodukt testet. Ziel als Ausgangspunkt

Zeitgesteuerter Flow blockiert Custom Leadkonvertierung

Die programmierte Konvertierung eines Leads bricht mit der Fehlermeldung "Unable to convert lead that is in use by workflow" ab. Der Grund ist ein Prozess, der automatisiert und zeitgesteuert ausgeführt wird. Dieser Prozess ruft zu einem späteren Zeitpunkt einen Flow auf. Während der Speicherung eines Leads wird dabei automatisch ein Flow Interview erstellt. Dieser Datensatz vom Typ "FlowInterview" blockiert die Leadkonvertierung. Lösung: Unmittelbar vor der Leadkonvertierung eine Checkbox auf dem Lead auf TRUE setzen. Da dieselbe Checkbox in den Process Builder Kriterien eingebunden ist und der Prozess nur auf den FALSE Wert reagiert, löscht das System automatisch das entsprechende Flow Interview.