SharePoint 4 Developers

Guia de referência adicional em desenvolvimento .NET / SharePoint

SharePoint 2010 Content Type Hub

1. agosto 2010 Marcel Medina Dicas e Truques (0)

Oi pessoal, tudo bem?

Nesse artigo veremos uma novidade no SharePoint Server 2010 chamada Content Type Hub, que permite a centralização e o compartilhamento de Content Types através do Metadata Service Application. Entenderemos seu funcionamento, configuração, maneiras de publicação e consumo de Content Types e, ao final, localização de erros de publicação.

Funcionamento

Bastante discutido na versão 2007, o compartilhamento de Content Types sempre foi uma questão problemática, pois uma vez que os Content Types são criados em um determinado Site Collection não podem ser compartilhados em outros Site Collections (não existe nenhum recurso OOTB disponível para isso).

Esse novo recurso é disponibilizado pelo Metadata Services Application, que mapeia o Site Collection em que compartilharemos os Content Types, o qual irá funcionar como um Hub.

A Figura 1 abaixo mostra o esquema de funcionamento do Content Type Hub:

 MSA
Figura 1 – Funcionamento (Publisher x Subscribers)

Seu funcionamento é bem simples, basicamente o Site Collection que serve como Content Type Hub publica os Content Types (Publisher) e através do Metadata Service Application os mesmos são distribuídos aos assinantes (Subscribers), podendo ser Site Collections que estão em diferentes Web Applications mesmo em diferentes Farms (se desejar).

O sincronismo dos Content Types é realizado por Timer Jobs que são executados no background. São eles:

  • Content Type Hub – Responsável pelo gerenciamento dos Content Types que serão publicados.
  • Content Type Subscriber – Responsável por publicar os Content Types do hub à Gallery de Content Types do Site Collection.

Configuração

Site Collection (Content Type Hub)

Para a criarmos o Content Type Hub é necessário que um Site Collection seja criado, para isso crie um novo Site Collection em Central Administration > Application Management > Create Site Collections, conforme Figura 2:

sitecol
Figura 2 – Criação do Site Collection

Na sequência habilite a Feature Content Type Syndication Hub em Site Actions > Site Settings > Site collection features, conforme Figura 3:

feature1
Figura 3 – Ativação da Feature Content Type Syndication Hub

OBS: Ao ativarmos essa Feature estamos provisionando o Site Collection para ser o nosso Hub.

Metadata Service Application

O Metadata Service Application é um serviço para compartilhamento de metadados, cuja principal característica é o armazenamento de keywords e term sets (o qual não abordaremos nesse artigo) e como característica opcional o de servir como Hub para Content Types.

Dentro do Farm é possível termos zero ou vários Metadata Service Application e esse critério depende totalmente do Design de sua solução. Nessa abordagem precisaremos apenas de um (1) serviço em execução, cuja connection consumirá um Content Type Hub apenas. Para consumir mais de um Content Type Hub, é necessário a criação de outro serviço para tal. Isso se aplica no caso em que você queira criar escopos diferentes de Content Types, por exemplo a separação de Content Type Hubs para consumo em uma Intranet e outro para Internet.

Aqui estamos abordando apenas o planejamento do Metadata Service Application como um Hub para Content Types, porém se você tiver interesse em explorar mais sobre esse serviço, acesse as referências deste artigo.

Podemos criar o Metadata Service Application acessando Central Administration > Application Management > Manage Service Applications > New > Managed Metadata Service. As Figuras 4 e 5 mostram os dados necessários para a criação do Service Application:

metadata3
Figura 4 – Criação de um novo Metadata Service Application (1/2)

metadata4
Figura 5 – Criação de um novo Metadata Service Application (2/2)

OBS: Um ponto importante a ser comentado é que uma vez criado o mapeamento da URL para o Content Type Hub, este não pode ser mudado via user interface. Se você quiser mudar a Url depois do Service Application estar criado, use essa abordagem para atualizar o Service Application.

