Esta entrada de blog es más un "en el ámbito de lo posible" entrada vs. información concreta.

Tenemos un diseño técnico que requiere para que poder crear un sitio en una colección de sitios mediante un proceso de trabajo manual lanzó. Básicamente, los usuarios introducen datos en un "nuevo cliente" lista personalizada y, a continuación, cuando han terminado y validado el proceso de entrada de datos, Tenemos que crear un sitio para que el cliente.

Soy un gran fan de flujo de trabajo declarativo, así como un programador de flujo de trabajo débil visual studio, así que quería cumplir el requisito de uso de SharePoint Designer.

Tengo pensado escribir sobre esto en mayor detalle (y esperemos que presentar a un grupo de usuarios o dos en el año que viene), pero aquí está la solución general:

• Crear una acción personalizada que se integra con el SPD.
• La acción personalizada permite SPD invocar un servicio web y se pasa una cadena de XML.
• Servicio Web localiza la fila en la lista personalizada y crea un nuevo sitio como por los datos de ese nuevo cliente utilizando una definición de sitio personalizado.
• Servicio Web, a continuación, actualiza la lista personalizada con alguna información como un enlace al nuevo sitio.

Hemos considerado otros enfoques, como controladores de eventos y flujo de trabajo de visual estudio. El enfoque SPD da a nuestros usuarios finales un poco más control sobre el proceso de. Otorgado, hay un montón de código de C# en esta solución, pero está envuelto dentro de un flujo de trabajo declarativa, por lo que obtener algunos de los beneficios del flujo de trabajo declarativa mientras se enganchen al servicio de creación de sitios.

Todo lo que necesitamos ahora es una herramienta fácil de migrar de forma automática SPD flujos de trabajo en torno a la misma facilidad que lo que podamos para flujos de trabajo de Visual Studio y que realmente va a ser cocinar con gas 🙂 entiendo que alguna gente por ahí están trabajando en este problema y espero que tengan un buen éxito con él pronto.

</final>

Suscribirse a mi blog.

He estado jugando con acciones personalizadas de SharePoint Designer para algún tiempo (ver aquí para algunas cosas detalladas, Si le interesa).

En mi proyecto actual, tenemos que hacer un trabajo bastante pesado y queremos usar flujo de trabajo declarativo de la SPD para gestionar el proceso de negocio asociado.

Larga historia corta, Esto es totalmente posible. Amplié mi proyecto de Codeplex para invocar un "servicio de ayudante" y ahora podemos invocar un servicio web directamente en un flujo de trabajo SPD.

Aquí está la firma:

 público cadena Dispatcher(
        GUID WebID, // Pasó por el entorno de ejecución
        GUID SiteID, // Pasó por el entorno de ejecución
        cadena ListID, // Pasó por el editor de texto enriquecido (no sé por qué esto es una cadena, no un GUID)
        int ListItemID, // Pasó por el editor de texto enriquecido.
        cadena XmlMessage) // Aprobada por el usuario, como declaró en SPD.

Esto aprovecha el hecho de que podemos obtener información importante de flujo de trabajo, como el sitio, ID de la lista, etc.. Esto está bien documentado en varios lugares para los interesados en la creación de tus propias acciones personalizadas. La idea es extraer la cadena XML proporcionado por el usuario para enviar un procedimiento adecuado. Cosas divertidas!

Lamentablemente, Esto es obviamente un boleto de ida a "Antipatrón vacacional" anti-patrón tierra, pero es mejor que golpear una pared de ladrillo 🙂

Es un antipatrón si lo haces a pesar de que sabe que es un antipatrón?

Espero que esto Envuelva dentro de Codeplex en el futuro cercano. Si usted está interesado en mí hacerlo, Dame poke (Correo electrónico o deja un comentario) y voy a ser más entusiasta que en hacerlo 🙂

</final>

Suscribirse a mi blog.

Estoy trabajando en un proyecto que utiliza cinco diferentes flujos de trabajo de SharePoint Designer para manejar algunas aprobaciones de documentos. SPD proporciona los "recogemos datos de un usuario" acción por lo que nos podemos preguntar al usuario para diferentes bits de información, como si apruebe, algunos comentarios y quizá preguntar lo que tenían para cenar la otra noche.

Las formas son perfectamente funcionales. Ellos están vinculados a una lista de tareas como un tipo de contenido. Son 100% generados por el sistema. Esta es su fuerza y debilidad. Si podemos vivir con el formulario predeterminado, luego somos buenos ir. Sin embargo, no tenemos demasiado control sobre cómo SPD crea la forma. Si no nos gusta ese comportamiento predeterminado, necesitamos recurrir a varios trucos para obtener alrededor de ella (por ejemplo, configurar la prioridad de una tarea).

