Este blog é unha "no ámbito do posible" entrada vs. información concreta.

We have a technical design that calls for us to create a site in a site collection via a manually launched workflow process. Basicamente, os usuarios insiran datos nun cliente novo "" lista personalizada e, a continuación, cando remate e validado o proceso de entrada de datos, necesitamos crear un sitio web para que o cliente.

Eu son un gran fan tanto de fluxo de traballo declarativa, así como un programador de fluxo de traballo feble Visual Studio, entón eu quería atender ao requisito usando o SharePoint Design.

Eu pretendo escribir sobre isto en maior detalle (e espero que presente a un grupo de usuarios ou dous o ano que vén), pero aquí está a solución global:

• Crear unha acción personalizada que se integra con SPD.
• A acción personalizada permite SPD para invocar un servizo web e pasalo a cadea XML.
• Web situada a liña de servizos da lista personalizada e crea un novo sitio web de acordo cos datos para ese novo cliente, usando un personalizado definición web.
• Servizo web, a continuación, actualiza a lista personalizada con algunhas informacións, como un enlace para o novo sitio web.

Foron consideradas outras abordaxes, such as event handlers and visual studio based workflow. The SPD approach gives our end users a little more control over the process. Granted, hai unha morea de código C # con esta solución, pero é acondicionada dentro dun fluxo de traballo declarativa, entón temos algúns dos beneficios do fluxo de traballo declarativa, mentres chamando ao servizo local de creación de.

All we need now is an easy tool to automatically migrate SPD workflows around as easily as we can for visual studio workflows and we’ll really be cooking with gas 🙂 I understand that some folk are out there working on this problem and I hope they have some good success with it soon.

</final>

Rexístrate para o meu blog.

Eu fun xogar con accións personalizadas para o SharePoint Deseño por algún tempo (vexa aquí para algunhas cousas detallada, que che interesa).

O meu proxecto actual, we need to do some fairly heavy lifting and we want to use declarative SPD workflow to manage the associated business process.

Longa historia curta, this is entirely possible. I extended my Codeplex project to invoke a "helper service" and now we can invoke a web service directly from an SPD workflow.

Aquí está a sinatura:

 público corda Expedidor(
        GUID Webid, // Aprobada polo ambiente de execución
        GUID SiteID, // Aprobada polo ambiente de execución
        corda ListId, // Aprobada pola RTE (non sei por que isto é unha cadea, non un GUID)
        int ListItemID ListItemID, // Aprobada pola RTE.
        corda XmlMessage) // Pasado polo usuario, segundo declarou o SPD.

Este aproveita o feito de que podemos obter a información de fluxo de traballo importante, como o lugar, lista de ID, etc. This is well documented in several places for those of you interested in creating your own custom actions. The idea is to extract the XML string as provided by the user to dispatch an appropriate procedure. Fun stuff!

Desafortunadamente, este é, obviamente, un billete de ida-down para "Loosey Goosey" anti-pattern terra, but it’s better than hitting a brick wall 🙂

É un anti-patrón se fai iso mesmo que vostede sabe que é un anti-estándar?

I hope to wrap this inside Codeplex in the near future. If you’re interested in me doing so, dáme picar (e-mail ou deixar un comentario) and I’ll be that more enthusiastic about doing it 🙂

</final>

Rexístrate para o meu blog.

Eu estou a traballar nun proxecto que usa cinco fluxos de traballo do SharePoint Designer diferentes para xestionar algunhas aprobacións de documentos. SPD ofrece os "datos de queda a partir dun usuario" acción para que poidamos solicitar ao usuario para diferentes bits de información, como se aproba-lo, algúns comentarios e quizais preguntar o que tiña para a cea na outra noite.

As formas son perfectamente funcional. Eles están vinculados a unha lista de tarefas como un tipo de contido. Son 100% xerado polo sistema. Esta é a súa forza e debilidade. Se podemos vivir co formulario estándar, entón somos bos de ir. Con todo, non temos moito control sobre como SPD crea o formulario. Se non nos gusta que o comportamento estándar, necesitamos recorrer a varios trucos para contorná-la (por exemplo, establecer a prioridade dunha tarefa).

