Comment une Carte est rendue

Comprenez quand The Wallet Crew rend une Carte, quelles données sont utilisées et comment se comportent les échecs de rendu.

Comment une carte est rendue

Lorsque The Wallet Crew livre une carte à Apple Wallet ou Google Wallet, il construit l’artefact Wallet à partir de trois entrées : l’enregistrement de la carte, le modèle de la carte et les données récupérées depuis les systèmes connectés. Cette page explique quand le rendu est déclenché, comment le pipeline s’exécute et ce qui se passe en cas d’échec.

Exemples concrets

• Un solde de fidélité change dans le CRM, mais la carte installée ne change qu’après une mise à jour push ou un nouveau rendu.
• Un délai d’attente du connecteur empêche une mise à jour de billet d’atteindre Apple Wallet alors même que le système source a déjà la nouvelle porte.
• Un chemin de modèle est incorrect, donc la carte est livrée avec un champ vide au lieu d’échouer complètement.

Lorsque le rendu est déclenché

La plateforme rend une carte dans quatre cas.

1. Ajouter à Wallet — un client appuie sur un bouton d’ajout et The Wallet Crew génère le fichier Apple .pkpass ou crée ou met à jour l’objet Google Wallet.
2. Mise à jour push — une mise à jour est déclenchée via un appel API ou un connecteur, la plateforme reconstruit la carte, puis avertit Apple via APNs ou Google via l’API Google Wallet.
3. Aperçu — un aperçu est demandé depuis le back-office ou depuis le point de terminaison de l’API d’aperçu.
4. API de rendu du modèle — l’API de rendu est appelée explicitement avec un modèle et un contexte de données.

Le rendu n’est pas continu. La plateforme n’interroge pas les sources et ne reconstruit pas les cartes selon un calendrier. Une carte reflète l’état des données au moment où le dernier rendu a été déclenché.

Le pipeline de rendu

Le pipeline de rendu suit une séquence fixe.

1. Charger l’enregistrement de la carte — The Wallet Crew récupère l’enregistrement de la carte depuis la base de données, y compris ses identifiants externes, ses métadonnées et ses données supplémentaires.
2. Charger le modèle de la carte — le modèle YAML du type de carte est chargé. Il définit le mappage des champs, les expressions Liquid, la configuration du code-barres, les images et les fournisseurs de données à appeler.
3. Récupérer les données du fournisseur — tous les fournisseurs de données configurés sont appelés en parallèle. Chaque fournisseur utilise les identifiants de la carte et renvoie des données externes qui sont fusionnées dans le contexte de rendu.
4. Appliquer les modèles Liquid — chaque champ du modèle est évalué par rapport au contexte de rendu. Cela produit les valeurs finales utilisées pour les champs du Wallet.
5. Générer l’artefact Wallet — les valeurs résolues, les images et les paramètres du code-barres sont assemblés dans le bundle Apple .pkpass ou dans la charge utile de la classe et de l’objet Google Wallet.
6. Livrer — la carte Apple signée est renvoyée à l’appelant. L’objet Google est créé ou mis à jour de serveur à serveur.

Pour les filtres et balises Liquid pris en charge dans The Wallet Crew, utilisez le moteur de templating. Pour le comportement Liquid standard au-delà des extensions personnalisées, utilisez la documentation DotLiquid.

Quelles données sont disponibles pour le modèle

Le contexte Liquid dépend du modèle de carte et des fournisseurs de données configurés. Les sources courantes sont l’enregistrement de la carte, les données supplémentaires stockées sur la carte et les sorties des fournisseurs récupérées au moment du rendu.

• Champs de l’enregistrement de la carte tels que l’ID de carte, le type de carte, la date de création et la date de mise à jour.
• Données supplémentaires stockées sur la carte.
• Sorties des fournisseurs telles que customer.firstName, loyaltyBalance, ou offerTitle.

Les données des fournisseurs sont récupérées au moment du rendu. The Wallet Crew ne met pas en cache à l’avance la sortie des fournisseurs sur l’enregistrement de la carte. Une carte rendue reflète les dernières données source disponibles lors du dernier rendu réussi.

Les métadonnées sont utilisées pour la segmentation opérationnelle et le reporting. Elles ne doivent pas être considérées comme une source d’affichage du Wallet.

Que se passe-t-il en cas d’échec ?

Fournisseur de données indisponible

Si un fournisseur de données renvoie une erreur ou dépasse le délai d’attente, tout le rendu échoue. La plateforme ne revient pas à une valeur précédente du fournisseur. L’appel de mise à jour renvoie une erreur et la carte installée n’est pas modifiée.

L’échec du fournisseur est la cause la plus courante d’une mise à jour de carte qui n’atteint pas les appareils. Si une mise à jour semble échouer silencieusement, vérifiez que les points de terminaison du fournisseur sont accessibles depuis les IP sortantes de The Wallet Crew répertoriées sur Infrastructure.

Variable Liquid manquante

Si une expression Liquid référence une variable qui n’est pas présente dans le contexte de rendu, le champ prend une valeur vide et l’erreur est consignée. La génération de la carte se poursuit. La carte peut toujours être livrée avec un champ vide.

Modèle manquant ou invalide

Si le modèle du type de carte est manquant ou contient un YAML invalide, la génération échoue avant même le début de l’appel à un fournisseur.

Historique de la carte

La plateforme enregistre un événement de cycle de vie chaque fois qu’une carte est rendue, mise à jour ou livrée. Ces événements peuvent être interrogés via l’API Insights et sont également exposés dans l’espace de supervision.

La plateforme ne stocke pas d’instantané du contenu de la carte rendue. Lorsqu’une piste d’audit des valeurs rendues est nécessaire, la source de vérité reste les systèmes amont qui ont fourni les données.

FAQ

Pourquoi un changement de source n’apparaît-il pas immédiatement sur la carte ?

La plateforme n’interroge pas les systèmes source en continu. Un déclenchement de rendu reste nécessaire avant que la carte installée ne change.

Une variable manquante fait-elle toujours échouer le rendu ?

Non. Les variables manquantes se résolvent généralement en valeurs vides. Les défaillances des fournisseurs et les modèles invalides sont plus susceptibles d’arrêter complètement le rendu.

Par où faut-il commencer le dépannage du rendu ?

Commencez par les identifiants stockés, l’état de santé du fournisseur et les chemins des champs du modèle. Ces trois domaines expliquent la plupart des défauts de rendu.