Necesitaba proporcionar un vínculo de estas formas de tarea que abren las propiedades de la vista (DispForm.asxp) el tema relacionado"" en una nueva ventana. Esto proporciona acceso con un clic a los metadatos del elemento relacionado. Esto es lo que quiero decir:

Afortunadamente, podemos hacer eso y no es muy difícil. En términos generales, fuego de SPD, Desplácese hasta el directorio que contiene los archivos de flujo de trabajo y abrir el archivo ASPX que desea modificar. Estos son sólo clásicas instrucciones de transformación XSL y si he mucked con itemstyle.xsl, búsqueda o otros escenarios XSL, Esto será fácil para usted. En realidad, Pareció ser generalmente más fácil ya que el formulario generado es algo más fácil seguir frente a un elemento de búsqueda principales resultados web (o la pesadilla CWQP).

Claro, hay un escollo importante. Editor de trabajo de SPD espera el control total sobre el archivo. Si lo modificas, SPD felizmente sobrescribirá su elasticidad cambios el derecho conjunto de circunstancias. Hice dos pruebas rápidas para ver lo mal que esta podría conseguir. Ambos presuponen que has elaborado un flujo de trabajo SPD válida que utiliza los "recogemos datos de un usuario" paso.

Prueba 1:

• Modificar manualmente el archivo ASPX.
• Prueba (Compruebe que los cambios se han guardado correctamente y no rompen nada).
• Abrir el flujo de trabajo y agregar una acción relacionada (como "registro de historia").
• Guardar el flujo de trabajo.

Resultado: En este caso, SPD no volver a crear el formulario.

Prueba 2:

• Lo mismo que #1 excepto directamente modificar el "recopilar datos de un usuario" acción.

Resultado: Esto vuelve a crear el formulario desde cero, sobrescribe los cambios.

Notas finales:

• Al menos dos acciones de SPD creación formas como este: "Recoger datos de un usuario" y "a punto". Ambas de estas acciones’ las formas pueden modificarse manualmente.
• Fui capaz de generar mi enlace a dispform.aspx porque, en este caso, relacionar siempre tiene su identificador incrustado en la URL del elemento relacionado. Era capaz de extraer y construir un <a href> basada en ofrecer la función de acceso de un solo clic meta datos. Es poco probable que su dirección URL sigue esta regla. Puede haber otras maneras de obtener el ID del elemento relacionado pero no he tenido que cruzar ese puente, así que no sé si obtiene al otro lado de la Sima.
• No encargado de investigar, pero yo no estaría sorprendido si hay algún tipo de archivo de plantilla en el 12 sección que podría modificar la afectan a cómo SPD genera los formularios predeterminados (al igual que podemos modificar plantillas de alertas).

</final>

Suscribirse a mi blog!

Tengo un escenario de negocio como este:

• Un usuario carga un documento en una biblioteca de documentos.
• Ella selecciona un tipo de contenido y entra metadatos según sea necesario. Uno de los campos de datos de metadatos es un indicador, "Urgente".
• Esto desencadena un flujo de trabajo de SharePoint Designer que, entre otras cosas, utiliza el "recoger datos de un usuario" acción.

"Recoger datos de un usuario" crea un elemento en una lista de tareas, solicitando autorización para que el documento.

Necesitaba crear una vista de la lista de tareas que mostró las solicitudes urgentes de aprobación.

Solución: Poner la palabra "urgente:" en el título de estas tareas.

Hubiera preferido especificar el campo de prioridad directamente. Sin embargo, No he podido hacerlo por varias razones:

1. La acción de recopilar datos no proporcionan un mecanismo para actualizar cualquier campo distinto título (y esos campos adicionales que desea recopilar datos).
2. El "asignar un punto" acción tiene el mismo problema.
3. Es posible insertar un elemento en una lista (i.e. Insertar un elemento en la lista de tareas directamente) pero esta no una acción de bloqueo. Eso significa que el flujo de trabajo no esperará por el usuario completar la tarea.

He considerado algunos enfoques antes (Afortunadamente) darse cuenta de que podríamos simplemente pone "urgente" en el título.

