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.

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 http://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 = "http://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 (http://msdn.microsoft.com/en-us/library/ee537247%28v=office.14%29.aspx)
• SharePoint Foundation REST Interface (http://msdn.microsoft.com/en-us/library/ff521587%28v=office.14%29.aspx)

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

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

A engine do workflow permite que este comportamento seja feito, então conforme o estágio que o workflow estiver, ele irá alterar as permissões do documento automaticamente, garantindo a integridade das informações.

Neste post veremos como utilizar atividades do workflows para implementar este comportamento.

No exemplo deste post vou utilizar o SharePoint 2013 e criar um workflow com engine do SharePoint 2010, o que significa que irá funcionar no SharePoint 2010 também.

A atividade de alteração de permissões do documento não existe no engine 2013, mas para isso você pode fazer um fluxo auxiliar utilizando o engine 2010, como mostrei recentemente no post SharePoint 2013 Workflows: Engine 2010 versus Engine 2013.

O nosso case é bem simples, vamos fazer um workflow com dois estágios onde o primeiro será uma tarefa para o gerente aprovar e o outro para o diretor. A diferença é que apenas o gerente e o diretor poderão alterar o documento, em seus respectivos momentos (enquanto a tarefa estiver pendente).

Para iniciar criei um workflow de lista com o engine 2010 apontando para uma biblioteca de documentos qualquer, como mostra a imagem 01.

Imagem 01: Criando o workflow com engine do SharePoint 2010

Posicione o cursos acima do passo padrão “Step 1”, depois clique em “Impersonation Step” para adicioná-lo. Se o cursor não estiver posicionado no local correto, a opção “Impersonation Step” não estará habilitado. A imagem 02 mostra a tela, repare nas flechas. Um “Impersonation Step” é um passo que é executado com as permissões do usuário que fez a publicação do Workflow, o que geralmente é um usuário com nível elevado de acesso no site. Isso é fundamental porque um usuário colaborador não vai ter privilégios para alterar as permissões do documento. Então, rodando com um usuário com acesso, o workflow consegue realizar esta operação.

Imagem 03: Adicionando um impersonation step

Ao colocar o cursor dentro do “Impersonation Step” repare que novas atividades será exibidas na opção “Actions”. Selecione a atividade “Substituir Permissões dos Item de Lista”, conforme a imagem 04. Além dessa existem várias outras, mas para o nosso case esta é suficiente.

Imagem 04: Adicionando a atividade para substrituir as permissões do item

Para configurar a atividade de substituir permissões, clique em “estas permissões” e a janela para configuração será exibida, conforme imagem 05. Clique em “Add…” para adicionar permissões aos usuários. É possível adicionar vários usuários, como por exemplo o dono da tarefa e um grupo de adminsitradores.

Imagem 05: Configurando as permissões do item

A imagem 06 mostra a tela para adicionar as permissões, selecione o usuário e o nível de permissão. Aqui estão sendo exibidos todos os níveis do acesso do site, repare que existe inclusive um tipo chamado “Colaboração sem exclusão”, que é um tipo de permissão customizado. Considere utilizar níveis assim para evitar que o usuário atual do workflow exclua o documento.

Imagem 06: Adicionando permissão para um usuário

E por fim, configurar qual o item que receberá as permissões. No nosso caso o item corrente, conforme a imagem 07.

Imagem 07: Configurando o objeto que irá receber as permissões

Neste ponto a atividade de substituição das permissões está pronta. Depois disso coloquei um passo chamado “Aprovação Gerente” e uma tarefa para o gerente aprovar, conforme mostra a imagem 08. Após isso fiz o mesmo processo só que para o diretor conforme o case definido. Também fiz as demais configurações no workflow, como fazer com que ele inicie automaticamente e publiquei-o.

Imagem 08: Finalizando o workflow

Com o workflow publicado, acessei a biblioteca “Documentos” e adicionei um documento qualquer. Na coluna do workflow podemos ver que ele está em andamento, conforme a imagem 09. Sendo assim, se acessarmos as permissões do documento neste momento, ele estará apenas com as permissões para o gerente poder alterá-lo.

Imagem 09: Worklow em andamento

Selecione o item e clique no menu contextual, na opção “Gerenciar Permissões”, conforme a imagem 10.

Imagem 10: Verificando as permissões do documento

Verifique na imagem 11 que apenas o usuáro Eleriane, que é o Gerente, possui acesso de colaboração. Sendo assim, concluímos que está passou ocorreu com sucesso. Os demais usuários estão apenas com acesso limitado, o que não vai possibilitar nem o acesso ao documento. Poderia ter sido configurado para os usuários terem acesso de leitura, mas para simplificar foquei só no gerente.

Imagem 11: Verificando as permissões do gerente

O workflow foi acessado pelo gerente a a tarefa dele foi concluída. O fluxo seguiu para a aprovação do diretor e agora apenas a permissão de colaboração dele deve existir. A imagem 12 mostra que apenas o Fabian , que é o Diretor, tem acesso de colaboração, o restante apenas de acesso limitado. Sendo assim conseguimos validar as 2 etapas do workflow.

Imagem 12: Verificando as permissões do diretor

Neste post vimos como podemos simplificar o gerenciamento de documentos que estão sob workflow qualquer, fazendo com que somente os usuários que estão realizando tarefas no processo  tenham acesso ao documento . Desta forma evita-se que o documento seja alterado após a aprovação do gerente, por exemplo. O melhor de tudo é que essa lógica está dentro do próprio workflow, o que facilita bastante o trabalho de quem estiver automatizando este processo.

A ideia deste post saiu de uma discussão com os amigos Ednei Monteiro e Juan Alberich, muito obrigado pela inspiração e pelas ideias trocadas.

Neste post vamos discutir algumas coisas relacionadas a este assunto. Não pretendo falar sobre tudo, apenas algumas ideias iniciais. Para pessoas que estão iniciando com o SharePoint 2013, o novo engine trouxe muitos recursos que vão revolucionar a forma de fazer workflows no SharePoint 2013, mas não vamos falar sobre isto neste post. O objetivo é falar como utilizar o poder do engine 2013 junto com o engine 2010.

Para começar, recomendo a leitura das referências sobre as atividades existentes em cada engine Workflow actions quick reference (SharePoint 2010 Workflow platform) e Workflow actions quick reference (SharePoint 2013 Workflow platform). Com isso é possível concluir que o Engine 2013 trouxe muitas coisas novas, mas várias atividades existentes no 2010 foram removidas. Talvez por causa da nova arquitetura, que não está mais dentro do SharePoint como a engine 2010, mas vamos ver como resolver algumas coisas que só podem ser feitas com o engine 2010.

Uma atividade que utilizo muito no engine 2010 é a Send Document Set to Repository, que move/copia um documento para o organizador de conteúdo aplicar as regras de roteamento de documentos (para saber mais sobre o organizador de conteúdo, veja as referências). No engine 2013 essa atividade não existe. Algo que seria similar é a atividade Copy Document, mas o comportamento dela é estático, copiando o documento sempre para o mesmo lugar. Com o organizador de conteúdo temos várias regras que podem ser configuradas sem alterar o workflow, apenas via configuração das regras. Sem o organizador de conteúdo, precisamos colocar as regras diretamente no workflow, o que pode ser muito trabalhoso, deixando o fluxo ilegível e fazendo com que sofra muitas alterações para regras novas. Se utilizamos a atividade Copy Document para copiar um documento para a biblioteca de redistribuição, o evento do organizador de conteúdo não é executado, tornando este o endereço final do documento.

Como resolver isso? O engine 2010 faz algo que eu preciso, o engine 2013 faz coisas que eu preciso também. Não consigo fazer um fluxo com ambos ao mesmo tempo? Como resolver?

Pelos workflows que já fiz com o engine 2013, digo que este cenário vai ser comum e para resolver isso utilizei a atividade Start a List Workflow, que serve para iniciar um outro workflow. Esta atividade é nova e veio muito a calhar. Com ela eu posso fazer o meu workflow com o engine 2013 e chamar workflows auxiliares com o engine 2010 para realizarem tarefas específicas, como utilizar o organizador de conteúdo. Com isso, tenho o melhor dos dois mundos. Só que preste atenção, esta atividade é nova no engine 2013, se você fizer o workflow no engine 2010 e tentar chamar um workflow no 2013, não vai conseguir.

Gostei muito da possibilidade de poder chamar workflows com engine 2010 a partir de workflow engine 2013. Isso nos dará uma flexibilidade muito grande, podendo associar recursos exclusivos do engine 2010 com os novos recursos do engine 2013. É importante exclarecer que apenas workflows do engine 2013 podem chamar workflows do engine 2010, é a única combinação possível.

Referências

• Configurar o Organizador de Conteúdo para rotear documentos (http://office.microsoft.com/pt-br/sharepoint-server-help/configurar-o-organizador-de-conteudo-para-rotear-documentos-HA010378237.aspx)
• Criar regras do Organizador de Conteúdo para circular documentos (http://office.microsoft.com/pt-br/sharepoint-server-help/criar-regras-do-organizador-de-conteudo-para-circular-documentos-HA101807927.aspx)
• Introduzindo Gerenciamento de Conteúdo da Web no SharePoint 2010 (http://blogs.msdn.com/b/sharepoint_br/archive/2010/11/25/introduzindo-gerenciamento-de-conte-250-do-da-web-no-sharepoint-2010.aspx)
• Workflow actions quick reference (SharePoint 2010 Workflow platform) (http://msdn.microsoft.com/en-us/library/jj822977.aspx)
• Workflow actions quick reference (SharePoint 2013 Workflow platform) (http://msdn.microsoft.com/en-us/library/jj164026.aspx)

• Understanding Coordination actions in SharePoint Designer 2013 (http://msdn.microsoft.com/en-us/library/jj554503.aspx)

As provas seguem o mesmo padrão adotado para as demais provas da Microsoft, que é o retorno da nomenclatura Microsoft Certified Solutions Expert (MCSE). Essa nomenclatura já foi utilizado a algumas gerações atrás das certificações, mas sofreu uma enorme alteração nos requisitos para ter o nível professional da carreira SharePoint 2013: passou a exigir a certificação MCSA em Windows Server, esse assunto será tratado no tópico MCSE: SharePoint mais abaixo.

A data estimada da publicação das provas é dia 05 de fevereiro de 2013, mas antes disso estará disponível as provas betas, que ainda não tem informação de data.

As provas de desenvolvimento ainda não estão disponíveis, mas assim que estiverem, publicarei aqui.

As provas de infra agora estão divididas em Core e Advanced e englobam outros assuntos relacionados ao SharePoint e não apenas o SharePoint. Vejam abaixo:

MCSE: SharePoint

Foi uma grande surpresa ver que os requisitos da certificação professional foram alterados, agora ficou muito mais trabalhoso ter esse nível de certificação. Isso porque foi adicionado o requisito da carreira MCSA: Windows Server 2012. O que na minha opinião faz total sentido. Como administrador de SharePoint é comum precisar de conhecimentos avançados de Windows Server, mas como não era obrigatório, acabava ficando em segundo ou terceiro plano. Agora para ser especialista de infra de SharePoint, o profissional vai conhecer profundamente a infra estrutura do Windows Server, além da de SharePoint. Mais difícil, mas muito mais valoroso. Isso implicará diretamente nos esforços das empresas em conseguir as competências Gold, que imagino, irão cobrar o MCSE, mas irá aumentar em mais ainda o respeito e confiança em quem é Gold.

A imagem 01 mostra o caminho para a obtenção do MCSE SharePoint.

Imagem 01: Caminho da certificação MCSE SharePoint

70-331: Core Solutions of Microsoft SharePoint Server 2013

Esta prova é o upgrade da prova 70-667: TS – Microsoft SharePoint 2010, Configuring para o Sharepoint 2013. Possui tópicos diferentes, mas acredito que será muito parecida com ela, só esperando as betas para ter certeza.

Os tópicos principais desta prova são:

• Desing a SharePoint Topology: design da arquitetura da informação, design da arquitetura lógica, desing da arquitetura física e planejamento do SharePoint Online;
• Plan Security: planejamento e configuração da autenticação, planejamento e configuração da autorização, planejamento e configuração da plataforma de segurança e planejamento e configuração do nível de segurança da farm;
• Install e Configure SharePoint Farms: planejamento da instalação, planejamento e configuração da farm, criação e configuração da busca, criação e configuração do serviço de metadados gerenciados, criação e configuração do serviço de sincronição de usuários;
• Create and Configure Web Applications and Site Collections: provisionamento e configuração de aplicações web, criação e manutenção de coleções de sites, gerenciamento da segurança de sites e coleções de sites, gerenciamento da busca, gerenciamento da taxonomia;
• Maintaing Core SharePoint Environment: monitoração do ambiente SharePoint, tunando e otimizando o ambiente SharePoint, solucionando problemas do ambiente SharePoint.

70-332: Advanced Solutions of Microsoft SharePoint Server 2013

Esta prova é o upgrade da prova 70-668: PRO – Microsoft SharePoint 2010, Administrator, possui tópicos e alguns assuntos mais abrangentes, mas deve seguir a mesma linha.

Os tópicos principais desta prova são:

• Plan Business Continuity Management: planejamento de alta disponibilidade com SQL e recuperação de desastres, planejamento de alta disponibilidade do SharePoint, planejamento de backup e restore;
• Plan SharePoint Environment: planejamento da workload social, planejamento e configuração da workload de busca, planejamento e configuração da workload de gerenciamento de conteúdo web (WCM), planejamento da workload de gerenciamento de conteúdo corporativo (ECM);
• Upgrade and Migrate a SharePoint Environment: avaliar o conteúdo e customizações, planejamento do processo de upgrade, upgrade de coleções de sites;
• Create and Configura Service Applications: criando e configurando o gerenciamento de aplicativos (Apps), criando e configurando serviços de produtividade, configurando serviço de aplicativo de federação, criando e configurando BCS e Secure Store Application;
• Manage SharePoint Solutions, BI, and System Integration: gerenciamento de soluções e aplicações SharePoint, planejamento e configuração da infraestrutura de BI, criando e configurando gerenciamento de trabalho (tarefas).

MCSD: SharePoint

As certificações de desenvolvimento do SharePoint 2013 também tiveram bastante mudanças evolutivas. Os requisitos agora existem e a princípio são duas provas de desenvolvimento, a 70-480: Programming in HTML5 with JavaScript and CSS3 e outra que ainda não foi divulgada. Com isso, para receber o título Microsoft Certified Solutions Developer SharePoint, é necessário fazer as duas provas de desenvolvimento e as provas de desenvolvimento do SharePoint 2013 70-488 e 70-489, que podem ser vistas nos tópicos abaixo.

Seguindo a mesma linha das provas de infra, o desenvolvimento para SharePoint vem cobrando mais coisas básicas (desenvolvimento “normal”) e com isso, mostra também uma maior abertura nas customizações. Com os recursos de apps, o SharePoint 2013 está muito mais natural para ser customizado por desenvolvedores ASP.NET ou qualquer tecnologia. Com os serviços REST qualquer desenvolvedor de qualquer tecnologia que suporte REST, pode interagir com os dados do SharePoint. Além disso, como o padrão dos apps é html, javascript e css, a curva de aprendizado de qualquer desenvolvedor web é bem menor.

Na minha opinião, mais um ponto positivo para as certificações de SharePoint 2013;

70-488: Developing Microsoft SharePoint Server 2013 Core Solutions

Com a quantidade de novidades em desenvolvimento do SharePoint 2013, não me arrisco a dizer que está prova é a evolução da 70-573 do SharePoint 2010. Mas, não deixa de ser um upgrade, só que com mais conteúdo novo.

Os tópicos desta prova são:

• Plan and Design SharePoint Sites: manage the site life cycle, create content types, manage content type behaviors, implement site provisioning;
• Implement Authorization and Authentication: implement user authentication, implement application authentication and authorization, plan and implement user authorization;
• Access and Manage Data: design solutions to handle large amounts of data, access data contained in SharePoint, store configuration data;
• Implement SharePoint Solutions: Manage SharePoint Object Life Cycle, Upgrade solutions and features, Determine a solution structure, Create sandbox solutions, Create a no-code solution;
• Implement the User Experience and Information Architecture: Implement branding, Implement navigation, Customize UI elements;
• Create Business Processes: Create event receivers and timer jobs, Create SharePoint Designer workflows, Create and deploy Microsoft Visual Studio workflows;
• Create Office Apps: Plan and design applications, Create applications, Package and deploy Apps, Manage the App life cycle.

70-489: Developing Microsoft SharePoint Server 2013 Advanced Solutions

Esta prova é algo como a evolução da prova 70-576 do SharePoint 2010.

Os tópicos desta prova são:

• Design and Implement Search: Query Search, Customize search results, Customize content processing.
• Implement  BCS (Business Connectivity Services): Create a model, Create external content types,  Implement authorization and authentication, Create custom connectors, Access BCS data, Implement client-side BCS.
• Implement User Profiles and Customize Social Workload: Manage user profile properties, Manage feeds, Access user profile data.
• Implement ECM (Enterprise Content Management) and WCM (Web Content Management): Implement a multi-lingual site, Implement E-discovery, Implement SEO (Search Engine Optimization), Implement content management, Implement a publishing page.
• Design for Performance and Troubleshooting: Design solutions to handle a high-traffic site, Design client applications for performance, Monitor and mitigate performance and scalability issues.
• Implement Managed Metadata Service (MMS): Manage term sets, Create solutions by using MMS, Use an MMS API.

Referências

Hezequias Vanconcelos: SharePoint 2013 – Certificações Microsoft

SharePoint 2013 Certification Overview

Atualizado em 19/10/2012 com informações sobre a certificação MCSE SharePoint.

Atualizado em 04/04/2013 com informações sobre a certificação MCSD SharePoint.

A primeira coisa que vem à sua cabeça é um monte de palavrão e começa a pensar quem foi a pessoa que exclui os workflows. Pensa se tem backup e como irá justificar para o seu chefe ou outras pessoas como que o workflow sumiu. Cadê os logs? O backup vai funcionar? Quem foi que apagou? Em quem vou colocar a culpa (menos né, essa já é demais).

Neste post vamos discutir algumas coisas que podem ocasionar este comportamento, veremos que provavelmente não será por exclusão e sim por outros motivos.

Como já vimos em outros posts neste blog, o SharePoint 2013 possui um novo engine de workflow, que roda de forma isolada ao SharePoint. Quando uso o termo “forma isolada” quero dizer em uma estrutura separada e não mais “dentro” do SharePoint. Este conceito muda muita coisa sobre a forma com que os administradores vão interagir e configurar com esses serviços.

Com base nisso, se tivermos problemas com o serviço de workflow, muito provavelmente os workflows não irão aparecer no SharePoint Designer e nem no site SharePoint. Dependendo do problema.

Então, se os workflows não tiverem aparecendo, o primeiro passo é verificar se o serviço está configurado adequadamente. Para isso, existem um artigo muito útil chamado Troubleshooting Workflow Manager 1.0 Management and Execution.

Outra dica que pode ser útil é verificar se o service application do workflow está associado ao web application. Caso você tenha mais de um service group, isso se torna muito relevante e pode lhe economizar muito tempo e dor de cabeça.

As principais dicas eram essas, espero que ajudem você a ganhar algum tempo e evitar dores de cabeças.

Outro cenário: a lista possui um event receiver que altera as permissões do item e, se necessário, cria um grupo de usuários no site SharePoint. Dificilmente os usuários comuns terão acesso no site para a criação de grupos.

Neste post vamos discutir esses pontos e ver como resolvê-los.

Os cenários acima são diferentes, mas caem no mesmo ponto: os componentes como web parts, event receiver e alguns outros são executados com a identidade do usuário logado no site, ou seja, se o usuário atual não tem permissão de editar um item de lista ou criar um grupo de usuários, essa permissão será respeitada.

Mas se eu precisar realmente fazer isso, não tem como? Tem sim, para isso temos o método RunWithElevatedPrivileges que permite que o código seja executado com privilégios de controle total dentro do site, o que resolveria os problemas apresentados nos cenários anteriores.

Isso não seria uma falta de segurança, permitir que o usuário tenha essa permissão total via componentes de desenvolvimento? Depende da governança existente, se qualquer um poder subir componente é sim, senão não. Por que é a melhor forma de resolver este problema.

A sintaxe básica para utilizar o SPSecurity.RunWithElevatedPrivileges está descrita na listagem 01. Repare que é necessário criar um delegate e colocar todo o código que será executado com privilégio elevado dentro dele, o que pode ser chamada de métodos.

SPSecurity.RunWithElevatedPrivileges(delegate ()
{
   // implementation details ommited
}

Listagem 01: Forma de execução do RunWithElevatedPrivileges

É comum utilizar os objetos SPSite e SPWeb do contexto, através do SPContext, mas neste cenário não se deve utilizar o contexto. Isso porque o contexto está com a identidade do usuário logado no site SharePoint, mas não é isso que queremos, sendo assim é necessário criar um novos objetos SPSite e SPWeb, como mostra a listagem 02, que está pegando o ID do site e lista a partir de um objeto SPListItem.

SPSecurity.RunWithElevatedPrivileges(delegate ()
{
   using (SPSite site = new SPSite(listItem.Web.Site.ID))
   {
      using (SPWeb web = site.OpenWeb(listItem.Web.ID))
      {
         // implementation details omitted
      }
   }
}

Listagem 02: Criando objetos SPSite e SPWeb

Com o uso do SPSecurity.RunWithElevatedPrivileges conseguimos executar código que necessita de permissão elevada dentro do conteúdo do SharePoint, sem que o usuário logado tenha os níveis de permissão necessários.

Referências:

• SPSecurity.RunWithElevatedPrivileges method