Ik schreef een uitvoerig artikel een paar weken geleden waarin wordt beschreven hoe een SharePoint Designer werkstroom die een e-mail met feedbackherinnering is taak op een dagelijkse basis stuurt te maken. Het is geweest gepubliceerd op de nieuwe SharePoint Magazine site. Meer in het algemeen, het artikel toont hoe maak een looping structuur in SPD.

Het magazine heeft een grote verscheidenheid van artikelen met inbegrip van, onder andere, zeer technische zaken, interviews en industrie nieuws. Ik adviseer dat u het aan uw RSS-feed toevoegt.

Hebt u een product of dienst te verkopen, Ik zou ook overwegen reclame op de site. Het is uitgeschakeld voor een sterke start met verscheidene duizend paren van ogen kijken naar het al. Dat is zeker te groeien.

Tot slot, Als u heb jeuk om te schrijven iets en het uit te krijgen voor een groter publiek, Dit is een geweldige tijd en plaats om te krabben.

</einde>

Abonneren op mijn blog.

Mark Miller over op Eindgebruiker SharePoint mijn laatste artikel over het gebruik van SharePoint Designer maken grote workflowoplossingen omhoog op zijn site heeft gepost. Check it out.

In dit artikel, Ik praat over het ontwerpproces en, meer in detail, het instellen van een betrouwbare en herhaalbare testproces met behulp van SharePoint-functies (aangepaste lijsten, sitesjablonen). Het artikel richt zich op eindgebruikers, maar de aanpak is ook goed voor ontwikkelaars.

</einde>

Abonneren op mijn blog.

Vorige week, Ik werkte uit hoe lus en uit te voeren een statusmachine met behulp van SharePoint Designer en vermeld, Als een terzijde, dat ik zou waarschijnlijk schrijf een blogbericht over betere werkstroom logboekregistratie.

Goed, Sanjeev Rajputs sloeg me aan het. Neem een kijkje.

Opslaan van logboekgegevens in een aangepaste lijst lijkt superieur aan met behulp van de regelmatige werkstroomgeschiedenis:

• Het is alleen een aangepaste lijst, dus u deze exporteren kunt naar excel heel gemakkelijk.
• U kunt weergaven maken, dynamisch filteren van de gegevens, etc.
• Het is niet onderworpen aan de auto-purge krijg je met regelmatige werkstroomgeschiedenis.

Er zijn enkele risico 's / nadelen:

• Veel actieve workflows met een heleboel logboekregistratie kunnen ertoe leiden dat teveel gegevens worden geschreven aan de lijst.
• Misschien heb je * * willen automatisch wissen. Je krijgt niet die functie met deze aanpak (zonder codering).
• Veiligheid is lastig. Om te schrijven aan de lijst, de gebruiker moet gemachtigd zijn om dit te doen. Dat betekent dat er waarschijnlijk niet geschikt voor elke vorm van "ambtenaar" audit aangezien de gebruiker kan de lijst ontdekken en bewerken. Dit kan worden overwonnen met sommige aangepaste programmering.

</einde>

Abonneren op mijn blog.

Dit afgelopen week ik afgewerkt een bewijs van concept project voor een cliënt in Manhattan. Terwijl de implementatie van de oplossing, Ik liep in een andere tekortkoming van MOSS KPI 's (Zie hier voor een eerdere KPI-kwestie en mijn workaround).

Achtergrond: We SharePoint Designer workflow gebruikt om het model van een vrij complexe meerdere maanden lange bedrijfsproces. Als het pufte langs, het zou sommige statusgegevens in een lijst bijwerken. KPI's gebruiken deze gegevens om te doen hun mojo.

We besloten om een nieuwe site wordt gemaakt telkens wanneer die een nieuwe transactie van deze bedrijfsprocessen aftrap. Afgezien van de werkstroom zelf, deze sites host meerdere documentbibliotheken, gebruiken van doelgroepen, enzovoort. Gewoon een heleboel dingen om te helpen met samenwerking tussen de interne medewerkers, reizen werknemers en de client de deelnemende zakelijke partners.

We wilden ook Toon Sommige KPI's die toezicht op de algehele gezondheid van dat specifieke bedrijfsproces bevorderd door de werkstroom staat gegevens en bekeken met behulp van de KPI 's.

Tot slot, we gebruikt KPI-lijstitems die een telling op een zicht op een lijst op de site doen (in tegenstelling tot trekken uit een andere gegevensbron, zoals excel of SQL).

Het probleem: Zoals u zich kunt voorstellen, ervan uitgaande dat we moesten voeren het basisidee vooruit in een productie-wereld, Wij willen een sitesjabloon. Bepaling van een nieuwe site op basis van een "business process" sjabloon.