1. Iniciar un flujo de trabajo en la propia lista de tareas, de modo que cuando se crea una nueva tarea, de alguna manera cruzar referencias hacia el documento que se inició el primer flujo de trabajo, Saque el valor urgente y actualizar prioridad según sea necesario.
2. Hacer algo parecido con un receptor de eventos. Por crear de la tarea, Localice el documento asociado y la prioridad de actualización según sea necesario.
3. Utilice el "crear elemento de lista" acción en conjunción con la espera"para el cambio de campo" acción y un receptor de eventos. Si creamos un elemento de lista, podemos especificar todos los campos que queremos. Utilizar un receptor de evento para actualizar el elemento original cuando el usuario finaliza la tarea y la "espera para el cambio de campo" se cumpliría la condición de la acción y el flujo de trabajo procedería. (Por alguna razón, Más o menos había asentado sobre este enfoque antes de decidir sabiamente a pie por un tiempo).

Hay un inconveniente para mi solución (Aparte del hecho evidente de que sólo el texto del título indica la urgencia). Desde "recoger feedback" sólo acepta nombres de título duro codificada, Necesito utilizar dos acciones de retroalimentación recoge diferentes cuya única diferencia es duro Título codificado.

Pero, al menos hay una solución que no requiere de receptores de eventos o acciones personalizadas de SPD.

Si alguien ha solucionado esto de una manera más inteligente, por favor, hágamelo saber.

</final>

ACTUALIZACIÓN: Madjur Ahuja señala este enlace de un discusión de grupo de noticias: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. Es bastante definitivo.

===

Muchas veces queremos incrustar enlaces a formularios de InfoPath en los correos electrónicos enviados desde flujos de trabajo de SharePoint Designer. Cuando los usuarios reciben esos correos, pueden hacer clic en el vínculo del correo electrónico y vaya directamente al formulario de InfoPath.

Este monstruo URL obras para mí:

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&Fuente = http % 3A % 2F % 2Fserver % 2Ecorp % 2Edomain % 2Ecom % 2Fsites % 2Fdepartments % 2FTechnical % 2520Services % 2FInformationTechnology % 2FHelpDesk % 2FREC % 2520REM % 2520RED % 2520Forms % 2FForms % 2FAllItems % 2Easpx&DefaultItemOpen = 1

Reemplace el texto en negrita rojo con el nombre de la forma, como se muestra en la siguiente captura de pantalla:

Tenga en cuenta que hay un montón de camino codificadas en esa URL, así como un componente codificado en URL. Si esto es difícil de traducir a su situación específica, Pruebe encendiendo las alertas para la biblioteca de formularios. Publicar un formulario y al llegar el correo electrónico, ver el origen del correo electrónico y verás todo que lo necesario para incluir.

Los lectores astutos pueden notar que el cuerpo del correo electrónico arriba también muestra un enlace que accede directamente a la tarea mediante una vista filtrada. Voy a explicarlo más detalladamente en un post futuro.

</final>

Yo he implementado un flujo de trabajo usando SharePoint Designer en un sitio que es principalmente sólo lectura a "NT_AUTHORITYAuthenticated usuarios" (i.e. todo el mundo). Hay una biblioteca de formularios para un formulario de InfoPath. Hay una lista de tareas de flujo de trabajo asociado, así que cuando funciona el flujo de trabajo, pueden asignar tareas a las personas.

Rompo el permiso para la lista de la biblioteca y tarea de formas para que cualquier usuario autenticado puede crear formas y actualizar sus tareas asignadas.

Pruebo con mi cuenta de prueba de bajo-privilegios.

¿Puedo yo rellene y guarde un formulario en la biblioteca? –> SÍ

Puedo acceder a la tarea de un vínculo de correo electrónico? –> SÍ

¿Puedo ver un vínculo de tarea de flujo de trabajo de edición –> SÍ

¿Puedo hacer clic en ese enlace? –> No … Permiso denegado.

¿Por qué puedo ver un enlace de editar que me niega permiso cuando hago clic en él? Es no como se supone que trabajan…

Voy a volver a la configuración de seguridad, muy de cerca. Lo hago otra vez. Considero que borrar este post porque obviamente no sabemos nada acerca de la seguridad.

Finalmente, Buscar las Internets. Encuentro este hilo del Foro de MSDN altamente improbable: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Los carteles parecen estar sugiriendo que el simple acto de exportar el flujo de trabajo a un plato de transmisión solucionará un problema de seguridad MOSS? Apenas puedo creer que apenas ha escrito. Me recuerda el episodio de South Park sobre la 9/11 conspiración donde Stan está pidiendo nuestra Preznit, "Realmente?" una y otra vez.