Como não utilizaremos o Metadata Service Application para armazenamento de keywords e term sets, desabilite o default storage location desse serviço em Central Administration > Application Management > Manage Service Applications selecionando o Managed Metadata Service Connection e clicando em Properties, conforme a Figura 6:

metadataconn
Figura 6 – Configuração da Connection do Metadata Service Application (1/2)

E para finalizar desabilite os checkboxes conforme Figura 7:

metadataconn2
Figura 7 – Configuração da Connection do Metadata Service Application (2/2)

OBS: Apenas um (1) default storage location for keywords and term sets são permitidos em uma Web Application, portanto deixe essas opções disponíveis até que você decida realmente usá-la.

Publicação

Estou disponibilizando no Hub os Site Columns e Content Types referenciados nos posts Criando Site Columns Programaticamente via XML e Criando Content Types Programaticamente via XML, pois servirão de exemplo para publicação de Content Types.

OBS: Se você for utilizar os scripts já criados nos posts, faça o deploy apenas dos Site Columns. Para os Content Types utilize outra abordagem, conforme esse artigo Série Lições de Sharepoint – Lição 2 – Content Types – Parte I (conteúdo ainda não migrado. Favor solicitar pelo material caso tenha interesse).

Assim que esses objetos forem criados poderemos fazer a publicação dos Content Types, o que pode ser feito manualmente ou programaticamente. Irei mostrar ambos.

Cabe lembrar que, para efeito de conhecimento apenas, damos o nome de Content Type Syndication à maneira que os Content Types são organizados e compartilhados entre Listas e Libraries, o que é justamente que estamos fazendo com a publicação destes utilizando o Content Type Hub.

Manual

Nesse tipo de publicação acesse Site Actions > Site Settings > Site Content Types e para cada um dos Content Types criados acesse a opção de configuração Manage publishing for this content type conforme a Figura 8 abaixo:

publishing
Figura 8 – Publicação Manual de Content Types (1/2)

Na sequência já temos a opção de publicação, conforme a Figura 9:

publishing2 
Figura 9 – Publicação Manual de Content Types (2/2)

OBS: Pelo fato de estarmos publicando pela primeira vez, somente a opção Publish está disponível. Caso você já tenha publicado o Content Type, as outras duas opções estarão disponíveis e a atual desabilitada.

Apenas para clarificação, estou comentando as opções de publicação:

  • Publish – Disponibiliza o Content Type para ser consumido nos demais Site Collections que o referenciam.
  • Unpublish – Retrai a publicação do Content Type apenas. Sua cópia permanece nos demais Site Collections, porém seu status muda para não ser mais Read-Only.
  • Republish – Refaz a publicação do Content Type. Deve ser aplicado nos casos em houve alguma alteração no mesmo.

Código

Se preferir automatizar o processo de publicação (principalmente se você possui vários Content Types), utilize o código abaixo para tal tarefa.

Code Snippet
  1. using System;
  2. using System.Collections.Generic;
  3. using System.Linq;
  4. using System.Text;
  5. using System.IO;
  6. using CommonLibrary;
  7. using Microsoft.SharePoint;
  8. using Microsoft.SharePoint.Taxonomy;
  9. using Microsoft.SharePoint.Taxonomy.ContentTypeSync;
  10. using System.Configuration;
  11.  
  12. namespace PublishingContentTypes
  13. {
  14.     public class Program
  15.     {
  16.         public static void Main()
  17.         {
  18.             try
  19.             {
  20.                 string url = ConfigurationManager.AppSettings["Url"].ToString();
  21.                 bool publish = bool.Parse(ConfigurationManager.AppSettings["Publish"].ToString());
  22.  
  23.                 using (SPSite site = new SPSite(url))
  24.                 {
  25.                     using (SPWeb web = site.RootWeb)
  26.                     {
  27.                         string contentTypeXml = Path.GetFullPath("ContentTypes.xml");
  28.  
  29.                         List<string> list = XMLHelper.ReadXML(contentTypeXml);
  30.  
  31.                         foreach (string item in list)
  32.                         {
  33.                             SPContentType ctype = web.ContentTypes[item];
  34.                             if (ctype != null)
  35.                             {
  36.                                 if (publish)
  37.                                 {
  38.                                     // Publishing
  39.                                     ContentTypeHelper.ContentTypePublish(site, ctype);
  40.                                 }
  41.                                 else
  42.                                 {
  43.                                     // Unpublishing
  44.                                     ContentTypeHelper.ContentTypeUnPublish(site, ctype);
  45.                                 }
  46.                             }
  47.                         }
  48.                     }
  49.                 }
  50.             }
  51.             catch (Exception ex)
  52.             {
  53.                 Console.WriteLine(ex.ToString());
  54.             }
  55.         }
  56.     }
  57. }

