Erreur Deluge Zoho CRM : Incompatibilité de type de données BIGINT avec les recherches

Une erreur Deluge Zoho CRM signalant une "incompatibilité de type de données BIGINT" avec une recherche signifie que le script a tenté d'écrire ou de comparer un ID de recherche numérique comme un type incorrect. Zoho stocke les ID d'enregistrement pour les recherches sous forme de grands entiers (BIGINT), et la transmission d'une chaîne, de null ou d'un format numérique incompatible déclenche cette erreur.

Ce que cela signifie — explication concrète liée à la surface de l'API Zoho

Lorsqu'une tâche Deluge ou l'API CRM met à jour un champ de recherche, le moteur s'attend à ce que la valeur de recherche soit l'ID de l'enregistrement du module (un BIGINT) ou un objet qui inclut cet ID conformément à la forme de la charge utile de l'API. Fournir une chaîne, une valeur vide, un objet composite sans la clé numérique "id", ou un nombre en dehors de la plage BIGINT entraîne le rejet de l'opération par la couche CRM avec une incompatibilité de type de données ^[3].

Causes courantes

• Transmission du nom d'affichage, de l'e-mail ou de la valeur d'un champ personnalisé de l'enregistrement de recherche au lieu de l'ID d'enregistrement numérique ^[3].
• Envoi de l'ID sous forme de chaîne entre guillemets (par exemple, "123456789012345") au lieu d'un type numérique dans Deluge ou JSON d'API ^[3].
• Utilisation d'une variable vide, indéfinie ou nulle dans le champ de recherche alors que l'API attend un BIGINT valide ^[1].
• Construction incorrecte de l'objet de recherche (clé "id" manquante ou structure JSON incorrecte) lors de l'appel de /crm/v2 ou de l'utilisation des appels zoho.crm.update d'enregistrement ^[3].

Comment y remédier

1. Confirmez que la valeur source est l'ID d'enregistrement numérique : récupérez l'enregistrement associé via getRecord ou un appel de recherche et utilisez sa propriété "id". Par exemple, utilisez response.get("id") plutôt que response.get("Name") dans Deluge ^[3].
2. Assurez-vous que l'ID est numérique dans la charge utile : dans Deluge, n'entourez pas l'ID de guillemets ; dans les appels REST, envoyez-le comme un nombre ou comme {"id": 123456789012345} à l'intérieur du champ de recherche.
3. Construisez l'objet de recherche exactement comme l'attend l'API. Pour une mise à jour d'enregistrement dans Deluge : map.put("Account_Name", {"id": accountId}); puis appelez zoho.crm.updateRecord("Contacts", contactId, map) ^[3].
4. Ajoutez des vérifications défensives : if (accountId == null || accountId.toString().trim().length() == 0) alors sautez la mise à jour de la recherche ou levez une erreur de validation claire au lieu d'envoyer une valeur vide ^[1].
5. Reproduisez avec une charge utile minimale : envoyez uniquement le champ de recherche et l'ID à l'API pour confirmer que l'erreur BIGINT disparaît, puis développez la charge utile complète une fois corrigée.

Quand escalader

Si vous confirmez que le code envoie un "id" numérique et que le CRM le rejette toujours, collectez le corps de la requête défaillante, les en-têtes de réponse, les ID d'enregistrement et les horodatages, puis ouvrez un ticket auprès du support Zoho. Incluez le script reproductible minimal et l'appel API afin que l'ingénierie puisse inspecter la coercition de type au niveau du service.

^[1]: Publications de la communauté Zoho sur le scripting CRM et les intégrations de listes associées.

^[3]: Fil de discussion de la communauté Zoho discutant du comportement de l'API et des interactions de scripts Deluge.