3

Je travaille pour un magasin de logiciels, qui possède un dialer prédictif interne, et nous devons implémenter une solution pour obéir aux listes DO-NOT-CALL. Fondamentalement, j'ai une base de données avec les clients/clients potentiels que j'ai besoin d'appeler, et une autre base de données avec les numéros de téléphone que je ne peux pas appeler. Comme le système est un numéroteur prédictif, basé sur les performances de l'opération, les moyennes temporelles et autres, il compose plus ou moins d'appels par utilisateur du système connecté. Habituellement, ce nombre «magique» est d'environ 3 à 4 appels par agent connecté.Quelle est la bonne solution pour un service d'autorisation à haute disponibilité?

Le référentiel de numéros de téléphone pour le numéroteur prédictif est une base de données PostgreSQL. Le numéroteur prédictif sélectionne un groupe de numéros dans la base de données et envoie une commande au PBX pour composer le paquet, puis la logique métier continue à transférer les appels valides vers les employés du centre d'appels, et ainsi de suite (ceci n'est pas pertinent le problème est avant l'appel).

J'ai besoin de mettre en œuvre la fonctionnalité de liste de numéros de téléphone exclus. Cette liste de numéros de téléphone exclus sera fournie à notre entreprise par un organisme gouvernemental, dans un fichier CSV, tous les jours. Chaque fois que je reçois un nouveau fichier CSV, je dois purger l'ancienne liste de non-appel et mettre la nouvelle en place.

Ma première pensée pour l'implémenter était de faire un traitement par lots, en croisant la LISTE DE NE PAS APPELER avec ma base de données client actuelle. Mais je pense que, selon la taille des deux bases de données, les références croisées seraient très axées sur la performance et, parfois, ne pourraient pas être terminées du jour au lendemain. J'ai eu ce genre de problèmes avec le traitement par lots avant, et ce n'est pas une bonne chose à voir. Ma seconde idée est née lorsque j'ai réfléchi à la façon dont les grandes institutions gèrent les systèmes d'autorisation haute performance et à haut débit, comme les cartes de crédit ou l'authentification/autorisation des utilisateurs. Je pensais que créer un service d'authentification pour les numéros DO NOT CALL LIST, et changer l'algorithme de mon dialer prédictif pour vérifier chaque numéro par rapport à ce service d'autorisation avant de composer serait soigné. Comme je ne fais que la confabulation ici, je n'ai aucune idée de quelle idée est la meilleure, ou si je l'ai eu totalement faux et devrait regarder dans une autre direction. Ma question est la suivante: quelle serait votre recommandation? Stockez le fichier CSN DO NOT CALL en mémoire? utiliser LDAP? utiliser MySQL? PostgreSQL? Faire la chose de traitement par lots? Ou suis-je vraiment foutu? Je sais que je ne suis pas la première personne au monde à avoir ce genre de problème, alors s'il vous plaît éclairez-moi.

Répondre

2

Votre défi, de trouver un certain nombre d'entrées à partir d'un vaste espace d'entrées possibles, me rappelle DNS black/block lists.

rbldnsd est un petit et rapide démon DNS qui est spécialement conçu pour servir zones DNSBL. Ce démon était inspiré du programme rbldns de Dan J. Bernstein trouvé dans le paquetage djbdns. More rbldnsd, from Google

Il a un support pour les zones basées sur le nom, vous pouvez donc convertir la liste des numéros à URIs style ENUM - par exemple + 1-555-4242 devient 2.4.2.4.5.5.5.1.e164.arpa. Ceci est ensuite entré dans le fichier de données rbldnsd, compilé en mémoire et accédé comme n'importe quelle autre liste de blocage. Une entrée par défaut signifie can-call, ou si l'entrée existe, elle recevrait une entrée DoNotCall.

Vous avez toujours le problème de conversion par lots, bien que ce soit un script un peu plus simple, tout à fait possible avec Perl ou AWK.Vous pouvez également diviser les fichiers CSV entrants en plusieurs fichiers pour un traitement en parallèle et une fusion finale.

Questions connexes