OBS: Atente-se para a utilização do namespace Microsoft.SharePoint.Taxonomy, que faz referência ao assembly Microsoft.SharePoint.Taxonomy.dll, que por sua vez só está disponível apenas no SharePoint Server 2010 (diretório 14\ISAPI).

Criei também algumas bibliotecas para facilitar o trabalho de publicação, conforme podemos ver na solução abaixo:

script
Figura 10 – Solução para publicação de Content Types

O código abaixo refere-se à classe ContentTypeHelper.cs e mostra os detalhes para publicação e retração dos Content Types:

Code Snippet
  1. using System;
  2. using System.Collections.Generic;
  3. using System.Linq;
  4. using System.Text;
  5. using Microsoft.SharePoint;
  6. using Microsoft.SharePoint.Taxonomy;
  7. using Microsoft.SharePoint.Taxonomy.ContentTypeSync;
  8.  
  9. namespace CommonLibrary
  10. {
  11.     public static class ContentTypeHelper
  12.     {
  13.         public static void ContentTypePublish(SPSite hubSite, SPContentType ctype)
  14.         {
  15.             // Check to see whether the site is a valid hub site.
  16.             if (ContentTypePublisher.IsContentTypeSharingEnabled(hubSite))
  17.             {
  18.                 ContentTypePublisher publisher = new ContentTypePublisher(hubSite);
  19.  
  20.                 Console.WriteLine("Publishing the content type: " + ctype.Name);
  21.  
  22.                 // Check to see whether this content type has been published.
  23.                 if (publisher.IsPublished(ctype))
  24.                 {
  25.                     Console.WriteLine(ctype.Name + " is a published content type.");
  26.                 }
  27.  
  28.                 publisher.Publish(ctype);
  29.             }
  30.             else
  31.             {
  32.                 // The provided site is not a valid hub site.
  33.                 Console.WriteLine("This site is not a valid hub site");
  34.             }
  35.         }
  36.  
  37.         public static void ContentTypeUnPublish(SPSite hubSite, SPContentType ctype)
  38.         {
  39.             if (ContentTypePublisher.IsContentTypeSharingEnabled(hubSite))
  40.             {
  41.                 ContentTypePublisher publisher = new ContentTypePublisher(hubSite);
  42.  
  43.                 Console.WriteLine("Unpublishing the content type: " + ctype.Name);
  44.  
  45.                 // Check to see whether this content type has been published.
  46.                 if (!publisher.IsPublished(ctype))
  47.                 {
  48.                     Console.WriteLine(ctype.Name + " is not a published content type.");
  49.                 }
  50.                 else
  51.                 {
  52.                     publisher.Unpublish(ctype);
  53.                 }
  54.             }
  55.             else
  56.             {
  57.                 // The provided site is not a valid hub site.
  58.                 Console.WriteLine("This site is not a valid hub site");
  59.             }
  60.         }
  61.     }
  62. }

Faça o download da solução aqui.

Consumindo Content Types

Para consumir os Content Types do Content Type Hub, assegure-se que você está referenciando o Metadata Service Application que disponibiliza o serviço. Isso se aplica apenas no caso em que você está utilizando outro Web Application como Hub, do contrário você já está habilitado para usá-lo dentro de seu Web Application.

Verifique se você referenciou o serviço em Central Administration > Application Management > Configure service application associations. A Figura 11 mostra o cenário que acabo de comentar:

