Tevékenységek paraméterei

Nem csak a workflow-knak vannak beépített paramétereik, hanem az egyes tevékenységeknek is. Az about_activitycommonparameters súgótémából kiolvashatjuk ezeket a lehetséges paramétereket:

Ezek egy része a workflow-tól „öröklődik”, azaz például a workflownál megadott PSComputerName természetesen áthagyományozódik az egyes tevékenységekre is (csak azokra, amelyek „igazi” tevékenységek) és implicit módon azok is használják, de explicit is használhatjuk ezeket tevékenségenként, ha akarjuk (lásd kövtkező fejezet).

Ha egy workflow-t egy központi gépen akarunk futtatni, de bizonyos tevékenységeket azon belül távoli gépen vagy gépeken, akkor azoknak a tevékenyégeknek –PSComputerName pereméterrel adjunk át gépnevet még akkor is, ha a az eredeti PowerShell parancsnak van –ComputerName paramétere. Az alábbi példában összefoglaltam az összes távoli futtatási lehetőséget:

A $data sorában a –PSComputerName paraméterrel határozom meg a távoli gépet, a $mydata-nál implicit módon adom át a –PSComputerName paramétert a workflow-tól, a $computer=… sorában az „eredeti” ‑computername paramétert használom, de ehhez egy inlinescript blokkba kellett helyeznem. Mivel a Get-CimInstance cmdlet a workflow-n belül már egy natív workflow tevékenységet jelent, ezért ott már nem használhatom a –computername paramétert, csak akkor, ha az beágíazom egy inlinescript  blokkba, amin belül már bármilyen PowerShell kód futhat. Ide viszont a PS3-tól kezdve használható $using:remote formulával adom át a gépnevet.

Futtassuk ezt először az én AzureWin7-1 gépemről, a remote paramétereként meg az AzureDC-1 gépet adom meg:

Az eredmény várakozás szerinti. A „ténylegesen futtat” és az „implicit futtat” is én gépem, a „távoli gép” és a „computer” is az AzureDC-1.

Mi van akkor, ha megadom a –PSComputerName paramétert is, ami legyen AzureWin7-2:

Kaptam először is egy hibát az inlinescript futtatásakor. De ezt majd nézzük később. A „ténylegesen futtat” lett az én gépem. Miért nem az AzureWin7-2? Azért, mert annak ellenére, hogy magának a workflow-nak adtam a –PSComputerName paramétert, valójában a workflow az én gépemen fut, a ‑PSComputerName paraméternek a hatása csak az „igazi” workflow tevékenységekre érvényes. Márpedig egy sima hivatkozás az $env:computername-re az nem workflow tevékenység, ez tehát mindenkppen a helyi gépen fut. Az „implicit futtat” esetében már egy Get-CimInstance fut, ami „igazi” workflow tevékenység, így arra hat a workflow ‑PSComputerName paramétere. Ezzel szemben a „távoli gép” esetében ezt az implicit paraméterátadást felülbíráljuk egy explicit gépnévvel, így ebből AzureDC-1 lett. És mi történt az inlinescript-tel? Maga az inlinescript a szkriptblokkjával együtt is egy workflow tevékenység, így arra is hat az implicit ‑PSComputerName. Tehát elmegyünk AzureWin7-2-re és onnan akarnánk továbbmenni AzureDC-1-re. Ezt a kétszeres ugrást a PowerShell alaphelyzetben a Kerberos autentikáció miatt nem engedi. Ehhez a CredSSP autentikációt kellene használni, ami alaphelyzetben nincs engedélyezve.

Ezeken az „öröklött” paramétereken kívül vannak csak a tevékenységeknél megtalálható paraméterek is. Ilyen például a UseDefaultInput, aminek felhasználásával dolgozhatjuk fel a csővezetékből érkező értékeket, hiszen a workflownak nincs Process blokkja, így ezzel a módszerrel tudjuk csak behelyezni a csőbe a workflowt:

Persze hagyományos paraméterátadással is használhatjuk a workflowt ebben az esetben is az InputObject paraméter használatával:

A többi paraméter használata talán egyértelműbb, vagy nagyon ritkán használjuk, így ezekre most nem térek ki részletesebben.

Word To HTML Converter