Générer des événements récurrents avec Telerik Blazor Scheduler

L’interface utilisateur de Telerik pour Blazor Scheduler vous permet à la fois de générer et de gérer des événements futurs et récurrents. Apprenez comment.

J’ai regardé l’interface utilisateur de Progress Telerik pour Planificateur Blazor d’un Point de vue de l’interface utilisateur dans les colonnes précédentes, mais cette fois, je vais considérer Scheduler comme un outil de planification.

Dans le cadre de mon étude de cas, supposons que votre entreprise propose un service d’abonnement que les clients peuvent payer selon un calendrier hebdomadaire ou annuel. Le planificateur fournira non seulement l’interface utilisateur dont vous avez besoin pour gérer ce plan de facturation, mais prendra également en charge la génération d’une liste des dates de paiement futures qui vous permettront de garder vos clients sur la bonne voie (par exemple, l’envoi de rappels sur les paiements à venir et d’avis de suivi pour les paiements manqués). Le planificateur vous permettra même de sauter des dates dans le futur (« congés de paiement ») si vous souhaitez donner à votre client une certaine flexibilité dans l’exécution des paiements programmés.

Configuration du planificateur

Je ne répéterai pas le processus de configuration de votre projet depuis mon message précédent et allez directement à l’installation du planificateur sur une page. Pour cette étude de cas, une page très simple permettant d’afficher le calendrier de facturation d’un client sur une base mensuelle fera l’affaire et ressemblerait à ceci :

@using Telerik.Blazor.Components.Scheduler
@using Telerik.Recurrence

<PageTitle>Schedule Management</PageTitle>

<h1>Schedule Management</h1>
<TelerikScheduler Height="600px"
                                       Data="@BillingPlans">
    <SchedulerViews>
        <SchedulerMonthView />
    </SchedulerViews>
</TelerikScheduler> 

Lors de la configuration de mon planificateur, il me suffit de définir les paramètres du planificateur. Data propriété pour pointer vers une collection d’objets qui représentent les plans de facturation des clients (vous pouvez faire beaucoup plus avec l’interface utilisateur de Scheduler, comme je l’ai montré dans mes articles précédents, mais c’est tout ce qui est nécessaire pour cette étude de cas).

Création de la classe du plan de facturation

Pour conserver les informations sur le forfait de facturation du client, vous devrez décider des informations dont votre organisation a besoin dans un forfait de facturation. Ci-dessous, j’ai supposé que cela signifiait certaines propriétés GUID pour identifier le calendrier et le plan de facturation qui indiquent à Account Receivable combien facturer au client, ainsi qu’une propriété de chaîne pour identifier le client :

public class BillingPlan
{
  public Guid ScheduleId {get; set;}
  public string CustId [get; set; }
  public string PlanName {get; set; } = string.Empty;

Ensuite, vous devrez ajouter les propriétés dont le planificateur a besoin. Voici l’ensemble de base :

   public DateTime Start { get; set; }
   public DateTime End { get; set; }
   Public string Title {get; set;} = string.Empty;
   public bool IsAllDay {get; set;}
   public Guid RecurrenceId { get; set; }
   public IList<DateTime> RecurrenceExceptions = new List<DateTime>();
   public string RFC5545Rule { get; set; } = string.Empty;
}

Certaines propriétés sont faciles à expliquer pour moi : Start et End les propriétés conservent la date du premier paiement du client. Le planificateur utilise le Title propriété dans son interface utilisateur lors de l’affichage des événements planifiés. Le IsAllDay la propriété n’est pas requise pour cette étude de cas mais, si vous l’omettez, le planificateur s’en plaindra.

Les autres propriétés sont… moins évidentes. Vous verrez comment les utiliser dans la suite de cet article.

Affichage du planning

Je vais commencer par le RFC5545Rule property : c’est ici que vous spécifierez votre emploi du temps dans un format (principalement) lisible par l’homme. Vous devez indiquer au TelerikScheduler que votre RFC5545Rule La propriété contient votre emploi du temps afin que le planificateur puisse générer des dates futures. Pour ce faire, définissez le paramètre du planificateur RecurrenceRuleField au nom de votre propriété de planification :

<TelerikScheduler Height="600px"
                                       Data="@BillingPlans"
                                       RecurrenceRuleField="RFC5545Rule">
    <SchedulerViews>
       …

