A maior alteração feita nos treinamentos foi a incorporação do SharePoint Online, agora os treinamentos possuem módulos específicos para tratar do SharePoint que faz parte do Office 365 e inclusão de itens que vieram novos no SP1.

Essa alteração já era algo esperado, já que as provas correspondentes já estavam tratando desses assuntos.

Link das versõe novas:

10174B – Configuring and Administering Microsoft SharePoint 2010

10231B – Designing a Microsoft SharePoint 2010 Infrastructure

Esta promoção durará até dezembro e terá atividades durante o ano inteiro.

Um dos benefícios fornecidos até agora é a possibilidade de ganhar um voucher para fazer qualquer das provas abaixo:

• Exam 70-583: PRO: Designing and Developing Windows Azure Applications
• Exam 70-640: TS: Windows Server 2008 Active Directory, Configuring
• Exam 70-659: TS: Windows Server 2008 R2, Server Virtualization
• Exam 70-662: TS: Microsoft Exchange Server 2010, Configuring
• Exam 70-664: TS: Microsoft Lync Server 2010, Configuring
• Exam 70-573: TS: Microsoft SharePoint 2010, Application Development
• Exam 70-599: PRO: Designing and Developing Windows Phone Applications

Vamos acompanhar para ver os outros benefícios, participe!

Workflows são recursos presentes em diversos projetos SharePoint, geralmente são feitos no SharePoint Designer e outros, mais complexos, no Visual Studio.

Neste post vou falar de algumas considerações sobre o desenvolvimento e implantação sobre workflows feitos no Visual Studio, o foco não é explicar como fazer, mas informar sobre alguns cuidados importantes na implantação deles.

Solução

A implantação de novos workflows em ambiente de produção são praticamente iguais a qualquer solução (solution) ou recurso (feature) feitas para o SharePoint 2010, basta “só” instalar o pacote no servidor e associar o workflow à biblioteca.

Até aí não tem muito segredo, mas como fazer quando um workflow estiver sendo executado? Como atualizá-lo? Imaginem o seguinte cenário: a versão 1.0 do workflow está rodando e existem 500 documentos (formulário, documentos, itens, qualquer coisa) que estão executando esse workflow. O worklfow sofre alterações e algumas atividades são adicionadas. Ao liberar a atualização do pacote, sem os devidos cuidados, todas as 500 instâncias que estão em execução irão parar de funcionar.

Por que isso acontece? Porque uma instância de workflow fica grande parte do tempo persistida em banco de dados ao invés de ocupar a memória do servidor – o SharePoint abstrai esse comportamento para nós. Sempre que um workflow está aguardando uma ação de usuário ou resposta de um serviço, a sua instância é serializada e gravada em banco. Quando essa ação acontece, como por exemplo o usuário editar uma tarefa pendente, o workflow é desserealizado, volta para a memória e continua a execução do ponto em que estava.

Agora que já entendemos um pouco mais, fica mais simples de explicar o problema gerado e sua solução. Como o assembly da alteração realizada é diferente da versão original, o .NET não vai conseguir desserializar as instâncias do banco de dados e carregar para a memória, ou seja, todos os processos rodando vão parar de funcionar. É como se a tarefa perdesse a referência com o workflow, ocasionando diversos problemas aos usuários.

A solução para isso é encarar as coisas com uma visão um pouco diferente. Para começar encare que cada alteração no workflow a partir do Visual Studio é um workflow novo que deve ter uma feature com nome e identificadores diferentes, assemblies com versão diferente – o nome das dlls pode ser o mesmo, se eles forem alterados terá muito trabalho desnecessário – e atribuição dos workflows à lista com nomes diferentes. Ao atribuir um workflow novo (versão nova) a uma lista ou biblioteca configure os demais para não iniciarem automaticamente, dessa forma somente a versão nova será iniciada automaticamente.

Isso significa que uma biblioteca terá diversas versões do workflows rodando ao mesmo tempo? Sim, isso mesmo,  lembrando que um item terá uma instância do workflow sendo executada, o que não ocasionará problemas no ambiente.

Pensem no assunto e evitem problemas futuros.

Criar scripts PowerShell algo muito comum para administradores de serviços Microsoft, ele vem conquistando cada vez mais espaço e grande parte dos produtos da Microsoft estão vindo com muito suporte ao PowerShell, dá para fazer tudo o que é feito pela interface e geralmente mais coisas.

A parte mais complicada de fazer um script é ver as funções existentes e quem sabe, ter algo mais voltado ao usuário para a criaçãod e scripts. Já que trabalhamos tanto para o usuário final, porque não podemos ter algo mais simples também? O Visual Studio é uma bela IDE para fazer scripts PowerShell, sem sombra de dúvidas, mas já pensou se tivesse alguma ferramenta que fosse voltada para algum produto específico. Algo como uma ferramenta que ajudasse a ver os comandos e a criá-los rapidamente através de um “wizard”?

Solução

