Przepływ zadań w Sharepoint kontra Przepływ pracy w systemie Windows

Question

Jesteśmy w trakcie wdrażania aplikacji Sharepoint, chcielibyśmy poznać zalety i wady przepływu pracy SharePoint w porównaniu do obiegu pracy w Windows.

Answer 1

To są to samo. Aktualny Windows Workflow Engine został stworzony dla SharePoint.

Teraz należy zauważyć, że silnik Workflow zostanie poddany przeglądowi wraz z wydaniem .Net 4.0. Nie znam szczegółów, ale powiedziano mi, że różnice są znaczące. Zakładam, że to będzie używane w Sharepoint 2010, ale nie mam żadnych informacji na ten temat.

Oto link opisujące uaktualnienie w wersji 4.0.

Answer 2

SharePoint po prostu używa Windows Workflow Foundation (WF) jako swojego silnika workflow. WF sam w sobie jest tylko generycznym mechanizmem przepływu pracy.

Aby korzystać WF należy wdrożyć proces hosta dla realizacji przepływów pracy i skonfigurować go tak, że nie ustąpi instancji do bazy etc (w dzisiejszych czasach większość ludzi korzysta z usług WCF jako gospodarz workflow, zobacz here lub here) .

SharePoint zawiera wszystko, co już zostało skonfigurowane i implementuje własny host workflow, dzięki czemu można rozpocząć korzystanie z workflow po wyjęciu z pudełka. Poza tym, jest wyposażony w niestandardowe działania i inne gadżety specyficzne dla SharePoint.

Answer 3

Przepływy pracy w SharePoint są realizowane za pomocą Windows Workflow Foundation, więc nie są aż tak różne, ale wciąż istnieją pewne rzeczy, o których należy pamiętać w odniesieniu do tej implementacji.

SharePoint jest gospodarzem Windows Workflow, dzięki czemu nie trzeba zaimplementować własną komputerze, który jest w porządku, jeśli zgadzają się z decyzjami podjętymi przez zespół SharePoint:

• przypadki Workflow są zachowywane w treści baza
• komunikacji z użytkownikiem jest poprzez zadań SharePoint
• Każdy workflow instancja jest przywiązany do elementu listy/biblioteki
• Tracking nie jest realizowany

Jeśli te wybory są do Twojej dyspozycji, to w każdym razie użyj przepływów pracy SharePoint.

Jeśli nie, zaimplementuj własnego hosta i podejmij własne decyzje.

Answer 4

Jak stwierdzono w innych odpowiedziach, są one takie same, ponieważ korzystają z Windows WOrkflow Foundation. Biorąc to pod uwagę, należy pamiętać o najważniejszych przepływach pracy utworzonych za pomocą SharePOint Designer: nie są one "przenośne" po wyjęciu z pudełka, co oznacza, że ​​można utworzyć jedną oprawę, a następnie zapisać listę jako szablon, a następnie utworzyć kolejną listę opartą na tym szablonie, workflow NIE będzie działał (rebindujesz go, ponieważ wciąż odwołuje się do identyfikatora oryginalnej listy (GUID).

Answer 5

Nie określono, czy budujesz niestandardowe kodowane aplikacji SharePoint lub konfigurowania z roztworu skrzynki poprzez przeglądarkę. Tak czy inaczej, oto kilka opcji dla workflow w SharePoint.

1. Użyj natywnych przepływy wbudowane w SharePoint i łatwo dostępne z dowolnego lista.Są bardzo proste (głównie proste zatwierdzenia z jednym lub dwoma krokami), ale szybko i sprawnie uruchomią wszystko, a wszystko to można zrobić za pomocą przeglądarki.
2. Użyj programu SharePoint Designer, aby tworzyć nieco bardziej złożone przepływy pracy. Umożliwi to dostęp do logiki warunkowej (np. Routing przepływu pracy w oparciu o wartość listy) i nieograniczoną liczbę kroków oraz wiele innych funkcji, które pozwalają wprowadzić więcej logiki do procesu. Minusem jest praca z programem SharePoint Designer, który, szczerze mówiąc, może być prawdziwym bólem.
3. Niestandardowe kodowanie przepływów pracy w WF. System Windows Workflow stanowi podstawę dla dwóch pierwszych opcji, które są w zasadzie abstrakcjami nad podstawową strukturą. Główną różnicą w stosunku do tego podejścia jest to, że nie ograniczasz się do funkcji przeglądarki lub powierzchni SPD. Minusem jest to, że staje się bardziej złożony proces (choć trzeba przyznać, że przepływy będą prawdopodobnie bardziej skomplikowana) i trzeba przejść przez żmudną procedurę kodowania przeciwko SharePoint, wdrożeń opakowaniowych, wydawnictwa itp

znajdę Najlepszą równowagą pod względem łatwości rozwoju i funkcjonalności jest próba przepracowania powyższej listy w kolejności, w jakiej je dostarczyłem i przechodzę do następnej opcji, jeśli zdecydowanie nie można zrealizować wymogu z bieżącym punktem.

Answer 6

Jest to w zasadzie ta sama technologia. Jeśli znasz jedną, możesz łatwo pracować z/przełączać się na drugą.

Po dodaniu biblioteki dll SharePoint do rozwiązania otrzymujesz pewne określone działania programu SharePoint, które można wykorzystać w obiegu pracy. (Utwórz zadanie, ...)

Serwer SharePoint będzie działać jako host dla przepływów pracy.

Najlepszym sposobem na wdrożenie przepływu pracy w SharePoint jest użycie funkcji SharePoint. Mówi to SharePoint, jakie dll (złoenia) naley uyć, a które (wprowadzić) stronom pokazać.

Jako strony wejściowe można używać prostych stron asp.net lub formularzy infopath. Oba wymagają prób i błędów, aby się zawiesić.