I necesario para proporcionar unha ligazón sobre eses formularios de tarefas que abriu as propiedades da vista (dispform.asxp) do "elemento relacionado" nunha nova ventá. Isto proporciona un acceso de un click para os datos de meta do elemento relacionado. Isto é o que quero dicir:

Agradecidamente, podemos facer, e non é moi difícil. En termos xerais, lume ata SPD, desprácese ata o directorio que contén os ficheiros de fluxo de traballo e abra o arquivo aspx querer modificar. Estes son só clásico XSL transformar instrucións e se fixo muck aproximadamente con ItemStyle.xsl, investigación ou outros escenarios XSL, que vai ser doado para ti. En realidade, Eu pensei que fose máis doado, pois xeralmente o formulario xerado é algo máis doado de seguir, en comparación con un núcleo de investigación de resultados parte web (ou CWQP pesadelo).

Por suposto, hai unha gran trampa. Editor de fluxo de traballo do SPD espera que o control total sobre o ficheiro. Se modificalo lo, SPD vai alegremente substituirá os cambios dan dereito conxunto de circunstancias. Eu fixen dúas probas rápidos para ver como malo que pode estar. Ambos supoñen que teña creado un fluxo de traballo SPD válido que usa a "recoller datos dun usuario" paso.

Proba 1:

• Editar o arquivo ASPX á man.
• Probalo (comprobar se os cambios foron debidamente gardado e non romper nada).
• Abre o fluxo de traballo e engadir unha acción non relacionada (tales como "rexistro para a historia").
• Garda o fluxo de traballo.

Resultar: Neste caso, SPD non volver a crear a forma.

Proba 2:

• Fai o mesmo que #1 excepto modificar directamente o "recoller datos dun usuario" acción.

Resultar: Esta re-crea o formulario a partir de cero, sobre-escribir os seus cambios.

Notas Finais:

• Polo menos dúas accións SPD crear formas coma este: "Recoller datos dun usuario" e "Asignar To Do elemento". Ambas as accións’ formas pode ser modificado a man.
• Eu era capaz de xerar o meu enlace para DispForm.aspx porque, neste caso, o elemento relacionar sempre ten o seu ID incorporado no URL do elemento relacionado. Eu era capaz de extraelo lo e, a continuación, construír unha <a href> con base nel para facilitar a funcionalidade de acceso de un click datos meta. É improbable que o seu URL segue esta regra. Pode haber outras formas de obter o ID do elemento relacionado, pero eu non tiven que cruzar esa ponte, entón eu non sei se chega ao outro lado do abismo.
• Non investigar, pero eu non quedaría sorprendido se hai algún tipo de arquivo de modelo na 12 colmea que eu podería modificar para afectar a forma como SPD xera os formularios estándar (así como podemos modificar os modelos de alerta).

</final>

Rexístrate para o meu blog!

Eu teño un escenario de negocios coma este:

• Un usuario carga un documento a unha biblioteca de documentos.
• Ela selecciona un tipo de contidos e entra meta datos polo que sexa. Un dos campos de datos de meta é unha bandeira, "Urgent".
• Isto desencadea un fluxo de traballo do SharePoint Design que, entre outras cousas, uses the "Collect Data from a User" acción.

"Collect Data from a User" crea un elemento nunha lista solicitando a aprobación tarefa para aquel documento.

Eu precisaba crear unha visualización da lista de tarefas que amosa as solicitudes urxentes de aprobación.

Solución: Put the word "URGENT:" into the title of these tasks.

I would have preferred to specify the priority field directly. Con todo, Eu era capaz de facelo por varias razóns:

1. A recollida de datos acción non ofrece un mecanismo para actualizar calquera outro campo de título (e os campos adicionais para o que quere recadar datos).
2. The "assign a to do item" acción ten o mesmo problema.
3. É posible inserir un elemento nunha lista (i.e. introducir un elemento da lista de tarefas directamente) but this not a blocking action. That means that the workflow will not wait for the user to complete that task.

Considerei algunhas enfoques antes (agradecidamente) realizing we could just put "urgent" no título.

1. Iniciar un fluxo de traballo na lista de tarefas a si mesmo de xeito que, cando unha nova tarefa créase, que dalgún xeito cruzar referencias ao seu documento, que comezou o primeiro fluxo de traballo, pull out the urgent flag value and update priority as needed.
2. Do something similar with an event receiver. On create of the task, atopar o documento asociado e actualizar prioridade que corresponda.
3. Use the "create list item" action in conjunction with the "wait for field change" action and an event receiver. If we create a list item, we can specify all the fields we want. Use an event receiver to update the original item when the user completes the task and the "wait for field change" action’s condition would be met and the workflow would proceed. (Por algunha razón, Eu tiña máis ou menos resolto sobre esta visión antes sabios decide afastarse por un tempo).

Hai unha desvantaxe para a miña solución (ademais do feito evidente de que o texto do título indica urxencia). Since "collect feedback" só acepta nomes de título codificado, I need to use two different collect feedback actions whose only difference is that hard coded title.

Pero, polo menos hai unha solución que non require receptores de eventos ou accións SPD personalizados.

Se alguén xa resolveu isto dun xeito máis intelixente, por favor me aviso.

</final>

Actualización: Madjur Ahuja apunta este enlace dun discusión newsgroup: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. It’s pretty definitive.

===

We often want to embed hyperlinks to InfoPath forms in emails sent from SharePoint Designer workflows. When users receive these emails, poden premer na ligazón do correo-e e ir directamente ao formulario do InfoPath.

Este URL construción monstro funciona para min:

http://server/sites/departments/Technical Services/InformationTechnology/HelpDesk/_layouts/FormServer.aspx?XmlLocation=/sites/departments/Technical Services/InformationTechnology/HelpDesk/REC REM RED Forms/REC2007-12-18T11_33_48.xml&Source=http://server.corp.domain.com/sites/departments/Technical%20Services/InformationTechnology/HelpDesk/REC%20REM%20RED%20Forms/Forms/AllItems.aspx&DefaultItemOpen = 1

Substituír o texto en negra vermello co nome do formulario, como se mostra na imaxe seguinte:

Teña en conta que hai unha morea de camiño hard-Coded ese URL, as well as a URL-encoded component. If this is too hard to translate to your specific situation, try turning on alerts for the form library. Post a form and when you get the email, ver o código fonte do correo electrónico e vai ver todo o que ten que incluír.

Astute readers may notice that the above email body also shows a link that directly accesses the task via a filtered view. I plan to explain that in greater detail in a future post.

</final>

I’ve implemented a workflow using SharePoint Designer in a site which is mainly read-only to "NT_AUTHORITY\Authenticated Users" (i.e. todos). There is a forms library for an InfoPath form. There is an associated workflow tasks list as well so that when the workflow operates, pode atribuír tarefas a persoas.

Eu romper o permiso para a biblioteca de formularios e lista de tarefas para que calquera usuario rexistrado pode crear formularios e actualizar as súas tarefas.

I test with my low-privileges test account.

Podo cubrir e gardar un formulario á biblioteca? –> SI

Podo acceder a tarefa desde unha ligazón de correo-e? –> SI

Podo ver unha ligazón Editar tarefa de fluxo de traballo –> SI

Podo facer clic na ligazón? –> NO … Permiso denegado.

Polo que podo ver unha ligazón Editar que nega-me o permiso cando premer sobre el? That’s not how it’s supposed to work…

Eu atravesso a configuración de seguridade de novo, very closely. I do it again. I considerar a exclusión deste post porque eu obviamente non sabe nada sobre seguridade.

