Windows PowerShell: Atividades de fluxo de trabalho em detalhes
Cada mês deste ano, Don Jones apresentará uma parcela em um tutorial de 12-parte de 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
Ao escrever um fluxo de trabalho no Windows PowerShell, você precisa se lembrar que cada comando deve ser traduzido em uma atividade de Windows Workflow Foundation (WF) ou uma atividade InlineScript.
Em primeiro lugar, o que é uma atividade? Fluxos de trabalho do Windows PowerShell traduzem-se, finalmente, em algo que entende de WF. O que entende a WF é atividades. No WF, uma atividade é uma ação única que ocorre dentro de um fluxo de trabalho.
Muitos dos comandos do Windows PowerShell de núcleo têm atividades equivalentes. Essas atividades são completamente separadas dos comandos. Em outras palavras, a equipe da Microsoft teve que sentar e escrever tanto o comando do Windows PowerShell — como Where-Object — e uma atividade WF correspondente que fez a mesma coisa.
Assim, eles são realmente duas estruturas paralelas. Quando você usa um comando em um fluxo de trabalho, Windows PowerShell procura para ver se há uma atividade equivalente escrito e instalado no computador. Se houver um, é o que vai usar o fluxo de trabalho.
Esta é uma consideração importante. É inteiramente possível que outras equipes da Microsoft e até mesmo de terceiros, será autor atividades no futuro. Antes que você pode usá-los, porém, devem ser instalados e registrados em qualquer computador executará os fluxos de trabalho que você escreve. Como você vai fazer isso irá variar de produto para produto.
Ausência de atividade
Se você usar um comando que não tem uma equivalente de atividade WF, o Windows PowerShell irão quebrar o comando em um bloco de InlineScript implícito. InlineScript é uma atividade reconhecida nativamente pelo WF. Basicamente, diz WF para lançar uma cópia do Windows PowerShell, execute o comando e, em seguida, fechar essa cópia do Windows PowerShell.
Porque o envolvimento InlineScript pode acontecer implicitamente — ou seja, você não vê isso acontecendo — você pode ser completamente sem saber o que está acontecendo. No Windows PowerShell 3.0, na verdade, é difícil descobrir quais comandos têm equivalentes do WF e quais não. Você não pode nunca ser capaz de dizer o que está sendo executado como uma atividade de nativa e o que está sendo ajustado em um InlineScript. Na maior parte, você não precisa saber. Ele, no entanto, criar certo impacto.
Se você tentar fazer isso, por exemplo, ele iria falhar:
Workflow My-Workflow { Import-Module DHCPServer Get-DHCPServerv4Scope }
O fluxo de trabalho falha porque não há nenhuma atividade WF para módulo de importação. Cada atividade precisa acontecer em seu próprio processo (mais ou menos). Lembre-se você pode interromper e retomar mais tarde um fluxo de trabalho, ou seja, cada comando precisa fazer a sua própria configuração e a subdivisão. Nada pode contar com nada mais ter executado no mesmo processo ou memória. Windows PowerShell não envolva importação-módulo em um InlineScript porque que iria abrir o Windows PowerShell, execute o módulo de importação e, em seguida, feche o Windows PowerShell. Isto efetivamente descarregar o módulo e fazer todo o exercício inútil.
A seguir, no entanto, vai funcionar:
Workflow My-Workflow { InlineScript { Import-Module DHCPServer Get-DHCPServerv4Scope } }
Isso adiciona um bloco de InlineScript explícito. Isso significa que os dois comandos serão executados na mesma sessão do Windows PowerShell.
InlineScript blocos
Você provavelmente pode imaginar quantos de seus fluxos de trabalho poderiam ser divididos em um ou mais blocos de InlineScript. Afinal, se você precisar executar mais de um comando em um processo e ter esses comandos compartilhar resultados e saída, um InlineScript é o caminho a percorrer.
Tenha em mente que cada InlineScript é seu próprio processo autónomo do Windows PowerShell. Por exemplo, isso não vai funcionar:
Workflow My-Workflow { InlineScript { Import-Module DHCPServer $scopes = Get-DHCPServerv4Scope } InlineScript { ForEach ($scope in $scopes) { Write $scope.IPAddress } } }
A variável de $scopes criada no primeiro InlineScript não existe em um segundo. O código irá falhar ou simplesmente não fazer nada. Agora você pode estar pensando, "por que não eu apenas colocar tudo em um único bloco de InlineScript?" Você poderia:
Workflow My-Workflow { InlineScript { Import-Module DHCPServer $scopes = Get-DHCPServerv4Scope ForEach ($scope in $scopes) { Write $scope.IPAddress } } }
O problema para você executa agora é que seu fluxo de trabalho consiste em uma única atividade. WF apenas suporta retomada e inter-activity pontos de verificação. Seu fluxo de trabalho simples-atividade não pode ser pausado, retomado ou interrompido.
De muitas maneiras, você removeu as vantagens de fazer um fluxo de trabalho em primeiro lugar. Você ainda obter o suporte interno para execução remota. Se este era um processo demorado, várias etapas, porém, você não poderia sobreviver a uma falha (como uma queda de energia ou interrupção de rede) e pegar onde você parou.
Fluxo de trabalho, portanto, torna-se um enigma arquitectónico interessante. Você quer manter cada tarefa como discreta e independente quanto possível. Fazendo isso, você pode obter o máximo apoio para interrupção e reinício. No entanto, você está limitado pelo limite de processo para a partilha de informação entre os comandos.
Na verdade, o que tornaria o fluxo de trabalho do Windows PowerShell muito mais útil é a capacidade para uma atividade manter as informações em um armazenamento externo (como o SQL Server). Essa atividade de outra maneira poderia pegar e usá-las. Tal um armazenamento externo se tornaria uma espécie de loja de variável externa, persistente.
Infelizmente, o Windows PowerShell nativamente não oferece tal coisa. Não há nenhuma razão, no entanto, que você não poderia construir algo parecido em seu próprio país.
.jpg)
**Don Jones**é um receptor do prêmio de MVP do Windows PowerShell e um editor colaborador da TechNet Magazine. Ele é co-autor de quatro livros sobre o Windows PowerShell versão 3, incluindo os gratuitos sobre o Windows PowerShell remoting e criação de relatórios HTML no Windows PowerShell. Encontrá-los todos no PowerShellBooks.com, ou fazer perguntas de Jones nos fóruns de discussão em PowerShell.org.