association
Figura 11 – Configurando a associação de serviços

OBS: Repare que possuo 2 Web Applications, onde o 81 funciona como Publisher e o 80 funciona como Subscriber. Ambos utilizam o mesmo serviço Managed Metadata Service.

No começo do artigo comentei rapidamente sobre os Timer Jobs que fazem o sincronismo dos Content Types, agora indo um pouco mais a fundo, se desejar acioná-los após a publicação ou retração de Content Types para uma rápida verificação, acesse Central Administration > Monitoring > Check job status e selecione o job definition desejado conforme Figuras 12 e 13:

jobdefinition
Figura 12 – Forcando a execução de jobs (1/2)

 jobdefinition2
Figura 13 – Forcando a execução de jobs (2/2)

OBS: Ao forçar a execução dos jobs acima, sempre dispare o Content Type Hub (Publisher) primeiro e depois os Subscribers. A execução é assíncrona, portanto apesar do status mudar rapidamente após o disparo do job, provavelmente este ainda estará em execução.

Observe também que existem 2 Subscribers (porta 80 e 81) mesmo estando o Hub na porta 81, justamente pois outros Site Collections dentro do mesmo Web Application podem usufruir dos Content Types.

Após a execução assíncrona, você tem a opção de verificar nos Site Collections Subscribers se os Content Types foram replicados com sucesso. Uma maneira é acessar os Content Types através de Site Actions > Site Settings > Site content types (grupo Galleries) e verificar se o Content Type está lá, conforme Figura 14:

happyend
Figura 14 – Content Types publicado :)

Outra maneira é exemplificada na seção “Troubleshooting” logo abaixo.

Troubleshooting

Nem tudo são flores no jardim, para chegar no resultado esperado você vai ter que enfrentar problemas que aparecem no meio do caminho. Bem vindo ao Mundo Real!

Para verificar erros de publicação temos 2 opções de verificação, tanto no Publisher quanto no Subscriber, o primeiro deles está disponível no Site do Content Type Hub em Site Actions > Site Settings > Content type service application error log (grupo Site Collection Administration), conforme a Figura 15 abaixo:

errorpublisher
Figura 15 – Verificando erros no Publisher

A segunda opção está disponível nos Site Collections Subscribers em Site Actions > Site Settings > Content Type Publishing (grupo Site Collection Administration) conforme Figura 16:

errorsubscriber1
Figura 16 – Verificando erros no Subscriber (1/2)

OBS: A figura acima mostra um resultado com sucesso, pois os Content Types foram publicados corretamente (o que deve acontecer em seu ambiente). Apenas para exemplificação de onde localizar possíveis erros esta figura está sendo utilizada.

Um outro ponto a ser comentado é com relação ao Refresh dos Content Types publicados. Se você desejar forçar uma atualização do Subscriber que foi alterado por algum motivo, deixe essa opção selecionada. Isso sobrescreverá os Content Types atuais com a versão do Publisher.

Acesse o link para o log de erros e também poderemos ver os erros propagados na publicação (os mesmos do Publisher) conforme Figura 17:

errorsubscriber2
Figura 17 – Verificando erros no Subscriber (2/2)

Dica do dia

***ATUALIZADO em 29/08/2011***
Features podem ser utilizadas para fazer o deploy de content types no Hub. Sempre são melhores práticas. Apenas esteja atento que isso criará uma dependência nos content types com uma FeatureId, e ao fazer isso, quando você publicar os content types a mesma Feature nos Site Collections Subscribers será necessária, para que você obtenha os content types publicados.

Outra opção é utilisar um Powershell script ou Console Application. Nesse caso quando você publicar os content types, não há nenhuma necessidade de ativar qualquer feature nos Site Collections Subscribers.

Espero que isso clarifique as opções que você tem ao fazer o deploy e publicação de content types. :)

Conclusão

Na versão do SharePoint Server 2010, o Metadata Service Application possibilita o compartilhamento de Content Types, promovendo Content Type Syndication em diferentes Site Collections de diferentes Web Applications e até em diferentes Farms!

