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!

quinta-feira, 31 de março de 2022

Integração do Project Online com o Microsoft Teams - Adaptative Cards

 Olá pessoal –

Por aqui continuamos a todo vapor na exploração de soluções automatizadas que permitam às equipes trabalhar de maneira mais produtiva, com o objetivo de facilitar a comunicação e a colaboração, tornando o gerenciamento de projetos mais eficaz e inteligente.

Atualmente, um número muito grande de organizações utiliza o Microsoft Teams para possibilitar que as diferentes equipes de trabalho possam se comunicar e colaborar de maneira simples e eficiente, e por muitas vezes há o desejo de que tal cenário possa ser, de certa forma, estendido à gestão de projetos disponível na plataforma PPM – uma vez que os recursos e funcionalidades padrão do Teams não possuem uma integração nativa com o Project Online.

Para dar início à exploração das possibilidades de integração entre o Project Online e o Microsoft Teams, decidi começar pelos Adaptative Cards: de maneira bem resumida, eles são cartões abertos que podem ser formatados para exibir informações nos mais variados formatos, a depender das necessidades apresentadas. Para conhecer um pouco mais sobre os adaptative cards, sugiro que você dê uma olhada na galeria de exemplos e templates disponibilizada pela Microsoft. Você encontrará coisas muito legais 😎


A ideia aqui é começar pelo básico: na minha empresa fictícia foi criado um novo time no Microsoft Teams, com o objetivo de que seja utilizado pelos membros do escritório de projetos, gerentes de projetos e demais interessados para troca de informações, aconselhamento e esclarecimento de dúvidas, armazenamento dos modelos utilizados pelas equipes (documentos, planilhas, apresentações e etc.), disponibilização de processos, procedimentos e treinamentos e todos os demais aspectos e artefatos que estejam relacionados à gestão de projetos na organização.

Dessa forma, nosso objetivo será o de desenvolver um fluxo automatizado no Power Automate para que uma publicação seja feita no Microsoft Teams (através de um adaptive card) sempre que um novo projeto for criado no Project Online.

O flow

O flow é relativamente simples: assim que um novo projeto for criado, algumas informações devem ser coletadas e um novo post deve ser feito no Microsoft Teams:


Para começar, utilizei o gatilho nativo do Project Online When a new project is created. Em seguida, mais duas ações: a) iniciar uma variável para capturar a URL do ambiente do PWA; b) uma pausa de 30 segundos, para garantir que todas as informações tenham sido processadas adequadamente antes de efetivamente postar a mensagem no Teams.

Em seguida utilizei a ação Send an HTTP request to SharePoint, da qual já falei inúmeras vezes aqui no blog, para capturar as informações do projeto recém criado:


Uma vez capturadas as informações desejadas, é necessário utilizar a ação Post adaptative card in a chat or channel para passar as intruções a respeito de como o cartão deverá ser configurado:


Abaixo vou deixar a instrução completa do exemplo que utilizei para construir o meu adaptative card. Vou destacar em amarelo os itens que você precisará ajustar, de acordo com o que desejar exibir:

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

{

    "$schema": "http://adaptivecards.io/schemas/adaptive-card.json",

    "type": "AdaptiveCard",

    "version": "1.0",

    "body": [

        {

            "type": "TextBlock",

            "text": "Novo projeto: <insira o nome do projeto aqui>",

            "id": "ProjectName",

            "spacing": "Medium",

            "horizontalAlignment": "Center",

            "size": "Large",

            "weight": "Bolder",

            "color": "Accent"

        },

        {

            "type": "TextBlock",

            "text": "Um novo projeto foi criado. Abaixo você poderá visualizar os detalhes",

            "id": "Subheader",

            "separator": true

        },    

        {

            "type": "TextBlock",

            "text": "<insira o título do seu campo personalizado aqui>",

            "id": "Campo1Header",

                "weight": "Bolder",        

            "wrap": true

        },

            {

            "type": "TextBlock",

            "text": "<insira o campo desejado aqui>",

            "id": "Campo1",

            "wrap": true,

                "separator": true 

        },

            {

            "type": "TextBlock",

            "text": "<insira o título do seu campo personalizado aqui>",

            "id": "Campo2Header",

                "weight": "Bolder",        

            "wrap": true     

        },

            {

            "type": "TextBlock",

            "text": "<insira o campo desejado aqui>",

            "id": "Campo2",

            "wrap": true,

                "separator": true 

        },

            {

            "type": "TextBlock",

            "text": "<insira o título do seu campo personalizado aqui>",

            "id": "Campo3Header",

                "weight": "Bolder",

            "wrap": true

        },

            {

            "type": "TextBlock",

            "text": "<insira o campo desejado aqui>",

            "id": "Campo3",

            "wrap": true,

                "separator": true 

        },

            {

            "type": "TextBlock",

            "text": "Projeto criado por: <insira o nome do proprietário do projeto aqui>",

            "id": "CriadoPor",

            "wrap": true

        }

     ]

}

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

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


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

E aí, o que achou? Deixe seu feedback pra eu saber se você gosta desse tipo de conteúdo 😉

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

terça-feira, 29 de março de 2022