Het probleem is dat u niet lijken te krijgen een functionerende KPI die manier. Wanneer ik een nieuwe site op basis van een sjabloon met een KPI-lijst en KPI-webonderdeel maken, de nieuwe site KPI gegevens zijn gebroken. De nieuwe site KPI lijst punten op welke bron u hebt gedefinieerd toen u het eerst hebt opgeslagen als een sjabloon.

Bij wijze van voorbeeld:

• Een nieuwe site maken en bouwen tot in de perfectie. Deze site bevat de KPI-gegevens.
• Die als een sjabloon opslaan.
• Maak een nieuwe website en baseren als uit de sjabloon.
• Deze nieuwe site KPI-lijstitems’ bronnen wijzen op de sitesjabloon, niet de huidige site.

De URL niet wordt opgelost door het instantiëren proces.

Ik heb geprobeerd dit op te lossen door een relatieve URL op te geven bij het definiëren van het lijstitem KPI. Echter, Ik kon niet krijgen een variatie van dat aan het werk.

Ik wil altijd aan paar op deze "probleem" blogberichten met een soort van oplossing, maar in dit geval heb ik niet een goeie. De beste die ik kan vinden is dat je nodig hebt om naar de nieuw ingerichte site in en alles handmatig vast te stellen. De Gebruikersinterface maakt dit nog moeilijker omdat de URL van de bronlijst wijzigt, wordt een vernieuwen, dus je moet echt het hele ding van kras opnieuw definiëren.

Als er iemand weet een betere manier om dit te gaan, post een reactie.

</einde>

Ik heb onlangs geleerd dat het mogelijk en zelfs vrij gemakkelijk een staat machine werkstroom met behulp van SharePoint Designer te maken. Noodzaak is de moeder van de uitvinding en al dat goede materiaal en ik had een behoefte deze week die keek voor een uitvinding. Toevallig, Ik kwam dit MSDN forumpost ook. Mijn persoonlijke ervaring deze week en dat "onafhankelijke bevestiging" leent kracht om mijn overtuiging. Ik ben van plan om te schrijven over dit uitvoeriger met een volledige geblazen voorbeeld, maar hier is de kern van het:

• De aanpak maakt gebruik van het feit dat een werkstroom een item in de lijst kunt wijzigen, daardoor triggering een nieuwe workflow. Ik heb dit een overlast en zelfs normaal overwogen geblogd over het gebruik van semaforen om het te behandelen.
• SharePoint laat toe meerdere onafhankelijke werkstromen te zijn actief tegen een specifieke lijst-item.

Te configureren:

• Ontwerp uw statusmachine (dat wil zeggen, de Staten en hoe Staten de overgang van de ene naar de volgende).
• Uitvoering van elke staat als aparte werkstroom.
• Elk van deze werkstromen staat uit te voeren in reactie op wijzigingen in het lijstitem configureren.

Elke staat-workflow volgt dit ruwe patroon:

• Bij initialisatie, bepalen of het moet echt worden uitgevoerd door inspectie van statusgegevens in het "huidige item". Afbreken als niet.
• Het werk doen.
• De "huidige-item bijwerken" met nieuwe statusgegevens. Dit start een update naar het huidige item en branden uit alle staat workflows.

Afgezien van de hand liggende voordeel kunt dat men een declaratieve staat machine workflow maken, dat alles staat informatie is geweldig voor het bouwen van KPI's en interessante views.

Het heeft een vrij grote nadeel — het standaard bijhouden van de workflowgeschiedenis is zelfs nog nuttelozer dan normaal 🙂 Dat is eenvoudig te verhelpen, echter. Al uw audit typegegevens in een aangepaste lijst opslaan. Dat is waarschijnlijk een goed idee zelfs voor vanille sequentiële workflow, maar dat is voor een andere blogpost 🙂

Ik noem dit een "mea culpa" want ik heb, Helaas, meer dan eens gezegd op forums en elders moet dat een gebruikt u visual studio een staat machine werkstroom te maken. Dat is gewoon niet waar.

</einde>

Abonneren op mijn blog.

Het is mogelijk om een eindeloze lus veroorzaken in een werkstroom-SharePoint Designer. Een gemeenschappelijke uitvoering patroon als dit veroorzaakt het probleem:

• Als u een workflow maken en koppelen aan een lijst.
• Aangeven dat het moet beginnen met maken van nieuwe items en bijwerken van bestaande items.
• Een stap in de werkstroom een veld in de 'Huidige Item' bijgewerkt.
• Aangezien het huidige item gewijzigd, de werkstroom wordt opnieuw gestart.

Om te voorkomen dat deze eindeloze lus, uitvoering van een eenvoudige semafoor:

• Een sitekolom toevoegen (of kolom aan de lijst/bibliotheek als u niet bent met behulp van inhoudstypen).
• Het verbergen van de bewerkingspagina (gemakkelijk om te doen als een sitekolom via zijn eigenschappen, niet zo eenvoudig als een lijstkolom).
• In de werkstroom, controleren om te zien als de waarde van de semafoor kolom leeg is.
• Als het leeg is, Stel deze in op een niet-lege waarde en gaan.
• Als is niet leeg is, onmiddellijk te verlaten.

Dit kan een vrij genuanceerde oplossing worden, afhankelijk van de bedrijfsvereisten enzovoort, maar het is geweest een werkbare patroon wanneer heb ik het nodig had.

</einde>

Abonneren op mijn blog.

Zo veel mensen weten, de werknemer opleiding sjabloon geboden door: Microsoft hier heeft een bug die we kunnen reproduceren volgt:

• Een klasse maken met een maximale grootte van 10 studenten.
• Registreren –> Totaal aantal beschikbare zitplaatsen goed verlaagd door een. Resultaat: 9 beschikbare zitplaatsen.
• Uitschrijven: –> Bug. Totale beschikbare zitplaatsen moeten verhogen met één. Het niet. Resultaat: 9 beschikbare zitplaatsen per SharePoint, maar in feite, Er zijn 10 beschikbare zitplaatsen.

Oplossing: SharePoint Designer gebruiken om te corrigeren van de werkstroom.

Eerste, Open de site. De mappenlijst voor mij ziet er als volgt:

Als we eens een kijkje op de "deelnemer registratie" werkstroom, We zien dat er een stap met het label "Zitplaatsen beleid afdwingen". Het ziet er als volgt:

Deze stap in de werkstroom het item bijgewerkt door het verhogen van de "gevuld zitplaatsen" metagegevens kolom op de cursus. Als we die in meer detail optrekken, We zien dit:

Dat is alle informatie die wij moeten de werkstroom verwijdering bevestigen.

Als we over aan de verwijdering workflow wegknippen, Er is geen vergelijkbare werkstroomstap. Als volgt toe te voegen:

1: Vouw "deelnemer verwijdering" en open te stellen het XOML (Zie het eerste scherm ontsproten als je verloren).

2: Toevoegen van een nieuwe werkstroomvariabele, "Nieuwe gevulde zitplaatsen" van het type "Number".

3: Een waarde toewijst aan "nieuwe gevuld zitplaatsen" zoals:

4: Decrement de gevulde zetels door 1:

5: De gerelateerde cursus item bijwerken:

6: Zorg ervoor dat alle stappen in de juiste volgorde. Voor mij, het ziet er als volgt:

7: Voltooien van de werkstroom om opnieuw te bouwen.

8: Test.

</einde>

Abonneren op mijn blog.

Een van de opkomende patronen die ik vind in het bewerken van SharePoint oplossingen maakt gebruik van SharePoint Designer workflow en de ontvanger van een gebeurtenis.

Hier is een bedrijfsscenario om hem in verband:

• Ik uploaden een document naar een doc-lib.
• Ik kick-off scriptingregel werkstroom die is gemaakt met behulp van SharePoint Designer.
• Op een bepaald punt tijdens dat proces, werkstroom toewijst een taak aan iemand (via gegevens verzamelen van een gebruiker of een taak toewijzen).
• Wij willen met een KPI bijhouden hoe lang die taak is in afwachting van voltooiing. De KPI toont groen voor taken die voltooid zijn of vervaldatum meer dan 3 dagen vanaf nu. Het toont geel als de taak verschuldigd morgen of vandaag is. Het toont rood als de taak achterstallig is.
• Hier is de kicker: Ik wil de datum die dat KPI drijft op de vakantie-hoogte.

Ik kan niet berekenen een vakantie-bewust due datum in SharePoint Designer workflow heel gemakkelijk. Ik zou hebben om een aangepaste actie maakt of een 3rd party tool gebruiken. Echter, het is gemakkelijk genoeg om dergelijke een datum in een gebeurtenis ontvanger te berekenen. Samenvoegen van deze twee samen en krijgen we een patroon:

