Limite de 300 registros na call REST api ao SharePoint

 Olá pessoal –

Meio que sem querer, me deparei recentemente com uma limitação do SharePoint no que se refere a quantidade de registros que podem ser obtidos através de uma call à sua api, ao utilizar o Power Automate.

Tanto aqui no blog quanto no meu canal do YouTube eu falo bastante sobre a utilização do Power Automate para turbinar o uso do Project Online, e na quase totalidade dos casos eu acabo utilizando a opção de realizar uma call ao SharePoint através da ação Send an HTTP Request to SharePoint, dada sua versatilidade e flexibilidade.

Pois bem... ao realizar um trabalho para um cliente, eu tinha a necessidade de obter a lista de todos os projetos salvos no Project Online, para então executar uma série de ações em alguns projetos específicos. Acontece que, ao estabelecer a conexão entre o Power Automate e o SharePoint, o número de registros obtidos do banco de dados era bem menor do que o número de projetos que de fato existiam no ambiente. Pra ser mais preciso, apenas 300 registros estavam sendo obtidos toda vez que o fluxo era iniciado:

Após bater um pouco a cabeça e entender que não havia nada nos filtros que estivesse limitando o número de registros obtidos pela consulta, percebi que havia uma limitação do próprio conector do SharePoint, que fixava em 300 o número máximo de registros que poderiam ser disponibilizados ao Power Automate a cada chamada feita à sua API.

Dessa forma, caso você esteja criando flows que obtenham dados do SharePoint, mantenha-se atento a essa restrição, pois ela pode acabar gerando alguns problemas não disponibilizando todos os registros que efetivamente deveriam ser processados. No meu caso específico, minha consulta estava obtendo dados da entidade projetos – porém, existem inúmeras outras entidades que tendem a ter um número muito maior de registros (como Tarefas e Atribuições, por exemplo).

Para resolver o meu problema, tive que limitar a consulta para um tipo de projeto específico, de modo a aplicar as ações apenas ao grupo de projetos que deveriam ser submetidos ao fluxo (conforme exemplo abaixo):

Entretanto, se no seu caso a necessidade seja executar a ação para todos os projetos independentemente do tipo, uma solução viável talvez seja agrupar os projetos por uma determinada categoria (Tipo, Proprietário, Status, Departamento...) e então executar as ações para cada um desses grupos individualmente, de modo que o limite de 300 registros não seja ultrapassado. A mesma lógica se aplica a qualquer outro tipo de registros a serem obtidos (por exemplo, ao tentar obter informações de tarefas, a melhor opção é primeiro filtrar por projeto, assim as tarefas serão obtidas de maneira individual, de acordo com o projeto ao qual pertençam, reduzindo assim o escopo de registros a serem processados na chamada).

Enfim, para você que desenvolve automações e utiliza o Power Automate e o Project Online (SharePoint) com frequência, fica aí uma lição aprendida que deve ser observada com atenção nos seus próximos desenvolvimentos 😉.

Um forte abraço e até a próxima!

Project Web App Usage

 Project web app usage

Olá pessoal –

A Microsoft disponibiliza um importante material no seu site para tratar sobre as limitações do Project Online, no que se refere a desempenho e performance da plataforma – assim como da sua capacidade de armazenamento.

Um item importante da documentação se refere a cota destinada ao banco de dados do Project Online, que por padrão comporta 25GB por instância:

Esse limite de 25GB está relacionado diretamente com os objetos que existem no contexto do Project Online, como os Projetos (e seus respectivos cronogramas), Recursos, Tipos de Projeto da Empresa, Campos Personalizados da Empresa, etc. É importante lembrar que os sites de projeto e seus artefatos (documentos, riscos, problemas e demais listas customizadas) não entram nessa conta, pois são contabilizados no espaço total do SharePoint disponível na coleção de sites do PWA.

Ao navegar à página de Configurações Adicionais do Servidor do seu ambiente do Project Online, você poderá verificar se a utilização do banco de dados está se aproximando do limite de espaço disponibilizado:

É interessante observar que, nesse exemplo, mesmo estando próximo de atingir o limite de 25GB no que se refere aos objetos dentro do âmbito do Project Online, o consumo na camada de SharePoint é praticamente inexistente, como se pode verificar na imagem abaixo:

Fatores que contribuem para consumo do espaço

São vários os fatores que contribuem para um consumo elevado do banco de dados do Project Online. Entre eles, vale a pena citar:

• Campos Personalizados de fórmula associados à entidade Tarefa

