La fonctionnalité de flux de travail du module d'exécution des commandes permet de créer les types de tâches suivants :

• Installer
• Terminer
• Incident de connexion
• Incident de réseau
• Telco Migrate
• Migration des ports
• Installation ONT

InTask et OutTask

Gridsz utilise les termes InTask et OutTask pour distinguer les tâches entrantes et sortantes.

Une InTask est une commande créée par l'opérateur actif. Cet ordre est transmis via l'API et le portail GRIDSZ à un contractant. En fonction du type d'InTask créé, la tâche sera assignée à la partie désignée par l'opérateur passif pour exécuter le travail. Une InTask peut être assortie d'un accord de niveau de service (SLA) visible sur l'interface graphique. Chaque InTask possède un numéro DHID, un identifiant de connexion et un code de recherche identiques. Ces numéros d'identification identiques sont équivalents pour l'InTask et l'OutTask.

Une OutTask est un ensemble de tâches créé par Gridsz sur la base d'une commande InTask reçue par l'opérateur actif. La OutTask apparaîtra dans le portail et l'API de la partie destinataire. Chaque OutTask contient les détails nécessaires à l'entrepreneur pour exécuter le travail et montre les métadonnées de la commande, comme le statut des tâches incluses, le statut SLA, la date de création et de dernière mise à jour, la priorité et les coordonnées du client le cas échéant.

Installer

L'ensemble de tâches d'installation contient toujours une tâche standard de Patch_Install pour le PoP, et éventuellement une FTU_Construct ou FTU_Reconstruct pour au domicile de l'utilisateur final.

Le type de FTU à placer est un texte libre qui est directement spécifié par l'opérateur. Gridsz suppose que l'entrepreneur connaît les types d'UFP qui peuvent être demandés.

Dans certaines situations, il existe déjà une FTU au domicile de l'utilisateur final, dans laquelle seule une tâche d'installation de correctifs sera attribuée au contractant. Il est également possible que la FTU fournie par l'opérateur actif soit différente de la FTU actuelle au domicile de l'utilisateur final, dans laquelle une tâche FTU_Reconstruct sera assignée au contractant.

Pour l'installation d'une connexion, un patch est toujours nécessaire. L'entrepreneur est invité à placer un patch entre le point d'extrémité passif spécifié et le point d'extrémité actif spécifié. Dans ce cas, le point d'extrémité passif est rempli par Gridsz, tandis que l'opérateur actif fournira le point d'extrémité actif.

Selon le type de PoP, l'équipement actif peut être un port sur l'équipement actif ou un port sur un panneau de brassage.

Terminer

Une TaskSet Terminate ne peut être créée que sur des adresses qui ont déjà été livrées avec succès via une TaskSet Install. Ainsi, si un opérateur actif crée un ordre d'interruption sur une adresse qui n'est pas connectée, l'ordre d'interruption sera refusé.

L'opérateur actif doit également donner le point de terminaison actif sur un ordre de terminaison, sur lequel l'adresse est actuellement connectée, afin de s'assurer que l'entrepreneur reçoit le point de terminaison actif le plus récent pour mener à bien son travail.

Sur la base de la configuration par défaut d'un TaskSet Terminate, seule une OutTask PATCH_REMOVE sera créée pour que les contractants l'exécutent. Cela signifie qu'il n'y a pas de tâche liée à la FTU.

Incident de connexion

Un incident de connexion signifie qu'une seule connexion est en panne. Dans ce cas, le contractant spécifié se voit attribuer le ticket d'incident pour enquêter sur le problème et le résoudre si possible. Les incidents de connexion sont toujours un Prio 4. Avec ce type de tâche, le contractant reçoit une demande de résolution d'un incident unique sur une connexion.

Le contractant désigné peut effectuer des recherches sur l'incident et résoudre le problème. Pour résoudre l'incident, l'entrepreneur doit fournir un code de raison à la tâche :

DLV-01 : Problème rencontré dans le domaine des opérateurs actifs
DLV-02 : Problème rencontré dans le domaine des clients
DLV-03 : Problème rencontré dans le domaine passif souterrain
DLV-04 : Problème rencontré dans le domaine passif PoP
DLV-05 : Aucun problème trouvé (après enquête ok)
DLV-99 : autre + clarification

Incident de réseau

Un incident de réseau concerne une défaillance qui affecte plusieurs connexions individuelles. Cet incident signifie qu'un incident a un impact sur au moins N connexions. N peut être différent pour chaque opérateur actif. La valeur par défaut de N est de 48. Par exemple, un PoP complet est hors service ou un câble principal de l'épine dorsale a été coupé. Avec ce type de tâche, le contractant reçoit une demande de résolution d'une panne de réseau (il peut également s'agir d'une panne dans l'anneau urbain).

Le contractant désigné peut effectuer des recherches sur l'incident et résoudre le problème. Pour résoudre l'incident, l'entrepreneur doit fournir un code de raison à la tâche :