Aproveite esse recurso para criar um novo Design compartilhando Content Types!

Referências:
http://www.wictorwilen.se/Post/Plan-your-SharePoint-2010-Content-Type-Hub-carefully.aspx
http://www.chakkaradeep.com/post/SharePoint-2010-Content-Type-Hubs
http://msdn.microsoft.com/en-us/library/ff394469.aspx
http://technet.microsoft.com/en-us/library/ee424403.aspx
http://technet.microsoft.com/en-us/library/ee519603.aspx


[]’s,

Marcel Medina

Clique aqui para ler o mesmo conteúdo em Inglês.

SharePoint 2010 Developer Dashboard

14. maio 2010 Marcel Medina Dicas e Truques (0)
Aprenda a habilitar o Developer Dashboard, como utilizar as APIs para exibir suas informa&#231;&#245;es de Tracing e como exibir os resultados de processamento de sua p&#225;gina graficamente.

Oi pessoal, tudo bem?

Durante o desenvolvimento de soluções, nós desenvolvedores temos a preocupação de entregar soluções funcionais, que estejam de acordo com os requisitos solicitados. Apesar de me preocupar com a performance de minhas aplicações, na maioria das soluções comerciais que tenho trabalhado performance não é um fator crítico.

Dependendo do cenário e se isso for um requisito? Como obter informações de diagnóstico em suas soluções no SharePoint 2010?

Justamente temos agora o Developer Dashboard que traz um painel de informações de tracing.

Nesse artigo vou mostrar como habilitar o Developer Dashboard, como utilizar as APIs para exibir suas informações de Tracing e como exibir os resultados de processamento de sua página graficamente.

Apresentando o Developer Dashboard

Assim como um desconhecido, antes de tudo gostaria de apresentar o Developer Dashboard, conforme podemos ver na Figura abaixo:

419BF2880E221BB9_581_0[1]
Figura 1 – SharePoint 2010 Dashboard Developer

OBS: Repare que a borda do Dashboard é de cor verde, pois não contém asserts e eventos críticos. Compararemos a mudança de cor mais adiante.

O lado esquerdo apresenta os eventos executados durante o processamento da página (http handler events) e seus respectivos tempos de execução, enquanto que no lado direito temos um mix contendo informações abrangentes e também detalhes do mergulho da requisição, como por exemplo as queries enviadas ao banco de dados.

O interessante é que os links revelam o Callstack da execução e mais detalhes, de acordo com a figura abaixo:

419BF2880E221BB9_581_1[1]
Figura 2 – Detalhes de uma query do banco de dados

Uma vez apresentados vamos partir para o que interessa.

Ativando e desativando o Developer Dashboard

Por padrão o Developer Dashboard não vem habilitado e para exibí-lo temos 3 possibilidades:

  • Código .Net

  • STSADM

  • PowerShell

Também temos 3 níveis de exibição do Dashboard: On, Off e OnDemand. Onde:

  • No nível de exibição "On" o painel sempre será exibido;

  • Em "Off" ele é desligado;

  • Em "OnDemand" um ícone é adicionado à página para exibição do painel apenas quando solicitado.

A figura abaixo nos exibe tal ícone:

419BF2880E221BB9_581_2[1]
Figura 3 – Ícone do Developer Dashboard

OBS: É importante ressaltar que se o Dashboard foi habilitado utilizando OnDemand, somente Administradores do Site Collection e Owners terão acesso. Membros e Visitantes não visualizarão o ícone. Em todas as ativações do Developer Dashboard utilizarei o nível de exibição OnDemand, que no meu ponto de vista é o ideal.

Código .Net

Podemos criar uma Feature que ative ou desative o Dashboard, ao invés de utilizar scripts. Dessa forma a ativação ou desativação pode ser feita diretamente pelo Site Collection Features.

Crie um projeto no Visual Studio 2010 do tipo Empty SharePoint Project chamado DeveloperDashboard. Escolha a opção para trabalharmos com uma Farm Solution. Seu projeto inicial deve estar semelhante à Figura 4:

