Aquesta entrada del bloc és més d'un "en l'àmbit de les possibles" entrada vs. informació de formigó.

Tenim un disseny tècnic que requereix per a nosaltres per crear un lloc en una col·lecció de llocs mitjançant un procés de flux de treball manualment llançat. Bàsicament, els usuaris introdueixen dades en un nou "client" llista personalitzada i llavors quan han acabat i validat el procés d'entrada de dades, hem de crear un lloc per a que el client.

Sóc tant un gran fan de declarativa de flux de treball, així com un programador de flux de treball feble visual studio, així jo buscat complir el requisit mitjançant el SharePoint Designer.

M'he proposat escriure sobre això en major detall (i esperem que presenta a un grup d'usuaris o dos en el proper any), però aquí és la solució global:

• Crear una acció personalitzada que s'integra amb SPD.
• L'acció personalitzada permet SPD a invocar un servei web i donar-lo un reguitzell d'XML.
• Servei web localitza la fila a la llista de costum i crea un lloc nou, segons les dades per a aquest nou client utilitzant una definició del lloc de costum.
• Servei web llavors actualitza la llista personalitzada amb alguna informació com un enllaç a la nova pàgina.

Hem considerat altres enfocaments, com controladors d'incidències i flux de treball d'estudi visual. L'enfocament SPD dóna nostres usuaris finals una mica més control sobre el procés. Concedit, hi ha un munt de codi de c# en aquesta solució, però això és embolicat en un flux de treball declarativa, Així aconseguim alguns dels beneficis del flux de treball declarativa mentre connectant al servei de la creació de llocs.

Tot el que necessitem ara és una eina fàcil de migrar de forma automàtica SPD fluxos de treball al voltant de la mateixa facilitat que el que puguem per a fluxos de treball de Visual Studio i que realment serà cuinar amb gas 🙂 entenc que alguna gent hi són fora treballant en aquest problema i espero que tinguin cert èxit bé amb ell aviat.

</final>

Subscriure's al meu blog.

