Générer des déployables et writers universels de destination

Generate deployables crée un runner portable à partir du catalogue et/ou de définitions Output Target enregistrées. Il peut conserver les sorties CSV/Excel et router plusieurs cibles logiques vers une destination physique unique.

DSE utilise maintenant un Universal Destination Writer Framework. Tous les presets Output Target actuels disposent d’un chemin d’écriture exécutable. DSE choisit l’adaptateur approprié : provider natif, ODBC, REST/OData, SDK d’object storage, fichier ou gateway.

« Runtime writer » signifie que le runner généré sait exécuter la route. Certains prérequis restent externes : pilote ODBC du fournisseur, identifiants API, permissions cloud ou gateway approuvée pour VSAM/IMS/CICS.

Flux recommandé

1. Découvrez les sources et vérifiez le catalogue.
2. Créez/révisez les mappings dans Compose targets.
3. Ouvrez Generate deployables et ajoutez les targets enregistrées.
4. Configurez la destination avant d’activer l’écriture.
5. Vérifiez technologie du writer, noms d’objets et mode d’écriture.
6. Activez Route selected targets to one destination uniquement pour autoriser la route physique.
7. Testez la connexion, choisissez plateforme/RID, puis générez.
8. Exécutez, consultez View results et rapprochez les comptes du système cible.

Cibles logiques et destination physique

Un Output Target est un contrat logique. Il n’a pas besoin d’utiliser la même technologie que la destination physique.

Exemples :

MongoDB + Couchbase + InfluxDB -> PostgreSQL

Oracle + MongoDB + DynamoDB -> Redis

Le manifeste conserve provenance et mappings afin que les enregistrements soient envoyés au bon objet de destination.

Configurer d’abord, activer ensuite

Le preset, le mode, les noms et les types d’objets restent modifiables lorsque le routage est désactivé. La case de routage contrôle l’exécution externe, pas l’édition.

Technologies de writer

Destination object routing

Destination object est directement éditable. Les noms doivent être non vides, uniques et valides. Le type d’objet est limité par le writer : Table, Collection, Hash, Index, Label, Measurement, Bucket, etc.

Append et Replace

• Append conserve les données existantes et ajoute les nouveaux enregistrements.
• Replace nettoie une fois l’objet/préfixe appartenant à la route puis écrit l’ensemble courant.

Pour Salesforce, Dynamics 365 CRM, SharePoint, ServiceNow, Workday et SAP OData, le writer API direct expose uniquement Append. Un Replace destructif complet nécessite une gateway approuvée avec une politique métier explicite.

Connexion

En production, préférez l’injection runtime :

DSX_DESTINATION_CONNECTION_STRING

ODBC exige un string explicite Driver= ou DSN= et le pilote installé sur l’hôte d’exécution.

REST/OData utilise généralement Url=/Endpoint=, token, utilisateur/mot de passe ou API key.

VSAM/IMS/CICS/Generic utilisent une gateway Endpoint=https://... ou une surface ODBC autorisée.

Modèle canonique

Le runner convertit d’abord les données source en enregistrements DSE neutres contenant id stable, provenance et champs mappés. L’adaptateur de destination traduit ensuite ce modèle vers la représentation physique.

AI Advisor

Dans Destinations, sélectionnez une seule recommandation IA avec le bouton radio. Utiliser la destination sélectionnée dans Deployables prépare cette destination pour la prochaine session Generate Deployables. Créer des cibles brouillon crée ou actualise uniquement la destination sélectionnée afin d’éviter les brouillons IA en double.

AI Advisor recommande et transmet une route, mais n’écrit pas silencieusement dans les systèmes externes. L’utilisateur approuve technologie, objets, mode, connexion et package avant l’exécution.

Tous les presets actuels ayant désormais un chemin de writer, la recommandation peut conserver sa technologie cible, sous réserve des prérequis runtime.

Dépannage

• Preset impossible à changer : utilisez la version avec le correctif dropdown ; le routage désactivé ne doit pas verrouiller l’éditeur.
• ODBC Driver/DSN manquant : installez le pilote fournisseur sur l’hôte du runner.
• REST 401/403 : vérifiez endpoint, token/tenant/site et droits d’écriture.
• Pas de Replace pour SaaS : comportement intentionnel de sécurité.
• VSAM/IMS/CICS demande une gateway : configurez le bridge du site ou ODBC.
• Connection string requise : définissez DSX_DESTINATION_CONNECTION_STRING.

