Šī bloga ieraksts ir vairāk "šajā valstība no iespējamā" ierakstu vs. betona info.

Mums ir tehniskā projekta, kas aicina mūs, lai izveidotu vietni vietņu kolekcijas, izmantojot manuāli uzsākusi darbplūsmas procesu. Būtībā, lietotāji ievada datus "jauns debitors" pielāgotu sarakstu un pēc tam, kad tie ir pabeigta un validēt datu ievades procesu, mums ir nepieciešams, lai izveidotu vietni šim debitoram.

Es esmu gan liels ventilators deklaratīva darbplūsmas, kā arī vāju visual studio darbplūsmas programmētājs, tāpēc es gribēju, lai atbilstu prasībai izmantot programmu SharePoint Designer.

Es plānoju uzrakstīt par šo sīkāk (un cerams, ka patlaban ir lietotāju grupai vai divas nākamajā gadā), bet šeit ir kopējā risinājuma:

• Izveidot pielāgotas darbības, kas integrējas ar VPD.
• Pielāgota darbība ļauj VPD izsaukt tīmekļa pakalpojumu un nodot to virkni XML.
• Web pakalpojums atrod rindas pielāgotais saraksts un tiek izveidota jauna vietne saskaņā ar datiem par to jaunu klientu, izmantojot pielāgotas vietņu definīcijas.
• Web pakalpojums pēc tam atjaunina pielāgoto sarakstu ar kādu informāciju, piemēram saite uz jauno vietni.

Mēs uzskatīja, ka citas pieejas, piemēram, notikumu apdarinātāji un vizuālā studija, pamatojoties darbplūsmas. VPD pieeja dod mūsu tiešajiem lietotājiem nedaudz lielāku kontroli pār šo procesu. Piešķirtā, C# kodu šajā risinājumā ir daudz, bet tas ir iesaiņoti iekšpusē deklaratīva darbplūsmu, Tātad mēs daži no ieguvumiem no deklaratīvā darbplūsmas vienlaikus hooking ekspluatācijā vietnes izveidi.

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.

</beigās>

Abonēt manu blogu.

Es esmu spēlē ar pielāgoto darbību SharePoint Designer kādu laiku (skatīt šeit daži sīki stuff, Ja tas jūs interesē).

Ar manu pašreizējo projektu, mums ir jādara dažas diezgan smagumu celšana un vēlamies izmantot deklaratīvo VPD darbplūsmu, lai pārvaldītu saistīto biznesa procesu.

Garš stāsts īss, tas ir pilnīgi iespējams. Es paplašināt manu Codeplex projektu izsaukt "palīgs pakalpojums" un tagad mēs var izsaukt tieši no VPD darbplūsmas web pakalpojumu.

Lūk, paraksts:

 valsts virkne Dispečers(
        GUID ID, // Garām izpildlaika vidi
        GUID SiteID, // Garām izpildlaika vidi
        virkne ListID, // Garām RTE (nezinu, kāpēc tas ir virkne, nevis GUID)
        Int ListItemID, // Garām RTE.
        virkne XmlMessage) // Pagājis lietotājs, kā paziņoja VPD.

Tas piesaista fakts, ka mēs varam iegūt informāciju svarīgos darbplūsmu, piemēram, vietnes, saraksta ID, uc. Tas ir labi dokumentēta vairākās vietās attiecībā uz tiem no jums interesē izveidot savas pielāgotās darbības. Ideja ir iegūt XML string, ko norādījis lietotājs nosūtīt atbilstošu procedūru. Fun stuff!

Diemžēl, tas ir acīmredzami vienvirziena biļeti uz leju, lai "Loosey Goosey" Anti-modelis zemes, bet tas ir labāk nekā atsitoties pret ķieģeļu sienu 🙂

Tas anti-modelis, ja jūs to darīt, pat ja jūs zināt, tas ir anti-modelis?

Es ceru, ka tas jāaplauž Codeplex tuvākajā nākotnē. Ja jūs vēlaties man darīt, Dodiet man kule (e-pasts vai atstāt komentāru) un es vēlēšos to darīt 🙂

</beigās>

Abonēt manu blogu.