Finalmente, I search the Internets. I find this highly unlikely MSDN forum thread: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Os carteis parecen suxerir que o simple acto de exportar o fluxo de traballo para unha travessa unidade pode resolver un problema de seguridade Moss? I can hardly believe I just typed that. I’m reminded of the South Park episode about the 9/11 conspiración onde Stan está pedindo nosa Preznit, "Really?" over and over again.

Así, nada que perder, Eu lume ata SPD, dereito do rato sobre o fluxo de traballo e garda-lo para o meu c:\ drive. That would be the c:\ drive on my laptop. I’m looking over my shoulder the whole time so that no one will ask me, "why are you saving that workflow to your laptop?"

Incrible, that solves my problem. I can edit the task.

Teño a honra de indicar que esta é a solución alternativa de fluxo de traballo máis bizarro de 2007.

</final>

We often want to send an email that includes a hyperlink to the item or document that triggered the workflow. We can use current item’s "Encoded Absolute URL" for this purpose. Con todo, it always seems to use "http" for the URL protocol. If your site runs on HTTPS then it will not work for you.

Polo que eu sei, there is no out of the box solution to this problem. If you need to use HTTPS, non ten a opción de caixa.

Para resolver-lo, create a custom action that provides a string replace function to use in your workflow. Alternatively, usar unha ferramenta de terceiro partido, como o excelente paquete aquí: http://www.codeplex.com/spdwfextensions 🙂

</final>

Os usuarios do foro, en ocasións, pedir: Por que poñer o SharePoint Design ???? no meu correo electrónico en lugar dun valor de campo?

Unha razón isto acontece é porque a variable á que se refire é nulo.

Isto pode ocorrer porque estás a facer referencia a un campo do elemento "actual" but the user never entered a value into that form field.

</ Comezo>

Escenario: En un fluxo de traballo do SharePoint Design, you need to determine if a date field is blank.

Problema: SPD does not provide a direct method for comparing dates to anything other than a date. You cannot create a condition like this: "Se [DateField] é igual en branco ".

Solución: Convert the date to a string. Use string comparison to determine if the date is blank.

Screen Shots:

The following screen shots show how to do this. Neste escenario, a field on an item, "Environmental Permits:First Permit Reminder Date", is submitted and the workflow fires in response.

Notas:

When I tried this, I was pleasantly surprised to learn that it works. I was worried that SharePoint Designer might disallow the string assignment (Variable:StringReminderDateDate) but it did allow it.

I was also concerned that allowing it, the value might be null and either blow up the WF at runtime or maybe raise the global temperature 1/2 a degree, but those concerns were unfounded.

</final>

Basta unha observación rápida, que hai unha diferenza moi importante entre estas dúas definicións:

<FieldBind Field="InParam1" DesignerType="StringBuilder" Id="2" Text="Input parameter #1"/>

contra:

<FieldBind Field="InParam1" Id="2" Text="Input parameter #1"/>

O primeiro mostra como este en SPD:

mentres que o último amosa como este:

I’m not sure how helpful these screen shots are but I put in the effort to make them so you have to view them 🙂

A observación é este: StringBuilder permite que constrúe unha secuencia de (obviamente) pola mestura de cadeas e datos de fluxo de traballo (via the "Add Lookup" botón na parte inferior esquerda). When you use the Add Lookup button, it inserts a token in the form "[%% Símbolo]". When SharePoint invokes your custom action, (Código C # no meu caso), SharePoint pasa o token-se, not the value of the token. If you use the default designer type (O segundo tipo), SharePoint amplía o sinal e pasa o valor real do token para a súa acción.

StringBuilder = BAD, tipo de deseño default = BO.

Por suposto, that’s not what I really mean. Just don’t try and pass a parameter to your custom action when the designer type = StringBuilder. Use the default designer type and chain a StringBuilder to it up front if you need to build complex strings in your workflow (que, de feito, é o que se fai para crear un tema dinámico para a acción de correo-e, pero iso é asunto para outro blog, foi).

</ Comezo>