Caso a sua organização utilize um grande número de campos personalizados do tipo fórmula para a entidade de tarefas, vale a pena revê-los para identificar se todos os campos são necessários e devem ser mantidos no ambiente. Lembre-se que campos do tipo fórmula são calculados e processados toda vez que um cronograma é aberto, salvo e publicado.

• Projetos com uma longa duração

Veja o exemplo abaixo:

O primeiro projeto dessa lista tem uma duração total de 26.163 dias ⚠, com a data final prevista para 2120 💀 ! Considerando que estou escrevendo esse post em 2022, serão necessários mais 98 anos para que este projeto seja finalizado – isso, é claro, se tudo sair conforme o plano atual 😊.

A depender da quantidade de tarefas no cronograma desse projeto, serão necessárias milhares (senão milhões) de linhas para registrar e armazenar todas as atribuições, a distribuição das horas, dos custos, das informações de linha de base, etc. Adicionalmente, o próprio processamento das informações pelo Microsoft Project (quando da abertura, do salvamento e da publicação do projeto) ficará comprometido, aumentando o risco de corrupção do arquivo. Abaixo é possível ver um exemplo de 4 cronogramas reais com mais de 35 mil atribuições, um número extremamente alto e definitivamente não recomendável:

Em casos assim, o recomendado seria decompor os cronogramas em partes menores e mais gerenciáveis, que poderiam estar conectadas entre si. Dessa forma, quando uma fase do projeto estiver concluída, o cronograma pode ser arquivado adequadamente, sem comprometer as etapas futuras.

Apenas para se ter uma ideia do volume de dados processados e armazenados, veja a quantidade de atribuições para cada um dos projetos da tabela acima, numa hierarquia de ano/mês:

Agora pense na quantidade de transações que são necessárias para processar esses dados a cada vez que o cronograma é aberto, salvo ou publicado.

Objetos adicionais

Fique atento também à quantidade de objetos adicionais que eventualmente existam no seu ambiente. Mesmo que não haja um processamente explícito desses elementos, eles podem ter uma contribuição significativa no consumo de espaço do seu banco de dados. Entre esses objetos, vale a pena destacar:

• Demais Campos Personalizados da Empresa e Tabelas de Pesquisa
• Calendários Empresariais
• Modos de Exibição Empresariais
• Tipos de Projeto da Empresa
• Grupos e Categorias de Segurança personalizados
• Quantidade de Projetos e Recursos
• Quantidade de Timesheets (Quadros de Horários)

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

Na posição de administrador do Project Online, estabeleça um cronograma de revisões periódicas no seu ambiente para garantir que a quantidade de dados utilizados esteja em acordo com o volume de espaço disponibilizado, para não correr nenhum risco de ter o ambiente paralisado ou a utilização temporariamente suspensa.

Espero que tenha ajudado, e até a próxima!

Relatório de projetos em check-out

 Olá pessoal –

Há um certo tempo eu venho falando aqui no blog sobre as diferentes possibilidades e opções de check in e check out no Project Online através da utilização do Power Automate. Entender esse conceito é muito importante para aqueles que precisam automatizar as rotinas do escritório de projetos, uma vez que na grande maioria das vezes é preciso colocar um projeto em edição (check out) para que então seja possível realizar ações de atualização em suas propriedades.

Como existem incontáveis cenários de automatização no Project Online, assim como existem também inúmeras restrições e impedimentos que podem ser aplicáveis de acordo com a característica de cada negócio, pode haver situações nas quais forçar o check in dos projetos não seja uma opção.

Dessa forma, através da utilização da API do Project Server é possível criar um relatório (no Excel ou no Power BI) que identifique dinamicamente os projetos em check out.

Para construir o relatório, utilizando a plataforma de sua preferência, efetue uma conexão à API do Project Server da sua organização:

https://<URL da sua organização>.sharepoint.com/sites/pwa/_api/ProjectServer

Ao se conectar ao ambiente do Project Online, clique na opção de expansão da tabela Projects:

Em seguida, selecione os campos que deseja utilizar no relatório. Como sugestão, você pode utilizar os seguintes campos:

• Id
• Name
• CheckedOutDate
• IsCheckedOut
• CheckedOutBy

Em seguida, você deverá filtrar todos os projetos para os quais o campo IsCheckedOut é igual a TRUE:

Caso você queira saber quem é o gerente de projeto que efetuou o check out em cada um dos projetos listados, você poderá expandir a coluna CheckedOutBy:

Assim você terá em mãos todos os campos necessários para gerar o relatório, e então poderá entender quais são os projetos em check out, quem são os responsáveis pelo check out e até há quanto tempo cada projeto encontra-se bloqueado:

Por hoje era isso. Espero que ajude 😊

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!

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!

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!