Neste post vamos falar um pouco sobre intrumentação no SharePoint 2010, como podemos controlar a execução de nossos processos para descobrir problemas de performance e o controle de erros. Os recursos abordados neste artigo serão uma introdução à developer dashboard e como gravar informações nela e o registro de erros no log do SharePoint e do Windows.

Developer Dashboard

A developer dashboard é um painel de acompanhamento da execução da página, nela aparecem informações importantes para descobrir problemas de performance ou erros. Por padrão a developer dashboard está desabilitada no SharePoint, para habitá-la é necessário executar um comando através de Power Shell do SharePoint 2010. A listagem 01 exibe o comando em detalhes.

$service = [Microsoft.SharePoint.Administration.SPWebService]::ContentService
$addsetting =$service.DeveloperDashboardSettings

$addsetting.DisplayLevel =

      [Microsoft.SharePoint.Administration.

          SPDeveloperDashboardLevel]::OnDemand

$addsetting.Update()

Listagem 01: Habilitando a developer dashboard

A developer dasboard pode ser utilizada em três modos:

• On: é exibida em todas as páginas automaticamente;
• OnDemand: não é exibida nas páginas mas o usuário pode ativá-la manualmente clicando no ícone que ficar perto do seu login, conforme mostra a imagem 01;
• Off: desligada e nunca é exibida.

Imagem 01: Ativando/desativando a developer dashboard em modo OnDemand

Ao ativar a developer dashboard na página (na imagem 02 é possível observar a Developer Dashboard ativa, ela está visível na parte inferior da página), várias informações sobre o processamento da página e atividades relacionadas serão exibidas. Cada área consiste em um tipo de informação (ver imagem 02):

1. Exibe o processo de renderização do ASP.NET, exibindo o tempo de execução e renderização de cada controle em milissegundos (ms). É aqui que problemas de performance de controles/métodos serão avaliados individualmente;
2. Exibe o tempo total de processamento da página, que consiste na soma de todos os tempos dos outros recursos. Exibe o usuário atual e nível check-out da página;
3. Exibe os erros que aconteceram durante a execução da página;
4. Exibe as consultas feitas no banco de dados com o respectivo tempo de duração;
5. Exibe o de processamento das web parts, mostrando o tempo de execução (em milissegundos) dos eventos por web part.

Imagem 02: Developer dashboard

Com base nessas informações o desenvolvedor irá descobrir, por exemplo, se a sua web part está lenta, se de repente o problema de lentidao é no banco e as consultas estão demorando demais, e por aí adiante.

Registrando Eventos na Developer Dashboard

O conteúdo exibido na developer dashboard é o conteúdo padrão do SharePoint, os controles que o próprio SharePoint utiliza. Mas como desenvolvedor apenas isso acaba não resolvendo o meu problema, o que fazer então?

Podemos usar a facilidade de registrar na developer dashboard os eventos, e assim exibir no painel as ações e tempos de execução destes eventos. Dessa forma conseguimos ter um rastreamento melhor da execução de nossos artefatos.

Para fazer o registro das informações na developer dashboard devemos utilizar a classe SPMonitoredScope dentro de um using. Assim, tudo o que estiver dentro do escopo do using será computado como uma ação e o tempo total será registrado. No exemplo da listagem 02, estamos abrindo o using para criar o objeto SPMonitoredScope e colocando um sleep de 1 segundo. Dessa forma a developer dashboard irá informar que o tempo de execução do MeuTexto foi de 1 segundo (aproximadamente).

using (new SPMonitoredScope("MeuTexto"))
{
    System.Threading.Thread.Sleep(1000);
}

Listagem 02: Exemplo de uso da classe SPMonitoredScope

Para melhorar a exibição e controle das informações, podemos utilizar os registros na developer dashboard de forma aninhada, ou seja, uns dentro de outros. A listagem 03 mostra em detalhes. Dessa forma o tempo de execução de MeuTexto passa para 2 segundos e o tempo de DentroMeuTexto é de 1 segundo. Tudo o que estiver dentro do using será considerado tempo de execução para o escope criado e para casa using interno é feito o mesmo controle, de forma aninhada.

