A visszaállíthatóságot úgy valósítja meg a rendszer, hogy egyrészt naplózza az ellenőrzési pontokat, másrészt az eredményeket szerializált formában elmenti. PowerShell esetében ez a diszkre történik, a C:\Users\<userid>\AppData\Local\Microsoft\Windows\PowerShell\WF\PS\default\<SID> helyre alaphelyzetben:
PS C:\> dir C:\Users\ST\AppData\Local\Microsoft\Windows\PowerShell\WF\PS\defaul
t\S-1-5-21-2583457872-4292199810-2893339361-1000\a211af55-8292-4cbf-b279-ced7f1
a0a9c0
Directory: C:\Users\ST\AppData\Local\Microsoft\Windows\PowerShell\WF\PS\de
fault\S-1-5-21-2583457872-4292199810-2893339361-1000\a211af55-8292-4cbf-b2
79-ced7f1a0a9c0
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 2015.02.11. 21:57 Def
d---- 2015.02.11. 21:57 Meta
d---- 2015.02.11. 21:57 Stat
d---- 2015.02.11. 21:57 Str
-a--- 2015.02.11. 21:57 259 V.xml
Látható, hogy workflow-nként egy GUID alatt egy könyvtárstruktúrában mindenféle adat van elmentve. Annak ellenére, hogy sok fájlnak XML kiterjesztése van itt, nem érdemes nagyon nézegetni ezeket, mert a tartalmuk titkosított.
Hogyan tudjuk megfeleltetni a GUID-okat a workflow-kkal? Valójában, ha workflow-t futtatunk PowerShellből, akkor 2 háttérfolyamatot (job) indítunk, melyeket a Get-Job –IncludeChildJob kpacsolójával futtatva meg is nézhetünk:
PS C:\> Get-Job -IncludeChildJob | ft ID, State, ChildJobs
Id State ChildJobs
-- ----- ---------
4 Completed {Job5}
5 Completed {}
A „fő” job az, amelyiknek van ChildJobs tulajdonsága, ami egy utalás egy vagy több másik jobra. Igazából akkor válik érthetővé, hogy miért kell fő- és aljob, ha nem is egy gépre, hanem többre futtatjuk a workflow-t. Itt direkt eleve job-ként futtatom a workflowt az –AsJob kapcsolóval, hogy még egyszerűbb legyen a vizsgálat:
PS C:\> Test-Checkpoint -AsJob -PSComputerName AzureWin7-1, AzureWin7-2
Id Name PSJobTypeName State HasMoreData Location
-- ---- ------------- ----- ----------- --------
2 Job2 PSWorkflowJob NotStarted True AzureW...
Ha megvizsgáljuk az aljobokat is, akkor ezt látjuk (kicsit mélyebben van maga a GUID, így ezt kihozom a format-table segítségével):
PS C:\> Get-Job -IncludeChildJob | ft id, location, state, @{n="GUID";e={$_.PSW
orkflowInstance.InstanceID.guid}} -AutoSize
Id Location State GUID
-- -------- ----- ----
2 AzureWin7-1,AzureWin7-2 Suspended
3 AzureWin7-1 Suspended 33944393-698c-4101-837f-cce5483dea97
4 AzureWin7-2 Suspended 2e6a7b5c-bb7e-4e0e-8feb-d869d8b6a099
Látható tehát, hogy a fő jobnak az a szerepe, hogy a tényleges, célgépenként külön aljobbal futó workflow-kat összefogja. A tényleges munkát az aljobok végzik el, és ezeknél látható az a bizonyos GUID, ami alapján kideríthetük, hogy melyik szál hol tartja nyilván a státuszát a fájlrendszerben:
PS C:\> dir C:\Users\soostibor.STAD\AppData\Local\Microsoft\Windows\PowerShell\
WF\PS\default\S-1-5-21-852094961-2763772764-3754700265-500_EL | ft -AutoSize
Directory: C:\Users\soostibor.STAD\AppData\Local\Microsoft\Windows\PowerSh
ell\WF\PS\default\S-1-5-21-852094961-2763772764-3754700265-500_EL
Mode LastWriteTime Length Name
---- ------------- ------ ----
d---- 2/11/2015 9:18 PM 2e6a7b5c-bb7e-4e0e-8feb-d869d8b6a099
d---- 2/11/2015 9:18 PM 33944393-698c-4101-837f-cce5483dea97
Ezen háttérinformációk után nézzük meg, hogyan élik túl a workflow-k a gép újraindítását.