419BF2880E221BB9_581_3[1]
Figura 4 – Projeto Inicial da Feature DeveloperDashboard

Adicione um Event Receiver à Feature conforme exibido na Figura 5:

419BF2880E221BB9_581_4[1]
Figura 5 – Adição de Event Receiver

A classe DeveloperDashboardEventReceiver será criada automaticamente, com os métodos comentados. Adicione o seguinte código para ativação e desativação da feature:

Code Snippet
  1. public override void FeatureActivated(SPFeatureReceiverProperties properties)
  2. {
  3.     SPWebService contentService = SPWebService.ContentService;
  4.     contentService.DeveloperDashboardSettings.DisplayLevel = SPDeveloperDashboardLevel.OnDemand;
  5.     contentService.DeveloperDashboardSettings.Provision();
  6. }
  7.  
  8. public override void FeatureDeactivating(SPFeatureReceiverProperties properties)
  9. {
  10.     SPWebService contentService = SPWebService.ContentService;
  11.     contentService.DeveloperDashboardSettings.DisplayLevel = SPDeveloperDashboardLevel.Off;
  12.     contentService.DeveloperDashboardSettings.Unprovision();
  13. }

No final seu projeto deve ficar parecido com o da figura abaixo:

419BF2880E221BB9_581_5[1]
Figura 6 – Projeto Final da Feature DeveloperDashboard

Compile e faça o deploy diretamente pelo Visual Studio 2010 em ambientes de desenvolvimento. Para ambientes de produção faça o deploy via STSADM conforme figura abaixo:

419BF2880E221BB9_581_6[1]
Figura 7 – Deploy da feature em Produção

No final nossa feature deve estar habilitada conforme a seguinte figura:

419BF2880E221BB9_581_7[1]
Figura 8 – Deploy da Feature Developer Dashboard

Faça o download da solução aqui.

STSADM

Abra o command e digite o seguinte trecho para habilitar o Developer Dashboard:

stsadm –o setproperty –pn developer-dashboard –pv OnDemand

Para desabilitar:

stsadm –o setproperty –pn developer-dashboard –pv Off

OBS: A opção –pv é case-sensitive.

Resultado:

419BF2880E221BB9_581_8[1]
Figura 9 – Execução dos comandos via STSADM

PowerShell

Uma outra possibilidade que temos é a utilização do PowerShell para a execução de scripts.

Para habilitar o Developer Dashboard:

$dash = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$settings = $dash.DeveloperDashboardSettings
$settings.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::OnDemand
$settings.Update()

Resultado:

419BF2880E221BB9_581_9[1]
Figura 10 – Execução de script de ativação via PowerShell

Para desabilitar:

$dash = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$settings = $dash.DeveloperDashboardSettings
$settings.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::Off
$settings.Update()

Resultado:

419BF2880E221BB9_581_10[1]
Figura 11 – Execução de script de desativação via PowerShell

Medindo performance e adicionando mensagens via Tracing

Uma vez que o Dashboard está ativo, podemos prosseguir com a adição de mensagens no Tracing do SharePoint 2010.

Conforme já dito essa é uma excelente maneira de você medir a performance de seu código e adicionar mensagens customizadas para monitoramento.

Para medirmos o tempo do trecho de código que temos a intenção de monitorar, devemos utilizar a classe SPMonitoredScope. Essa informação será disponibilizada no lado esquerdo do Dashboard.

Para adicionarmos mensagens de log, warnings ou assert messages utilizaremos a classe SPCriticalTraceCounter. Essa informação será disponibilizada no lado direito do Dashboard, e um link estará a disposição para visualizarmos os detalhes da mensagem.

OBS: O Callstack que se encontra nos detalhes da mensagem pode adicionar alguns Kb na página. Portanto fique atento ao crescimento da quantidade de mensagens customizadas que você tiver, elas vão aumentar o tamanho (Kb) de sua página caso o Dashboard esteja ativado.

