Journaux asynchrones REDA
Les traitements REDA en arrière-plan — facturation nocturne, régularisation des charges, instantanés et formulaires web qui alimentent vos demandes — s’exécutent sans surveillance constante. Le journal asynchrone REDA conserve les informations que ces traitements enregistrent. Lorsqu’une erreur y est consignée, une notification peut vous parvenir directement par e-mail, selon les destinataires configurés, sans attendre l’appel d’un locataire. Cet article explique comment lire un journal, consulter son fichier d’erreurs, trier les incidents, comprendre les notifications et consigner une résolution. Aucune expérience préalable de REDA n’est nécessaire.
Autorisations nécessaires. La consultation est fournie par REDA - Master Data - Read Only, REDA - Expense Reconciliation Admin ou REDA - Inflation Adjustment User ; l’accès à l’onglet est aussi accordé par REDA - Property Leasing User. Les administrateurs utilisent REDA - Master Data - Admin. REDA crée les journaux pendant ses traitements ; vous ne les saisissez pas manuellement.
Quels traitements créent un journal ?
Les processus REDA créent automatiquement leurs journaux lorsqu’ils ont des informations à signaler. Vous ne planifiez pas les journaux et n’avez pas à les activer séparément. Les traitements concernés comprennent :
- La régularisation des charges : si un calcul rencontre un enregistrement qu’il ne peut pas traiter, il crée un journal lié au lot. Une exécution entièrement réussie se termine sans en créer.
- Les instantanés de régularisation : ils consignent les échecs partiels, par exemple lorsqu’un bien n’a pas de loyer de marché configuré.
- Les formulaires web entrants : une soumission dont le traitement échoue crée un journal contenant les données consignées et la cause de l’échec, afin de retrouver les demandes non créées.
- Les lots de facturation nocturne : frais récurrents, pénalités de retard, frais de prolongation mensuelle, indexations et autres traitements déclenchent une notification d’erreur lorsqu’ils consignent un incident au niveau des enregistrements.
- La détection des automatisations retirées : si votre organisation appelle encore un ancien processus retiré de REDA, un journal permet à l’administrateur de repérer et supprimer cet appel.
- Le routage des e-mails entrants : sur Platform, la suite e-mail consigne ici les erreurs prises en charge et les avertissements de configuration, afin de retrouver les problèmes de routage ou d’analyse dans la même file. Le champ Classe de lot contient
REDA_EmailInboundHandleret, exceptionnellement, le Type de processus est Futur.
Lire une fiche de journal
Une fiche décrit une exécution : processus, dates, nombre d’enregistrements traités et résultats. Le tableau présente chaque champ. Lorsque les libellés diffèrent, la variante Sales Cloud est indiquée après celle de Platform.
| Champ | Signification |
|---|---|
| Classe de lot / Classe par lots | Processus REDA à l’origine du journal. Dans les explications, nous utilisons une désignation courante, par exemple « traitement nocturne des frais récurrents ». |
| Type de processus | Mode d’exécution : Lot ou Futur sur Platform, Avenir sur Sales Cloud. Il s’agit généralement d’un lot. |
| ID du processus | Identifiant Salesforce de l’exécution. L’administrateur peut le rechercher dans Configuration pour approfondir l’analyse. |
| Date et heure de début / Date et heure de fin | Période d’exécution. La différence entre ces valeurs donne la durée ; aucun champ de durée distinct n’est prévu. |
| Total des enregistrements / Enregistrements réussis / Enregistrements échoués | Nombre d’enregistrements tentés, réussis et en échec. Sur Sales Cloud, les libellés sont Enregistrements totaux, Records de succès et Résultats des échecs. |
| Total des tâches de lot / Tâches de lot traitées / Erreurs de lot | Statistiques Salesforce des blocs traités. Sur Sales Cloud : Nombre total de tâches par lot, Traitement par lots et Erreurs par lots. Une valeur Erreurs de lot supérieure à zéro signale un échec au niveau du traitement par lots, même sans échec individuel consigné. |
| Attention requise | Indicateur calculé, activé lorsque le nombre d’erreurs de lot ou d’enregistrements échoués est supérieur à zéro. Il sert au tri des incidents décrit ci-dessous. |
| Détails supplémentaires | Jusqu’à 10 000 caractères de détails : texte de l’erreur et données consignées pour une soumission de formulaire en échec. Cette limite ne garantit pas la conservation intégrale d’une soumission volumineuse. |
| Référence | Texte libre défini par le traitement pour préciser son contexte. |
| Date et heure de résolution | Champ destiné à votre intervention. Renseignez-le après avoir traité le problème pour consigner sa résolution. |
| Notifier l'utilisateur actuel | Indique si l’utilisateur qui a lancé le traitement doit également recevoir l’e-mail. Le processus renseigne ce choix. |
| Sobject automat. obsolète | Désigne l’enregistrement concerné par une automatisation retirée. Sur Sales Cloud : Objet S d'automatisation obsolète. Ce cas rare demande de supprimer l’appel à l’ancien processus. |
| Lot de rappr. des dépenses / Règle d'inflation | Lien vers l’enregistrement à l’origine du traitement, pour le consulter et relancer l’exécution. Sur Sales Cloud : Lot de rapprochement des dépenses / règle d'inflation. |
Le fichier d’erreurs
Les compteurs indiquent combien d’enregistrements ont échoué ; le fichier joint précise lesquels. Lorsqu’un traitement utilise le journaliseur de lots avec des lignes d’erreur, REDA joint un CSV nommé à partir de l’identifiant du journal, avec le suffixe -error.csv. Chaque ligne contient une référence, le message, le numéro de ligne et la cause technique. Un traitement sans ligne d’erreur ne joint pas ce fichier ; certains journaux, notamment les soumissions web, détaillent directement l’erreur dans la fiche.
Ouvrez les Pièces jointes du journal, puis le fichier CSV associé à son identifiant, s’il existe. Vous pouvez ainsi passer de « Enregistrements échoués : 1 » à « le pourcentage de répartition manque sur l’unité n° 101 ».
Trier les incidents dans une vue de liste
La vue de liste sert au suivi quotidien. Filtrez Attention requise pour ne conserver que les lignes où Attention requise vaut vrai et Date et heure de résolution est vide. Vous obtenez la file des problèmes non résolus ; toute ligne qui y reste nécessite une intervention.
Ces deux champs se complètent : Attention requise signale une exécution en erreur, et Date et heure de résolution la retire de la file après traitement. Ces colonnes permettent de suivre ce parcours.
Qui reçoit les notifications ?
Deux canaux de notification distincts peuvent vous informer sans consulter l’onglet :
- L’e-mail de suivi administratif. À la création d’un journal répondant aux critères d’erreur, REDA envoie son lien aux utilisateurs actifs dont la case Réception d'une notification d'erreur as est cochée sur la fiche utilisateur. Cette option ne concerne donc pas automatiquement tous les administrateurs. Si personne ne reçoit d’alerte, vérifiez ce réglage. Un e-mail à 1 h peut simplement correspondre à un traitement nocturne et à cette inscription aux alertes. Si le processus le demande, son lanceur reçoit aussi une copie.
- La notification de régularisation. À la fin d’un calcul de régularisation des charges, REDA envoie également une notification sous la cloche, sur ordinateur et mobile, à la personne qui l’a lancé. Le lien ouvre le lot. Cette notification de fin de traitement s’applique à la régularisation, que l’exécution réussisse ou échoue.
Distinguez ces deux usages : l’e-mail signale les erreurs consignées par les différents moteurs ; la cloche confirme à l’utilisateur la fin d’un calcul de régularisation.
Résoudre un problème
Le parcours est toujours le même : lire, trouver la cause, corriger, relancer et consigner la résolution.
Identifier le traitement à l’origine du journal
À l’arrivée d’un journal, commencez par identifier ce qui l’a créé. Ce tableau relie les principales sources aux incidents courants.
| Source du journal | Quand le journal est créé | Cause courante du signalement |
|---|---|---|
| Calcul de régularisation des charges | En fin d’exécution lorsqu’au moins un enregistrement n’a pas pu être traité | Pourcentage de répartition manquant ou périmètre de données incorrect |
| Instantané de régularisation | Lors d’un échec partiel | Bien sans loyer de marché ou configuration de loyer |
| Réception d’un formulaire web | Une ligne par soumission dont le traitement échoue | Valeur incorrecte ou correspondance de champs inadéquate |
| Lots de facturation nocturne | Lors d’un incident au niveau des enregistrements | Erreur de validation pendant la création d’une facture |
| Détection d’une automatisation retirée | Lorsqu’un ancien processus retiré est appelé | Votre organisation appelle encore un processus que REDA a retiré |
Exemple : une unité non traitée par une régularisation
Meridian Properties lance une régularisation des charges sur 12 unités d’un immeuble. Le pourcentage de répartition d’une unité manque et l’exécution se termine avec une erreur. Le lendemain matin, les destinataires inscrits aux alertes disposent d’un e-mail contenant le lien du journal.
| Ce que vous voyez | Signification |
|---|---|
| Total : 12 / Réussites : 11 / Échecs : 1 | Onze unités traitées, une en échec |
| Attention requise = vrai | L’exécution a rencontré un échec et apparaît dans la file des incidents |
| Pièce jointe : fichier d’erreurs | Le fichier identifie l’unité concernée et son pourcentage de répartition manquant |
| Lien vers le lot de régularisation | Ouvre directement le traitement à l’origine de l’erreur |
L’administrateur renseigne le pourcentage manquant, ouvre le lot lié et relance le calcul. Les 12 unités sont alors traitées avec succès, sans nouveau journal d’erreur pour ce calcul de régularisation. Il revient sur le journal initial et renseigne Date et heure de résolution : la file des incidents est à nouveau vide.
Pour aller plus loin
- Planifier les traitements en arrière-plan : les exécutions que vous surveillez ici.
- Exécuter une régularisation des charges : l’un des traitements à l’origine des journaux.
- Le service de données entrantes : la réception des soumissions web pouvant échouer.
- Indexations : le parcours de traitement des erreurs propre à l’indexation.
- La console d’administration REDA : l’espace de pilotage voisin de cet onglet.
Questions fréquentes
Un nouveau journal répondant aux critères d’erreur a été créé. REDA envoie son lien aux utilisateurs actifs dont l’option Réception d'une notification d'erreur as est cochée. Ouvrez le journal et son éventuel fichier d’erreurs pour comprendre le problème.
Ouvrez les Pièces jointes du journal. Lorsqu’un CSV associé à son identifiant est présent, chaque ligne décrit un échec avec son message et son emplacement. Consultez aussi Détails supplémentaires, notamment pour les formulaires web.
Les processus REDA créent les journaux. Le champ destiné à votre intervention est Date et heure de résolution : renseignez-le lorsque vous avez traité le problème.
Le service de données consigne les soumissions dont le traitement échoue et leur cause dans Détails supplémentaires. Consultez les données enregistrées, corrigez la soumission et renvoyez-la. La capacité de ce champ est limitée à 10 000 caractères ; elle ne garantit pas une copie intégrale de toute soumission.
L’indicateur dépend des compteurs d’erreurs de l’exécution d’origine ; la correction de la cause ne les efface pas. Renseignez Date et heure de résolution pour retirer ce journal de la file des incidents non résolus.
Cet article vous a-t-il été utile ?