WF4 d'affinité sur Windows Azure et d'autres environnements NLB

Question

J'utilise Windows Azure et WF4 et mon service workflow est hébergé dans un rôle Web (avec les instances N). savoir comment mon travail est maintenant faire une affinité, d'une manière que je peux envoyer des messages à l'instance de workflow droit. Pour expliquer ce scénario, mon flux de travail (ci-joint) commence par un « StartWorkflow » activité de réception, crée 3 « Personne » et, dans un parallèle for-each, attend la confirmation de ces 3 personnes ( « confirmCreation » activité de réception).

Je puis a commencé à chercher comment l'affinité est fait dans d'autres environnements NLB (principalement pour des informations sur contemplé comment fonctionne sur Windows Server AppFabric), mais je ne ai trouvé une réponse précise. Alors, comment est-il fait dans d'autres environnements NLB?

Ma tâche suivante est de savoir comment je pourrais mettre en place un système pour gérer cette affinité sur Windows Azure et combien cela coûterait de solution (dans le prix, le temps et la quantité de travail) pour voir si son viable ou s'il est préférable de travailler avec une seule instance Web rôle en attendant l'hôte WF4 pour l'Azure AppFabric. La seule façon que j'ai trouvé persister l'instance de workflow. Y at-il d'autres façons de le faire?

Mon troisième, mais pas la dernière, la tâche est de savoir comment gère WF4 plusieurs messages reçus en même temps. Dans mon scénario, ce moyen comment elle traiterait si les 3 personnes ont confirmé en même temps et les messages de confirmation sont également reçus en même temps. Étant donné que la réponse la plus logique à ce problème semble être d'utiliser une file d'attente, je commencé à chercher des informations sur les files d'attente sur WF4 et personnes ont trouvé parlant de MSQM. Mais quel est le message de WF4 natif système de gestionnaire? Est-ce vraiment gestionnaire une file d'attente ou est-il un autre système? Comment est-ce traité concurrency?

Answer 1

Vous ne devriez pas besoin d'aucune affinité. En fait, ce qui est un peu le point de déroulements durable. Alors que votre flux de travail attend cette confirmation, il devrait être persisté et déchargé de tout un serveur.

En ce qui concerne que la persistance va pour Windows Azure vous le feriez soit besoin de pirater les scripts standards de persistance SQL afin qu'ils travaillent sur SQL Azure ou écrire votre propre InstanceStore mise en œuvre qui se trouve au-dessus de Azure Storage. Nous avons fait ce dernier pour un flux de travail, nous sommes en cours d'exécution dans Azure, mais je suis incapable de partager le code. Sur une échelle de 1 à 10 pour l'effort, je lui donnerais autour d'un 8.

En ce qui concerne plusieurs messages, ce qui se passera est les messages seront reçus et livrés à l'instance de workflow un message à la fois. Maintenant, il est possible que chacun de ces messages va au même serveur ou peut-être chacun va à un diff. serveur. Peu importe la façon dont il se produit, le moteur d'exécution de workflow essayera de charger le flux de travail à partir du magasin d'exemple, voir qu'il est actuellement verrouillé et bloc / nouvelles tentatives jusqu'à ce que le flux de travail devient disponible pour traiter le message suivant. Donc, vous n'avez pas à vous soucier de l'accès simultané à la même instance de flux de travail aussi longtemps que vous configurez tout correctement et la mise en œuvre de InstanceStore fait son travail.

Voici quelques autres suggestions:

• Assurez-vous que vous utilisez l'option PersistBeforeSend sur votre SendReply actvités
• Configurer les options de service de flux de travail suivants
  • <workflowIdle timeToUnload="00:00:00" />
  • <sqlWorkflowInstanceStore ... instanceLockedExceptionAction="AggressiveRetry" />

Answer 2

Utilisation de la sortie de la boîte banque d'instance SQL avec SQL Azure est un peu d'un problème au moment avec le SDK Azure 1.3 que chaque déploiement, même si vous avez fait 0 changements de code, les résultats dans un nouveau déploiement de services qui signifie déjà les flux de travail persisteraient ne peut continuer. C'est un bug qui sera résolu, mais un PITA pour l'instant.

Comme Drew dit que votre instance de workflow doit simplement passer d'un serveur à au besoin, pas besoin de lui épingler une machine spécifique. Et même si vous pourriez qui nuirait à l'évolutivité et la fiabilité donc quelque chose à éviter.

L'envoi de messages par MSMQ à l'aide du Fonds de roulement NetMsmqBinding fonctionne très bien. En interne WF utilise un mécanisme complètement différent appelé signets qui permettent un flux de travail d'arrêter et de reprendre. Chaque activité de réception, ainsi que d'autres comme délai, va créer un signet et attendre que, pour reprendre. Vous ne pouvez reprendre les signets existants. Même la reprise d'un signet n'est pas une action directe, mais mettre en une file d'attente interne, non MSMQ, par le planificateur de workflow et exécuté par un SynchronizationContext. Vous obtenez aucun contrôle sur le planificateur, mais vous pouvez remplacer le SynchronizationContext lors de l'utilisation du WorkflowApplication et ainsi obtenir un certain contrôle sur comment et où les activités sont exécutées.