Production

Testez avec peu de lignes, préférez Append au début, protégez les secrets, utilisez le moindre privilège, des objets/préfixes dédiés et conservez les artefacts d’audit avant le cutover.

Fiabilité d’entreprise, lignage et sécurité de reprise

Les deployables générés peuvent maintenant inclure une couche de fiabilité en plus des sorties CSV/Excel et du routage physique.

Chaque exécution reçoit un Run ID et peut produire sous output/audit/<run-id>/ :

• lineage.jsonl : événements structurés avec source, champs, route de destination, objets mappés, comptages, technologie du writer, mode d’écriture, statut et empreinte du mapping ;
• run-summary.json : copie stable du résumé pour chaque exécution, conservée dans le répertoire d’audit afin qu’une exécution ultérieure n’écrase pas l’historique;
• run-manifest.json : résumé de gouvernance avec comptages, reprises, informations de redémarrage et hashes SHA-256 ;
• integrity.sha256 : hashes du résumé, du lignage, du manifest et des fichiers générés.

Les artefacts de lignage excluent les chaînes de connexion et les secrets.

Lease et heartbeat

Activer le verrou d’exécution et le heartbeat crée un lease propre au schéma et un heartbeat dans le répertoire d’état. Deux runners partageant le même schéma et DSX_STATE_DIR ne peuvent pas s’exécuter simultanément. Pour un modèle actif/passif, utilisez un stockage durable partagé.

Overrides utiles : DSX_RUN_ID/--run-id, DSX_STATE_DIR/--state-dir, --lease-timeout-seconds, --heartbeat-seconds.

Reprises et checkpoints

Les lectures confrontées à des erreurs transitoires utilisent un backoff exponentiel borné. Les écritures ne sont rejouées que lorsque le writer annonce des garanties transactionnelles ou Upsert adaptées.

La reprise conserve des checkpoints des écritures de destination terminées. Après une panne, un nouveau processus peut éviter de les rejouer tout en reconstruisant CSV/Excel. La reprise est désactivée pour Replace.

Différence avec CDC

Les checkpoints améliorent la reprise mais ne constituent pas un Change Data Capture (CDC) basé sur les journaux. Le mode de lecture reste Snapshot. Un CDC de production exige des adaptateurs par source et des curseurs durables : LSN SQL Server CDC, WAL/logical replication PostgreSQL, resume tokens MongoDB, continuations Cosmos Change Feed, positions de shards DynamoDB Streams, etc.

Voir Docs/Enterprise-Reliability-CDC-Governance-HA-Plan.md.

<!-- DSE_DEPLOYABLE_CERTIFICATION_HELP_V1 -->

20. Exécution certifiée des déployables Windows et Linux générés

Utilisez cette section après la fin de Generate deployables. Elle documente le flux de certification/exécution pour les packages générés win-x64 et linux-x64 natifs. Il s’agit de runners d’intégration générés, et non des SKU d’installation commerciaux Windows/Container de DSE.

20.1 Déployable Windows (windows/win-x64)

Copiez le dossier Windows généré sur la machine de certification (ou extrayez l’archive transférée), puis travaillez depuis le répertoire windows\win-x64.

Vérifiez la présence de ces fichiers générés avant la première exécution :

• DataSourceExplorer.Runner.exe
• manager.cmd
• run.cmd
• schema-catalog.json
• source-connections.json
• destination-route.json — lorsque le routage vers la destination est activé

Démarrez le Runtime Manager local :

cd /d C:\Path\To\deployables\windows\win-x64
manager.cmd

manager.cmd lance DataSourceExplorer.Runner.exe --manager. Le gestionnaire écoute sur 127.0.0.1 et ouvre normalement le navigateur par défaut. Si le navigateur ne s’ouvre pas, lancez directement l’exécutable et utilisez l’URL de gestion locale affichée dans la console.

DataSourceExplorer.Runner.exe --manager

