"Access token has expired, resubmit with a new access token" (nível avançado)

[Joao Raulino]

Boa galera!

Hoje ao chegar no trabalho tive a grata surpresa de ver que alguns dos meus datasets falharam na ultima atualização automática:

Esse dataset do exemplo tem duas fontes de dados: uma lista no SharePoint e um dataflow no serviço online. Na mensagem de erro inicial foi indicado que as credenciais do SharePoint estavam invalidas:

Portanto, acessei as conexões criadas no gateway e atualizei as credenciais de acesso para a conexão ao SharePoint. Porém, ao fazer uma nova atualização do dataset um novo erro apareceu, desta vez dizendo que o token de acesso estava expirado:

Esse demorou um pouco mais de tempo para resolver, mas depois de algumas buscas na internet descobri que o problema podia estar na conexão ao dataflow criada no gateway. Para testar esse ponto, acessei o gateway e atualizei as credenciais de acesso para a conexão ao dataflow e voilà:

Resolver esse problema, porém, me gerou algumas duvidas... especialmente porque sei que vai acontecer de novo:

1. Como mostrado na primeira screenshot, aparentemente o problema de "token expirado" acontece de 7 em 7 dias. Alguém sabe o porque disso?
2. Visto que o dataflow já esta na cloud (serviço online), porque é que ainda assim temos que configurar uma conexão de gateway para ele?
3. Existe alguma maneira de mesclar conexões on-premises (e.g.: SharePoint) com conexões cloud (e.g.: dataflow) e mesmo assim manter a atualização automática funcionando sem problemas por um longo periodo? Ou vamos ser sempre obrigado a atualizar as credenciais?

Abs!

[Michele]

Olá @Joao Raulino!

Não sei sobre o erro que aconteceu com você, pois conosco isso nunca ocorreu.

Já sobre a necessidade de configurar uma conexão de gateway no dataflow eu acho que é loucura do PBI, porque faz parte da estrutura, mas aqui a gente apenas desativa a necessidade do gateway e seguimos a vida, funciona normalmente justamente porque já está tudo online.

Sobre mesclar as conexões não entendi bem o questionamento, mas na nossa estrutura temos um DataFlow "pai" que busca as coisas da nossa fonte no SQL e das fontes no SharePoint, então a necessidade de conexão/gateway fica apenas nele, acho que até evita dar erros. Daí nos DataFlows "filhos" apenas conectamos desse DataFlow "pai" e que já tá tudo na nuvem.

A partir desses DataFlows "filhos"  conectamos nossos Conjuntos de Dados. Posso dizer que a ocorrência de erros nessa nossa estrutura não chega a 1%, tudo funciona bem redondinho, quando dá problema é lá da fonte inicial (banco de produção do sistema) para a nossa ETL no SQL.

Espero ter ajudado de alguma forma, qualquer novidade coloca aqui pra gente 🙂

[Joao Raulino]

Oi @Michele!

De fato me parece que o problema de credenciais ocorre sempre que se fazem mudanças no conjunto de dados. Tivemos que escrever uma documentação para lembrar o pessoal de sempre atualizar elas quando fizerem updates no modelo.

Achei bem interessante essa opção com dois dataflows em série! Teve alguma razão específica para voces estruturarem assim?

Abs!

[Michele]

Oi @Joao Raulino

Essa alteração no Conjunto de Dados que você fala seria uma alteração normal? Não deveria dar problema nisso não, estranho, a gente nunca teve isso. Será que não é a forma da conexão?

Sobre a nossa estrutura, quando eu comecei na empresa cada relatório era plugado diretamente no SQL, em tabelas "brutas", mas também eram apenas 4 relatórios, hoje são mais de 300 (considerando os modelos "padrão" com N clientes publicados). Então estruturei tabelas tratadas no SQL e no começo também puxava cada relatório, daí foi dando problema as vezes no SQL e as vezes no Sharepoint, então criei o DataFlow principal e por um tempo ele atendeu bem. Dessa forma, não deu mais problema enquanto não tínhamos muitos relatórios e com isso também buscamos tudo uma única vez, tanto do SharePoint quanto do SQL.

Daí com o passar do tempo a quantidade de relatórios só foi crescendo e chegou num ponto que para melhor organização e também balanceamento das atualizações acabamos criando esses DFs "filhos". Temos 2 DFs, um para relatório das áreas internas e outro para relatórios de clientes (este tem relatórios personalizados e Conjuntos de Dados de relatórios "padrão"), daí podemos agendar atualização de Conjuntos de Dados/Relatórios ao mesmo tempo, cada um no seu DF "filho" correspondente.

Na nossa estrutura depois ainda defini uso de Conjunto para os relatórios "padrões" de clientes, pois assim ao atualizar o Conjunto todos os relatórios dos clientes eram atualizados, agendar cada um estava ficando inviável também, além de que queriam que todos atualizassem logo no começo do mês e agendar todos para o mesmo dia era impossível.

Hoje essa estrutura toda funciona muito bem, temos sofrido agora apenas com concorrência de uso, das atualizações, etc. e tivemos que migrar para o A2 do Embbeded, mas faz parte, sabíamos que uma hora isso ia ser necessário.