Antes de ir em frente e colocar uma restrição de verificação realmente terrível na tabela Catálogo, gostaria de solicitar algumas ideias melhores primeiro.
Desejo garantir que todas as fontes de dados compartilhadas em nosso servidor de relatório sejam implantadas em "/Data Sources". De vez em quando, recebemos um implantado por engano em algum outro diretório (principalmente se for um relatório atualizado do SSRS 2000, que não permitia especificar um local de implantação de fonte de dados diferente).
Posso colocar uma restrição de verificação feia no Catálogo ( Type != 5 OR ParentID = 'GUID of /Data Sources directory'
, ou similar) se for necessário, mas se houver uma opção melhor, prefiro usá-la.
Por que não alterar as permissões para que as pessoas não possam implantar fontes de dados em nada além desta pasta?
Portanto, remova "Gerenciar fontes de dados" de todas as pastas, exceto
/Data Sources
. Isso pode ser feito no nível raiz e, em seguida, definir permissões personalizadas em/Data Sources
Você pode precisar configurar uma função personalizada para isso se não puder alterar as existentes.
Não acho que a MS realmente garanta nada sobre o banco de dados SSRS subjacente, então você está entrando em um território sem suporte ao se preocupar com isso. Geralmente, é melhor evitar esse tipo de coisa em servidores de produção.
Você pode consultar fontes de dados e outros metadados do servidor de relatório programaticamente por meio de uma API de serviço Web exposta pelo SSRS. A API permitiria que você percorresse as pastas em busca de fontes de dados compartilhadas em locais onde não deveriam estar.
Caçar e relatar exceções é provavelmente a melhor maneira de lidar com isso, em vez de tentar evitá-lo na fonte. Você também pode consultar os metadados do relatório para procurar relatórios com referências a fontes fora das áreas designadas. Isso permite que você eduque os autores.
A MS fornece um utilitário chamado
rs.exe
que permite escrever scripts para fazer isso no VB.NET. Versões posteriores também podem oferecer suporte a C#, mas não fiz isso com nada mais recente do que o SSRS 2005. Essencialmente, ele cobre e fecha seu script com um pouco de clichê, compila e executa.Alguma documentação sobre o
rs.exe
utilitário e a API do serviço da Web do SSRS pode ser encontrada aqui , aqui e aqui.Só para ter uma ideia - em nosso ambiente, os desenvolvedores de relatórios têm acesso ao banco de dados de origem, mas os usuários de relatórios não. Todas as nossas fontes de dados são implantadas em uma única pasta e uma conta de serviço é usada para autenticação dessa fonte de dados.
Os desenvolvedores de relatórios não sabem a senha da conta de serviço.
Portanto, com essa configuração, se um desenvolvedor de relatórios implantar uma fonte de dados em outro lugar, o relatório não funcionará para consumidores de relatórios, apenas para outros desenvolvedores. (Tecnicamente, eles sempre devem usar "não sobrescrever a fonte de dados" ou todos os relatórios ficarão confusos até que o administrador modifique a "nova" fonte de dados com a conta de serviço.)
Espero que isto ajude!