Olá pessoal –
Os leitores mais
atentos desse blog já devem ter percebido que, na maioria dos cenários em que é
necessário construir um processo de automação do Project Online através do Power Automate, a realização do check
out dos projetos é obrigatória.
Tal obrigatoriedade
é observada porque, sempre que uma interação com o Project Online tenha como objetivo
editar/modificar um parâmetro (seja ele um parâmetro da entidade Projects
– como por exemplo um campo personalizado; seja ele um parâmetro da entidade Tasks
– como a data de término de uma tarefa do cronograma) o projeto deve primeiramente
ser bloqueado para edição, impedindo que outros usuários tenham condições de manipular
o objeto (projeto) ao mesmo tempo.
Porém, e se
durante o processo de automação o projeto já se encontrar bloqueado por outra
pessoa? O que devemos fazer caso algum gerente de projeto se esqueça de efetuar
o check in do projeto ao finalizar o seu trabalho, mantendo assim o objeto
bloqueado no servidor?
Faz uns 2 anos, eu fiz um vídeo com o MVP Renato Romão ensinando como obter a relação de projetos em check out no Project Online via Power Automate.
Em teoria, ao obter a relação de projetos bloqueados, alguém poderia agir de maneira proativa, seja conversando com os gestores para que efetuem o check in dos projetos, seja forçando o check in por conta própria...
Porém, para um
cliente com o qual venho trabalhando atualmente, essa abordagem ainda seria insuficiente.
Esse cliente roda todo sábado um processo automatizado que tem como objetivo
obter informações de um sistema financeiro (ERP) para então alimentar algumas
tarefas no Project Online, atualizando os custos do cronograma com base nos lançamentos
realizados pelo time de controladoria. E, para garantir que o processo possa
acontecer independentemente de o projeto encontrar-se em check in ou não, a
decisão foi radical: no momento da execução do fluxo, caso algum projeto esteja
em check out, o check in deve ser forçado para que as tarefas possam ser
atualizadas corretamente.
A instrução Uri deverá
explicitar que o check in será forçado para cada projeto encontrado em check
out:
/_api/ProjectServer/Projects('<projectId>')/Draft/checkIn(true)
Lembre-se de
substituir os conteúdos dinâmicos com os resultados obtidos das ações
anteriores, conforme destacado acima.
Dessa forma,
toda vez que o fluxo é acionado será possível garantir que todos os projetos
serão atualizados, mesmo que algum gerente de projetos tenha esquecido de
efetuar o check in ao finalizar a atualização do cronograma.
....................................................................................................
⚠ É importante destacar que você
deve utilizar esse recurso apenas em casos extremos, pois ao forçar o check in
de um projeto a sessão ativa será encerrada e o gerente de projetos poderá eventualmente
perder todo o seu trabalho caso não o tenha salvo.
....................................................................................................
Nenhum comentário:
Postar um comentário