Como forçar o check in de projetos

 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.

 Para forçar o check in de um projeto no Project Online através do Power Automate, é possível utilizar a ação Send an HTTP request to SharePoint, conforme print abaixo:


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.

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

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

sexta-feira, 18 de fevereiro de 2022

Adicionando membros de equipe ao projeto automaticamente

 Olá pessoal –

No Microsoft Project Online, para que os recursos corporativos tenham condições de acessar os sites de projeto para colaborar através da criação e do gerenciamento de riscos, problemas, documentos, entre outros artefatos, eles precisam obrigatoriamente fazer parte da equipe do projeto.

Recentemente um cliente entrou em contato pois tinha um requisito de negócio importante: o processo de adição dos membros de equipe a um projeto recém criado deveria acontecer de maneira automatizada. Nessa organização, quando um novo projeto é criado, todos os colaboradores devem ganhar acesso ao site de projeto imediatamente, e o fato de os gerentes de projeto terem que adicioná-los manualmente estava causando muitos problemas – pois infelizmente nem todas as pessoas seguem os processos.

Para facilitar a vida dos gerentes de projeto e garantir o cumprimento dos requisitos de negócio, mais uma vez, o Power Automate foi utilizado para automatização dos processos. Nesse post vou detalhar o passo-a-passo caso você precise fazer algo parecido na sua empresa 😉.

Nota: é muito importante ressaltar que, sem a colaboração do meu grande amigo Alisson Scalco, este problema não teria sido resolvido. Então, fica aqui o meu agradecimento público a este grande profissional.

O flow

O gatilho When a new project is created (V2) foi utilizado para determinar quando o flow deve ser iniciado:


Na propriedade Select Query desse gatilho apenas duas colunas foram selecionadas para melhorar a eficiência do flow – são elas ProjectId e ProjectName:


Uma vez disparado o gatilho, foi necessário paralizar o flow por um certo tempo, pois as próximas ações não podem ocorrer imediatamente após a criação do projeto. Essa pausa precisa ser adicionada pois o gerente de projetos pode ainda estar trabalhando com o projeto (ou seja, o projeto pode estar em check-out) ao mesmo tempo em que o Power Automate tenta executar as ações do flow. É difícil determinar com precisão por quanto tempo o flow deve ser paralisado, pois não sabemos exatamente quando o gerente de projetos finalizará suas ações, mas uma boa alternativa é calcular um intervalo até que se atinja um horário fora do expediente de trabalho (por exemplo, até às 22 horas), onde se espera que o gerente de projetos não mais esteja trabalhando com o projeto em questão – e assim, espera-se, o projeto não mais esteja em check-out.

Após configurar a pausa, a próxima ação irá listar o projeto para que seja possível trabalhar com as suas propriedades:


Em seguida é preciso adicionar uma condição para verificar se o projeto está em check-out. Caso a condição seja verdadeira, é possível enviar um e-mail à equipe de PMO ou ao gerente de projetos para informar que não foi possível adicionar os membros de equipe automaticamente:


Entretanto, caso a condição seja falsa (ou seja, o projeto não encontra-se em check-out), será possível prosseguir e adicionar os membros de equipe ao projeto. A primeira coisa a se fazer é efetivamente colocar o projeto em check-out:


Em seguida, será preciso listar todos os recursos ativos da organização para que seja possível adicioná-los como membros de equipe ao projeto. Para listar os recursos adequadamente, foi utilizada a ação Send an HTTP Request to SharePoint, que neste exemplo foi renomeada para ‘Get Resources’ (para saber mais sobre esta ação, veja este link). Perceba que a instrução definida na ação está obtendo a lista de recursos ativos do Project Online, desde que não sejam recursos genéricos:


Aqui a instrução completa:

/_api/ProjectData/[en-us]/Resources()?$Select=ResourceId&$Filter= TypeName eq 'Work Resource' and ResourceIsActive eq true and ResourceIsGeneric eq false

Como a ação ‘Get Resources’ irá trazer a lista de todos os recursos ativos do Project Online, e como cada um deles terá de ser adicionado como membro de equipe no projeto, é necessário utilizar a ação Apply to each para especificar que esta ação deve ser aplicada a todos os registros obtidos (para saber mais sobre esta ação, veja este link). Dentro da ação ‘Apply to each’ é possível utilizar uma expressão para especificar o resultado que deve ser utilizado como entrada:


body('Get_Resources')?['value']

Dessa maneira será possível utilizar mais uma vez a ação Send an HTTP Request to SharePoint para adicionar os recursos como membros de equipe do projeto (perceba que a ação foi renomeada para ‘Add Resources’):


/_api/ProjectServer/Projects('<projectId>')/Draft/ProjectResources/AddEnterpriseResourceById('<enterpriseResourceId>')

Lembre-se de substituir os conteúdos dinâmicos com os resultados obtidos das ações anteriores, conforme destacado acima.

Como ação final, bastará publicar o projeto ao final do loop de adição de recursos para garantir que eles sejam devidamente sincronizados com o site de projeto:


Quando um novo projeto for criado, o flow será disparado, e como consequência os membros de equipe serão devidamente adicionados ao projeto:



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

Como mencionado no início do post, fica aqui minha nota de agradecimento ao Alisson Scalco pela sua fundamental colaboração nesse post. Valeu demais, Alisson!

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

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