He estat jugant al voltant amb accions de costum per al dissenyador de SharePoint per a una mica de temps (veure aquí per a algunes coses detallada, Si que t'interessi).

En el meu projecte actual, hem de fer alguns bastant pesat alçar i volem utilitzar de flux de treball SPD declarativa per gestionar el procés de direcció associades.

Llarga història curta, Això és totalment possible. Que va estendre el meu projecte de Codeplex per invocar un "servei d'ajudant" i ara podem invocar un servei web directament des d'un flux de treball SPD.

Aquí és la signatura:

 públic corda Despatx(
        GUID WebID, // Aprovat per l'ambient de temps d'execució
        GUID SiteID, // Aprovat per l'ambient de temps d'execució
        corda ListID, // Aprovada per les RTE (no sé per què això és una cadena, no un GUID)
        Int ListItemID, // Aprovada per les RTE.
        corda XmlMessage) // Aprovada per l'usuari com declarat el SPD.

Això aprofita el fet que puguem aconseguir informació importants de flux de treball, com el lloc, Llista d'ID, etc. Això està ben documentada en diversos llocs per a aquells de vostès interessaven a crear accions personalitzades pròpies. La idea és extreure la corda XML proporcionat per l'usuari per enviar un procediment adequat. Coses divertides!

Tristament, Això és òbviament un bitllet senzill a "Loosey Goosey" anti-patró terra, però és millor que colpejar una paret de maó 🙂

És un anti-patró si ho fa tot i que vostè sap que és un anti-patró?

Espero acabar amb això dins Codeplex en el futur pròxim. Si estàs interessat en mi fer-ho, donar-me ficar (correu electrònic o deixa un comentari) i seré més entusiasta que en fer-ho 🙂

</final>

Subscriure's al meu blog.

Estic treballant en un projecte que utilitza cinc diferents fluxos de treball de SharePoint Designer per manejar alguns aprovacions de document. SPD proporciona la "recollir dades d'un usuari" acció per tal que ens pot impulsar l'usuari per a diferents bits d'informació, com si l'aproven, alguns comentaris i potser demanar el que havia per al sopar de l'altra nit.

Les formes són perfectament funcionals. Estan lligats a una llista de tasques com un tipus de contingut. Són 100% generat pel sistema. Aquesta és la seva força i la debilitat. Si podem viure amb el formulari per defecte, llavors ens és bons anar. No obstant això, no tenim massa control sobre com SPD crea l'òrgan. Si no ens agrada aquest comportament per defecte, hem de recórrer a diversos trucs per esquivar-lo (per exemple, posant prioritat en una tasca).

Que necessitava proporcionar un enllaç a aquestes formes de tasca que va obrir les propietats de la visualització (dispform.asxp) de la "element de relacionat" en una finestra nova. Això proporciona accés d'un clic a les metadades de l'element relacionat. Això és el que vull dir:

Afortunadament, podem fer això i no és molt difícil. En termes generals, disparar cap amunt del SPD, Aneu al directori que alberga els arxius de flux de treball i obriu el fitxer ASPX que voleu modificar. Aquestes són només clàssic XSL transforma instruccions i si t'he Flipping amb itemstyle.xsl, Cerca o altres escenaris XSL, això serà fàcil per a vostè. De fet, Em va semblar ser en general més fàcil ja que la forma generat és una mica més fàcil de seguir en comparació amb una part de recerca fonamental resultats web (o la malson CWQP).

Clar, hi ha un gran escull. Editor de flux de treball de l'SPD espera un control total sobre aquell arxiu. Si modifiqueu-lo, SPD feliçment sobreescriurà ur give canvis dret conjunt de circumstàncies. Vaig fer dues proves ràpides per veure el mal això podria anar. Tots dos presuposa que he creat un vàlid SPD flux de treball que utilitza els "recollir dades d'un usuari" pas.

Prova 1:

• Modificar l'arxiu d'ASPX de forma manual.
• Analitzar-lo (Comproveu que els canvis s'han desat correctament i no trencarà res).
• Obrir el flux de treball i afegir una acció no relacionat (com "diari a la història").
• Salvar el flux de treball.

Resultat: En aquest cas, SPD va fer no recrear la forma.

Prova 2:

• Fer el mateix que #1 excepte directament modificar els "recollir dades d'un usuari" l'acció.

Resultat: Això re-crea la forma de zero, sobre-escriure els canvis.

Notes finals:

• Com a mínim dues accions de SPD crear formes com aquest: "Recollir dades D'un usuari" i "Assignar a l'element". Tant d'aquestes accions’ formes es poden modificar manualment.
• Vaig ser capaç de generar el meu enllaç a dispform.aspx perquè, en aquest cas, l'element relat sempre té el seu identificador incrustat en l'URL de l'element relacionat. Vaig ser capaç d'extreure'l i llavors construir un <un href> en base a proporcionar la un clic tret meta dades d'accés. És poc probable que el seu URL segueix aquesta regla. Hi pot haver altres maneres d'aconseguir l'ID de l'element relacionat però no he hagut de creuar aquell pont, Així que no sé si arriba a l'altre costat de l'abisme.
• Jo no investigar, però jo no em sorprendria si hi ha algun tipus d'arxiu de plantilla en la 12 rusc que jo podria modificar per afectar com la SPD genera les formes d'omissió (molt com podem modificar plantilles d'alertes).

</final>

Subscriure's al meu blog!

Tinc un escenari de negoci com aquest:

• Un usuari carrega un document a una biblioteca de documents.
• Ella selecciona un tipus de contingut i entra en metadades segons sigui necessari. Un dels camps de dades meta és una bandera, "Urgent".
• Això provoca un flux de treball de dissenyador de SharePoint que, entre altres coses, utilitza el "recollir dades des d'un usuari" l'acció.

"Recollir dades d'un usuari" crea un element en una llista de tasca sol·licitar l'aprovació d'aquell document.

Necessitava crear una visualització de la llista de tasques que es van presentar sol·licituds urgents per a l'aprovació.

Solució: Posar la paraula "URGENT:" en el títol d'aquestes tasques.

Hauria preferit especificar el camp prioritat directament. No obstant això, Jo era incapaç de fer això per diverses raons:

1. L'acció de recollir dades no proporciona un mecanisme per actualitzar qualsevol camp que no sigui a títol (i aquells camps addicionals per a la qual voleu recollir dades).
2. El "assignar una per tema" acció té el mateix problema.
3. És possible inserir un element en una llista (i. e. inserir un element en la llista de tasques directament) però això no una acció de bloqueig. Això significa que el flux de treball no s'esperarà a l'usuari per a completar aquesta tasca.

Vaig considerar uns plantejaments abans (Afortunadament) adonar-se que podria només posar "urgent" en el títol.

1. Iniciar un flux de treball en la mateixa llista de tasca per tal que quan es crea una tasca nova, d'alguna manera es creu referències torna al document que es va iniciar el primer flux de treball, treure el valor de bandera urgents i actualització n'esdevinguin.
2. Fer una cosa semblant amb un auricular d'esdeveniment. En crear la tasca, Localitzeu el document associat i n'actualització esdevinguin.
3. Utilitzar el "crear l'element de llista" acció en conjunció amb l'espera"per al canvi de camp" acció i un auricular d'esdeveniment. Si podem crear un element de llista, es pot especificar tots els camps que volem. Utilitzar un auricular d'esdeveniment per actualitzar l'element original quan l'usuari es completi la tasca i l'espera"per al canvi de camp" vols complir condicions de l'acció i vols continuar el flux de treball. (Per alguna raó, Més o menys havia establert en aquest enfocament abans de decidir assenyadament allunyar per un temps).

Hi ha un inconvenient a la meva solució (a banda del fet evident que només el text del títol indica urgència). Des de "recollir vots" només accepta noms títol durament codificat, Necessito utilitzar dues accions diferents retroalimentació recollir l'única diferència és que el títol dur codificat.

Però, almenys hi ha una solució que requereix auriculars d'esdeveniment o accions personalitzades de SPD.

Si algú ha resolt aquest d'una manera més intel ligent, Si us plau deixi'm saber.

</final>

ACTUALITZACIÓ: Madjur Ahuja assenyala aquest enllaç des d'un discussió del grup de discussió: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. És força definitiva.

===

Sovint volem inserir hiperenllaços a formes d'InfoPath en els correus electrònics enviats des de fluxos de treball de SharePoint Designer. Quan els usuaris reben aquest tipus de correus, poden fer clic a l'enllaç de l'e-mail i anar directament a la forma d'InfoPath.

Aquesta construcció URL monstre funciona per a mi:

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

Substituïu el text en negreta vermella amb el nom de la forma, com mostrat en el screenshot següent:

Tingueu en compte que hi ha un munt de camí codificats en aquell URL, així com un component d'URL codificat. Si això és massa difícil de traduir a la seva situació específica, Habiliteu-avisos de la biblioteca forma. Enviar un formulari i quan arribi l'e-mail, Visualitza l'origen de l'e-mail i veuràs tot el que necessites per incloure.

Lectors astuts poden notar que el cos d'e-mail anterior també mostra un enllaç que accedeix directament la tasca mitjançant un visualització filtrada. Planejo que expliquen amb més detall en un futur post.

</final>

I've implemented un flux de treball utilitzant el dissenyador de SharePoint en un lloc que és principalment read-only als "usuaris de NT_AUTHORITYAuthenticated" (i. e. tot el món). Hi ha una biblioteca de formularis per a un formulari InfoPath. Hi ha una llista de tasques de flux de treball associat, així que quan el flux de treball funciona, pot assignar tasques a les persones.

Trenco permís per a la llista de Biblioteca i tasca de formes per a que qualsevol usuari autenticat pot crear formularis i actualitzar la seva comesa.

Vaig provar amb el meu compte de prova de baix-privilegis.

Pot omplir out i desar un formulari a la biblioteca? –> SÍ

Puc accedir a la tasca d'un enllaç de correu electrònic? –> SÍ

Puc veure un enllaç de tasca de flux de treball Edita –> SÍ

Pot faig clic a aquell enllaç? –> NO … Permís negat.

Per què es pot veure un editar enllaç que em nega permís quan faig clic en això? Thats no com ha suposat treballar…

Vaig anar a través de la configuració de seguretat una altra vegada, molt estretament. Fer-ho una altra vegada. Considero que la supressió d'aquest post perquè, òbviament, no sé res sobre seguretat.

Finalment, Cerca l'Internets. Vaig trobar aquest fil de fòrum MSDN altament improbable: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Els cartells semblen estar suggerint que el simple acte d'exportar el flux de treball a una safata d'empenta es fixarà un assumpte de seguretat de molsa? No puc creure que acaba d'escriure que. Em recorda de l'episodi de South Park sobre la 9/11 conspiració on Stan està demanant el nostre Preznit, "Realment?" una i altra vegada.

Així, res a perdre, Vaig disparar cap amunt del SPD, clic correcte en el flux de treball i desar-lo al meu c:\ unitat. Això seria el c:\ empenta al meu portàtil. Estic buscant sobre l'espatlla tot el temps per tal que ningú em demanarà, "per què està salvant aquest flux de treball al seu portàtil?"

Increïblement, que resol el meu problema. Podeu editar la tasca.

Per la present nominar això sigui el més estrany de flux de treball Workaround de 2007.

</final>

Sovint volem enviar un correu electrònic que inclou un enllaç a l'element o document que va provocar el flux de treball. Podem utilitzar "codificat adreça URL l'element actual absoluta" amb aquesta finalitat. No obstant això, sempre sembla que utilitza "http" per al protocol d'URL. Si el seu lloc s'executa en HTTPS llavors no funcionarà per a vostè.

Pel que jo sé, no hi ha cap fora de la solució a aquest problema de caixa. Si vostè necessita utilitzar HTTPS, no es té cap fora de l'opció de caixa.

Per solucionar-lo, crear una acció personalitzada que proporciona una funció substitueix de corda d'utilitzar en el seu flux de treball. Alternativament, utilitzar una eina de 3r com el paquet excel·lent aquí: http://www.codeplex.com/spdwfextensions 🙂

</final>

Usuaris del Fòrum de tant en tant pregunten: Per què posar dissenyador de SharePoint ???? en el meu e-mail en comptes d'un valor de camp?

Això passa una de les raons és perquè la variable al que fas referència és nul.

Això pot passar perquè intenteu fer referència a un camp de el "element actual" però l'usuari mai no va entrar un valor en aquell camp de formulari.

<final />

Escenari: En un flux de treball de dissenyador de SharePoint, cal determinar si un camp data està en blanc.

Problema: SPD no proporciona un mètode directe per comparar les dates a res que no sigui una data. No podeu crear una condició com aquesta: "Si [DateField] és igual a en blanc".

Solució: Convertir la cita en una cadena. Ús de comparació de cadenes per determinar si la data és en blanc.

Captures de pantalla:

Els pesos de pantalla següent mostra com fer-ho. En aquest escenari, un camp en un element, "Permisos mediambientals:Primer permís recordatori data", es presenti i el flux de treball dels incendis en resposta.

Notes:

Quan tastava això, Em sorprenia agradablement aprendre que funciona. Em preocupava que el SharePoint Designer podria rebutjar l'assignació de corda (Variable:StringReminderDateDate) però això va permetre.

També estava preocupat que permetent-lo, el valor pot ser nul·la i tampoc volar la WF al temps d'execució o potser fer pujar la temperatura global 1/2 un grau, però aquestes preocupacions eren infundades.

</final>

Només una observació ràpida que hi ha una diferència molt important entre aquestes dues definicions:

<Camp de FieldBind = "InParam1" DesignerType = "StringBuilder" ID = "2" Text "Paràmetre d'aportació # 1" = />

versus:

<Camp de FieldBind = "InParam1" ID = "2" Text "Paràmetre d'aportació # 1" = />

El primer Mostra com aquest en l'SPD:

mentre les últim espectacles com aquest:

No estic segur de quina utilitat són aquestes captures de pantalla, però m'esforço per fer-les perquè les hagis de veure 🙂

L'observació és això: StringBuilder li permet acumular una cadena (Òbviament) barrejant juntes literals corda i dades de flux de treball (Via la "afegir Lookup" botó a la cantonada esquerra inferior). Quan utilitzeu el botó afegir Cerca, Insereix un testimoni de la forma"[%Token %]". Quan el SharePoint invoca el seu acció personalitzada, (Codi de c# en el meu cas), SharePoint passa la fitxa en si, no el valor de la fitxa. Si utilitzeu el tipus de disseny per defecte (el segon tipus), SharePoint s'expandeix la fitxa i passa el valor real de la testimoni a l'acció.

StringBuilder = dolent, tipus de dissenyador d'omissió = bo.

Clar, que és el realment vol dir. No només provaré i passar un paràmetre a l'acció personalitzada quan el dissenyador tipus = StringBuilder. Utilitzar el tipus de disseny per defecte i un StringBuilder a la mateixa cadena al davant si cal construir complexes cordes en el seu flux de treball (que per cert és exactament el que un fa per crear un tema dinàmic per a l'acció de correu electrònic, però aquest és un tema per a una altra entrada de bloc, har har).

<final />