Es esmu strādā pie projekta, kas izmanto piecas dažādas SharePoint Designer darba plūsmas rīkoties daži dokumenta apstiprinājumu. SPD sniedz "savākt datus no lietotāja" darbību, lai mēs varētu aicināt dažādas informācijas apjomiem, ar, piemēram, vai viņi to apstiprināt, dažas piezīmes un varbūt lūgt to, ko viņi bija vakariņas tovakar.

Veidlapas ir pilnīgi funkcionālu. Tie ir saistīti ar uzdevumu saraksta satura tipu. Tie ir 100% sistēmas ģenerēti. Tas ir viņu spēks un vājums. Ja mēs varam dzīvot ar noklusējuma veidlapu, tad mēs esam labi iet. Tomēr, mums nav pārāk daudz kontrolēt kā VPD izveido veidlapu. Ja mums nepatīk, ka pēc noklusējuma, mums ir nepieciešams izmantot dažādus trikus, lai ap to (piemēram, nosakot prioritāro uzdevumu).

Man vajadzēja sniegt saiti uz šo uzdevumu veidlapām, kas atvērušas skata rekvizīti (dispform.asxp) "saistītā vienuma" jaunā logā. Tā nodrošina viena klikšķa piekļuvi meta datu saistītā vienuma. Tas ir tas, ko es domāju:

Laimi, mēs varam darīt, un tas nav ļoti grūti. Visumā, uguns līdz SPD, Naviģējiet uz direktoriju, kas mājas darbplūsmas failus un atveriet ASPX failu, kuru vēlaties modificēt. Šie ir tikai klasisko XSL transformāciju instrukcijas un ja jūs esat atmestās ar itemstyle.xsl, meklēšanu vai citas XSL scenārijus, tas būs viegli. patiesībā, Es atklāju, ka ir pārsvarā vienkāršāk, jo ģenerēts formā ir nedaudz vieglāk sekot salīdzinājumā ar galveno rezultātu web daļu (vai_ar ī murgainu CWQP).

protams, tur ir viens no galvenajiem lamatām. SPD darbplūsmas redaktors paredz pilnīgu kontroli pār šo failu. Ja to modificēt, VPD laimīgi pārrakstīs jūsu izmaiņas dot tiesības noteikt apstākļus. Es tā divas ātrās pārbaudes, lai redzētu, cik slikti tas varētu iegūt. Viņi abi priekšnoteikumu, ka esat izstrādāts spēkā VPD darbplūsmu, kas izmanto "savākt datus no lietotāja" solis.

Tests 1:

• Modificēt ASPX failā ar roku.
• Izmēģiniet to (Pārbaudiet, vai jūsu izmaiņas netika pareizi saglabāts un neko neizjauc).
• Uzsākt darbplūsmu un pievienot nesaistītu darbību (piemēram, "žurnāla vēsture").
• Saglabāt darbplūsmas.

Rezultāts: Šajā gadījumā, VPD nevar atkārtoti izveidot veidlapas.

Tests 2:

• Tāpat kā #1 izņemot tieši pārveidot "savākt datus no lietotāja" darbības.

Rezultāts: Atkārtoti tiek izveidots no jauna forma, pār-rakstīt jūsu veiktās izmaiņas.

Nobeiguma piezīmes:

• Vismaz divas VPD darbības izveidot formas līdzīgs šim: "Datu savākšanai no lietotāja" un "Piešķirt vienuma". Abas šīs darbības’ formas var manuāli mainīt.
• Man bija iespēja, lai radītu manu saiti uz dispform.aspx, jo, Šajā gadījumā, relate krājumam vienmēr ir tās ID, kas iegulti saistītā elementa URL. Man bija iespēja iegūt to un pēc tam veidot <href => pamatojoties uz to, lai nodrošinātu vienu klikšķi meta datu piekļuves līdzekli. Maz ticams, ka jūsu URL seko šai kārtulai. Var būt citi veidi, kā iegūt saistītā elementa ID, bet nav bijusi šo tiltu šķērsot, tāpēc es nezinu, ja saņem otras malas bezdibenis.
• Nebija izmeklēt, bet es nebūtu pārsteigts, ja pastāv zināma veida veidnes failu 12 stropu, kas varētu modificēt ietekmē kā VPD izveido noklusējuma veidlapas (līdzīgi mēs varētu modificēt brīdinājumu veidnes).

