# BC Scheduling

De nombreux processus et événements dans les différents BCs de la plateforme Mojaloop Switch nécessitent une fonctionnalité permettant de déclencher des actions à des moments précis ou selon un calendrier défini. Afin de prendre en charge ce besoin de manière centralisée et d’éviter d’implémenter cette fonctionnalité dans chaque BC, un seul BC dédié à la planification sera introduit et mis en œuvre sur la plateforme Switch.

Pour planifier un processus ou un événement, un BC Client soumet une demande au Scheduling BC pour créer un rappel destiné à être déclenché à un horaire précis ou selon une récurrence. Le Scheduling BC maintient un registre de tous les rappels reçus et, lorsque le moment fixé arrive, il envoie une notification du rappel au BC Client concerné.

De plus, le Scheduling BC fournira également des services au Switch pour permettre aux BC Clients et aux administrateurs du Switch de gérer les rappels.

# Termes

Le(s) terme(s) suivant(s) sont utilisés dans ce BC :

Terme	Description
BC Client	Tout autre BC utilisant les services du Scheduling BC

# Cas d’Utilisation

L’état des cas d’utilisation (UC) pour le Scheduling BC est le suivant :

UCs Disponibles			UCs Prévus
Cas d'utilisation	Description		Cas d'utilisation	Description
Créer un rappel	Le BC Client demande la création d’un rappel		Requête de rappel du client	Le BC Client interroge ses propres rappels
Supprimer un rappel	Le BC Client demande la suppression d’un rappel		Requête de rappel de l’administrateur	L’administrateur de la plateforme interroge tous les rappels
Déclenchement du rappel	Le Scheduling BC exécute le déclenchement du rappel lorsque le moment est venu
Mettre à jour un rappel	Non fourni. Solution recommandée : supprimer et créer un nouveau Rappel

# Créer un rappel

# Description

Ce flux permet au Switch de traiter les demandes autorisées des BC Clients pour créer des rappels.

# Diagramme de flux

# Déclenchement du rappel

# Description

Ce flux permet au Switch de traiter les rappels envoyés du Scheduling BC à un BC Client pour exécuter une tâche, ou simplement comme rappel.

# Diagramme de flux

# Suppression d’un rappel (récurrent)

# Description

Ce flux permet au Switch de gérer les messages des BC Clients autorisés au Scheduling BC pour supprimer un Rappel. Si le Scheduling BC ne parvient pas à traiter l’instruction, il envoie un message d’alerte au Notifications BC.

# Diagramme de flux

# Notes

# Créer un Rappel – Données requises

La demande de Création de Rappel doit inclure les données suivantes :

Donnée	Description
Identifiant	nom/id
Définition Cron	récurrent ?, intervalle de temps ?
Transport de Déclenchement	Callback HTTP/Événement ; URL de Callback ou Sujet d'Événement
Payload Spécial	opaque pour le Scheduling BC
Conditions de récupération	nouvelle tentative, replanification, abandon, abandon
Alertes	notification, journalisation en cas d’exception
Actions	registre des processus BC automatisables/planifiables

# BC Scheduling – Exigences

Le Scheduling BC doit répondre aux exigences suivantes :

• Les rappels ne doivent être déclenchés qu’une seule fois

• Le BC doit conserver l’historique des Rappels déclenchés

• Le BC doit garder l’historique des actions de Création/Lecture/Suppression

  • Les mises à jour seront facilitées via les actions Suppression/Création, comme indiqué dans la liste des UCs disponibles

• Lots de tâches (Job batches)

• Offrir plusieurs options d’interface (gRPC, REST, HTTP, etc.)

• Les rappels doivent être déclenchés avec un callback HTTP, pas un appel gRPC, ou vers un sujet spécifique

• Il ne doit pas avoir la capacité de traiter de la logique externe au Scheduling BC lui-même

• Utiliser exclusivement les horodatages UTC basés sur Linux pour éviter les problèmes de synchronisation

Remarque : Il est supposé que le système sous-jacent maintiendra une heure parfaite.

# BC Scheduling – Exigences en suspens

Les exigences d’accès pour le Scheduling BC restent à définir.

# BC Scheduling – Exceptions

• Instructions malformées
  • Date/heure invalide, y compris des heures dans le passé
  • BC ou commande invalide
• Échec d’exécution (identifié via le callback)
• Autorité insuffisante du BC Client pour réaliser l’opération CRD
• Échec du traitement/exécution du Rappel

# Questions

Certaines questions sont apparues lors des sessions d’architecture de référence. Jugées utiles pour le plus grand nombre, elles sont incluses ci-dessous :

• Après que la tâche planifiée a été initiée, le Scheduling BC reste-t-il responsable du suivi de sa progression ?

  • Réponse : Non. Lorsque le rappel est dû, il est communiqué au BC Client selon la méthode prévue, et la responsabilité du rappel est alors transférée au BC Client.

• Est-ce le BC Client ou la personne qui a planifié le Rappel qui est noté comme « Utilisateur » par le Scheduling BC ? En d’autres termes, quel ID est inscrit dans la piste d’audit (audit trail) ?

  • Réponse : Cela doit être déterminé par le BC Client, selon l’action qu’il entreprend à la réception du rappel.