Windows PowerShell: Parece muito com um fluxo de trabalho
Cada mês deste ano, Don Jones apresentará um novo artigo em um tutorial dividido em 12 partes sobre o fluxo de trabalho do Windows PowerShell. Nós encorajamos você a ler a série na ordem, começando com o de janeiro de 2013 coluna.
Don Jones
Fluxos de trabalho aparência muito parecido com funções do Windows PowerShell ou scripts — mas não eles. Essa semelhança é apenas superficial, e talvez ele mesmo não estende toda a maneira através da pele.
Você tem que lembrar sempre que o Windows PowerShell deve traduzir fluxos de trabalho em uma tecnologia completamente separada — Windows Workflow Foundation (WF). Isso significa que você só pode fazer coisas que podem ser duplicadas em WF. Então, seu código será executado em um tipo inteiramente diferente do ambiente que tem suas próprias regras e restrições.
Executar qualquer script como um fluxo de trabalho
A maneira mais fácil de executar um fluxo de trabalho é simplesmente executar qualquer script padrão do Windows PowerShell como um fluxo de trabalho. Você pode fazer isso com o comando Invoke-AsWorkflow. Este comando vive no módulo PSWorkflow, embora o Windows PowerShell versão 3 deve ser capaz de descobrir e executar o comando sem você precisar carregar explicitamente o módulo primeiro. Esse comando essencialmente quebra seu script inteiro em um bloco de InlineScript, significando que ele é executado dentro de WF como uma única etapa.
Isso significa que você não precisa se preocupar muito sobre restrições de fluxo de trabalho do Windows PowerShell. No entanto, você também não consegue tirar proveito de certas características de fluxo de trabalho do Windows PowerShell, como a capacidade de retomar um processo interrompido. Seu "processo", nesse caso, será composto de todo o script em execução em uma única etapa. Não há nenhuma maneira para que retomar a meio caminho através de se tiver pausar ou interromper. Aqui está um exemplo, em que eu criei um bloco de script com alguns comandos e, em seguida, executá-los como um fluxo de trabalho:
$script = { $name = Get-Content Env:\COMPUTERNAME $name | Out-File c:\MyName.txt Get-Service } Invoke-AsWorkflow -Expression $script -PSComputerName DC,CLIENT
Uma razão que eu usei uma variável aqui foi demonstrar que o WF corre tudo isso como um único InlineScript. Tenha em mente que cada comando WF executa obtém seu próprio, ambiente fresco. Não há nenhuma maneira interna para persistir os dados entre os comandos. Isso significa que as variáveis são nativamente bastante inútil. No entanto, porque tudo isto implicitamente é empacotado como um InlineScript passo a passo, a variável que eu criei persistirá ao longo.
Então por que se preocupar? Fluxo de trabalho do Windows PowerShell ainda lhe dá algumas vantagens adicionais. Há um certo número de parâmetros compartilhados por todos os fluxos de trabalho. Estas permitem que você especifique coisas como nomes de computador de destino e assim por diante. Seu script vai herdar uma infra-estrutura básica para o trabalho de vários computadores. Para scripts de longa duração, você pode lançar um fluxo de trabalho, em seguida, desconecte do computador remoto, enquanto o fluxo de trabalho continua funcionando, o que é bom.
Sintaxe do fluxo de trabalho formal
Aqui é um fluxo de trabalho muito simples:
Workflow New-Server { Get-Content -Path Env:\COMPUTERNAME | Out-File -FilePath C:\MyName.txt Get-NetAdapter -Physical } New-Server -PSComputerName CLIENT,DC
Fluxos de trabalho são uma espécie de comando do Windows PowerShell, como um cmdlet, script ou função. Sendo esse o caso, você pode executá-los simplesmente chamando seu nome, como eu fiz na última linha deste exemplo. Lembre-se, todos os fluxos de trabalho herdam um certo número de parâmetros internos, como –PSComputerName. Fluxos de trabalho também contam com o recurso de comunicação remota do Windows PowerShell, que está habilitado em ambos os computadores neste exemplo.
O resultado prático é que ambos os comandos no fluxo de trabalho estão sendo executados directamente nos computadores remotos, com os resultados, voltando para o meu computador. Eu não tinha a código qualquer que ou até mesmo criar um parâmetro de nome de computador. Eu não tenho que enumerar os nomes de computador, criar conexões, ou qualquer outra coisa. Fluxo de trabalho do Windows PowerShell não é tudo para mim. Não há absolutamente nada neste script, eu não poderia ter alcançado sem o fluxo de trabalho do Windows PowerShell — apenas exigiria um trabalho um pouco mais da minha parte.
Você vai notar que eu tenho escrito os nomes de comando no meu trabalho. Eu também usei parâmetros nomeados em cada instância. Que é sempre recomendável em qualquer script do Windows PowerShell, mas é obrigatório em um fluxo de trabalho. Você não pode usar parâmetros posicionais. Você tem que soletrar tudo ou você obterá um erro.
Agora confira este fluxo de trabalho (não que você precisará importar a sessão de PSWorkflow para sua instância do shell para que a palavra-chave "Workflow" ser legal):
Workflow New-Server { $name = Get-Content -Path Env:\COMPUTERNAME Get-Content -Path Env:\COMPUTERNAME | Out-File -FilePath C:\MyName.txt Get-NetAdapter -Physical $name | Out-File -FilePath C:\MyOtherName.txt } New-Server -PSComputerName CLIENT,DC
Quando eu escrevi neste exemplo, eu pensei, "MyOtherName.txt estará vazio." Lembre-se, o conteúdo do fluxo de trabalho cada executar como um comando separado, com nenhum contexto compartilhado entre eles. Quando executei este exemplo, porém, ele funcionou. O nome do computador foi na verdade escrito para MyName.txt e MyOtherName.txt. O que dá?
Windows PowerShell realmente faz muita coisa sob o capô para tentar certificar-se de que você obtenha os resultados que você espera de um fluxo de trabalho. Por exemplo, um comando de fluxo de trabalho "normal" é escrito em uma maneira muito específica. WF nativamente não pode ser executado apenas qualquer velho Windows PowerShell cmdlet. Equipe do Windows PowerShell fornece equivalentes de WF para uma enorme lista de cmdlets nativos, por isso há muitas vezes um mapeamento entre cmdlets e atividades do WF.
Quando você usar um cmdlet que não tem uma atividade correspondente, Windows PowerShell implicitamente quebra seu código dentro de uma atividade InlineScript do WF. Que tem o efeito de tornar WF executar o Windows PowerShell, execute o comando no Windows PowerShell e, em seguida, retomar os resultados em WF. Portanto, um monte de coisas que "não devem" trabalhar funcionará, porque o Windows PowerShell hacks juntos para você.
O perigo aqui é que resolução de problemas pode tornar-se extremamente difícil, porque você não vai ser sempre capaz de ver o Windows PowerShell está fazendo nos bastidores. No caso deste exemplo, o Windows PowerShell garante que as variáveis de nível superior persistirem durante todo o fluxo de trabalho.
Onde nós estamos indo próximos
Acredite ou não, você já tem o suficiente para começar a escrever os fluxos de trabalho básicos. Você pode ter estas alvo qualquer computador onde você instalou o Windows PowerShell versão 3 e ativado Remoting. Parte da razão para habilitar a comunicação remota é que ele cria uma configuração de sessão que usa o fluxo de trabalho do Windows PowerShell. Se você habilitou o Remoting em um computador com o Windows PowerShell versão 2 e, posteriormente, instalei a versão 3, você vai querer re-executar Enable-PSRemoting para criar a configuração necessária.
Mantenha seus fluxos de trabalho bastante simples. Executar uma seqüência de comandos e não faço um monte de manobras extravagantes. Você não deve ter quaisquer problemas, e você começa a aproveitar o built-in Windows PowerShell Remoting de fluxo de trabalho, direcionamento de vários computadores e outros recursos.
No próximo mês, vou começar ficar mais complicado. Vou olhar para as diferenças profundas entre um fluxo de trabalho e um script do Windows PowerShell normal e começar a explorar alguns dos mais interessantes recursos de fluxo de trabalho do Windows PowerShell.
.jpg)
Don Jonesé um vencedor do prêmio de MVP do Windows PowerShell e editor colaborador da TechNet Magazine. Ele é co-autor de quatro livros sobre o Windows PowerShell versão 3, incluindo vários títulos gratuitos na criação de relatórios HTML no Windows PowerShell e Windows PowerShell Remoting. Encontrá-los todos no PowerShellBooks.com, ou faça sua pergunta nos fóruns de discussão em PowerShell.org de Jones .