Multi File Transfer sur BPMN : logique de synchronisation sur mesure entre clouds et stockages, avec contrôle du contenu

Place dans l’architecture

Le transfert s’exécute sous forme de processus BPMN versionnés dans MEF.DEV BPMN Low-code sur Enablement & Monetization Platform, et non comme une application séparée. Les processus héritent de l’alignement ODA de la plateforme : les fonctions API correspondent au rôle des composants ODA, et Kubernetes avec une livraison GitOps constitue l’environnement d’exploitation. Le contrat de chaque processus est sa frontière typée.

Composants

• Liste des routes Une liste SharePoint avec chemin source, chemin cible, mode de remplissage initial et indicateur d’activation. Un administrateur SharePoint la modifie ; la plateforme la lit au début d’un cycle, la compare à l’instantané stocké et écrit le statut.
• Processus de cycle transfer_files traite un drive pour un cycle.
• Processus de fichier transfer_file déplace un fichier en quatre opérations typées.
• Plugin backend Porte les opérations vers Microsoft Graph et SFTPGo.
• Task worker Reprend le travail inachevé après une panne.

Contrats

• DriveWorkModel Entrée d’un cycle : clé du drive, position stockée (DeltaLink), routes à traiter et mémoire des routes.
• FileTransferModel Entrée d’un transfert : operationId, transport et chemin source, transport et chemin de destination, nom final.
• OperationResult Statut avec code d’erreur, identifiant de corrélation et retryAfterSeconds. Un refus tel que FinalNameConflict revient sous forme de résultat, et l’appelant décide selon le statut.
• Issues d’un cycle COMMITTED, NOT_COMMITTED, NO_DELTA_LINK et, en mode debug, PLANNED_ONLY.
• Identifiants La valeur d’un access token ne franchit pas la frontière BPMN : l’identifiant est appliqué au contexte de connexion. L’application utilise Sites.Selected avec consentement administrateur.

Flux d’un cycle

1. Une notification signale seulement un changement. Le cycle lit les changements via Microsoft Graph page par page à partir de la position stockée.
2. Un changement ultérieur d’un fichier remplace le précédent ; un fichier est donc transféré au plus une fois par route et par cycle.
3. Le cycle planifie un transfert par fichier et par route et appelle transfer_file pour chacun, l’un après l’autre.
4. Chaque transfert résout la destination, lit la source, charge vers un emplacement temporaire et finalise sous le nom final. Le fichier ne devient visible à destination qu’à cette dernière étape.
5. La nouvelle position, avec la mémoire des routes, n’est validée que lorsque tous les transferts sont terminés ; sinon, le cycle suivant repart de l’ancienne position.

Reprise

• L’état de chaque appel est sauvegardé : après un redémarrage, les fichiers terminés ne sont pas retransférés, et l’étape interrompue s’exécute à nouveau depuis son début.
• Un worker reprend la tâche inachevée et poursuit la même instance principale ; un second hôte prend le relais après l’arrêt du premier.
• Un redémarrage ne reprend pas les octets à partir d’un offset, et une opération postérieure au dernier état sauvegardé peut se répéter.

Points d’intégration

• Microsoft 365 HTTPS sortant vers Microsoft Graph via un forward proxy avec liste d’autorisation ; un endpoint HTTPS entrant sur le reverse proxy de la DMZ (Demilitarized Zone) pour les notifications.
• SFTPGo Pour chaque route, l’administrateur SFTPGo définit les zones staging, published et quarantine, un compte technique, une règle d’événement de chargement vers le broker de messages et un contrôle ICAP comme condition de publication. Les partenaires ne voient que published.
• Plateforme Un broker de messages, une base de données pour le journal des transferts, les curseurs et les abonnements, et un ordonnanceur pour le renouvellement des abonnements et un cycle de contrôle quotidien.

Les personnes gardent le contrôle

L’administrateur SharePoint est responsable des routes et les suspend ou les reprend. Le processus relance automatiquement les transferts en échec, et un service externe contrôle la quarantaine via ICAP.

Limites

• Une route est unidirectionnelle ; le sens inverse est une route distincte avec des dossiers distincts.
• Les suppressions ne sont pas propagées, et un fichier renommé est considéré comme nouveau.
• Les permissions, l’historique des versions et les métadonnées SharePoint ne sont pas transférés.
• L’ordre entre les fichiers n’est pas préservé ; le mode de remplissage initial est fixé à la création d’une route.

Périmètre de la solution

Le périmètre des cycles de quarantaine et de contrôle ci-dessus est convenu dans le projet.

Détails techniques sur platform.mef.dev →