sábado, 30 de abril de 2022

Publicando os riscos do projeto no Microsoft Teams

 Olá pessoal –

Este post é uma continuação de uma publicação anterior, onde comentei sobre as possibilidades de integração entre o Project Online e o Microsoft Teams. Dessa vez, nosso objetivo será comunicar a equipe de projetos, através dos Adaptative Cards, sempre que um novo risco for criado em qualquer um dos projetos que façam parte do nosso portfolio.

Contexto e configurações iniciais

É sabido que as organizações podem configurar o Project Online com um ou mais modelos de site, de modo a garantir que a plataforma se encarregue de criar um novo site padronizado sempre que um novo projeto for iniciado. Para assegurar que a automação funcione corretamente, convém criar, no modelo de site, uma nova coluna na lista de riscos para capturar o status da automação. Essa coluna pode ser de texto livre e, idealmente, deveria ficar oculta no formulário de cadastro/edição de riscos, para evitar que usuários a manipulem desnecessariamente.


O flow

Criada a coluna auxiliar, vamos ao desenvolvimento do flow. Como não é possível monitorar todos os sites existentes no Project Online para que o gatilho do processo de automação seja disparado sempre que um novo risco for criado, a maneira mais adequada de organizar o processo de automação é criar um fluxo agendado, que seja disparado diariamente e então faça a varredura de todos os sites para verificar se novos riscos foram criados. A imagem abaixo apresenta um resumão de como o fluxo está estruturado, mas iremos entrar em detalhe sobre cada uma das ações em seguida:


De início, temos o gatilho do fluxo. No meu exemplo, estou disparando a automação de modo manual, mas é claro que a maneira mais conveniente seria através de um gatilho agendado para acontecer diariamente. Em seguida, duas variáveis são iniciadas para que seja possível capturar a URL do ambiente do Project Online e também  a URL exclusiva de cada site para qual o processo de automação será aplicado. O próximo passo irá utilizar a já consagrada ação Send an HTTP Request to SharePoint para escanear todos os projetos disponíveis no Project Online, assim como os endereços (URLs) dos seus respectivos sites:


A partir daí lançamos mão da ação Apply to each, pois a varredura na lista de riscos deve acontecer para cada um dos projetos encontrados. As instruções utilizadas foram:

Em Apply to each, na área Select an output from previous steps:

Body('Get_Projects')?['value']

Em Site Address:

Items('Apply_to_each')?[ 'ProjectWorkspaceInternalUrl']

É importante também notar que um filtro está sendo aplicado à consulta, de modo a obter apenas os riscos para os quais a coluna auxiliar Status Automação não seja igual a (ne) ‘Processado’:


Uma vez obtidos todos os riscos que ainda não foram processados no site de projetos em questão, a variável Project Site URL está sendo definida com o endereço do site (ou seja, nesse momento é definida a URL do site do contexto para o qual o processo de automação está sendo processado).

Em seguida, temos uma nova ação Apply to each. Essa ação é necessária porque, em cada um dos sites analisados, podemos ter um ou mais riscos que ainda não foram processados pela automação – e, dessa forma, para cada um desses registros o processo deverá acontecer. Dentro do Apply to each 2, a instrução utilizada foi:

Body('Get_Risks')?['value']

Assim, uma postagem utilizando os adaptative cards é realizada no Microsoft Teams para garantir que os membros do PMO e demais interessados sejam informados de que um novo risco foi criado:


Logo após a publicação no Teams informando sobre a criação do novo risco, é necessário utilizar novamente a ação Send an HTTP Request to SharePoint para atualizar a coluna auxiliar Status Automação, informando-a de que esse risco específico não mais precisa ser processado na automação na próxima vez em que ela for disparada:


Note que essa é uma ação bem específica, que não está sendo aplicada no contexto do Project Online, mas sim do próprio SharePoint (pois não é algo que está alterando uma propriedade do projeto, mas sim do risco, que pertence a um site de SharePoint).

A ação permite fazer uma chamada ao site do projeto, procurando especificamente pela lista de riscos e, dentro dessa lista, pelo ID do risco que está sendo atualizado:

items('Apply_to_each_2')?['ID']

Em seguida, na área de body, é passada a instrução para atualizar a coluna Status Automação: 

{

"__metadata": {

"type": "SP.Data.RisksListItem"

},

"Status_x0020_Automa_x00e7_x00e3": "Processado"

}

...........................................................................................................................................

Assim, quando um novo risco for criado, a postagem será feita no canal especificado no Microsoft Teams:

....................................................................................................

E por hoje é só pessoal. Espero que gostem desse post, e até o próximo!

domingo, 17 de abril de 2022

Como publicar os projetos sem realizar o seu check in?

 Olá pessoal –

Efetuar check out e check in nos projetos é uma situação corriqueira no processo de automação do Project Online através do Power Automate. Inclusive, em um dos meus posts mais recentes, procurei explicar como é possível forçar o check in de projetos que estejam bloqueados pelos gerentes.