DLV-01 : Problème rencontré dans le domaine des opérateurs actifs
DLV-02 : Problème rencontré dans le domaine des clients
DLV-03 : Problème rencontré dans le domaine passif souterrain
DLV-04 : Problème rencontré dans le domaine passif PoP
DLV-05 : Aucun problème trouvé (après enquête ok)
DLV-99 : autre + clarification

Telco Migrate

Le type de tâche Migrate permet de migrer un utilisateur final d'un opérateur actif à un autre, également connu sous le nom de Telco Migrate.

La tâche Migrate est très similaire à l'installation d'un patch, mais il y a une différence importante. Lors de l'insertion d'un correctif, le contractant doit supposer que la position passive spécifiée (tiroir et position ODF) est toujours occupée par le correctif de l'opérateur donneur. Ainsi, la tâche consiste à retirer le patch de l'opérateur donneur et à installer le patch de l'opérateur receveur comme spécifié dans l'ensemble de tâches.

Selon qu'il s'agit de la même fibre demandée, il s'agira d'un PATCH_MIGRATE ou d'un PATCH_INSTALL et d'un PATCH_REMOVE. Potentiellement, il peut aussi y avoir un FTU_RECONSTRUCT si la FTU souhaitée est différente de la FTU actuelle à l'adresse. Toute autre fibre utilisée sera également dépatchée, ce qui entraînera un PATCH_REMOVE.

Dans le cas d'une migration Telco, l'opérateur actif donneur de la migration doit toujours être informé. Qu'il s'agisse d'un PATCH_MIGRATE ou d'un PATCH_INSTALL et d'un PATCH_REMOVE séparés.

Avant qu'une tâche de migration ne soit acceptée, elle fait l'objet d'une vérification de l'ordre propre. Dans le cadre de ce processus, les exigences de la migration sont également vérifiées. Ainsi, il vérifie si le port passif est utilisé. Si cette vérification échoue, l'ordre de migration sera refusé. En outre, comme pour tous les types de tâches, un ordre de migration sera refusé si une tâche est déjà active sur l'adresse demandée.

En outre, dans tous les cas de migration, la date souhaitée doit également être utilisée comme date du plan. Cela signifie que le contractant doit indiquer la date souhaitée dans toutes les tâches liées au POP. Une exception à cette règle est constituée par les adresses avec deux fibres connectées, pour lesquelles la fibre non donnée peut être planifiée à un stade ultérieur si nécessaire, mais sera généralement concordante au même moment.

S'il est présent, le FTU_RECONSTRUCT peut être exécuté à partir d'une date différente de celle fournie dans le Wishdate. En outre, il n'y a pas d'exigence stricte quant à savoir si la FTU_RECONSTRUCT doit être exécutée avant ou après la migration du correctif.

Dans les rares cas où la fibre est migrée, mais que le PATCH_REMOVE sur la fibre qui n'est plus utilisée a échoué, l'ordre de migration est toujours considéré comme réussi. L'échec du PATCH_REMOVE sera considéré comme un incident distinct.

Migration des ports

La TÂCHE PORT_MIGRATE consiste à migrer une connexion pour un FAI vers un autre port d'extrémité d'équipement actif dans le PoP. Dans le cadre de cette migration, l'opérateur actif et le fournisseur de services restent les mêmes. La fibre connectée est déplacée d'un port à un autre, ou d'un module à un autre. Le FAI reste le même pour une migration de port, de sorte qu'aucune indication de migration ne sera fournie en amont au FAI actif.

Le PORT_MIGRATE est une TÂCHE qui demande un changement dans le PORT actif et/ou le MODULE, de l'AO actif où un nouveau Patch doit être créé. Les détails de l'extrémité active sont mis à jour par l'AO lors de la création d'une tâche PORT_MIGRATE, en remplissant ces informations dans les champs de l'extrémité active.

Les nouvelles données relatives au port et/ou au module seront mises à jour sur AC une fois que la tâche aura atteint le statut DELIVERD.

Installation ONT

Le type de tâche ONT_INSTALL est généré pour qu'un entrepreneur installe un ONT dans la maison d'un utilisateur final. Il n'existe pas de type de tâche spécifique pour l'activation de l'ONT. Gridsz suppose que l'entrepreneur connaît le type d'ONT à utiliser. Si d'autres instructions sont nécessaires, l'AO/ISP peut les indiquer dans la section des commentaires.

Le type de tâche ONT install est un type de tâche optionnel pour l'ordre d'installation. Lorsque l'ISP/AO crée une nouvelle tâche d'installation pour une adresse spécifique, il peut sélectionner l'option de créer une tâche ONT_Install dans cet ordre.

Lorsqu'un ordre d'installation est créé, Gridsz vérifie les données dans AC pour préparer les types de tâches corrects. Un ordre d'installation contient toujours un Patch_install. S'il n'y a pas de FTU en place, un ordre d'installation créera également une FTU_construct.

Lorsqu'une UFP est déjà en place mais que le type d'UFP "à créer" est différent du type d'UFP actuel, l'ensemble de tâches contient une UFP_remplacement au lieu d'une UFP_construction.

Pour mettre à jour le statut d'une tâche ONT_INSTALL, il est obligatoire de remplir le formulaire.

Schématiquement, il s'agit de deux scénarios :