Activations recommandées

Pour limiter la croissance des données associée à l’utilisation intensive de Agent virtuel et Messagerie instantanée d'agent, activez les tâches plus propres dans la table suivante :

Quelles tables doivent être nettoyées ?

Ces tables doivent être nettoyées, car elles peuvent atteindre des millions d’enregistrements dans des instances de longue durée :

• Historique de présence de l’agent [awa_agent_presence_history]
• AWA Taille du document [awa_document_size]
• AWA Élément de travail [awa_work_item]
• Consommateur [sys_cs_consumer]
• Contexte de l’appareil de consommateur [sys_cs_consumer_device_context]
• Conversation [sys_cs_conversation]
• Interaction [interaction]
• Blob JSON d’interaction [interaction_json_blob]
• Profil de groupe actif [live_group_profile]

Il existe d’autres tables connexes, telles que les tables Message de conversation [sys_cs_message] et Message de flux en direct [live_message], qui peuvent également devenir volumineuses. Ces tables ont reference_cascade_rule_delete des attributs qui provoquent leur nettoyage en tant qu’effet secondaire du nettoyage des tables de la liste précédente.

Quels enregistrements des tables doivent être supprimés

La configuration de l’effacement automatique vous permet de sélectionner les champs Matchfield (Champ de correspondance ) et Age in seconds (Âge en secondes ). Le champ Matchfield correspond à une colonne de date dans la table et le champ Âge en secondes indique le moment où les suppressions sont déclenchées. Lorsqu’un enregistrement atteint un point où le champ Matchfield a une date plus éloignée dans le passé que le champ Age en secondes , le nettoyeur supprime l’enregistrement lors de son exécution.

Idéalement, le champ Matchfield devrait indiquer la durée d’activité de l’enregistrement. Les colonnes de la table suivante fonctionnent bien ainsi que le champ Matchfield pour les tables en question, avec la condition supplémentaire dans le champ Conditions lorsqu’elle est indiquée.

interaction.closed_at et sys_cs_conversation.conversation_completed ne sont pas de bonnes options pour le champ Matchfield , car elles n’ont pas de valeurs pour les conversations défectueuses et certaines interactions fermées. Les écarts peuvent être comblés par des règles métier qui définissent cette date si elle est vide lorsqu’un changement d’état approprié se produit, mais pour simplifier, utilisez le champ sys_updated_on pour ces tables.

D’autres tables peuvent être limitées par des conditions du champ État qui garantissent que seules les messageries instantanées fermées sont supprimées. Étant donné que les interactions ne doivent jamais être laissées ouvertes plus de quelques jours en général, ces conditions peuvent être laissées de côté pour simplifier les requêtes et les exécuter plus rapidement après la dernière mise à jour. L’état de la table awa_work_item peut être plus important, car les tâches de plus longue durée telles que les tickets sont également représentées.

Le problème avec la table sys_cs_consumer est que, bien que vous souhaitiez normalement conserver ces enregistrements pour faire correspondre les nouvelles conversations aux utilisateurs existants, dans le cas des utilisateurs invités, un enregistrement différent est créé pour chaque conversation.

Pour la table sys_cs_consumer_device_context, il y a une référence à la table Compte de consommateur CS [sys_cs_consumer_account] (qui a elle-même une référence à la table sys_cs_consumer), mais la référence n’est pas marquée avec reference_cascade_rule=delete. Il est recommandé d’ajouter cette règle à la référence du compte consommateur. De cette façon, lorsque le nettoyeur supprime les enregistrements des tables sys_cs_consumer et sys_cs_consumer_account, il les supprime également.

Les tables awa_agent_presence et awa_agent_channel_availability ne s’agrandissent pas par messagerie instantanée de la même manière que les autres tables, mais sont régulièrement consultées par le moteur d’affectation et peuvent se retrouver avec des entrées périmées d’utilisateurs qui ne sont plus actifs. Les longues entrées inutilisées doivent également être nettoyées ici. Des précautions supplémentaires doivent être prises avec la colonne awa_agent_channel_availability car elle peut ne pas être mise à jour souvent. Pour cette raison, une condition supplémentaire doit être ajoutée à ce nettoyeur afin que seuls les enregistrements associés à des utilisateurs inactifs puissent être supprimés.

