Eu escrevi um artigo para SharePointBriefing.com e colocaram-ao vivo hoje.
Aqui está um teaser:
</fim>
Siga-me no Twitter em http://www.twitter.com/pagalvin
Estou trabalhando em um projeto onde eu preciso extrair anexos de um formulário do InfoPath. Existem alguns bons recursos para análise de formulários do InfoPath (que são apenas arquivos XML, Portanto, é realmente muito fácil).
Enquanto eu estava construindo o projeto, Comecei a baixar um formulário do InfoPath e salvando-o meu disco rígido local. Meu código c# estava lendo diretamente de instância. No entanto, os formulários do InfoPath são realmente vivendo dentro de uma biblioteca de formulários do SharePoint. Eu fiz um pouco meio coração pesquisa para descobrir como se lê diretamente da biblioteca e quase desisti, Nesse caso eu teria salvo o formulário para um diretório temporário local e lê-lo de lá. No entanto, Não há nenhuma necessidade de atravessar arcos como você pode lê-lo diretamente da biblioteca. Este pequeno trecho de código mostra como:
/// Coisas de definição de classe aqui, incluindo:
privada SPFile t: Microsoft.SharePoint.SPFile mySharePointFile; /* Parte de um SPList */ // Mais código vai aqui e dentro de um método da classe temos: textReader = Novo XmlTextReader(mySharePointFile.OpenBinaryStream()); textReader.WhitespaceHandling = WhitespaceHandling.Nenhum; TextReader(); // Se o nó tiver valor ao mesmo tempo (TextReader()) { |
Eles-chave bit acima é que podemos ler o InfoPath diretamente via o OpenBinaryStream() chamada de método sobre o SPFile como um parâmetro para o Construtor em XmlTextReader. Ele funciona muito bem.
</fim>
Siga-me no Twitter em http://www.twitter.com/pagalvin
Eu tenho uma solução de entrada de despesa para um cliente que utiliza o InfoPath e o fluxo de trabalho. Em um ponto durante o processo de aprovação, Eu preciso gerar um e-mail que tem tudo de que bons dados do InfoPath, como também os anexos próprios para que (suspiro) alguém pode tomar esses dados e recodificá-lo manualmente em um aplicativo de banco de dados Oracle.
Não é muito difícil de obter em ou analisar o formulário do InfoPath. Não sabia como lidar com os acessórios, no entanto. Após uma hora ou duas de bisbilhotando o Internets (uma eternidade!) Eu encontrei este artigo: http://support.microsoft.com/kb/892730
Ele fornecer algum código útil para extrair o acessório de um nó na forma. (Você ainda precisa encontrar o nó e todos os que, Mas isso é apenas análise de XML).
Eu sei que o anexo é codificado na base64 e originalmente desci o caminho de apenas extrair os dados base64, decodificá-lo e salvá-lo. No entanto, Rapidamente percebi que não sabia como conseguir o nome do arquivo em si, até que encontrei o referido artigo.
Na verdade achei que bem cedo, Mas eu fui posto por sua dupla personalidade. Por um lado, o artigo * diz * é bom para o InfoPath 2007. Ainda, o código e as instruções são todas sobre Visual Studio 2003 e as referências ao InfoPath 2003.
Linha inferior, Este artigo, desde que o código está funcionando bem para mim (até agora). Eu consigo meu formulário do InfoPath, Pode analisá-lo, Eu posso encontrar e decodificar o acessório e eu sei o seu nome. O que mais pode um perguntar da vida?
</fim>
Siga-me no Twitter em http://www.twitter.com/pagalvin
Se você está preocupado que seu ambiente do SharePoint pode ser um pouco doentio., Deixe-me ajudar a consertar isso com um exame de saúde.
Tenho um processo de aprovação de despesas que preciso implementar usando o InfoPath em uma autenticação de formulários com base (FBA) ambiente usando os serviços de formulários (Web baseado do InfoPath).
Existem dois grupos de aprovação e o processo funciona assim:
No lado do InfoPath de coisas, Tenho diferentes seções que esconder/aparecem com base em se o usuário é um membro de um desses grupos de aprovação.
Em um ambiente de FBA, o nome de usuário() função sempre retorna em branco, Infelizmente. O que eu fiz é configurar um uma lista personalizada chamada "Grupos de aprovação".
Não adicionar quaisquer colunas adicionais à lista.
Quando abre o formulário, tem uma regra assim:
O valor de um campo "set" é aqui:
Isto é basicamente dizendo: Consulta a lista personalizada do grupo aprovação e filtro que consulta procurando por qualquer linha onde o valor do título = "Nórdico".
Se que retorna qualquer valor, em seguida, o usuário atual é um membro desse grupo. Eu sei que contém esse valor porque o comprimento da seqüência de caracteres é maior que zero.
Fechar o ciclo fixando os itens individuais na lista grupo de aprovação. Em tempo de execução, Se o usuário atual não tem acesso de segurança apropriadas para esse item, em seguida, a consulta não vai devolvê-lo, comprimento de seqüência de caracteres será zero e agora sabe que o usuário atual não é parte desse grupo. Você pode usar esse fato como necessário na forma.
Este é um super breve write-up. Eu estou com pressa, ou eu iria fornecer mais detalhes.
Não sei quão relevante é o que eu estou em um ambiente de FBA. Isto provavelmente funcionaria bem em um ambiente não-FBA, mas posso imaginar casos onde isso seria útil.
</fim>
Siga-me no Twitter em http://www.twitter.com/pagalvin
Eu estava trabalhando em um formulário InfPath hoje e correu contra um velho amigo, "Exceção sem tratamento quando processamento forma sistema.XML.XmlException: Fim de arquivo inesperado ao analisar o nome ocorreu."
Isso aconteceu comigo há muito tempo e não sei o que exatamente eu fiz para resolvê-lo. Honestamente, Eu acho que eu tinha sido fazer a transição para um novo projeto e nunca vi este um resolvido (meus substituições tinham de lidar com essa dor de cabeça). Eu me lembro que era um diabo de um problema. Passei vários dias sem sucesso, a lidar com isso. Desde então, Eu vi isso surgem em fóruns do MSDN, pelo menos uma vez no ano passado e realmente nunca vi uma resposta para ela.
Eu bati ele hoje e felizmente desta vez , Eu só tinha feito uma mudança para o formulário. Desisti dessa mudança e o problema foi embora. Acontece que é possível criar uma de modelo usando o Designer do InfoPath de modo que ele gera um erro de análise no lado do servidor de formulários da cerca.
No meu caso, o problema foi causado por estes passos:
Não sei se essas etapas causam um problema ou talvez, de alguma forma os dados na própria lista são um problema. Vou experimentar um pouco e ver se eu posso pregar d parâmetros isto com mais detalhes.
</fim>
Siga-me no Twitter em http://www.twitter.com/pagalvin
Eu ainda estou vivendo em mundo de formulários do InfoPath e eu precisava fazer uma dessas "pequenas" mudanças de uma forma que, Infelizmente, quebra uma Convenção de nomenclatura que adotei com ele há duas semanas.. Eu pensei:, "alguém vai olhar para essa coisa de um ano de agora e dizer, ' O que estava pensando Paul? Por Júpiter, a Convenção de nomenclatura não faz sentido!”
Eu percebi que eu poderia criar uma exibição no formulário para isso e então, Mais uma vez, percebi que eu poderia ter feito algo assim ao longo de toda. Eu adicionei um modo de exibição de "Notas do desenvolvedor" para o formulário do InfoPath como tal:
Eu configurei o formulário para que os usuários não podem pegar esse ponto de vista e, portanto,, Só é visível com o cliente do InfoPath no modo de design. Agora sinto-me um pouco inoculado contra algum desenvolvedor desconhecido futuro olhando minha forma e pensar em coisas ruins sobre mim. Ufa!
</fim>
Siga-me no Twitter em http://www.twitter.com/pagalvin
Parece que passam por fases de InfoPath onde, fora do azul, Eu estou a elaborar um monte de formulários. Meus dedos aprendem como usar a ferramenta bem e depois passar por seca de nove meses e tem que aprender tudo de novo.
Estou no meio de uma fase do InfoPath e estou criando formulários do InfoPath com um monte de pontos de vista. Uma coisa que você provavelmente notar é que o InfoPath 2007 cliente mostra vistas em ordem alfabética. Este é um verdadeiro incômodo algumas vezes. Minha melhor técnica nos dias de hoje é para preceder um número para o nome de exibição para que eles sempre mostram na ordem que eu quero, conforme ilustrado aqui:
Quem me dera que eu tinha feito isso desde o começo.
</fim>
Siga-me no Twitter em http://www.twitter.com/pagalvin
Eu estive trabalhando em alguns formulários do InfoPath esta semana em musgo em um ambiente de FBA e aprendeu, Quando fui para implantar os formulários a um ambiente de produção com um FBA zona que o nome de usuário() função de função não funciona. Eu estava usando para gerar nomes de arquivo exclusivo.
Bem, Essa função não funciona em um ambiente de FBA (pelo menos, não fora da caixa). E, após a reflexão, usar o nome de usuário da maneira que eu tinha planejado não garantiram um nome de arquivo exclusivo em todo o caso.
Minha solução foi usar o agora() função e uma regra que é acionado na carga do formulário. Eu atribuir o nome de arquivo para o elemento de dados quando ele estiver em branco:
A vantagem dessa abordagem é que o nome do arquivo é definido somente uma vez. (Eu não mostrá-lo na captura de tela, mas colocar uma condição na regra ao fogo somente quando "meuNomeDeFicheir" está em branco). Eu usei para definir o nome do arquivo a nível de fonte de dados. Normalmente, Gostaria de fazer algo (ruim) Assim:
O problema com isto é que, se o usuário abre o formulário na segunda-feira e o usuário B muda-na terça-feira, você vai acabar com duas formas diferentes, já que dois usuários diferentes salva-lo com nomes diferentes.
Assim, tão irritante como FBA pode ser em geral e com o InfoPath em particular, Isso me fez repensar um pequeno mas importante detalhe técnico e abordagem que eu não teria feito de outra forma!
</fim>
Siga-me no Twitter em http://www.twitter.com/pagalvin
Há um cenário de negócio comuns como este:
Este exemplo office.microsoft.com Descreve como criar uma exibição separada"" e marcar a visão inteira como somente leitura. Esta é uma abordagem viável, mas tem a desvantagem que você efetivamente criou duas versões inteiras da mesma forma e deve agora mantê-los em sincronia manualmente. Se você adicionar um campo para a exibição editável, Você deve adicioná-lo para o modo de exibição não-editável também. Ao longo do tempo, com diferentes desenvolvedores, pode haver alguma divergência.
Esta alternativa pode funcionar melhor em alguns casos:
A desvantagem dessa abordagem é que todos os campos poderão ser editáveis na tela. O usuário pode obter uma falsa impressão de que eles podem realmente mudar o conteúdo. Você pode atenuar isso, colocando em algum texto que o formulário está desabilitado, possivelmente em grandes letras vermelhas no topo da página.
Em um projeto, Eu criei um status de fluxo de trabalho"" Exibir. Como o fluxo de trabalho progrediu, Ele iria atualizar campos de status específico que tinham sido promovidos de forma a. Quando o usuário abrir o formulário, o "formulário aberto" regra comutado automaticamente para que o Vista e o usuário tinham um status de resumo pouco agradável.
</fim>
Tivemos um desenvolvido um formulário do InfoPath com várias exibições para oferecer suporte a uma nova contratação / processo de ambientação. Quando a empresa contrata uma nova pessoa, o departamento de TI e outros grupos precisam agir (configurar a folha de pagamento, permitir o acesso aos aplicativos apropriados, Localize uma mesa, etc). Usamos na forma, mas uma visão diferente do formulário para cada uma dessas funções.
Esta empresa, QUE conhecem a maioria das pessoas envolvidas no processo de negócios são, Então, quando eles acessarem o formulário, seu modo de exibição padrão é um menu"" Ver os com botões que encaminhá-los para sua função específica. No entanto, Precisamos simplificar as coisas para o gerente direto a nova contratação. Esta pessoa não deve ver que qualquer do que coisas relacionadas. Na verdade, Ela deve ver apenas um modo de exibição do formulário e nem sequer têm uma opção para ver os outros modos de exibição.
No nosso caso, que direcionar a conta do gerente está diretamente ligada à forma cortesia de um entre em contato com o selector (que eu sempre estou querendo chamar um "people picker" por algum motivo).
As etapas são as seguintes:
1. No modo de design, Vá para ferramentas-> Opções de forma-> Abrir e salvar.
2. Selecione "regras".
3. Criar uma nova regra, cuja ação é "alternar para exibir" e cuja condição utiliza o nome de usuário() função.
nome de usuário() Retorna o simples"" nome de usuário sem o domínio. Se eu entrar no SharePoint com credenciais "domainpagalvin", nome de usuário() Retorna "pagalvin".
O seletor de contato fornece três bits de informações de um contato. O "AccountID" porção é mais útil para esse cenário. A única coisa que faz isso mesmo um pouco de desafio é que o seletor de contato (no meu ambiente de qualquer maneira) Retorna a ID de domínio e de usuário, como em "domainpagalvin". Isto nos impede de ter uma condição de igualdade direta desde AccountID ("domainpagalvin") nunca será igual a nome de usuário() ("pagalvin").
Podemos obter em torno desta usando o "contém" operador: AccountID contém nome de usuário().
Podemos tomá-lo ainda mais e pre-pend um domínio embutida na frente do nome do usuário() função para obter nossa verificação de igualdade e eliminar o risco de falsos positivos sobre o contém operador.
Temos realmente como alternar automaticamente o modo de exibição para outros usuários com base em sua associação de grupos de segurança do AD. Por exemplo, Quando um membro do "ele Analytics" grupo acessa o formulário, alternar automaticamente para o modo de exibição IT Analytics. Não tivemos tempo para implementá-lo, mas meu primeiro pensamento é criar um serviço web que teria um método como "IsMemberOfActiveDirectorySecurityGroup", passe a ele o nome de usuário() e retornar para true ou false. Alguém tem algum outro, idà © ia mais? Existe alguma função de SharePoint que pode aproveitar do InfoPath para fazer essa determinação?
</fim>
