Y a-t-il un délai de réplication dans Salesforce.com via l'API APEX?

J'ai utilisé SOAP pour traiter Salesforce.com et j'ai utilisé l'appel getUpdated(), en utilisant l'horodatage que je récupère de l'appel getServertimestamp(). J'ai regardé ma vérification de processus, (elle interroge chaque minute) et quelques secondes après avoir sauvegardé la modification dans l'environnement Sandbox, je la vois interroger, ne reçois aucun <ids> dans l'appel getUpdated, et ensuite lors du prochain sondage , l'identifiant modifié apparaît.Y a-t-il un délai de réplication dans Salesforce.com via l'API APEX?

Existe-t-il un délai de réplication backend dans SFDC? Je le soupçonne, mais je n'ai pas eu de chance d'en déterminer l'ampleur. Quelqu'un d'autre a-t-il vécu cela?

En outre, je me rends compte que je devrais mentionner, tout cela est dans une copie Sandbox de l'environnement, ce qui peut confondre les choses encore plus loin. Mise à jour: Je viens de tester, et j'ai fait un changement, et mon sondage a couru 48 secondes plus tard, et n'a pas vu l'objet mis à jour. Mais 1 minute 48 secondes plus tard, il l'a vu. Donc, c'est un point de données. (Je sais que mon point de terminaison SOAP et mon interface Web s'exécutent sur le même serveur à SFDC, tapp0).

Source

2010-07-06 geoffc

Utilisez-vous l'API de réplication (partie de l'API Web Services)? Ou créez-vous des bibliothèques en utilisant des WSDL d'entreprise/partenaire? –

Quelque part entre les deux, mais en utilisant le WSDL d'entreprise via des appels SOAP. – geoffc

Hmmm, j'ai regardé dedans mais je ne trouve rien. Il y a des retards dans certaines parties du système (comme les calculs de champ de cumul) mais je dirais que vous devez demander dans les forums ou utiliser le tag twitter #askforce. Simon Fell est votre meilleur pari. –

Il n'y a pas de retard dans l'enregistrement de la modification, mais les appels getUpdate/getDeleted arrondissent l'heure spécifiée à la minute la plus proche, de sorte que l'heure de fin est maintenant arrondie à la baisse. gamme. En outre, si vous effectuez une réplication en temps réel via ces appels, assurez-vous de vérifier l'horodatage de la transaction inflight renvoyé, sinon vous risquez de manquer des modifications (l'horodatage de modification ne peut pas être le temps réel de validation de la transaction).

Source

2010-07-26 02:35:31 superfell

Vous êtes-vous soucié de préciser ce qui vous semble être un problème avec l'horodatage du changement différent du temps de validation réel? Je ne suis pas sûr de voir l'inquiétude. – geoffc

Bien sûr, cela devrait être couvert dans les docs, mais voici un exemple. Supposons qu'une mise à jour a commencé à 00:00:55 et que l'horodatage de mise à jour de la ligne soit défini sur 00:00:55, mais que la transaction ne soit pas validée avant 00:01:02. Si vous appelez getUpdated à 00:01:01 pour la période 00:00 à 00:01, vous ne verrez pas ce changement de vol (car le tx n'a pas été validé), mais si vous avancez aveuglément votre fenêtre d'interrogation, le prochain sondage sera pour 00:01 à 00:02, et même si la mise à jour est maintenant validée, l'horodatage des modifications est toujours 00:00:55, et n'apparaîtra donc pas non plus dans les résultats des 2 sondages. – superfell

Plus vous vous rapprochez de l'heure actuelle, plus ce problème est grave. Les résultats de getUpdated incluent l'horodatage que la transaction inflight la plus ancienne a démarré et vous ne devez pas faire avancer votre horodatage d'interrogation après cet horodatage, sinon vous risquez de manquer des modifications. – superfell

Y a-t-il un délai de réplication dans Salesforce.com via l'API APEX?

Répondre

Questions connexes