Windows PowerShell-arbetsflödesbegrepp
Viktigt
Den här versionen av Service Management Automation (SMA) har nått slutet av supporten. Vi rekommenderar att du uppgraderar till SMA 2022.
En typ av runbook för Service Management Automation baseras på Windows PowerShell arbetsflöden. Den här artikeln innehåller en kort översikt över de viktiga funktionerna i arbetsflöden som är gemensamma för Automation-runbooks. Fullständig information om arbetsflöden finns i Komma igång med Windows PowerShell Workflow.
Runbook-strukturen är identisk mellan runbooks för Service Management Automation och För Microsoft Azure Automation även om de två vanligtvis fungerar med olika resurser.
Windows PowerShell-arbetsflöden
Ett arbetsflöde är en sekvens med programmerade, nätverksanslutna steg som utför tidskrävande uppgifter eller kräver samordning av flera steg i flera enheter eller hanterade noder. Fördelarna med ett arbetsflöde jämfört med ett vanligt skript är bland annat möjligheten att samtidigt kunna utföra en åtgärd på flera olika enheter samt förmågan till automatisk återställning vid fel. Ett Windows PowerShell arbetsflöde är ett Windows PowerShell skript som använder Windows Workflow Foundation. Arbetsflödet skrivs med Windows PowerShell syntax och startas av Windows PowerShell, men bearbetas av Windows Workflow Foundation.
Grundläggande struktur
Ett Windows PowerShell arbetsflöde börjar med nyckelordet Arbetsflöde följt av brödtexten i skriptet som omges av klammerparenteser. Namnet på arbetsflödet följer nyckelordet Arbetsflöde enligt följande syntax. Namnet på arbetsflödet matchar namnet på Automation-runbooken.
Workflow Test-Runbook
{
<Commands>
}
Om du vill lägga till parametrar i arbetsflödet använder du nyckelordet Param enligt följande syntax. Hanteringsportalen uppmanar användarna att ange värden för dessa parametrar när de startar sin runbook. Det här exemplet använder det valfria parameterattributet, som anger om parametern är obligatorisk eller inte.
Workflow Test-Runbook
{
Param
(
[Parameter(Mandatory=<$True | $False>]
[Type]$<ParameterName>,
[Parameter(Mandatory=<$True | $False>]
[Type]$<ParameterName>
)
<Commands>
}
Namngivning
Namnet på arbetsflödet bör följa det verb-substantiv-format som är standard i Windows PowerShell. Du kan läsa godkända verb för Windows PowerShell kommandon för en lista över godkända verb som ska användas. Namnet på arbetsflödet måste matcha namnet på Automation-runbooken. Om en Runbook importeras måste filnamnet matcha namnet på arbetsflödet och ha filändelsen .ps1.
Begränsningar
En fullständig lista över begränsningar och syntaxskillnader mellan Windows PowerShell arbetsflöden och Windows PowerShell finns i Syntaktiska skillnader mellan skriptarbetsflöden och skript.
Aktiviteter
En aktivitet är en viss åtgärd i ett arbetsflöde. Precis som ett skript består av ett eller flera kommandon, består ett arbetsflöde av en eller flera aktiviteter som utförs i en sekvens. När ett arbetsflöde körs i Windows PowerShell konverteras många Windows PowerShell-cmdletar automatiskt till aktiviteter. Om du anger en av dessa cmdletar i din Runbook, kommer dock motsvarande aktivitet köras i Windows Workflow Foundation. För cmdletar utan motsvarande aktivitet kör Windows PowerShell Workflow automatiskt cmdleten inom en InlineScript-aktivitet. Det finns en uppsättning cmdletar som är undantagna och inte kan användas i ett arbetsflöde om du inte uttryckligen inkluderar dem i ett InlineScript-block . Mer information om dessa begrepp finns i Använda aktiviteter i skriptarbetsflöden.
Arbetsflödesaktiviteter delar en uppsättning gemensamma parametrar för konfiguration av deras funktion. Mer information om vanliga parametrar för arbetsflödet finns i about_WorkflowCommonParameters.
Integreringsmoduler
En integreringsmodul är ett paket som innehåller en Windows PowerShell-modul och kan importeras till Automation. Windows PowerShell moduler innehåller cmdletar som kan användas i Automation-runbooks. Produkter och tjänster som Operations Manager och Azure har moduler med cmdletar som är specifika för driften.
Integreringsmoduler som importeras till Automation är automatiskt tillgängliga för alla runbooks. Eftersom Automation baseras på Windows PowerShell 4.0 har den stöd för automatisk inläsning av moduler, vilket innebär att cmdletar från installerade moduler kan användas utan att importera dem till skriptet med Import-Module.
Alla Windows PowerShell modulen kan importeras till Automation så länge alla dess beroenden kan finnas i en enda mapp. Om modulen är beroende av registerinställningar eller filer som inte finns i standardsökvägen kan den importeras, men den fungerar troligen inte eftersom Automation inte kan hitta dess beroenden. Moduler med externa beroenden kan användas i en runbook genom att installera dem på en annan värd med och sedan komma åt dem med ett InlineScript-skriptblock .
Med Service Management Automation kan du använda moduler med externa beroenden genom att installera dem på varje Worker-server. Även om cmdletarna i dessa moduler kan användas i runbooks, identifieras de inte av Automation för att stödja sådana funktioner som guiden Infoga aktivitet. För att kunna använda den här funktionen kan du skapa en bärbar modul med cmdleten New-SmaPortableModule . Den här cmdleten skapar en modul som innehåller en stub för var och en av dess cmdletar och kan importeras till Automation. När en Runbook använder en av dessa cmdletar, omdirigerar stub-funktionen anropet till den faktiska cmdleten i den externa modulen. Denna modul måste installeras på var och en av Worker-servrarna, annars kommer anropet att misslyckas.
Parallell körning
En av fördelarna med Windows PowerShell-arbetsflöden är möjligheten att utföra en uppsättning kommandon parallellt i stället för sekventiellt som i ett vanligt skript. Detta är särskilt användbart i Runbooks eftersom de kan komma att utföra ett antal åtgärder som tar en betydande tid att slutföra. En Runbook kan till exempel användas för att etablera en uppsättning virtuella datorer. I stället för att utföra varje etableringsprocess i följd med varandra kan åtgärderna utföras samtidigt, vilket ökar den övergripande effektiviteten. En sådan Runbook fortsätter köra endast efter att alla dessa aktiviteter slutförts.
Du kan använda nyckelordet Parallel för att skapa ett skriptblock med flera kommandon som ska köras samtidigt. Den aktuella syntaxen visas nedan. I det här fallet kommer Activity1 och Activity2 att startas samtidigt. Activity3 startas endast efter att både Activity1 och Activity2 har slutförts.
Parallel
{
<Activity1>
<Activity2>
}
<Activity3>
Du kan använda ForEach -Parallel-konstruktionen för att bearbeta kommandon för varje objekt i en samling samtidigt. Objekten i samlingen bearbetas parallellt medan kommandona i skriptblocket körs sekventiellt. Den aktuella syntaxen visas nedan. I det här fallet startar Activity1 samtidigt för alla objekt i samlingen. För vart och ett av objekten kommer Activity2 att startas efter att Activity1 har slutförts. Activity3 startar endast efter att både Activity1 och Activity2 har slutförts för alla objekt.
ForEach -Parallel ($<item> in $<collection>)
{
<Activity1>
<Activity2>
}
<Activity3>
Nyckelordet Sekvens används för att köra kommandon i följd i ett parallellt skriptblock. Sekvensskriptblocket körs parallellt med andra kommandon, men kommandona i blocket körs sekventiellt. Den aktuella syntaxen visas nedan. I det här fallet kommer Activity1, Activity2 och Activity3 att startas samtidigt. Activity4 kommer att startas endast efter att Activity3 har slutförts. Activity5 startar när alla andra aktiviteter har slutförts
Parallel
{
<Activity1>
<Activity2>
Sequence
{
<Activity3>
<Activity4>
}
}
<Activity5>
Kontrollpunkter
En kontrollpunkt är en ögonblicksbild av arbetsflödets aktuella tillstånd och inkluderar olika variablers aktuella värden samt de eventuella utdata som genererats vid den aktuella tidpunkten. Den sista kontrollpunkten som ska slutföras i en runbook sparas i Automation-databasen så att arbetsflödet kan återupptas även vid avbrott. När Runbook-jobbet har slutförts tas alla kontrollpunktsdata bort.
Du kan ange en kontrollpunkt i ett arbetsflöde med aktiviteten Checkpoint-Workflow . När du inkluderar denna aktivitet i en Runbook, lagras en kontrollpunkt omedelbart. Om en Runbook pausats på grund av ett fel, kommer den när jobbet återupptas, att återupptas från den punkt som återges av den senast lagrade kontrollpunkten.
I följande exempelkod uppstår ett fel efter Activity2, vilket gör att runbooken pausas. När jobbet återupptas startar det genom att Activity2 körs eftersom det motsvarar den senast lagrade kontrollpunkten.
<Activity1>
Checkpoint-Workflow
<Activity2>
<Error>
<Activity3>
Du bör ange kontrollpunkter i en runbook efter aktiviteter som kan vara felbenägna och bör inte upprepas om runbooken återupptas. Din Runbook kan till exempel skapa en virtuell dator. Du kan ange en kontrollpunkt både före och efter kommandona som skapar den virtuella datorn. Om kommandona misslyckas, kommer de att upprepas när Runbook-körningen återupptas. Om skapandet lyckas men runbooken misslyckas senare skapas inte den virtuella datorn igen när runbooken återupptas.
Mer information om kontrollpunkter finns i Lägga till kontrollpunkter i ett skriptarbetsflöde.
Pausa en Runbook
Du kan tvinga en runbook att pausa sig själv med aktiviteten Suspend-Workflow . Den här aktiviteten kommer att lagra en kontrollpunkt och sedan omedelbart pausa arbetsflödet. Att kunna pausa arbetsflödet är användbart för runbooks som kan kräva att ett manuellt steg utförs innan nästa uppsättning aktiviteter körs.
Mer information om hur du pausar ett arbetsflöde finns i Göra ett arbetsflöde avstängt.
InlineScript
InlineScript-aktiviteten kör ett kommandoblock i en separat session som inte är arbetsflöde och returnerar dess utdata till arbetsflödet. Medan kommandon i ett arbetsflöde skickas till Windows Workflow Foundation för bearbetning, bearbetas kommandona i ett InlineScript-block av Windows PowerShell. Aktiviteten använder vanliga parametrar för standardarbetsflödet, inklusive PSComputerName och PSCredential, som gör att du kan ange att kodblocket ska köras på en annan dator eller använda alternativa autentiseringsuppgifter.
Den aktuella syntaxen för InlineScript visas nedan.
InlineScript
{
<Script Block>
} <Common Parameters>
Den vanligaste användningen för InlineScript i en runbook är att köra ett kodblock på en annan dator. Detta krävs när cmdletar i din runbook inte är installerade i Automation eller om åtgärden bara har behörighet att utföras lokalt på måldatorn. Detta illustreras i följande diagram.
För att köra kodblocket på en annan dator används parametrarna PSComputer och PSCredential med InlineScript-aktiviteten . En global resurs, till exempel en autentiseringsuppgift eller anslutning , används vanligtvis i en runbook för att ange värden för dessa parametrar. I följande exempelkod körs en uppsättning kommandon på en dator som representeras av anslutningen MyConnection.
$con = Get-AutomationConnection -Name 'MyConnection'
$securepassword = ConvertTo-SecureString -AsPlainText -String $con.Password -Force
$cred = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $con.Username, $securepassword
InlineScript
{
<Commands>
} -PSComputer $con.ComputerName -PSCredential $cred
Även om InlineScript-aktiviteter kan vara kritiska i vissa runbooks bör de endast användas när det behövs av följande skäl:
Du kan inte använda kontrollpunkter inifrån ett InlineScript-block . Om ett fel uppstår i kodblocket, måste det köras om från början.
InlineScript påverkar runbookens skalbarhet eftersom den innehåller Windows PowerShell-sessionen under hela InlineScript-blockets längd.
Aktiviteter som Get-AutomationVariable och Get-AutomationPSCredential är inte tillgängliga i ett InlineScript-block.
Om du behöver använda en InlineScript bör du minimera dess omfång. Om din runbook till exempel itererar över en samling när samma åtgärd tillämpas på varje objekt, bör loopen ske utanför InlineScript. Detta ger följande fördelar:
Du kan kontrollera arbetsflödet efter varje iteration. Om jobbet pausas eller avbryts och återupptas, kan slingan återupptas.
Du kan använda ForEach "Parallel för att hantera samlingsobjekt samtidigt.
Tänk på följande rekommendationer om du använder ett InlineScript i din runbook:
Du kan dock skicka värden till skriptet med $Using omfångsmodifierare. En variabel med namnet $abc som har angetts utanför InlineScript skulle till exempel bli $using:abc i ett InlineScript.
Om du vill returnera utdata från en InlineScript tilldelar du utdata till en variabel och matar ut alla data som ska returneras till utdataströmmen. I följande exempel tilldelas strängen hi till en variabel med namnet $output.
$output = InlineScript { Write-Output "hi" }Undvik att definiera arbetsflöden inom InlineScript-omfånget . Även om vissa arbetsflöden kan verka fungera korrekt är detta inte ett testat scenario. Därför kan det dyka upp förvirrande felmeddelanden eller oväntade resultat.
Mer information om hur du använder InlineScript finns i Köra Windows PowerShell kommandon i ett arbetsflöde och about_InlineScript.