Windows Workflow 4.5 Délai d'activité non persistant

Question

J'ai un service WF4.5 que je développe pour le travail, qui utilise une activité de retard dans le flux de travail. Le flux de travail est hébergé dans AppFabric (test local dans Visual Studio). J'ai installé mon web.config dans le service et AppFabric est configuré pour utiliser la configuration personnalisée. Voici une image de la partie relevent du flux de travail:

Les points pour obtenir de l'image est que l'activité avant que le délai (Déterminer la communication) ne court et j'avoir une preuve vérifiable de celui-ci. Je sais également que UpdateRejectionInfo après que l'activité de délai ne s'exécute PAS (vérifié avec un point d'arrêt dans l'activité personnalisée lors de l'exécution du workflow). J'ai essayé d'ajouter une activité de persistance entre l'activité DétermineCommunication et l'activité de délai et elle enregistre effectivement dans la base de données où je recherche, donc je sais que le service a des permissions d'écriture sur la base de données.

Voici la section de comportement du web.config pour le service aussi:

<behaviors> 
    <serviceBehaviors> 
    <behavior> 
     <sqlWorkflowInstanceStore 
     connectionString="SERVER=hq-sql02\oculusdev;Database=EAA;Trusted_Connection=yes" 
     hostLockRenewalPeriod="00:00:30" 
     runnableInstancesDetectionPeriod="00:00:30" 
     instanceCompletionAction="DeleteNothing" 
     instanceLockedExceptionAction="AggressiveRetry" 
     instanceEncodingOption="GZip"/> 
     <workflowIdle timeToPersist="00:00:20" timeToUnload="00:00:30"/> 
     <serviceMetadata httpGetEnabled="true" httpsGetEnabled="true" /> 
     <serviceDebug includeExceptionDetailInFaults="true" /> 
    </behavior> 
    </serviceBehaviors> 
</behaviors> 

Toute sorte d'aide serait incroyable.

Answer 1

D'accord. Donc, la réponse à cette question va bien au-delà de l'activité de retard et entre dans d'autres technologies que j'utilise que je n'ai même pas mentionnées. TL: DR: Je n'ai pas défini mes objets de structure d'entité pour désactiver le chargement différé. Ainsi, lors de la sérialisation des données, une exception a été levée que je n'ai jamais vue et le workflow s'est effondré.

Version longue: Lors de la conservation des données dans la base de données, le programme tente de sérialiser tous les objets de votre étendue de workflow. Cela est normal pour les objets C# standard, mais lorsqu'ils deviennent des objets complexes, la sérialisation devient plus complexe. Pour la facilité des technologies, j'utilise Entity Framework (database-first) dans mon projet pour passer et enregistrer des entités de base de données. Lorsque les entités Entity Framework sont sérialisées, elles essaient de récupérer toutes les informations disponibles. Well Entity Framework a cette idée de données de chargement paresseux, donc si vous obtenez une entité de la base de données, et que vous cherchez à obtenir une couche plus profonde (ie par une relation de clé étrangère), elle retournera à la base de données pour cette information . Eh bien, un moyen courant pour obtenir des entités de la base de données est d'obtenir l'entité et ensuite couper la connexion à la base de données, grâce à l'utilisation de blocs à court terme. Si vous décidez d'utiliser le court terme en utilisant des blocs (ce que j'aime appeler des entités singleton), et que vous ne désactivez pas le chargement paresseux, alors quand un programme essaie de sérialiser l'entité, il commencera à demander à tous les données supplémentaires qui n'ont pas été saisies dans la demande initiale. Et si ce bloc utilisant a été quitté, la connexion à la base de données ne sera pas disponible et elle lèvera une exception.

Je n'étais pas en train de capturer les exceptions que les activités intégrées lançaient, et donc il ne semblait pas qu'il échouait quand il l'était vraiment.