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!