Vous pouvez déterminer si un problème vient de la configuration de l'hôte, de l'identité, du cycle natif ou d'un état réseau récupérable.
Questions d'intégration courantes
- Le widget web peut-il être anonyme ? Oui. Les intégrations web peuvent commencer anonymement puis joindre une identité signée courte après la connexion de l'hôte. Les intégrations natives exigent un token d'identité client signé avant les opérations réseau.
- Le mobile rend-il le widget web dans une WebView ? Non. iOS, Android, Flutter, React Native, NativeScript et Capacitor présentent le widget et le transport natifs partagés. Capacitor peut toutefois héberger le reste de l'interface dans sa WebView normale.
- Quelles versions minimales sont prises en charge ? iOS 15.1, Android API 26, Flutter 3.22.3 ou ultérieur avec Dart 3.4 à 3.x, React Native 0.76 à 0.87 avec New Architecture, NativeScript 8.9 à 9.x et Capacitor 6 à 8.
- Puis-je garder plusieurs conversations actives dans un client ? Non. Un accountScope possède une session native active et une outbox durable. Terminez ou réinitialisez la session actuelle avant d'en démarrer une autre et appelez logout avant de changer d'identité.
- Le SDK public diffuse-t-il les tokens IA ? Non. L'API publique renvoie des snapshots typés et des résultats wait-for-assistant. Ne construisez pas une interface token par token à partir des événements de polling.
- Push et voice sont-ils inclus dans le package de base ? Non. Ce sont des capacités natives optionnelles avec leur propre configuration de fournisseur et leurs permissions.
Associer les erreurs à l'action sûre suivante
Lisez le code d'erreur typé et conservez l'identité de la requête. Les états network, reconnecting et rate-limited peuvent être réessayés selon les règles du SDK. session-expired exige un nouveau token pour le même compte. field-invalid, payload-too-large et message-rejected exigent une correction de l'hôte ou du client. idempotency-conflict signifie que l'hôte doit examiner la clé originale plutôt que d'envoyer un nouveau message.
import { DobroDeskSdkError } from "@dobrodesk/mobile-protocol";
try {
await client.sendMessage(text, idempotencyKey);
} catch (error) {
// These host functions render controls; they do not retry inside catch.
if (!(error instanceof DobroDeskSdkError)) {
showRecoverableSdkError(error);
return;
}
switch (error.details.code) {
case "network":
case "rate-limited":
showRetryControl();
break;
case "session-expired":
showRefreshAndRetryControlForTheSameAccount();
break;
case "field-invalid":
case "payload-too-large":
case "message-rejected":
showCorrection(error.details);
break;
case "idempotency-conflict":
investigateOriginalRequest(error.details);
break;
default:
showRecoverableSdkError(error);
}
}Vérifier l'hôte avant d'ouvrir une demande de support
- Confirmez que apiOrigin est un origin HTTPS sans chemin, query ni credential et que integrationId est l'intégration DobroDesk visée.
- Confirmez que le token signé a été émis par le backend de l'hôte pour le client actuel et que accountScope est stable et réservé à ce client.
- Confirmez que le presenter natif est appelé depuis un écran au premier plan et que l'hôte n'a pas monté un second client pour le même compte.
- Confirmez qu'une nouvelle tentative réutilise l'idempotency key d'origine et que logout ou reset n'a pas été appelé alors que l'opération était simplement hors ligne.