Flux, planification et push dans le hub d'intégration
Comment DPP Shield récupère une source selon une planification, quelles authentifications chaque flux accepte, et comment votre système peut pousser les données à la place.
Équipe éditoriale DPP Shield · Mis à jour:
Un mappage reçoit ses données de trois façons : vous importez un fichier, DPP Shield récupère un flux en HTTPS ou SFTP selon une planification, ou votre système pousse les enregistrements vers le point d'entrée push du mappage avec un jeton push. Les trois passent par le même aperçu, la même correspondance et le même versionnement.
Trois voies d'entrée
L'import convient à un fichier ponctuel. Un flux convient à une source que DPP Shield peut atteindre et authentifier seul ; il s'exécute manuellement, toutes les heures ou chaque jour. Le push convient à une source impossible à récupérer - un système qui exige des requêtes signées ou une session, ou une plateforme d'intégration qui produit déjà l'export - et laisse ce système décider quand envoyer les données.
Options de connexion d'un flux
Les identifiants sont stockés chiffrés et ne sont plus jamais affichés. Ils sont effacés si l'adresse du flux change d'hôte, pour qu'une adresse modifiée ne puisse pas envoyer votre secret ailleurs. Les flux n'atteignent que des adresses publiques.
Options prises en charge
- HTTPS GET, ou POST avec un corps pour les requêtes GraphQL, OData ou SuiteQL.
- Sans authentification, jeton bearer, identifiants basic, ou clé API dans l'en-tête de votre choix.
- OAuth 2.0 avec les grants client credentials ou password, authentification du client par en-tête basic ou dans le corps, et scope facultatif ; un jeton est demandé à chaque exécution.
- SFTP avec mot de passe ou clé privée, face à une clé d'hôte épinglée : Test feed montre la clé présentée par le serveur, à comparer avec l'empreinte fournie par votre administrateur.
- Dans un corps POST, écrivez {{credential}} à la place du secret ; il est alors stocké chiffré plutôt que dans le corps.
Limites
Une exécution lit jusqu'à 5 000 enregistrements et une source de 10 Mo au plus ; un mappage contient jusqu'à 200 règles et une table de correspondance jusqu'à 100 entrées. Répartissez les sources plus grandes par famille de produits, ou poussez-les par lots.
Pousser les enregistrements depuis votre système
Un jeton push ne peut pousser que vers son propre mappage ; il ne peut rien lire. Traitez-le comme un mot de passe et gardez-le dans le coffre de secrets de votre plateforme d'intégration.
- Sur le mappage, ouvrez Feed and push et émettez un jeton push. Il commence par dpm_ et n'est affiché qu'une fois ; en émettre un nouveau remplace le précédent.
- Envoyez POST https://api.dppshield.com/api/v1/public/integrations/<mapping id>/push avec l'en-tête Authorization: Bearer <jeton push>.
- Placez les enregistrements dans le corps exactement comme le mappage les lit : CSV avec Content-Type text/csv, XML avec application/xml, ou JSON avec application/json. Les corps CSV et XML peuvent atteindre 10 Mo.
- Ajoutez ?dryRun=true à l'adresse pour obtenir l'aperçu sans rien écrire.
- Lisez la réponse : c'est le résumé de l'exécution - enregistrements, mis à jour, créés, inchangés, sans correspondance et erreurs - et l'exécution apparaît aussi dans l'historique avec le déclencheur push.
Quand une exécution ne fait pas ce que vous attendiez
Des enregistrements sans correspondance signifient que la clé diffère entre les systèmes - zéros en tête, espaces ou autre identifiant. Les erreurs indiquent l'enregistrement et le champ. Relancez un aperçu après toute modification de la source, et rappelez-vous qu'une valeur source vide n'efface jamais un champ.