using (new SPMonitoredScope("MeuTexto"))
{
    System.Threading.Thread.Sleep(1000);

    using (new SPMonitoredScope("DentroMeuTexto"))
    {
        System.Threading.Thread.Sleep(1000);
    }
}

Listagem 03: Exemplo de uso da classe SPMonitoredScope de forma aninhada

O próximo exemplo temos uma amostra de como instrumentar as classes e assim controlar a performance de execução dos métodos usando ainda o SPMonitoredScope. A listagem 04 mostra a criação de uma classe chamada Pessoa que possui alguns métodos que estão registrando o tempo de execução, depois a listagem 05 mostra como chamar essa classe e possui um outro registro do tempo de exeução, só que em nível macro de todas as chamadas dos métodos da classe pessoa. O resultado disso poder ser visto na imagem 03.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.Utilities;

namespace WebPartInstrumentada
{
    public class Pessoa
    {
        public List<Pessoa> ObterTodasPessoas()
        {
            using (new SPMonitoredScope("ObterTodasPessoas"))
            {
                System.Threading.Thread.Sleep(1000);
            }

            return null;
        }

        public Pessoa ObterPessoaPeloID(int id)
        {
            using (new SPMonitoredScope("ObterPessoaPeloID"))
            {
                System.Threading.Thread.Sleep(100);
            }

            return null;
        }

        public Pessoa ObterPessoaPeloNome(string nome)
        {
            try
            {
                throw new Exception("Erro ao obter pessoa pelo nome, contate o administrador do sistema");
            }
            catch (Exception ex)
            {
                // Registra o erro no log do SharePoint
                TratamentoErro.RegistrarErroLogSharePoint(ex);
                // Registra o erro no log do Windows
                TratamentoErro.RegistrarErroEventViewer(ex);
            }

            return null;
        }
    }
}

Listagem 04: Classe pessoa

using System;
using System.Web.UI;
using System.Web.UI.WebControls;
using System.Web.UI.WebControls.WebParts;
using Microsoft.SharePoint.Utilities;

namespace WebPartInstrumentada.WebPartInstrumentada
{
    public partial class WebPartInstrumentadaUserControl : UserControl
    {
        protected void Page_Load(object sender, EventArgs e)
        {
            using (new SPMonitoredScope("Processando pessoas"))
            {
                Pessoa pessoa = new Pessoa();

                pessoa.ObterPessoaPeloID(1);

                pessoa.ObterTodasPessoas();

                pessoa.ObterPessoaPeloNome("Fabian");
            }
        }
    }
}

Listagem 05: User Control

Da mesma forma que usamos a developer dashboard para exibir os nosso eventos customizados, também podemos usá-la para exibir erros tratados nesse processo. O próximo capítulo fala de como tratar erros e registrá-los no log do SharePoint ou no log do Windows. A imagem 03 mostra que os erros customizados para aparecer nos logs do Sharepoint e do Windows, também são mostrado na developer dashboard, na seção “Asserts and Critival Events”.

Imagem 03: Developer dashboard exibindo o tempo de execução da rotina de processamento de pessoas

Registrando eventos no log do SharePoint e log do Windows

Além das informações de performance, podermos gravar informações de erro ou avisos nos logs do SharePoint ou do Windows, para isso utilizamos a classe do SharePoint chamada SPDiagnosticsService, que é responsável por gravar os registros no log do SharePoint ou do Windows.

A listagem 06 mostra a implementação de uma classe de tratamento de erro, nesta classe temos um método para gravar no log do SharePoint e outro para gravar no log do Windows.  No caso do log do SharePoint, conforme a severidade informada para o registro, ele poderá ser exibido no log do SharePoint ou não. Isso depende da configuração feita na Administração Central relacionada à severiade do log de diagnóstico do SharePoint. Seria interessante personalizar o método RegistrarErroLogSharePoint para trabalhar com mais parâmetros, principalmente parâmetros que fossem relativos a severidade. Geralmente trabalhamos com mais de um tipo de informação de instrumentação, pois nem tudo é erro. Durante a execução podemos ter informações, avisos, erros, entre outros, e dessa forma conseguimos configurar o SharePoint para só gravar erros, por exemplo.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Microsoft.SharePoint.Administration;