</beigās>

Abonēt manu blogu!

Man ir biznesa scenāriju, kā šis:

• Lietotājs augšupielādes dokumentu dokumentu bibliotēkā.
• Viņa izvēlas satura tipu un meta datus ievada pēc nepieciešamības. Viens meta datu laukiem ir karogs, "Steidzams".
• Tas izraisa SharePoint Designer darbplūsmas, kas, cita starpā, izmanto "savākt datus no lietotāja" darbības.

"Datu savākšanai no lietotāja" izveido vienumu uzdevumu sarakstā, kas pieprasa apstiprinājumu šim dokumentam.

Nepieciešams, lai izveidotu uzdevumu saraksts, kurā atklājās steidzamu pieprasījumu apstiprināšanai skatu.

Šķīdums: Likt vārdu "steidzami:" par šiem uzdevumiem nosaukumu.

Es vēlētos, lai tieši norādītu lauku prioritāte. Tomēr, Es nevarēju to darīt vairāku iemeslu dēļ:

1. Datu apkopošana rīcības neparedz mehānismu, lai atjauninātu jebkurā jomā, izņemot virsraksta (un šie papildu laukus, kurai vēlaties apkopot datus).
2. "Piešķirt ar krājumu" darbība ir tāda pati problēma.
3. Ir iespējams ievietot vienumu sarakstu (ti. Ievietot vienumu uzdevumu sarakstu tieši) bet tas nav bloķējošā darbība. Tas nozīmē, ka darbplūsmas negaidīs lietotājs var pabeigt darbplūsmas uzdevumu.

Es uzskatīju, ka dažas pieejas pirms (laimi) realizējot, mēs varētu vienkārši ielieciet "steidzams" nosaukums.

1. Sākt darbplūsmu uzdevumu sarakstā, pati par sevi tā, ka, veidojot jaunu uzdevumu, tas kaut kā pāri norādes atpakaļ uz dokumentu, kas pirmās darbplūsmu ir sākusi, izraut steidzami karoga vērtību un atjaunināt prioritātes, nepieciešamības.
2. Darīt kaut ko līdzīgu notikumu uztvērēju ar. Uz izveidot uzdevumu, Atrodiet saistīto dokumentu un atjaunināšanas prioritāti pēc nepieciešamības.
3. Izmantot "izveidot saraksta vienums" rīcība saistībā ar "Pagaidiet lauka maiņa" darbību un notikumu uztvērēju. Ja mēs radām saraksta vienums, mēs var norādīt visus laukus, ko mēs vēlamies. Izmantot notikumu uztvērēju, lai atjauninātu sākotnējā vienuma, kad lietotājs pabeidz uzdevumu un "gaidīt no lauka maiņa" darbības nosacījums būtu izpildīts un varētu turpināt darbplūsmu. (Kāda iemesla dēļ, Es vairāk vai mazāk norēķinās par šo pieeju pirms lēmuma pieņemšanas par gudri iet prom, bet).

Tur ir mans risinājums atmaksas (Papildus acīmredzams fakts, ka tikai virsraksta teksts norāda steidzamības). Kopš "atsauksmju" akceptē tikai grūti kodētu nosaukumu vārdi, Nepieciešams, lai izmantotu divas dažādas atsauksmju darbības, kuru vienīgā atšķirība ir tā, ka grūti kodētu nosaukumu.

bet, vismaz tur ir risinājums, kas neprasa notikumu uztvērēju vai pielāgotas VPD darbības.

Ja kāds ir atrisinājis tas vairāk gudrs veids, kā, Lūdzu, let me know.

</beigās>

ATJAUNINĀJUMS: Madjur sarkans norāda šo saiti no intereškopu diskusijas: http://msdn2.microsoft.com/en-us/library/ms772417.aspx. Tas ir diezgan galīgo.

===