Adicione um novo projeto do tipo Visual Web Part chamado Tracing. A solução deve ficar parecida com a figura abaixo:

419BF2880E221BB9_581_11[1]
Figura 12 - Projeto da Web Part de Tracing

No arquivo TracingWebPartUserControl.ascx.cs adicione o código abaixo:

Code Snippet
  1. using System;
  2. using System.Web.UI;
  3. using System.Web.UI.WebControls;
  4. using System.Web.UI.WebControls.WebParts;
  5. using Microsoft.SharePoint.Utilities;
  6.  
  7. namespace Tracing.TracingWebPart
  8. {
  9.     public partial class TracingWebPartUserControl : UserControl
  10.     {
  11.         protected void Page_Load(object sender, EventArgs e)
  12.         {
  13.             // Using class for tracking the execution time
  14.             using (SPMonitoredScope sc = new SPMonitoredScope("LoadMeter"))
  15.             {
  16.                 for (uint i = 0; i < 10; i++)
  17.                 {
  18.                     // Adding custom messages
  19.                     SPCriticalTraceCounter.AddDataToScope(i, "Loop For", 15, string.Format("Mensagem monitorada - {0}", i.ToString()));
  20.                 }
  21.             }
  22.         }
  23.     }
  24. }

Classe TracingWebPartUserControl

Esse código contém as duas classes SPMonitoredScope e SPCriticalTraceCounter conforme já comentamos. Vale ressaltar que o traceLevel (3º parâmetro do método AddDataToScope) pode ser:

  • 1 – Critical
  • 4 - Exception (Watson)
  • 6 – Assert
  • 8 – Warning
  • 10 – Unexpected
  • 15 - Monitorable

Realize a adição da Web Part (1), salve (2) e logo após visualize o Dashboard (3) conforme figura abaixo:

419BF2880E221BB9_581_12[1]
Figura 13 – Adição da Web Part de Tracing

Veja o Dashboard, seu enquadramento não está mais da cor verde conforme Figura 1. Temos a cor vermelha que mostra que temos asserts e eventos críticos ocorrendo (no nosso caso as mensagens criadas): 

419BF2880E221BB9_581_13[1]
Figura 14 – Dashboard com Time Scope e Mensagens adicionadas

Clique sobre uma das mensagens e observe que podemos ver os detalhes do Callstack e da mensagem:

419BF2880E221BB9_581_14[1]
Figura 15 – Mensagem customizada exibida nos detalhes

Faça o download da solução aqui.

Visualização do Dashboard com gráfico

Podemos incrementar o Dashboard com um gráfico de visualização chamado Developer Dashboard Visualizer criado por Jaap Vossers que consiste em um UserControl que faz utilização do JQuery para exibição dos eixos eventos x tempos de execução (lado esquerdo do Dashboard).

Esse projeto está disponível no Codeplex pelo link: http://devdashvis.codeplex.com/

Baixe o pacote wsp e instale-o utilizando o STSADM, conforme a figura abaixo:

419BF2880E221BB9_581_15[1]
Figura 16 – Ativando o Developer Dashboard Visualizer

Os http handler events são exibidos imediatamente acima do dashboard:

419BF2880E221BB9_581_16[1]
Figura 17 – Visualização Gráfica

Nesse artigo vimos como habilitar o Developer Dashboard do SharePoint 2010. Vimos que informações de diagnóstico e mensagens de tracing são exibidas no output da página ao browser que fez o request. Tais informações podem ajudar na clarificação de erros ou resultados indesejados durante o processamento de sua solução no SharePoint 2010.

Espero que essas dicas sejam úteis.

Referências para a criação desse post:
http://blogs.msdn.com/pandrew/archive/2010/03/26/sharepoint-2010-developer-dashboard-for-debugging-code.aspx
http://weblogs.asp.net/jcortez/archive/2010/03/16/developer-dashboard-in-sharepoint-2010.aspx
http://devdashvis.codeplex.com/

[]’s

Marcel Medina

Clique aqui para ler o mesmo conteúdo em Inglês.