• Definiëren van een verborgen Ja/geen sitekolom op de documentbibliotheek met het label "DoCalcualteDueDate".
• Het initialiseren op false.
• Op het juiste moment in de workflow (bijvoorbeeld. vlak voor de 'verzamelen gegevens" actie), toewijzen van deze waarde op True.
• Een ItemUpdate() gebeurtenis ontvanger kijkt om te zien als "DoCalculateDueDate" waar is. Aangezien de gebeurtenis ontvanger op elke update draait, "DoCalculateDueDate" is normaal gesproken ingesteld op false.
• Wanneer de workflow toegewezen DoCalculateDueDate op true, de gebeurtenis ontvanger berekent de vakantie-bewust due datum.
• Wanneer de gebeurtenis ontvanger doet deze berekening, het stelt u de DoCalculateDueDate vlag op false.

In het einde, SPD werkstroom wordt verstrekt met een gebeurtenis ontvanger via de semafoor DoCalculateDueDate en we hebben vakantie-bewust verschuldigde datums die zijn toegewezen op het precies juiste moment in het leven van de werkstroom. SharePoint Designer bepaalt wanneer de vervaldatum is toegewezen, maar de gebeurtenis ontvanger de werkelijke berekening en toewijzing voert.

</einde>

Abonneren op mijn blog.

UPDATE: Ik heb onderzocht hoe embed een EPD workflow in een sitedefinitie. Deze keten van MSDN forum heeft een aantal interessante informatie. Het is niet afdoende, maar naar pad door de jungle wijst.

Ik ben het geven van deze post een enigszins excentrieke "waargenomen gedrag" leiden aangezien ik een beetje wantrouwend ben van het trekken van conclusies uit het. SPD werkstromen zijn … temperamentvolle.

Mensen vragen zich vaak af / benieuwd / piekeren over EPD werkstromen verplaatsen van de ene plaats naar de andere. Vandaag, Ik volgde deze stappen en maakte deze opmerkingen:

• Ik heb gemaakt een workflow in een site die is gekoppeld aan een documentbibliotheek met behulp van SharePoint Designer.
• De bijbehorende documentbibliotheek gehuisvest al verschillende documenten.
• Ik heb de site opgeslagen als een sjabloon.
• Wanneer ik de site opgeslagen als een sjabloon, Ik heb de inhoud ook opgeslagen.
• Ik heb een nieuwe site gemaakt in dezelfde siteverzameling met die sjabloon.

Op dit punt, Mij beproefd voor stormloop van de werkstroom. Het beëindigd onmiddellijk zelf met de log boodschap, "Fout bij begin".

Ik verwacht dat dit. Ik heb lage verwachtingen als het gaat om het EPD werkstromen bewegen.

Ik bleef:

• De site geopend in SharePoint Designer.
• Had een kijkje op de werkstroom. Het leek prima.
• Ik klikte op "Finish".
• Ik liep de werkstroom.

Deze keer, het werkte boete.

Ik zal toevoegen dat deze werkstroom de "verzamelen gegevens van gebruiker gebruikt" actie die een relatief complexe actie onder de motorkap is.

Ik voorlopig concluderen dat het proces van "afwerking" de werkstroom veroorzaakt EPD goed de SPD-werkstroom koppelen aan de nieuwe documentbibliotheek. Ik ook sluiten dat de XOML en andere XML-artefacten zijn redelijk "losse". Ze zijn niet super strak gekoppeld aan de documentbibliotheek.

Wat betekent dit betekenen? Ervan uitgaande dat het een betrouwbare en reproduceerbare proces, Er is ten minste één ruwe methode die we gebruiken kunnen om hen rond bewegen. Ik weet niet of dit zou werken als wij site collectie grenzen overschreden of zelfs meer drastisch, hele nieuwe boerderijen (bijvoorbeeld. dev naar toneel voor de prod).

Als u dit leest en geneigd, post een reactie of e-mail me uw SharePoint Designer migratie verhaal. Ik zal graag updaten dit bericht met elke inzichten dus aangeboden.

</einde>

Abonneren op mijn blog.

Het is vaak handig om op te slaan statusinformatie in een aangepaste lijst zoals een goedkeuringsnummer die nooit rechtstreeks moet worden gemanipuleerd door eindgebruikers. Dit is een gemeenschappelijk scenario voor business. Ik heb gewerkt aan een project dit jaar dat genereert verschillende status en herinnering data via SharePoint Designer werkstromen die vervolgens rijden KPI's en in het algemeen ondersteunen tijdkritieke zakelijke processen.

Gebruik een site-inhoudstype / kolom om dit effect te bereiken.

Een site-inhoudstype maken met de statuskolom zoals:

Opmerking de Status" (voor Demo)" veld onderaan.

Volgende, Klik op de naam van de kolom tot de kolomeigenschappen. Selecteer "verborgen (Worden niet weergegeven in formulieren)" in de sectie Kolominstellingen zoals:

Dit wordt het veld verwijderd uit de formulieren standaard bewerken/bijwerken. Echter, het is nog steeds beschikbaar in weergaven, KPI 's, het objectmodel en nergens anders u wilt gebruiken, met inbegrip van EPD werkstroom.

</einde>

Abonneren op mijn blog.