1. Vérifiez que Runtime status indique READY et qu’aucune exécution n’est active.
2. Dans Connections, vérifiez que chaque source et destination requise est Configured. Laissez les champs protégés vides pour conserver la valeur enregistrée/intégrée.
3. Pour la première certification, utilisez la planification Manual only et définissez le dossier de sortie sur output.
4. Sélectionnez Run now et attendez le retour de l’état READY.
5. Vérifiez que Last result et Run history indiquent Success, puis contrôlez indépendamment les sorties/données de destination attendues.

Pour une exécution unique sans interface :

run.cmd

Le générateur tente d’abord une publication autonome. S’il a dû revenir à une publication dépendante du framework, installez les runtimes .NET 8 et ASP.NET Core 8 correspondants sur la machine cible.

20.2 Déployable Linux (linux/linux-x64) — flux Ubuntu Hyper-V validé

La procédure suivante suit le guide validé Ubuntu Server 26.04.1 LTS / Microsoft Hyper-V fourni pour la certification. Elle exécute le déployable Linux natif ; Docker n’est pas requis.

Accès navigateur sécurisé recommandé depuis Windows

Au lieu d’exposer le gestionnaire sur le réseau de la VM, créez un transfert de port SSH local depuis Windows PowerShell après avoir lu le port du gestionnaire dans le journal Linux :

ssh -L 18093:127.0.0.1:<manager-port> <linux-user>@<VM-IP>

Ouvrez ensuite http://127.0.0.1:18093/ sous Windows. Gardez la session SSH ouverte pendant l’utilisation du gestionnaire. Le relais socat décrit ci-dessous reste utile sur un réseau de certification isolé/de confiance.

Objectif

Cette procédure crée une machine virtuelle Ubuntu Server légère et exécute le déployable Linux natif généré par DSE. Elle reproduit le flux Windows : copier le package généré, démarrer le DSE Deployable Runtime Manager, ouvrir le gestionnaire depuis l’hôte Windows, exécuter le déployable et vérifier le résultat.

Le package décrit ici est un déployable natif linux-x64. Docker n’est pas requis pour ce flux.

Prérequis

• Hôte Windows avec Hyper-V activé
• Image ISO Ubuntu Server LTS
• Dossier linux généré par DSE contenant linux/linux-x64
• Au moins 4 vCPU, 4 Go de RAM et un disque virtuel de 40 Go
• Accès réseau depuis la VM vers les sources/destinations DSE requises

Windows → Hyper-V → Ubuntu → DSE Runtime Manager → Browser

1. Créer la machine virtuelle Hyper-V

Créez une VM de génération 2 avec les paramètres de base suivants :

Pendant l’installation d’Ubuntu, sélectionnez Install OpenSSH server. Après l’installation, éjectez l’ISO et démarrez sur le disque virtuel.

2. Préparer Ubuntu

Connectez-vous à Ubuntu et mettez le système à jour. Vérifiez ensuite le processeur, la mémoire, le disque et l’adresse IP.

sudo apt update
sudo apt upgrade -y
hostname -I
nproc
free -h
df -h

Si le VHDX de 40 Go existe mais que le volume racine ne fait qu’environ 18-19 Go, étendez le volume logique LVM pour utiliser l’espace libre.

sudo vgs
sudo lvextend -l +100%FREE -r /dev/ubuntu-vg/ubuntu-lv
df -h

3. Se connecter depuis Windows avec SSH

Utilisez l’adresse IP actuelle de la VM retournée par hostname -I. L’adresse du commutateur par défaut Hyper-V peut changer après un redémarrage.

ssh <linux-user>@<VM-IP>

4. Copier le dossier Linux généré

Exécutez ssh/scp depuis Windows PowerShell, et non depuis le shell Ubuntu. DSE génère un dossier linux, pas un fichier linux.zip. Remplacez le chemin, l’utilisateur et l’IP par les valeurs réelles.

ssh <linux-user>@<VM-IP> "rm -rf /home/<linux-user>/dse-deploy/linux && mkdir -p /home/<linux-user>/dse-deploy"
scp -r "C:\Path\To\GeneratedDeployables\...\linux" <linux-user>@<VM-IP>:/home/<linux-user>/dse-deploy/

Si Linux affiche « Could not resolve hostname c: », la commande scp a été exécutée dans Ubuntu. Revenez à Windows PowerShell et relancez-la.