Bieži vien mēs gribam iestrādāt hipersaites uz InfoPath veidlapas e-pastus sūta no SharePoint Designer darbplūsmas. Kad lietotāji saņem šos e-pastus, viņi var noklikšķināt uz saites no e-pasta un doties tieši uz InfoPath veidlapas.

Šis briesmonis URL būvniecības darbi mani:

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

Sarkanā treknrakstā tekstu aizstāt ar veidlapas nosaukums, kā redzams pēc screenshot:

Ņemiet vērā, ka pastāv daudz iekodētu ceļu šo URL, kā arī URL kodēta komponents. Ja tas ir pārāk grūti tulkot jūsu konkrētajai situācijai, mēģiniet ieslēgt brīdinājumu veidlapu bibliotēkai. Publicēt veidlapu un saņemot e-pastu, skatiet e-pasta avotu un jūs redzēsiet, ka viss, kas jums nepieciešams iekļaut.

Vērīgs lasītāji var pamanīt, ka iepriekš minēto e-pasta iestāde rāda arī saites, kas tieši piekļūst caur filtrētais skats uzdevuma. Plānu, lai izskaidrotu, ka sīkāk nākotnē post.

</beigās>

Esam ieviesuši darbplūsmu, izmantojot SharePoint Designer vietnes, kas ir galvenokārt tikai lasāms "NT_AUTHORITYAuthenticated lietotājiem" (ti. visi). Tur ir par InfoPath veidlapu veidlapu bibliotēkā. Tur ir saistīto darbplūsmas uzdevumu sarakstu, lai, kad darbplūsma darbojas, cilvēkiem tā var piešķirt uzdevumus.

Es pārtraukums atļauju veidlapu bibliotēkā un uzdevumu sarakstu, lai visiem autentificētiem lietotājiem var izveidot veidlapas un atjaunināt to piešķirtos uzdevumus.

Es testa ar manu zema privilēģijas pārbaudes kontu.

Vai varat aizpildīt un saglabāt veidlapas bibliotēka? –> jā

Var piekļūt uzdevumu, izmantojot e-pastu saiti? –> jā

Redzu, saites Rediģēt darbplūsmas uzdevumu –> jā

Varat noklikšķināt uz šīs saites? –> nē … Permission Denied.

Kāpēc redzams saites Rediģēt, kas noliedz mani atļaujas, noklikšķinot uz tā? Tas ir, nevis kā tas ir paredzēts darbam…

Man iet caur drošības konfigurāciju vēlreiz, ļoti cieši. Man to izdarīt vēlreiz. Es uzskatu, ka šo ziņu dzēšana jo es, protams, nezinu neko par drošības.

Beidzot, Es varu meklēt Internets. Es uzskatu, ka maz ticams MSDN forumā diegu: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1838253&SiteID=17

Plakāti, šķiet, liecina, ka vienkārša likuma izvešanai darbplūsmas disku plate noteiks MOSS drošības jautājums? Man grūti noticēt, ka es tikko ierakstījāt. Es esmu atgādināja par South Park epizodi par 9/11 sazvērestība, kur Stan jautā mūsu Preznit, "Patiešām?" atkal un atkal.

Tik, nekas nav ko zaudēt, Es uguns līdz SPD, ar peles labo pogu noklikšķiniet uz darbplūsmas un saglabājiet to uz manu c:\ diskdzinis. Tas būtu c:\ vadīt savu klēpjdatoru. Es meklēju pār manu plecu visu laiku tā, lai neviens man jautā, "kāpēc jūs saglabājat šo darbplūsmu klēpjdatorā?"

Neticami, tas atrisina mana problēma. Var rediģēt šo uzdevumu.

Ar šo es izvirzīt, tas ir visvairāk savāda darbplūsmas risinājums 2007.

</beigās>

Mēs bieži vēlaties sūtīt e-pastu, kas ietver hipersaiti uz vienuma vai dokumenta, kas izraisa darbplūsmas. Mēs varam izmantot pašreizējam krājumam "kodēts absolūtam vietrādim URL" šim nolūkam. Tomēr, tas vienmēr šķiet izmantot "http" URL protokols. Ja jūsu vietā darbojas uz HTTPS, tad tas nestrādās jums.