Pois é, isso existe. Graças ao meu amigo Wilson Júnior (que descobriu o link) agora podemos criar scripts PowerShell para SharePoint Foundation, SharePoint Server e Office 365 utilizando o Windows PowerShell Command Builder, feito em Silverlight. Ele nos permite selecionar os verbos (1) ou substantivos (2) e arrastar para a área de design (3), após isso ele pede os parâmetros obrigatórios e permite que os adicionais sejam adicionados, gerando o comando logo abaixo dos campos.

Imagem 01: Tela da ferramenta

É a primeira vez que vejo uma ferramenta assim para PowerShell, independente da tecnologia. Quando encontrar outras posto aqui as referências.

Fiquei supreso com a facilidade e funcionalidade, muito bom!

Abaixo seguem os links diretos para os vídeos:

Aqui está um resumo:

A sala de concertos da Ópera de Sydney tem uma capacidade de 2.700 pessoas. Este blog foi visitado cerca de 13.000 vezes em 2011. Se fosse a sala de concertos, eram precisos 5 concertos egostados para sentar essas pessoas todas.

Clique aqui para ver o relatório completo

É uma grande honra fazer parte do time de MVPs e principalmente do time de MVPs de SharePoint (Hélio Sá Moreira, Thiago Cruz Soares e Fernanda Saraiva), obrigado JP pela confiança e oportunidade. Parabéns aos demais novos MVPs (Sara Barbosa – Office 365, Rodo Marques – WP7, Elemar Jr – C#, Fabrício Sanchez – ASP.NET, entre outros que ainda não conheço) e aos que renovaram.

Depois de receber o e-mail de nomeação fiquei pensando: “Toda virada de ano a gente pensa que o próximo ano vai ser de arrasar”, a conclusão que cheguei é que isso é a mais pura verdade. Todo ano tem sido de arrasar, acho que estamos numa fase muito boa de crescimento profissional e pessoal que nos leva a todo ano fazer as coisas melhores.

No primeiro dia útil de 2011 eu fiz a minha última prova de SharePoint 2010, conseguindo a certificação de MCPD de SharePoint 2010, no primeiro dia do ano de 2012 recebo a nomeação de MVP, estou com medo de 2013 (rsrsrs).

Após o SharePoint ter entrado na minha vida ela mudou radicalmente. Sabe quando vc faz algo que gosta muito e faz com muita vontade? Pois é, assim que me sinto trabalhando com SharePoint, mais do que um trabalho, é uma diversão trabalhar com ele. É muito gratificante e os resultados são fantásticos. Lembro que uma vez fui numa palestra do Hélio Sá Moreira (MVP de SharePoint) no TechEd Brasil 2008 e ele falou algo que ficou marcado, foi mais ou menos assim: “Com o SharePoint podemos fazer projetos em menos tempo do que o esperado, é aí que surpreendemos e etregamos mais coisas para o cliente, deixando ele muito mais satisfeito”. Fantástico, depois disso foi algo que tentei fazer em todos os projetos: surpreender o cliente positivamente.

Pois é, depois de tanto estudar, trabalhar e contribuir com o SharePoint surgiram várias oportunidades e uma delas me chamou muito a atenção, acabei parando em Uberlândia/MG. Agora sou morador de Uberlândia (finalmente com a família toda) e estou ensinando a minha filha a falar “Uai sô” e “SharePoint” (esse é um pouco mais difícil de falar). O mais interessante é que vim parar aqui por causa do SharePoint, tenho certeza que o SharePoint continuará me trazendo coisas boas.

Gostaria de agradecer ao pessoal das comunidades BluDotNet, MCITPSC e CanalTechShare as quais tive o prazer de participar e continuarei participando, só que algumas delas por serem físicas com menor participação; ao pessoal da DotNetSô, que estamos movimentando aqui em Uberlândia; ao Alex Schulz, Fábio Hara, Lucas Romão e muitos outros que sempre me motivaram e apoiaram nessa jornada, o que são muitos e outros muitos ficariam de fora, sintam-se agradecidos. Muito obrigado ao pessoal que postou os agradecimentos no Twitter, Facebook e pessoalmente, é muito importante ver esse carinho todo. À KeepIT, por ter me ajudado no meu desenvolvimento profissional com o SharePoint e em especial à uma das três pessoas mais importantes da minha vida, que sempre me ajudou quando eu precisei, sem ela nada disso seria possível, muito obrigado Eleriane Costa, a digníssima mãe dos meus filhos.

Detalhes no blog do Luciano Condé – Anúncio–Novidades Dezembro 2011–150 GB de SQL Azure, Novo sistema de Billing e outras.

É muito comum pessoas que trabalham com SharePoint e estão iniciando e estudando o produto terem dúvidas do que é uma coleção de sites (site collection) e um site e quando usar cada um deles.

Neste post vou tentar esclarecer alguns pontos sobre o assunto e quem sabe com base nisso tirar um pouco da dúvida.

Solução

Por questão de definição, uma coleção de sites é um conjunto de sites, ou seja, ela contém vários sites. Para um site existir ele obrigatoriamente deve estar dentro de uma coleção de sites.

Isso não diz muita coisa, mas é um começo, vamos em frente…

As principais capacidades e recursos de uma coleção de sites são as seguintes:

1. Base de dados: uma coleção de sites pode estar dentro de uma base de dados exclusiva para ela, mas somente em uma. Uma base de dados pode conter várias coleções de sites. Essa capacidade permite a criação de uma base única e depois ir dividindo em outras bases conforme necessidade e crescimento da coleção de sites. Um site, como está dentro de uma coleção de sites, não pode ser dividido desta forma, ele vai respeitar o que estiver definido na coleção de sites;
2. Segurança: uma coleção de sites é um container de segurança, é o nível superior de permissionamento (sem contar a farm e políticas de segurança do aplicativo web). Todas as configurações feitas como níveis de permissão, grupos de usuários, permissões de acesso devem ser feitos em todas as coleções de sites. Em compensação, os sites utilizam automaticamente a segurança do site superior. Tudo o que for criado e aplicado dentro da coleção de sites pode ser aplicado e utilizado em todos os seus sites;
3. Provisionamento: as coleções de sites são criadas a partir da Administração Central, ao criar uma coleção de sites o SharePoint automaticamente cria um site de nível superior, que é um site normal, apenas foi criado automaticamente. Por via de regra um usuário nunca vai acessar uma coleção de sites, ele irá sempre acessar o site de nível superior da coleção de sites desejada. Os sites são criados a partir da própria coleção de sites e todos que forem criados ficarão dentro dela. Outro ponto importante no provisionamento é o endereço, uma coleção de sites sempre terá um endereço definido por um caminho gerenciado, como “sites”, “pessoal”, “departamentos”, etc., enquanto um site vai respeitar sempre o endereço do site superior. Uma coleção de sites pode ser migrada de um aplicativo web para outro e levar com ela todo seu conteúdo e configurações, enquanto um site não, ele será migrado para dentro de uma outra coleção de sites;
4. Conteúdo: o conteúdo de uma coleção de sites não pode ser acessado de outra coleção de sites, pelo menos não com os recursos padrão do SharePoint. Existem ferramentas de terceiros e poderíamos criar ferramentas para fazer isso, mas pelo SharePoint mesmo não dá. Dentro de uma coleção de sites, entre subsites, essa operação é possível. O SharePoint contém web parts padrão para fazer isso;
5. Navegação: uma coleção de sites tem navegação isolada de outras coleções, enquanto um site pode herdar a navegação de seu site superior. Coleções de sites possuem uma configuração que permite “dizer” que ela está abaixo de uma outra coleção de sites. Com isso a navegação não muda, mas através da opção de visualização da hierarquia (fica na ribbon, é um botão com uma flecha para cima) ele apresenta a coleção de sites atual sob a configurada. A implicação dessa configuração é apenas isso, mas auxilia muito o usuário;

Onde utilizar uma coleção de sites e/ou sites?

A resposta para esta pergunta não é trivial. Varia muito de acordo com o cenário e necessidade do projeto. Tudo depende de variáveis como: tamanho do conteúdo total, gerenciamento, isolamento de segurança, público alvo, permissionamento, reaproveitamento de conteúdo, etcs.

Algumas perguntas que poderiam ajudar na decisão:

• Qual o tamanho total de arquivos que o usuário irá postar no site? Dependendo da resposta é melhor dividir em várias coleções de sites e até em várias bases de dados. Colocar todo o conteúdo em um único site, isso vai de encontro com as recomendações do SharePoint, ver em referências para mais detalhes;
• Será necessário consulta de conteúdo entre sites? Uma coleção de sites não troca informações com outras, um site troca com outro, desde que dentro da mesma coleção de sites; 
• Os usuários irão acessar todos os sites? Separar em coleções de site facilita, ou não, o gerenciamento de segurança. Em sites com acessos mais restritos fica mais simples gerenciar;
• O gerenciamento deverá ser simples? Querendo ou não, com várias coleções de site o gerenciamento fica um pouquinho mais complexo. Deve ser avaliado;
• O portal deverá trabalhar com vários temas? Cada site pode ter um tema diferente, mas fazer em nível de coleção de sites é um pouco mais fácil. Por outro lado, para aplicar o mesmo tema em várias coleções de sites é mais trabalhoso.
• …

Essas foram apenas alguns questionamentos que podem ser feito, vários outros podem ser adicionados. O importante é entender bem a diferença entre coleção de sites e sites para tomar a decisão mais assertiva para o projeto.

Para desenvolvedores o importante é saber que um objeto SPSite é uma coleção de sites e um SPWeb é um site.

Referências:

• SharePoint Server 2010 capacity management: Software boundaries and limits
• Sites and site collections overview (SharePoint Server 2010)
• About SharePoint Site Collections

Vou utilizar este post para publicar links interessantes sobre material, artigos, posts e outros tipos de conteúdo a respeito de SharePoint.

Solução

Collaborating with SharePoint Server 2010 Get Started