Przepływ pracy w chmurze
W tym przykładzie fikcyjna firma zajmująca się wynajmem samochodów implementuje decyzje biznesowe oparte na strategiach i cenach. Kilka osób współpracuje nad projektowaniem, tworzeniem i testowaniem usługi decyzyjnej oraz wdrażaniem aplikacji reguł w środowiskach wykonawczych.
Na poniższym diagramie przedstawiono, w jaki sposób predefiniowane role użytkowników współpracują z komponentami produktu w trakcie cyklu życia aplikacji reguł biznesowych. Cykl obejmuje programowanie, testowanie i produkcję. Współpracownicy wykonują zadania w różnych środowiskach chmurowych.
Konfigurowanie ról użytkowników
W poniższej tabeli John widnieje jako administrator technologii informatycznych (IT) w wypożyczalni samochodów. Jest odpowiedzialny za administrowanie kontami użytkowników w firmowym portalu w chmurze. Jako pierwsza osoba zaproszona do portalu pełni rolę administratora chmury. Mimo że sam nie korzysta z komponentów w chmurze, musi zapraszać inne osoby do portalu i przypisywać im role do korzystania z komponentów.
| Członek zespołu | Praca | Rola użytkownika | Dostęp do komponentów i środowisk |
|---|---|---|---|
| Jan | Administrator IT | Administrator chmury (administrator) Menedżer uprawnień
|
Portal w chmurze i produkt Decision Center. Zarządza kontami użytkowników, grupami i rolami. |
| Kamila | Twórca aplikacji | Twórca reguł | Rule Designer i Decision Center. Wdraża w środowiskach programistycznych i testowych. |
| Grzegorz | Strateg marketingowy | Użytkownik biznesowy | Konsola biznesowa produktu Decision Center . Wdraża w środowisku programistycznym. |
| Franek | Analityk | Menedżer wersji | Konsola biznesowa produktu Decision Center . Ma funkcje administracyjne i jest wdrażany we wszystkich środowiskach. |
| Andrzej | Specjalista ds IT | Integrator | Konsola biznesowa produktu Decision Center . Wdraża w środowiskach programistycznych i testowych. Wykonuje test porównawczy usługi decyzyjnej. |
Współpraca przy usłudze decyzyjnej
Jako programista reguł, Kim używa programu Rule Designer do tworzenia usługi decyzyjnej, wdrażania jej w środowisku wykonawczym i publikowania jej w produkcie Decision Center. Zna język Java™ i rozumie model obiektowy firmy. Wspólnie z architektami oprogramowania opracowuje pierwszą wersję usługi decyzyjnej, przygotowuje dla niej słownik i pisze reguły biznesowe modelujące logikę wypożyczalni samochodów.
Działania Kim przedstawia poniższy diagram. Najpierw tworzy usługę decyzyjną i powiązane z nią artefakty w programie Rule Designer. Podczas pracy nad usługą decyzyjną testuje ją, wdrażając ją na serwerze Rule Execution Server w środowisku programistycznym. Po zakończeniu początkowej wersji usługi decyzyjnej publikuje ją w produkcie Decision Center.
Jako menedżer wersji Frank używa środowiska zarządzania decyzjami w produkcie Decision Center. Tworzy wersję usługi decyzyjnej i konfiguruje działania wprowadzania zmian w wersji i sprawdzania jej poprawności. Po zakończeniu działań sprawdzania poprawności przez zespół, gdy reguły są gotowe do testowania, Frank wdraża wersję na serwerze w celu uruchamiania reguł w środowisku programistycznym.
Na poniższym diagramie użytkownik biznesowy Gary aktualizuje usługę decyzyjną w produkcie Decision Center, a Frank wdraża usługę decyzyjną z produktu Decision Center na serwerze Rule Execution Server.
W związku z tym, że Gary pracuje w dziale marketingu, chce zweryfikować politykę cenową realizowaną w regułach. Gary przegląda i edytuje reguły za pomocą konsoli Decision Center . Gary pracuje w gałęzi aktywności, która śledzi jego zmiany.
Oprócz skonfigurowania kont użytkowników w portalu w chmurze, Jan działa również jako menedżer uprawnień w konsoli Decision Center . Ustawia parametry zabezpieczeń i dostępu użytkowników na karcie administracyjnej. Kontroluje, czy Gary i inni użytkownicy potrzebujący dostępu do wersji i gałęzi aktywności w usłudze decyzyjnej, są przypisani do prawidłowych grup użytkowników. Może również wdrożyć usługę decyzyjną do środowiska produkcyjnego.
Testowanie i publikowanie usługi decyzyjnej
Frank, menedżer wersji, ma dostęp do wszystkich trzech środowisk chmurowych. Może przeprowadzać testowanie w całym cyklu życia usługi decyzyjnej. Jak wynika z poniższego diagramu, po ukończeniu przez zespół usługi decyzyjnej w środowisku programistycznym, Frank wdraża ją do środowiska testowego.
Frank ściśle współpracuje z Arjunem, integratorem. Aby określić, czy usługa decyzyjna działa zgodnie z oczekiwaniami, Arjun działa w konsoli Decision Center i we wszystkich trzech środowiskach w chmurze. Monitoruje i ocenia zachowanie usługi decyzyjnej, gdy zostaje wywołana przez aplikację kliencką.
Aby ocenić wydajność usługi decyzyjnej w środowisku testowym, Frank prosi Arjuna o wykonanie testów porównawczych opartych na standardowych procedurach sprawdzania poprawności oprogramowania. Arjun dodaje kod do aplikacji WWW wypożyczalni samochodów, tak by mogła ona wywoływać nową usługę decyzyjną. Na poniższym diagramie przedstawiono aplikację WWW wypożyczalni samochodów działającą na serwerze aplikacji przedsiębiorstwa i wywołującą usługę decyzyjną ze środowiska testowego.
Po zakończeniu programowania, gdy Frank jest zadowolony z wyników testu porównawczego w środowisku testowym, awansuje usługę decyzyjną na serwer Rule Execution Server w środowisku produkcyjnym jako ostatni krok w cyklu życia usługi decyzyjnej. Jako menedżer wersji Franek może wdrożyć usługę decyzyjną w środowisku produkcyjnym.
Poniższy diagram przedstawia przebieg publikowania usługi decyzyjnej w środowisku produkcyjnym. Klient, który używa aplikacji WWW, powoduje wywołanie usługi decyzyjnej.
Gary może również powiedzieć swoim współpracownikom z działu marketingu, że może wdrożyć nową kampanię promocyjną w następnym kwartale, ponieważ może użyć portalu w chmurze, aby skorygować reguły ustalania cen w usłudze decyzyjnej.