Cik man zināms, nav neviena ārpus box risinājums šai problēmai. Ja jums nepieciešams izmantot HTTPS, jums nav no lodziņa opciju.

Lai to atrisinātu, izveidot pielāgotas darbības, kas nodrošina virkne aizstāt funkciju izmantot darbplūsmas. Vai arī, izmantot 3rd puses rīks, piemēram lielisks pakete šeit: http://www.codeplex.com/spdwfextensions 🙂

</beigās>

Foruma lietotāji laiku pa laikam pieprasīt: Kāpēc likts SharePoint Designer ???? uz manu e-pastu, nevis lauka vērtību?

Viens no iemesliem, kāpēc tas notiek, ir tāpēc, ka mainīgais, uz kuru atsaucaties, ir null.

Tas var notikt tāpēc, ka mēģināt atsauces lauku no "pašreizējam krājumam" bet lietotājs nekad nav stājies vērtību formas laukā.

<beigām />

Scenārijs: SharePoint Designer darbplūsmā, nepieciešams noteikt, ja datuma lauks ir tukšs.

Problēma: VPD nesniedz tiešā metode salīdzināšanai datumus, lai kaut ko, kas nav datuma. Kā šis nosacījums nevar izveidot: "Ja [DateField] ir vienāds ar tukšu".

Šķīdums: Datumu konvertētu uz virkni. Izmantot virkņu salīdzināšana, lai noteiktu, ja datums ir tukšs.

Ekrānuzņēmumus:

Šādu ekrāns šāvienu parādīt, kā to izdarīt. Šajā scenārijā, lauka ar vienumu, "Vides atļaujām:Pirmo reizi atļauja atgādinājuma datumu", ir iesniegts un darbplūsmas ugunsgrēki, atbildot.

Piezīmes:

Kad es mēģināju šo, Es biju patīkami pārsteigts, lai uzzinātu, vai tā strādā. Es biju noraizējies, ka SharePoint Designer var neatļaut virkne uzdevumu (Mainīgais:StringReminderDateDate) bet tas tomēr ļauj.

Es biju arī bažas, ka ļaujot, vērtība varētu būt tukšums un vai nu WF Runtime uzspridzināt vai varbūt paaugstināt globālā temperatūra 1/2 pakāpe, bet šīs bažas nav pamatotas.

</beigās>

Vienkārši ātri novērošana ir ļoti būtiska atšķirība starp šīm divām definīcijām:

<FieldBind lauka "InParam1 =" DesignerType = "StringBuilder" ID = "2" Text = "Ievades parametrs # 1" />

salīdzinot ar:

<FieldBind lauka "InParam1 =" ID = "2" Text = "Ievades parametrs # 1" />

Pirmais parāda kā šis VPD:

savukārt pēdējā izstādes līdzīgs šim:

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 🙂

Novērojums ir tas: StringBuilder ļauj veidot virkni (acīmredzot) sajaucot kopā virknes literāļus un darbplūsmu datus (izmantojot "pievienot uzmeklēšanas" pogu apakšējā kreisajā stūrī). Ja izmantojat pogu pievienot uzmeklēšanas, Iesprauž simbolisku formā"[%marķiera %]". Kad SharePoint atsaucas uz jūsu pielāgoto darbību, (C# kodu, manā gadījumā), SharePoint nodod marķieri, pats par sevi, nav marķiera vērtību, kā. Ja izmantojat noklusējuma veidotāja tips (otrais tips), SharePoint paplašinās pilnvaru un faktiskā vērtība pilnvaru nodod savu darbību.

StringBuilder = slikti, noklusējuma veidotāja tips = labs.

protams, tas ir, nav tas, ko es tiešām domāju. Tikai nav mēģināt un nodot parametrs pielāgotajai darbībai, ja dizainers tips = StringBuilder. Izmantot noklusējuma veidotāja tips un ķēdes StringBuilder to uzreiz, ja jums ir nepieciešams veidot sarežģītas virknes jūsu darbplūsmā (kas starp citu ir tieši tas, ko cilvēks dara, lai veidotu dinamisku tēmu e-pasta darbības, bet tas ir pakļauts citu blog entry, har har).

<beigām />