namespace WebPartInstrumentada
{
    public static class TratamentoErro
    {
        /// <summary>
        /// Método que registra os erros no log do SharePoint (pasta C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS)
        /// </summary>
        /// <param name="ex"></param>
        public static void RegistrarErroLogSharePoint(Exception ex)
        {
            SPDiagnosticsService diagnostics = SPDiagnosticsService.Local;
            diagnostics.WriteTrace(1409,
                new SPDiagnosticsCategory("ErroCustomizado",
                    TraceSeverity.Monitorable,
                    EventSeverity.Error),
                TraceSeverity.Monitorable,
                "Ocorreu um erro: {0}",
                new object[] { ex });
        }

        /// <summary>
        /// Método que registra os erros no log do Windows (Visualizador de Eventos)
        /// </summary>
        /// <param name="ex"></param>
        public static void RegistrarErroEventViewer(Exception ex)
        {
            SPDiagnosticsService diagnostics = SPDiagnosticsService.Local;
            diagnostics.WriteEvent(1408,
                new SPDiagnosticsCategory("ErroCustomizado",
                    TraceSeverity.Monitorable,
                    EventSeverity.Warning),
                    EventSeverity.Error,
                    "Ocorreu um erro: {0}",
                    new object[] { ex });
        }
    }
}

Listagem 06: Classe de tratamento de erro

A listagem 07 mostra a implementação do método ObterPessoaPeloNome da classe pessoa (já feito anteriormente na listagem 04). Veja que no tratamento de exceção o erro está sendo gravado no log do Sharepoint e no log do Windows.

public Pessoa ObterPessoaPeloNome(string nome)
{
    try
    { 
        throw new Exception("Erro ao obter pessoa pelo nome, contate o administrador do sistema");
    }
    catch (Exception ex)
    {
        // Registra o erro no log do SharePoint
        TratamentoErro.RegistrarErroLogSharePoint(ex);
        // Registra o erro no log do Windows
        TratamentoErro.RegistrarErroEventViewer(ex);
    }

    return null;
}

Listagem 07: Utilização do tratamento de erro gravando no log do SharePoint e Windows

Agora basta conferir o resultado do tratamento de erro e execução do método ObterPessoaPeloNome, que pode ser visto no log do SharePoint, conforme a imagem 04, e no log de eventos do Windows, conforme imagem 05.

Imagem 04: Evento gravado no log do SharePoint

Imagem 05: Evento gravado no log do Windows

Referências

• SharePoint 2010 – Enable & using Developer Dashboard
• SPDiagnosticsService Class
• Using SPMonitoredScope
• SP 2010: Developing for performance Part 1 - Developer Dashboard
• SP 2010: Developing for performance Part 2 – SPMonitoredScope
• SP 2010: Developing for performance Part 4 – Logging
• Using SPMonitoredScope to monitor performance of your code
• How to Enable the Developer Dashboard in SharePoint 2010
• Improve your SharePoint 2010 applications with monitoring using SPMonitoredScope
• Fontes do projeto utilizado neste post

Assembly [My.Assembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cfc9a4dcd383ae1e] is referenced in the database [WSS_Content], but is not installed on the current farm. Please install any feature/solution which contains this assembly.

Na maioria dos casos esse erro é gerado por algum Event Receiver problemático, ou seja, que tenha sido esquecido de remover da solução customizada, ou outro problema relacionado com a desativação ou retração da solução.

Neste post eu quero compartilhar com vocês um script Power Shell que pode ajudá-los a remover esse event receiver problemático.