5. Préparer le déployable

Installez socat si vous utilisez le relais, ouvrez le dossier linux-x64 copié et appliquez les droits d’exécution Linux. Les scripts générés par la version actuelle de DSE sont en UTF-8 sans BOM : aucune extraction ni suppression de BOM n’est nécessaire.

sudo apt update && sudo apt install -y socat
cd ~/dse-deploy/linux/linux-x64
chmod +x DataSourceExplorer.Runner manager.sh run.sh
ls -l DataSourceExplorer.Runner manager.sh run.sh

6. Vérifier la connectivité source/destination

Avant de démarrer DSE, vérifiez que la VM Ubuntu peut atteindre le port requis. L’exemple utilise MongoDB sur le port 27017.

timeout 5 bash -c '</dev/tcp/<source-host>/<source-port>' \
  && echo 'Port reachable' \
  || echo 'Port NOT reachable'

# MongoDB example
timeout 5 bash -c '</dev/tcp/192.168.50.124/27017' \
  && echo 'MongoDB port reachable' \
  || echo 'MongoDB port NOT reachable'

7. Démarrer le DSE Deployable Runtime Manager

Démarrez le gestionnaire et consultez son journal. Le gestionnaire écoute sur 127.0.0.1 et choisit un port local.

cd ~/dse-deploy/linux/linux-x64
./manager.sh
sleep 2
cat .dse-manager/manager-console.log
curl http://127.0.0.1:<manager-port>/ | head

Un journal correct contient une ligne comme : Local management URL: http://127.0.0.1:51827. Le port peut changer après redémarrage.

8. Rendre le gestionnaire accessible au navigateur Windows

Utilisez socat dans Ubuntu pour relayer un port stable de la VM (18093) vers le port local actuel du gestionnaire. Les commandes détectent automatiquement l’IP de la VM et le port du gestionnaire.

cd ~/dse-deploy/linux/linux-x64
VM_IP=$(hostname -I | awk '{print $1}')
MANAGER_PORT=$(grep -oE '127\.0\.0\.1:[0-9]+' .dse-manager/manager-console.log | tail -1 | cut -d: -f2)
nohup socat TCP-LISTEN:18093,bind="$VM_IP",reuseaddr,fork TCP:127.0.0.1:"$MANAGER_PORT" > ~/dse-relay.log 2>&1 &
echo "Open: http://$VM_IP:18093/"
ss -ltnp | grep 18093

Utilisez ce relais uniquement sur un réseau de test de confiance. Tant que socat fonctionne, le gestionnaire est accessible via l’interface réseau de la VM.

9. Exécuter le déployable depuis l’interface

1. Ouvrez dans Edge ou Chrome l’URL affichée par la commande de relais.
2. Vérifiez que Runtime status indique READY et qu’aucune exécution n’est active.
3. Dans Connections, vérifiez que la source et la destination indiquent Configured. Laissez les champs protégés vides pour conserver les valeurs intégrées.
4. Pour le premier test, définissez Scheduler configuration sur Manual only, Output directory sur output, puis enregistrez.
5. Cliquez sur Run now et attendez le retour à READY.
6. Vérifiez que Last result et Run history indiquent Success, puis contrôlez les fichiers de sortie et les données de destination.

10. Arrêt, redémarrage et nettoyage

L’IP de la VM et le port du gestionnaire peuvent changer après redémarrage. Relancez manager.sh, lisez le nouveau port et recréez le relais socat. Pour arrêter le relais :

pkill -f 'socat TCP-LISTEN:18093' || true

Liste de vérification

• Ubuntu démarre depuis le VHDX et SSH fonctionne
• Le système de fichiers racine dispose de suffisamment d’espace libre
• Le port source/destination est accessible depuis Ubuntu
• DataSourceExplorer.Runner, manager.sh et run.sh sont exécutables
• manager-console.log affiche une URL de gestion locale
• Le navigateur Windows ouvre http://<VM-IP>:18093/
• Runtime status revient à READY après Run now
• Run history indique Success et les données de sortie/destination sont présentes

Dépannage

Pour l’intégration à l’aide produit, utilisez la page HTML localisée de ce package. Ne traduisez pas les commandes ; traduisez uniquement les explications et les indications d’interface.