
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 est destiné 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 de flux de programmation de base. Les termes qui pourraient être nouveaux pour vous, comme RFC 5322, sont liés à leur référence source. Maintenant que cela est clarifié, plongeons directement dedans.
Les modèles et les 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 le format d'email brut qui est défini dans RFC 5322, anciennement connu sous le nom de (RFC 822). Mais parfois, vous voudrez peut-être créer des messages plus complexes qui ont 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
D'abord, examinons un scénario idéal pour l'envoi d'un email. Utilisez le point de terminaison transmission pour fournir le contenu texte
et HTML. En coulisses, SparkPost s'occupe de composer un email RFC 5322 valide. SparkPost insérera des variables de substitution à partir 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 de transmission et de modèle de SparkPost peuvent effectuer une substitution simple de contenu dans les en-têtes d'email et les corps d'email. 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.
Cela est accompli en fournissant un tableau JSON de données qui sera peuplé dans le corps de l'email. Une fois les données fournies, SparkPost utilisera la logique dans le modèle pour les peupler.
Dans cet exemple, SparkPost recherchera des données de substitution appelées « files_html » et effectuera un « pour chaque » élément dans le tableau. Il créera une ligne avec la valeur de « fichier » dans l'élément « files_html ». Notez les triples accolades autour de « loop_var.file ». C'est parce que chaque élément du tableau contient du HTML et 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 vers le fichier.
Voici l'exemple de travail complet :
Astuce Professionnelle : Dans votre code, il est conseillé de séparer le balisage de vue des données, mais l'objectif ici était de garder l'exemple aussi simple et facile à suivre que possible, donc nous avons créé deux tableaux. Un tableau est pour la partie HTML et l'autre est pour la partie Texte. À des fins de production, il serait courant d'avoir un seul 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 en texte, HTML, substitutions et d'itérer à travers le tableau des pièces jointes pour coder un message d'email correctement formé.
Les bonnes pratiques dictent qu'il est préférable d'éviter d'envoyer des pièces jointes sauf si cela est explicitement requis dans le cadre de votre service.
Ci-dessous se trouvent les champs requis pour une pièce jointe :
type : Le type MIME de la pièce jointe
nom : Le nom de fichier de la pièce jointe
données : Données du fichier encodées en Base64
Voici à quoi ressemble une pièce jointe à l'intérieur de la strophe de contenu de 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ù chacun des objets inline_image est similaire à l'objet pièce jointe montré ci-dessus.
Pièces Jointes dans les Modèles
Maintenant que nous avons les bases appropriées pour envoyer des pièces jointes avec le point de terminaison de transmission, examinons comment faire cela avec les modèles. À l'heure où nous écrivons ces lignes, il n'y a pas d'abstraction pour les 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 serez plus isolé du format RFC 5322.
Vous pouvez réaliser des pièces jointes dans les modèles en codant vous-même le contenu RFC 5322 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 d'email, HTML et parties texte. Soyez conscient que ce type de modèle limite les substitutions aux en-têtes et à la première partie HTML et première partie texte.
Voici un exemple de la manière dont cela est accompli.
Email RFC822
Créez votre email RFC 5322 avec les données de substitution souhaitées. J'ai créé celui-ci dans mon client de messagerie et me l'ai envoyé à moi-même. Une fois que je l'ai reçu, j'ai copié la source et remplacé les champs que je veux substituer dynamiquement.
La dernière partie MIME de ce message vous verrez Content-Disposition: attachment; filename=myfile.txt”. C'est là que se trouve le nom du fichier est défini. Votre contenu de pièce jointe sera très certainement bien plus complexe, mais cet exemple essaie de rester simple.
Modèle Stocké
Une fois que vous avez un email RFC 5322 valide, stockez-le en utilisant le formulaire email_rfc822 du point de terminaison de modèle au lieu d'utiliser les champs texte et HTML. Voici à quoi ressemble le contenu de ce message :
Lorsque la demande est complétée, SparkPost répondra avec un identifiant unique pour votre nouveau modèle. Par exemple xxxxxxx.
Envoyer le Modèle
La bonne nouvelle est que créer le contenu RFC 5322 était la partie la plus difficile. À partir de maintenant, envoyer ce modèle avec SparkPost est exactement le même que pour n'importe quel autre modèle.
Voici comment nous envoyons ce modèle et peuplons les données de substitution :
Modèles à partir de l'API d'un Client de Messagerie
Si vous utilisez un langage de programmation qui dispose d'une bibliothèque pour composer un email, vous pouvez l'utiliser pour créer le modèle ou même envoyer le message en ligne. Ici se trouve un exemple d'utilisation de JavaMail pour faire cela via le point de terminaison de transmission de SparkPost. Cette méthode devrait être facilement traduite en PHP ou dans votre langage de prédilection.
Conclusion
Maintenant que vous voyez comment SparkPost peut être utilisé pour envoyer des emails de presque n'importe quelle complexité, vous voudrez peut-être jeter un œil à « SparkPost Supports Sending Email on Apple Watch » ou examiner la syntaxe de substitution pour voir comment elle peut être utilisée avec « if then else », « expressions in conditionals » ou « array Iteration » directement dans votre contenu de modèle ou de transmission.