J'utilise Windows Workflow Foundation sur un projet, en particulier les composants StateTracker, Instance Store et de suivi. Le suivi pour chaque flux de travail instancié se sérialisé à la base de données, et en plus je suis en mesure de désérialiser ces données en utilisant la technique suivante:Windows Workflow Foundation Tracking ActivityId - Qu'est-ce que l'encodage?
https://msdn.microsoft.com/library/ee960223(v=vs.100).aspx
Le suivi désérialise un grand arbre XML, ce qui représente l'état actuel de la à long flux de travail en cours d'exécution, à savoir:
//...brevity
<activities z:Id="5" xmlns="http://schemas.datacontract.org/2010/02/System.Activities">
<SerializedInstanceLists z:Id="6" z:Size="4" xmlns:a="http://schemas.datacontract.org/2004/07/System.Activities.Runtime">
<a:ActivityInstanceMap.InstanceList z:Id="7">
<singleItem z:Id="8" z:Type="System.Activities.ActivityInstance" z:Assembly="System.Activities, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" xmlns="http://schemas.datacontract.org/2004/07/System.Activities">
//...brevity
Cependant, je suis tombé sur un problème où de temps en temps quand nos changements de code du système, les ActivityIds affectés au système d'un changement particulier de conception de workflow ainsi. Ces ID étant référencés dans le suivi, les workflows refusent de charger.
Par exemple, avant la mise à jour du code:
Activity 1 ID: 1.2170
Activity 2 ID: 1.2337
Activity 3 ID: 1.2215
Après la mise à jour du code:
Activity 1 ID: 1.2170
Activity 2 ID: **1.2338**
Activity 3 ID: **1.2216**
Un flux de travail qui est actuellement à Activité 3 aura suivi qui désérialise comme:
<a:ActivityInstanceMap.InstanceList z:Id="129">
<singleItem z:Ref="11" i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.Activities"></singleItem>
<a:ActivityId z:Id="130">AQE=</a:ActivityId>
</a:ActivityInstanceMap.InstanceList>
<a:ActivityInstanceMap.InstanceList z:Id="131">
<singleItem z:Ref="109" i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.Activities"></singleItem>
<a:ActivityId z:Id="132">AacR</a:ActivityId>
</a:ActivityInstanceMap.InstanceList>
<a:ActivityInstanceMap.InstanceList z:Id="133">
<singleItem z:Ref="95" i:nil="true" xmlns="http://schemas.datacontract.org/2004/07/System.Activities"></singleItem>
<a:ActivityId z:Id="134">AaMR</a:ActivityId>
</a:ActivityInstanceMap.InstanceList>
J'ai trouvé que par comp En raison d'un workflow dont le suivi a été instancié avec le nouveau code, la différence est AacR et AaMR ActivityIds. La mise à jour de ces valeurs correctes permet de réparer le flux de travail.
Ma question est la suivante:
Quelqu'un reconnaît l'encodage utilisé pour ces AACR et Aamr ActivityIds? Si je peux travailler sur la façon de convertir le 1.2216 ActivityId en cette valeur de suivi sérialisé, je serai en mesure de réparer par programme les workflows à la volée lorsque cela se produit.
J'ai trouvé que les identifiants sont initialement sérialisés en tableaux d'octets via la source de référence suivante, mais je ne peux pas expliquer comment ils vont de cela dans les quatre chaînes de caractères ci-dessus.
L'article suivant explique comment ActivityIds sont générés:
Toute aide grandement appréciée!