Este artigo é uma tradução livre do artigo MissingAssembly Error in Health Analyzer (https://blogs.technet.com/b/pfelatam/archive/2013/06/26/missingassembly-error-in-health-analyzer.aspx)

O script a seguir possui 2 funções:

Delete-MissingAssembly: Esta é a função principal que percorre todos os possíveis containers no banco de dados específicos que podem hospedar um event receiver: site collections, web ou listas.

Remove-EventReceiver: Essa função verifica se o container do event receiver possui qualquer event receiver com o nome do assembly específico, exibe suas informações e/ou tenta excluí-lo.

As 2 funções tem um parâmetro para permitir excluir diretamente o event receiver ou apenas mostra na tela as informações sobre ele.

function Delete-MissingAssembly($ContentDb, $Assembly, [switch]$ReportOnly)

{

   [bool]$report = $false

   if ($ReportOnly) { $report = $true }

   $database = Get-SPContentDatabase | ?{$_.Name -eq $ContentDb}

   foreach($site in $database.Sites)

   {

      Remove-EventReceiver -ERContainer $site -Assembly $Assembly -ReportOnly $report

      foreach($web in $site.AllWebs)

      {

         Remove-EventReceiver -ERContainer $web -Assembly $Assembly -ReportOnly $report

         foreach($list in $web.Lists)

         {

            Remove-EventReceiver -ERContainer $list -Assembly $Assembly -ReportOnly $report

         }

      }

   }

}

function Remove-EventReceiver($ERContainer, $Assembly, $ReportOnly)

{

   foreach($er in $ERContainer.EventReceivers)

   {

      if($er.Assembly -eq $Assembly)

      {

         Write-Host "Event Receiver with Id[" $er.Id "], Name[" $er.Name "] and Type [" $er.Type "] found in [" $ERContainer.Url $ERContainer.DefaultViewUrl "]."

         if($ReportOnly -eq $false)

         {

            Write-Host "Try to delete the receiver:"

            $er.Delete()

            Write-Host "ER deleted."

         }

      }

   }

}

Depois de salvar o script em um arquivo PS1 e importá-lo (Exemplo: Import-Module .\MissingEV.PS1), você pode usar essa função da seguinte forma:

Delete-MissingAssembly -ContentDb WSS_Content -Assembly "My.Assembly, Version=1.0.0.0, Culture=neutral, PublicKeyToken=cfc9a4dcd383ae1e" -ReportOnly

E a mensagem exibida será parecida com essa:

Como você pode ver a função exibe o Id, Nome, Tipo e Local do event receiver específico, você pode decidir se irá removê-lo com esse script, acessar através do PowerShell ou ainda através de alguma ferramenta de terceiros.

Espero que com este post tenha lhe ajudado a resolver a falta de dependência do lado do servidor que é exibida no Health Analyzer.

Este post tem um exemplo de como implementar esta necessidade.

Antes de iniciar, vale lembrar que existem outras formas mais recomendas de acessar dados remotamente do SharePoint, como por exemplo o Client Object Model ou o serviço REST, mas como a solicitação era via webservice, vou deixar o exemplo na mesma linha. O código deste post foi copiado do post original do fórum e adaptado para que funcione corretamente.

Neste exemplo, a biblioteca do SharePoint possui as pastas na seguinte estrutura:

1. Pasta1
   1. PastaA
      1. Folder1
      2. Folder2
      3. Folder3
   2. PastaB
   3. PastaC
2. Pasta2
3. Pasta3

O primeiro passo para começar o desenvolvimento é adicionar a referência do webservice no Visual Studio, que fica no endereço https://enderesite/_vti_bin/lists.asmx, conforme mostra a imagem 01.

Imagem 01: Adicionando a referência do Webservice SharePoint

Criei uma classe chamada Pasta para conter a nossa lógica, ela possui as propriedades ID e Nome e o método RecuperaPasta que faz a busca no SharePoint. A listagem 01 tem a implementação completa da classe.

public class Pasta
{
    public int ID { get; set; }
    public string Nome { get; set; }

    /// <summary>
    /// Busca a pasta em uma biblioteca do SharePoint utilizando os webservices
    /// </summary>      
    public void RecuperaPasta(string nomePasta, string nomeBiblioteca)
    {
        WebServiceLists.Lists service = new WebServiceLists.Lists();
        service.Url = "https://lab-sp04/_vti_bin/lists.asmx";
        service.Credentials = new System.Net.NetworkCredential("usuario", "senha", "dominio");
        XmlDocument xDoc = new XmlDocument();
        XmlNode ndQuery = xDoc.CreateNode(XmlNodeType.Element, "Query", "");
        XmlNode ndViewFields = xDoc.CreateNode(XmlNodeType.Element, "ViewFields", "");
        XmlNode ndQueryOptions = xDoc.CreateNode(XmlNodeType.Element, "QueryOptions", "");
        ndQuery.InnerXml = "<Where>" +
                            "<And>" +
                                "<Eq>" +
                                    "<FieldRef Name=\"FileLeafRef\" />" +
                                    "<Value Type=\"Text\">" + nomePasta + "</Value>" +
                                "</Eq>" +
                                "<Eq>" +
                                    "<FieldRef Name=\"FSObjType\" />" +
                                    "<Value Type=\"Lookup\">1</Value>" +
                                "</Eq>" +
                            "</And>" +
                            "</Where>";

        ndViewFields.InnerXml = "";
        // O RecursiveAll eh fundamental para que a busca seja feita nas subpastas
        ndQueryOptions.InnerXml = "<QueryOptions><ViewAttributes Scope=’RecursiveAll’/></QueryOptions>";

        XmlNode resultNode = service.GetListItems(nomeBiblioteca, string.Empty, ndQuery, ndViewFields, null, ndQueryOptions, null);

        // Le os nodes de retorno
        foreach (XmlNode node in resultNode.ChildNodes)
        {
            if (node.Name == "rs:data")
            {
                for (int i = 0; i < node.ChildNodes.Count; i++)
                {
                    if (node.ChildNodes[i].Name == "z:row")
                    {
                        // Le os atributos dos nodes
                        foreach (XmlAttribute attr in node.ChildNodes[i].Attributes)
                        {
                            if (attr.Name == "ows_ID")
                                this.ID = int.Parse(attr.Value);
                            else if (attr.Name == "ows_FileRef")
                                this.Nome = attr.Value;
                        }
                    }
                }
            }
        }
    }
}

Listagem 01: Implementação da classe Pasta

Com a implementação da classe Pasta, agora temos que testá-la. A listagem 02 mostra as chamadas de teste.

class Program
{
    static void Main(string[] args)
    {
        Pasta pasta = new Pasta();

        Console.WriteLine("Obtendo Pasta1");
        pasta.RecuperaPasta("Pasta1", "Documentos");
        Console.WriteLine(string.Format("ID: {0} – Pasta: {1}", pasta.ID.ToString(), pasta.Nome));

        Console.WriteLine("Obtendo PastaA");
        pasta.RecuperaPasta("PastaA", "Documentos");
        Console.WriteLine(string.Format("ID: {0} – Pasta: {1}", pasta.ID.ToString(), pasta.Nome));

        Console.WriteLine("Obtendo Folder1");
        pasta.RecuperaPasta("Folder1", "Documentos");
        Console.WriteLine(string.Format("ID: {0} – Pasta: {1}", pasta.ID.ToString(), pasta.Nome));
        Console.ReadKey();
    }
}

Listagem 02: Testando a classe Pasta

Ao executar o teste, o resultado exibido na imagem 02 é exibido.

Imagem 02: Executando a pesquisa das pastas

Verifique que as três chamadas do método foram executadas com sucesso, retornando o ID e o Nome da pasta e apenas uma pasta por vez.

Referências

• SharePoint 2010 Client Object Model (https://msdn.microsoft.com/en-us/library/ee537247%28v=office.14%29.aspx)
• SharePoint Foundation REST Interface (https://msdn.microsoft.com/en-us/library/ff521587%28v=office.14%29.aspx)

• Search document from document library usin CAML query (https://sharepoint.stackexchange.com/questions/59323/search-document-from-document-library-usin-caml-query)

• Recuperar ID de pasta na Biblioteca usando Web Services (https://social.msdn.microsoft.com/Forums/pt-BR/sharepointpt/thread/b5d622a1-96d7-4f4b-9e17-05fc365c15d4)

Neste post vou mostrar como editar o e-mail de tarefa atribuída que o workflow envia, mas o conteúdo deste post pode ser utilizado em outras customizações desta atividade.

Este workflow foi criado e executado no SharePoint Designer 2013 e SharePoint 2013, mas feito com o engine 2010, o que significa que pode ser feito no SharePoint 2010.

O processo de aprovação que vamos ver neste post é muito rico em seu uso. Ele, e o processo customizado de aprovação, são as únicas formas de customizarmos as mensagens com usuários como título e corpo da tarefa e e-mails. Os demais tipos, como: atribuir uma tarefa ou coletar dado de um usuário são estáticos. A diferença entre o processo customizado e o que vamos utilizar aqui, é que o customizado vem “zerado”, ou seja, você tem que fazer tudo dentro dele. Este aqui já vem pronto e acaba sendo mais fácil editar algo do que criar um novo. Por isso a escolha do processo de aprovação neste post.

Depois de criado o workflow adicione a atividade “Iniciar Processo de Aprovação”, conforme a imagem 01.

Imagem 01: Adicionando a tarefa Iniciar Processo de Aprovação

Clique no nome do processo, conforme imagem 02, para editá-lo.

Imagem 02: Editando o processo de aprovação

Entre na opção Modificar o comportamento de tarefa única, conforme a imagem 03, que nos permitirá editar o comportamento individual de cada tarefa criada neste processo, caso existam mais.

Imagem 03: Modificando o comportamento da tarefa do processo de aprovação

A janela que abriu mostra algumas fases do processo de tarefas, onde podemos editar/adicionar atividades antes da tarefa ser criada, enquanto está pendente, quando expirada e quando completada. Role o scroll até a seção “enquanto está pendente” e procure o trecho selecionado na imagem 04. Veja que tem uma atividade de enviar e-mail para o usuário que está responsável pela tarefa. Clique nesta atividade para alterarmos sua configuração.

Imagem 04: Editando o e-mail para o usuário responsável pela tarefa

A tela com as configurações do e-mail foi exibida, posicione o cursor no local indicado na imagem e digite “O ID desta tarefa é “ e então clique no botão “Add or Change Lookup”. A tela para adicionar o lookup é exibida, selecione os valores conforme exemplo da imagem 05.

Muito dificilmente você irá exibir o ID desta forma, é apenas um exemplo, mas você pode criar links customizados utilizando essas informações, editar o e-mail para o usuário e atender diversas necessidades de negócio que não seriam possíveis se não fosse o processo de aprovação.

Imagem 05: Adicionando o ID da tarefa no e-mail da tarefa

Volte ao workflow principal e termine de editar o processo de aprovação, clique em “these users” conforme a imagem 06.

Imagem 06: Terminando a edição do processo de aprovação

Edite as informações da tarefa, tais como: responsável, título, corpo e data de vencimento, conforme a imagem 07.

Imagem 07: Editando o corpo da tarefa

O processo de customizar o e-mail enviado ao responsável pela tarefa do workflow foi concluído. Agora você pode editar as configurações do workflow, como fazer com que ele seja iniciado automaticamente, publicar o workflow e então testar o e-mail recebido.

Aqui mostrei apenas algo simples, mas aproveite para aprender mais sobre esta atividade que os resultados serão fantásticos.

Mas é possível exibir os formulários diretamente em uma página?

Neste post vou mostrar como exibir os formulários em páginas utilizando a web part nativa do SharePoint de exibição de formulário InfoPath.

Leia o resto deste post »

Neste post vou mostrar a página principal do SharePoint 2013 que está no Office 365 Preview, vai ser apenas uma página, mas já dá uma boa impressão das novidades.

Leia o resto deste post »

Neste post vamos ver mais sobre o conceito de apps do SharePoint 2013 Preview.

Leia o resto deste post »

Pois é, é com muita alegria que falo para vocês que os recursos do SharePoint Designer para criação de workflows estão ainda melhores, neste post vamos ver uma visão geral.

Leia o resto deste post »

Leia o resto deste post »

Existem duas maneiras de criar os aplicativos de serviço: manualmente, criando serviço por serviço, onde o trabalho é maior mas o nível de controle também superior. Podemos informar quais usuários que irão executar o serviço, nome do banco de dados e outras, isso tudo depende do tipo do serviço de aplicativo. A outra forma é utilizar o wizard de configuração da Farm, ele faz tudo com as configurações padrão e facilitam muito na configuração da Farm. Mas é importante ressaltar que ele não deve ser usado em todos os ambientes, cenários mais simples são uma boa opção, cenários médios deve ser considerado e cenários complexos muito dificilmente utiliza-se.

Neste post vamos ver mais detalhes sobre o wizard de configuração da Farm no SharePoint 2013.

Leia o resto deste post »