No post de hoje vamos discutir como configurar as ações dentro do Power Automate para publicar um projeto sem necessariamente fazer o seu check in. Essa necessidade surgiu a partir de uma solução de negócios desenvolvida para permitir que usuários utilizassem outra plataforma que não o Project Online (nesse caso específico, um aplicativo criado no Power Apps) para atualizar as suas tarefas. Em resumo, o aplicativo deveria funcionar da seguinte forma:

  1. Semanalmente, usuários deveriam acessar o aplicativo e lançar as horas trabalhadas (trabalho real) em tarefas dentro deste período
  2. Adicionalmente, caso houvesse algum ajuste a ser realizado no trabalho restante, a informação também seria lançada dentro do aplicativo
  3. Por sua vez, o Power Automate deveria capturar as horas reais e atualizá-las de volta no Project Online, em cada tarefa específica. Além disso, caso o trabalho restante também tivesse sido alterado, o novo montante de horas também deveria ser computado

Para garantir a melhor eficiência possível no processo de automação, a melhor alternativa é agrupar as tarefas a serem atualizadas por projeto. Assim, o projeto é acessado e colocado em check out; em seguida, para cada tarefa específica dentro daquele projeto, os valores são respectivamente atualizados; e, por fim, o check in e a publicação do projeto são realizados para que o processo continue e siga ao próximo projeto da lista.

Porém (e sempre parece haver um porém 😕), as coisas não são tão simples assim. Acontece que, uma vez que o projeto esteja em check out, é possível realizar apenas uma ação de cada vez. Em outras palavras, primeiro é necessário atualizar o trabalho real para que só então seja possível atualizar o trabalho restante. Dessa forma, caso duas atualizações aconteçam sem que o projeto tenha sido publicado, apenas a última é a que irá efetivamente valer.

Tal situação acontece porque o banco de dados do Project Online precisa que a alteração inicial (atualização do trabalho real) seja processada e atualizada, para que assim o trabalho restante seja recalculado e validado internamente pelo mecanismo de agendamento da plataforma. Só quando esse processo estiver concluído é que será possível ajustar o valor do trabalho restante através do processo de automação, sem que haja perdas nas informações anteriormente inseridas no trabalho real.

Dessa forma, a única maneira de processar e atualizar as informações no Project Online é através da publicação do projeto – ou seja, quando o processo de automação atualiza o trabalho real, o projeto deve ser publicado para que só então o trabalho restante possa ser ajustado. O problema que encontramos nesse ponto específico é que o conector nativo do Project Online no Power Automate é configurado para não só publicar, mas também efetuar o check in do projeto. Assim, caso o projeto fosse publicado e o seu check in fosse efetuado, o processo de automação perderia em eficiência, pois seria necessário efetuar outro processo de check out no mesmo projeto para que então o ajuste no trabalho restante pudesse ocorrer.

Como garantir a eficiência no processo

Para resolver o problema e manter a melhor eficiência possível no processo de automação, podemos utilizar a API do SharePoint Send an HTTP Request to SharePoint, tantas vezes já mencionada em posts anteriores aqui no blog. Veja o processo abaixo:


Temos aqui 8 passos:

  1. A variável Id do projeto é capturada, com base em ações anteriores do fluxo
  2. O check in do projeto é forçado (conforme explicado aqui)
  3. O check out do projeto é realizado, utilizando o conector nativo do Project Online para o Power Automate
  4. As ações de atualização do trabalho real são realizadas para as tarefas, no contexto do projeto atual
  5. Aqui é que está o pulo do gato . Ao invés de utilizar o conector nativo do Project Online que publica e efetua o check in do projeto, utilizamos a API do SharePoint para efetuar apenas a sua publicação, sem realizar o check in. Isso garante que o projeto continue aberto, permitindo que outras atualizações possam continuar a ser feitas no contexto do projeto específico. Além disso, essa ação também garante que as atualizações no trabalho real sejam devidamente processadas e atualizadas para que então os respectivos ajustes no trabalho restante possam acontecer
  6. A próxima ação aplica um delay de 10 segundos, apenas por segurança. Estamos aqui dando um fôlego para que o Project Online possa processar as informações adequadamente (junto à publicação) antes de enviar a próxima leva de atualizações
  7. Aqui, estamos tomando conta de atualizar o trabalho restante para as tarefas do projeto, conforme apropriado
  8. Por fim, quando todas as atualizações estiverem devidamente processadas, podemos finalmente utilizar o conector nativo do Project Online para publicar o projeto e realizar o seu check in

A imagem abaixo detalha toda a configuração que precisa ser realizada para que a publicação do projeto possa acontecer:


...........................................................................................................................................

É isso aí, espero que tenha gostado e happy automation 😉

Um abraço e até o próximo post!