
Ce post s'adresse au développeur qui souhaite tirer le meilleur parti des capacités de modèle d'email de SparkPost. On suppose que vous êtes à l'aise avec la lecture de contenu JSON et le suivi d'un flux de programmation basique. Au fur et à mesure que des termes qui pourraient vous être nouveaux, comme la RFC 5322, sont introduits, le texte est lié à sa référence source.
Ce post s'adresse au développeur qui souhaite tirer le meilleur parti des capacités de modèle d'email de SparkPost. Il est supposé que vous êtes à l'aise avec la lecture de contenu JSON et le suivi du flux de programmation de base. Les termes qui peuvent vous être nouveaux sont introduits comme RFC 5322, le texte est lié à sa référence source. Avec cela en tête, passons directement au sujet.
Les modèle et capacités de transmission de SparkPost rendent l'envoi d'emails simple. Ces capacités fournissent une abstraction pour le contenu texte et HTML, ce qui signifie que la plupart du temps, il n'est pas nécessaire de coder directement au format brut de l'email tel que défini dans RFC 5322 anciennement connu sous le nom de (RFC 822). Mais parfois, vous pouvez souhaiter créer des messages plus complexes qui comportent d'autres parties Multipurpose Internet Mail Extensions (MIME) qui ne sont pas directement exposées via l'interface RESTful de SparkPost.
Composition simplifiée d'Email
Tout d'abord, examinons un scénario idéal pour l'envoi d'un email. Utilisez le point de terminaison transmission pour fournir le texte
et le HTML . En coulisses, SparkPost s'occupe de composer un email RFC 5322 valide. SparkPost insérera des variables de substitution de substitution_data dans le contenu texte et HTML. C’est un moyen puissant de générer du contenu personnalisé pour chaque destinataire dans un modèle commun.
Voici un exemple de transmission avec du contenu HTML et texte avec substitution_data.
Substituer des Tableaux de Données
Beaucoup de gens réalisent que les points de terminaison transmission et modèle de SparkPost peuvent faire une substitution de contenu simple dans les en-têtes d'email et les corps des emails. Mais beaucoup négligent la capacité de fournir du contenu conditionnel ou des tableaux de données qui peuvent également être substitués. Vous pouvez également fournir du contenu unique par destinataire. Dans cet exemple, nous envoyons un tableau de liens uniques à chaque destinataire.
Ceci est accompli en fournissant un tableau JSON de données qui sera inséré dans le corps de l'email. Une fois les données fournies, SparkPost utilisera la logique dans le modèle pour les insérer.
Dans cet exemple, SparkPost recherchera des données de substitution appelées « files_html » et fera un « pour chaque » sur chaque élément du tableau. Il créera une ligne avec la valeur de « fichier » dans l'élément « files_html ». Notez le triple accolade autour de « loop_var.file ». C'est parce que chaque élément du tableau contient du HTML et que nous devons indiquer au serveur de l'utiliser tel quel sans l'échapper. La partie texte sera une simple étiquette de texte et l'URL du fichier.
Voici l'exemple de travail complet :
Astuce Pro : Dans votre code, il est conseillé de garder le balisage de la vue séparé des données, mais l'objectif ici était de garder l'exemple aussi simple et facile à suivre que possible, nous avons donc créé deux tableaux. Un tableau est pour la partie HTML et l'autre pour la partie Texte. Dans une utilisation en production, il serait courant d'avoir un ensemble de données et d'écrire la logique dans le code du modèle.
Pièces Jointes dans les Capacités de Transmission
Le point de terminaison de transmission fournit également une abstraction pour l'envoi de pièces jointes. Vous verrez ci-dessous que les pièces jointes sont spécifiées dans le tableau content.attachments où chaque objet du tableau décrit un élément de pièce jointe individuel. Comme auparavant, SparkPost s'occupera de coder texte, HTML, substitutions et d'itérer à travers le tableau de pièces jointes pour coder un message d'email adapté.
Les meilleures pratiques dictent que l'envoi de pièces jointes est à éviter, sauf si requis explicitement dans le cadre de votre service.
Ci-dessous sont les champs requis pour une pièce jointe :
type : Le type MIME de la pièce jointe
name : Le nom de fichier de la pièce jointe
data : Données de fichier encodées en Base64
Voici à quoi ressemble une pièce jointe à l'intérieur du contenu de la transmission :
Vous pouvez également envoyer des « images intégrées » dans une transmission. Celles-ci sont très similaires aux pièces jointes et sont spécifiées dans le tableau content.inline_images où chaque objet inline_image est similaire à l'objet de pièce jointe montré ci-dessus.
Pièces Jointes dans les Modèles
Maintenant que nous avons les bases pour envoyer des pièces jointes avec le point de terminaison de transmission, regardons comment le faire avec des modèles. Au moment de cette rédaction, il n'y a pas d'abstraction de pièces jointes comme vous le trouvez pour les transmissions intégrées. On pourrait conclure que les modèles ne peuvent pas être créés avec des pièces jointes. Vous auriez partiellement raison, mais il existe une solution, bien que vous ne soyez plus isolé du format RFC 5322.
Vous pouvez accomplir des pièces jointes dans les modèles en codant vous-même le contenu RFC 5322, ce qui inclut les pièces jointes. La bonne nouvelle est que vous ne perdrez pas la capacité d'utiliser encore Substitution Data dans vos en-têtes, HTML et texte. Sachez que ce type de modèle limite les substitutions aux en-têtes et à la première partie HTML et texte.
Voici un exemple de comment cela est fait.
Email RFC822
Créez votre email RFC 5322 avec les données de substitution que vous souhaitez. J'ai créé celui-ci dans mon client mail et me l'ai envoyé. Une fois reçu, j'ai copié la source et remplacé les champs que je voulais substituer dynamiquement.
La dernière partie MIME dans ce message vous verrez Content-Disposition: attachment; filename=myfile.txt”. C'est là que le nom du fichier est défini. Votre contenu de pièce jointe sera très certainement beaucoup plus complexe mais cet exemple s'efforce de rester simple.
Modèle Stocké
Une fois que vous avez un email RFC 5322 valide, stockez-le en utilisant la forme email_rfc822 du point de terminaison de modèle au lieu d'utiliser texte et HTML. Voici un exemple de ce que le content ressemble pour ce message :
Lorsque la demande est terminée, SparkPost vous répondra avec un identifiant unique pour votre nouveau modèle. Par exemple, xxxxxxx.
Envoi du Modèle
La bonne nouvelle est que créer le contenu RFC 5322 était la partie difficile. À partir de maintenant, envoyer ce modèle avec SparkPost est exactement la même chose que d'envoyer n'importe quel autre modèle.
Voici comment nous envoyons ce modèle et remplissons les données de substitution :
Modèles depuis l’API d’un Client Mail
Si vous utilisez un langage de programmation qui a une bibliothèque pour composer un email, vous pouvez l'utiliser pour créer programmatiquement le modèle ou même envoyer le message en ligne. Voici un exemple d'utilisation de JavaMail via le point de terminaison de transmission de SparkPost. Cette méthode devrait être facilement traduite en PHP ou dans le langage de votre choix.
Conclusion
Maintenant que vous voyez comment SparkPost peut être utilisé pour envoyer des emails de presque toute complexité, vous pourriez vouloir jeter un œil à «SparkPost Supporte l’Envoi d’Email sur Apple Watch» ou jeter un œil à la syntaxe de substitution pour voir comment elle peut être utilisée avec « si alors sinon », « expressions dans les conditionnels » ou « itération de tableau » directement dans votre modèle ou contenu de transmission.