Por lo tanto, nada que perder, Fuego SPD, Haga clic derecho sobre el flujo de trabajo y guardarlo en mi c:\ en coche. Sería la c:\ disco en mi laptop. Estoy mirando sobre mi hombro todo el tiempo para que nadie me pedirá, "¿por qué usted guardar ese flujo de trabajo en su ordenador portátil?"

Increíblemente, resuelve mi problema. Puedo editar la tarea.

Por la presente propongo que sea la más extraña de flujo de trabajo solución de 2007.

</final>

Muchas veces queremos enviar un correo electrónico que incluye un hipervínculo al artículo o documento que activa el flujo de trabajo. Podemos utilizar el "codificado dirección URL de elemento actual absoluta" para este propósito. Sin embargo, siempre parece utilizar http"" para el protocolo de dirección URL. Si tu sitio funciona con HTTPS y luego no va a funcionar para usted.

Lo que sé, no hay ninguna fuera de la solución a este problema. Si desea utilizar HTTPS, tienes que no fuera la opción de caja.

Para resolverlo, crear una acción personalizada que proporciona una función de reemplazar cadenas en su flujo de trabajo. Como alternativa, Use una herramienta de parte III como el excelente paquete aquí: http://www.codeplex.com/spdwfextensions 🙂

</final>

En ocasiones pedir a los usuarios del Foro: ¿Por qué pone SharePoint Designer ???? en mi correo electrónico en lugar de un valor de campo?

Una razón que esto ocurre es porque la variable que hace referencia es null.

Esto puede ocurrir porque intenta hacer referencia a un campo del elemento actual"" pero el usuario nunca entró un valor en ese campo de formulario.

<final />

Escenario: En un flujo de trabajo de SharePoint Designer, es necesario determinar si un campo de fecha está en blanco.

Problema: SPD no proporciona un método directo para comparar las fechas para que no sea una fecha. No se puede crear una condición como esta: "Si [DateField] es igual a en blanco".

Solución: Convertir la fecha a una cadena. Utilizar comparación de cadenas para determinar si la fecha está en blanco.

Capturas de pantalla:

Las capturas de pantalla siguientes muestran cómo hacerlo. En este escenario, un campo de un elemento, "Permisos ambientales:Primera fecha de recordatorio de permiso", se presenta y el flujo de trabajo se dispara en respuesta.

Notas:

Cuando traté de este, Me sorprendió gratamente saber que funciona. Yo estaba preocupado de que SharePoint Designer puede no permitir la asignación de cadena (Variable:StringReminderDateDate) pero le permitía.

Estaba también preocupado que permite, el valor puede ser nulo y cualquier golpe hasta el WF en tiempo de ejecución o tal vez aumente la temperatura global 1/2 un grado, pero esas preocupaciones eran infundadas.

</final>

Sólo una observación rápida que hay una diferencia muy importante entre estas dos definiciones:

<Campo FieldBind = "InParam1" DesignerType = "StringBuilder" ID = "2" Texto = "Parámetro de entrada # 1" />

frente:

<Campo FieldBind = "InParam1" ID = "2" Texto = "Parámetro de entrada # 1" />

El primero muestra como este en el SPD:

mientras que el último muestra como este:

No estoy seguro de lo útil que estas capturas de pantalla son más que pongo en el esfuerzo por hacer que lo que hay que verlas 🙂

La observación es esto: StringBuilder permite crear una cadena (Obviamente) mezclando los literales de cadena y datos de flujo de trabajo (a través de la "Añadir búsqueda" botón en la esquina inferior izquierda). Cuando se utiliza el botón de agregar consulta, inserta un token en forma"[%token %]". Cuando SharePoint invoca la acción personalizada, (Código de C# en mi caso), SharePoint pasa el testigo de sí mismo, no el valor de la ficha. Si utiliza el tipo de diseño por defecto (el segundo tipo), SharePoint amplía el token y pasa el valor real del token a su acción.

StringBuilder = mal, por defecto el tipo de diseñador = buena.

Claro, eso es no lo que quiero realmente decir. Simplemente no probar y pasar un parámetro a la acción personalizada cuando el diseñador = StringBuilder. Utilice el tipo diseñador predeterminado y la cadena StringBuilder que delante si necesita construir cadenas complejas en su flujo de trabajo (que por cierto es exactamente lo que uno hace para crear a un tema dinámico para la acción de correo electrónico, pero eso es un tema para otra entrada de blog, Har har).

<final />