Avec cette classe définie, je peux ajouter le code pour créer le BillingPlans collection que mon planificateur utilise dans son Data propriété:

@code {
    IList<BillingPlan> BillingPlans = new List<BillingPlan>();

En plus de la planification dans la RFC5545Rule de l’objet BillingPlan, le planificateur utilise également la règle RFC5545 de l’objet BillingPlan. Start et End propriétés, qui doivent contenir les dates de début et de fin du premier paiement. Le Start et End les dates doivent être différentes car l’interface utilisateur du planificateur n’affichera pas un événement qui n’a pas de durée (pour d’autres types d’événements récurrents, vous pouvez inclure une véritable heure de début et de fin).

Pour un client dont le premier paiement a lieu aujourd’hui et va payer chaque semaine, un plan de facturation initial qui générera un calendrier de 52 paiements hebdomadaires ressemblerait à ceci :

BillingPlan bp = new();

bp.Id = Guid.NewGuid();
bp.CustId = cust.CustomerId;
bp.Title = "Billing for " & cust.CustomerId.ToString();
bp.PlanName = "Weekly"; 

bp.Start = DateTime.Now;
bp.End = DateTime.AddSeconds(1);
bp.RFC5545Rule = "FREQ=WEEKLY;COUNT=52";

Une fois le BillingPlan entièrement configuré, ajoutez-le simplement à la collection BillingPlans qui oblige le planificateur à ajouter tous les paiements futurs à son interface utilisateur :

BillingPlans.Add(bp);        

Avec cette structure, si le client achète plusieurs services chez vous, vous pouvez ajouter des plans de facturation supplémentaires à la collection BillingPlans. Vous pouvez également ajouter des plans de facturation pour différents clients à la collection BillingPlans pour avoir une idée de ce à quoi ressemblera votre flux de trésorerie provenant de n’importe quel ensemble de clients.

Et si cette règle de planification au format RFC5545 vous semble intimidante, ne pas paniquer! C’est en fait raisonnablement sympathique et assez flexible. Par exemple, si le client souhaite payer annuellement, vous pouvez utiliser cette spécification pour générer un échéancier de paiement qui s’étend d’aujourd’hui jusqu’au début de 2028 :

bp.RFC5545Rule = "FREQ=YEARLY;UNTIL=2028-1-1T00:00:00.000Z";

Générer des dates futures

Vous souhaiterez bien sûr stocker ces BillingPlans dans votre base de données. De plus, vous devrez probablement également stocker une liste de ces futures dates de paiement, afin que d’autres applications puissent envoyer des rappels à vos clients lorsque les paiements arrivent à échéance (et envoyer des e-mails de menace lorsque des paiements sont manqués).

Pour générer cette liste de dates de paiement à partir de votre BillingPlan, vous devez créer un RecurrenceRule objet et chargez-le avec votre emploi du temps. Le RecurrenceRule la classe est statique Parse la méthode vous permettra de le faire. Appeler les RecurrenceRules ExpandRecurrence vous remettra ensuite une liste de dates en fonction de ce planning, à condition que vous réussissiez le ExpandRecurrence méthode un RecurrenceOptions objet.

Que RecurrenceOptions l’objet indique à la RecurrenceRule ExpandRecurrence méthode combien de travail à faire – vous ne voulez pas générer un ensemble de dates qui s’étend jusqu’à la mort thermique de l’univers, par exemple. Bien que l’objet RecurrenceOptions vous offre de nombreuses options, les deux seules dont vous avez besoin sont les dates de début et de fin de la période pour laquelle vous souhaitez générer des dates planifiées, à l’aide de l’objet RecurenceOptions. StartDate et RangeEnd propriétés.

Le code suivant crée un RecurrenceRule objet et le charge à partir du BillingPlan RFC5545Rule propriété. Le code crée alors un RecurrenceOptions objet, définition du StartDate et RangeEnd propriétés (encore une fois, du BillingPlan objet).

Avec tout créé et chargé, vous passez simplement le RecurrenceOptions s’opposer à la ExpandRecurrence méthode du RecurrenceRule objet pour obtenir une collection de Occurrence objets qui représentent les facturations futures :

RecurrenceRule rr = new();
rr = RecurrenceRule.Parse(bp.RFC5545Rule);

RecurrenceOptions ro = new RecurrenceOptions();
ro.StartDate = bp.Start;
ro.RangeEnd = bp.Start.AddMonths(12);

IEnumerable<Occurrence> FuturePayments =  rr. ExpandRecurrence (ro);

Chaque Occurrence l’objet a Start et End propriétés détenant les dates d’un paiement programmé. Vous pouvez les combiner Occurrence propriétés avec les données d’autres objets de votre application pour créer, par exemple, un ScheduledPayment objet que vous pourriez stocker dans votre base de données.

Cet exemple rassemble les données du plan de facturation et des occurrences pour créer ScheduledPayment objets qu’il ajoute à une base de données :

foreach(Occurrence fp in FuturePayments)
{
   ScheduledPayment sp = new ScheduledPayment {
             BillingPlanId = bp.ScheduleId,
             DueDate = fp.Start
   }
  dbContext.Add(sp);
}

Ignorer les événements programmés

Bien entendu, il n’est pas impossible que notre client doive occasionnellement sauter un paiement. Il est simple de prendre en charge cela dans le planificateur : ajoutez simplement les dates que vous souhaitez supprimer du calendrier dans le plan de facturation. RecurrenceExceptions propriété.

L’exemple suivant permet à notre client de se libérer des paiements dans sept et 14 jours (vous pouvez ajouter toutes les dates que vous souhaitez, à condition de vous assurer qu’elles correspondent exactement à l’une de vos dates programmées) :

bp.RecurrenceExceptions.Add( bp.Start.AddDays(7)  );
bp.ReccurenceExceptions.Add( bp.Start.AddDays(14) );

Et ces dates disparaissent de l’interface utilisateur de Scheduler :

Sauter ces dates lors de la génération de la liste des occurrences à stocker dans votre base de données est encore plus simple, grâce à l’option RecurrenceOptions object : définissez simplement l’objet RecurrenceOptions de votre objet ExceptionDates propriété à votre BillingPlan RecurrenceExceptions propriété avant d’appeler le ExpandRecurrence méthode. C’est ce que fait ce code :

RecurrenceOptions ro = new RecurrenceOptions();
ro.StartDate = bp.Start;
ro.RangeEnd = bp.Start.AddMonths(12);
ro.ExceptionDates = bp.RecurrenceExceptions;

IEnumerable<Occurrence> FuturePayments =  bp.ExpandRecurrence(ro);

Cependant, conserver cette liste de dates d’exception peut s’avérer délicat. La bonne chose à faire est de stocker les dates d’exception dans un tableau séparé afin qu’elles puissent être utilisées par d’autres applications. Si ce n’est pas nécessaire, vous pouvez convertir le RecurrenceExceptions collection dans une chaîne avec chaque date séparée par un point-virgule en utilisant le code suivant, puis stockez-la dans une propriété de chaîne ajoutée à votre BillingPlan objet (ici, j’ai appelé la nouvelle propriété PaymentExceptions) :

bp.PaymentExceptions = string.Join(";", bp.RecurrenceExceptions);

Pour récupérer la chaîne d’exceptions et la reconvertir en liste, vous pouvez utiliser un code comme celui-ci :

bp.RecurrenceExceptions = bp.PaymentExceptions.Split(';').
                                                         Select(sd => DateTime.Parse(sd)).ToList();

Vous voudrez également vous assurer de mettre à jour votre échéancier de paiement d’origine dans votre base de données avec ces exceptions. Pour prendre en charge cela, l’ajout d’exceptions entraîne également le BillingPlan s’opposer à ce que son RecurrenceId propriété définie sur un GUID. Vous souhaiterez utiliser ce GUID pour lier les exceptions au BillingPlan cela les anime.

Vous disposez désormais d’une interface utilisateur pour gérer les événements futurs, d’un ensemble de dates futures à charger dans votre base de données et de la possibilité de sauter des dates dans le planning. Si votre client saute des paiements, je suppose que votre entreprise voudra ajouter un nouveau paiement au calendrier du client (en dehors de l’horaire régulier) pour compenser la différence car, après tout, chaque jour férié doit être payé.

Essayez l’interface utilisateur Telerik pour Blazor

Essayez le composant Scheduler, ainsi que plus de 110 autres composants Blazor véritablement natifs et faciles à personnaliser pour répondre à toutes les exigences. Essayer Interface utilisateur Telerik pour Blazor gratuitement avec notre essai de 30 jours et profitez de notre assistance de pointe.

Essayez maintenant