Jaki jest najlepszy sposób, aby uzyskać komunikaty o błędach z przepływu pracy WF4 z powrotem do aplikacji ASP.NET MVC obsługującej hosting? Potrzebuję przepływu pracy, aby nie przerwać, ale nadal być aktywny, a następnie przekazać komunikat do aplikacji hostingowej w sprawie błędu, aby użytkownik mógł podjąć alternatywne działanie, ale nie jestem pewien, jak to zrobić.Obsługa błędów Windows Workflow Foundation 4 (WF4)
Aby utrzymać przebieg pracy, należy przechwycić wyjątek w obiegu pracy. Dodaj działanie TryCatch do przepływu pracy, aw bloku Catch możesz użyć działania Wyślij lub działania niestandardowego, aby wysłać dane do aplikacji hosta.
Jedynym wyjątkiem jest użycie wyjątku WorkflowApplication.OnUnhandledException z opcją persistence i określenie abort. W takim przypadku stan pamięci w przepływie pracy jest właśnie usuwany, a przepływ pracy można ponownie załadować dla ostatniego stanu trwałego. Jeśli pójdziesz tą drogą, musisz upewnić się, używając aktywności Perist, że twój przepływ pracy jest zapisywany, gdy coś, czego nie można przerobić.
Trzy sposoby, że mogę myśleć ...
WorkflowApplication.OnUnhandledException jest tam, aby poinformować, gdy nieobsługiwany wyjątek jest generowany, ale nie jestem pewien, czy można odzyskać z tego. Nie wygląda na dobrą drogę do zejścia.
WorkflowApplication.PersistableIdle informuje, kiedy działanie przepływu pracy utworzyło zakładkę i przerwał przepływ pracy. W tym momencie przepływ pracy czeka na powrót z większą ilością informacji, aby powrócić do przepływu pracy po wznowieniu z zakładki. To może być twój najlepszy wybór, ponieważ jest stosunkowo prosty w implementacji i użyciu.
Innym twistem jest utworzenie extension, które Twoje działania mogą uzyskać z kontekstu przepływu pracy. Rozszerzenia zapewniają bardziej elastyczny sposób komunikacji poza przepływem pracy, chociaż musisz je zakodować i upewnić się, że działają zgodnie z oczekiwaniami. Zakładka + rozszerzenie to twoja najbardziej elastyczna opcja.
TryCatch nie jest wystarczający, jeśli chodzi o WF4. Ponadto obsługa zdarzenia UnhandledException z hosta przepływu pracy nie mówi zbyt wiele o tym, które działanie nie powiodło się i dlaczego.
Sugerowana metoda polega na użyciu funkcji śledzenia próby i aktywności w ramach WF4. Dobre podsumowanie tego można znaleźć tutaj: http://msmvps.com/blogs/theproblemsolver/archive/2009/11/27/trycatch-activity-in-wf4.aspx
Możesz rozszerzyć swój host przepływu pracy z uczestnikami Śledzenia oraz programem obsługi catch, który hermetyzuje Twoją aktywność, która może być przyczyną błędu, obsłużyć wyjątek i utworzyć nowy TrackingRecord, który może lepiej zilustrować co stało się.
Rozszerzenie śledzenia jest wymagane tylko wtedy, gdy musisz wiedzieć, które działanie spowodowało błąd. TryCatch będzie dobrze radził sobie z uchwyceniem błędu i informacją, co poszło nie tak, a jedynie jego brakiem. – Maurice
To był mniej więcej mój punkt widzenia. Powinienem być bardziej jasny. Cierpiał na infekcję zatok i nie myślał zbyt dobrze o mojej odpowiedzi. –
Maurice, mój Workflow obecnie nie jest przepływem pracy w WCF (XAMLX), czy konieczne jest użycie działania Send opisanego powyżej? –
Nie ma potrzeby korzystania z funkcji Wyślij. Wszelkie niestandardowe działania, które wysyłają dane do hosta, są w porządku. BTW działanie Send używa komunikatów WCF, ale może być używane z dowolnego hosta przepływu pracy, jego działanie Receive, które wymaga WorkflowServiceHost. – Maurice
OK, utworzyłem niestandardową aktywność, która pobiera komunikat o błędzie z TryCatch, a następnie przypisuje go do OutArgument, ale nie widzę sposobu, aby uzyskać wartość OutArgument w mojej aplikacji hostingowej. Próbuję użyć WorkflowApplication, ponieważ mam również zakładki, które należy wznowić, ale widziałem tylko dane wyjściowe z przepływu pracy podczas korzystania z WorkflowInvoker, a następnie pobieranie z nich wyjściowego Dictionary. Czy istnieje sposób na odzyskanie danych z WorkflowApplication? –