Quand les enregistrements peuvent-ils être supprimés en toute sécurité ?

Plusieurs facteurs entrent en ligne de compte pour déterminer à quel moment les enregistrements peuvent être supprimés en toute sécurité :

• Ne supprimez pas les enregistrements des conversations en cours.

  Pour les conversations de messagerie instantanée basées sur une session, le seuil d’âge est de quelques jours seulement. Si les conversations par SMS/messagerie sont incluses, le seuil d’âge peut s’étendre à quelques semaines ou plus. Une façon d’évaluer cela est d’examiner toutes les propriétés du formulaire com.glide.cs.*_idle_timeout et de localiser celle ayant la valeur la plus élevée.

• Ne supprimez pas les enregistrements qui contribuent aux tableaux de bord/rapports sur l’activité récente.

  Le AWA tableau de bord Analyse avancée des interactions comprend un indicateur de tendances hebdomadaires qui permet de remonter trois mois en arrière. Pour prendre pleinement en charge cela, vous devez conserver les enregistrements des interactions et des awa_work_item pendant au moins 90 jours.

• Ne supprimez pas les enregistrements si l’une de leurs données doit être archivée pour référence ultérieure.

  Le moment de cette opération dépend du moment où toute logique personnalisée est ajoutée pour effectuer l’archivage nécessaire. Vous devriez être en mesure de le configurer de manière à ce qu’il s’exécute suffisamment tôt pour ne pas être le facteur décisif.

Considérations relatives aux performances

Des index sys_updated_on sont-ils nécessaires pour les tables qui en sont dépourvues ?

Les tests ont été exécutés sur une instance qui avait 12 000 000+ interactions, avec un nettoyage de table configuré pour une table ayant un index sur sys_updated_on champ (interaction) et une autre qui n’en a pas (interaction_json_blob). Dans les deux cas, pour les exécutions initiales et ultérieures, le temps passé à effectuer des suppressions (potentiellement plusieurs minutes) l’emportait largement sur le temps passé à interroger les enregistrements (2 secondes ou moins). Compte tenu de ce résultat, il n’est pas nécessaire d’ajouter des indices supplémentaires aux tables, car l’impact sur la performance serait minime.

À quel moment la tâche initiale et répétée de nettoyeur de table doit-elle s’exécuter ?

Normalement, le nettoyeur de table fonctionne sys_trigger une fois par heure. Si un ou plusieurs nettoyeurs sont définis sur des tables comportant de nombreux enregistrements obsolètes, le nombre de suppressions effectuées au cours de cette première exécution peut être très élevé et imposer une charge supplémentaire au système. Avant d’ajuster et d’activer la configuration de nettoyage de table, modifiez temporairement ce programme de nettoyage de table afin que sa prochaine exécution se produise en dehors des heures de travail (heure à laquelle le système est généralement moins chargé).

S’il n’y a pas d’heures non travaillées, certaines propriétés régissant les nettoyeurs de table peuvent aider. En particulier, glide.db.tablecleaner.chunk_delete_max_time_spent limite la durée pendant laquelle le nettoyeur essaie de supprimer des enregistrements par lots au cours d’une seule exécution. La valeur est donnée en secondes et est définie par défaut sur 1200 (20 minutes). Cela signifie que dans la configuration du système de base, le nettoyeur de tables s’exécute toutes les heures pendant un maximum de 20 minutes (à titre de référence, au cours d’un test, environ 400 000 interactions pourraient être supprimées en 20 minutes, y compris les suppressions en cascade). Si 20 minutes toutes les heures sont trop agressives, la valeur de la propriété peut être réduite.