Przepływ pracy w chmurze
W tym przykładzie fikcyjna wypożyczalnia samochodów implementuje decyzje biznesowe, które są oparte na strategiach i cenach. Wiele osób pracuje w pracy grupowej w celu zaprojektowania, utworzenia i przetestowania usługi decyzyjnej oraz wdrożenia 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 portalu chmurom firmy. 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 | Stanowisko | Rola użytkownika | Dostęp do komponentów i środowisk |
|---|---|---|---|
| John | Administrator IT | Administrator chmury (administrator) Menedżer uprawnień
|
Portal Cloud i Decision Center. Zarządza kontami użytkowników, grupami i rolami. |
| Kim | Programistka aplikacji | Programista reguł | Rule Designer i Decision Center. Wdraża w środowiskach programistycznych i testowych. |
| Gary | Strateg marketingowy | Użytkownik biznesowy | Decision Center Konsola biznesowa. Wdraża w środowisku programistycznym. |
| Frank | Analityk | Menedżer wydania | Decision Center Konsola biznesowa. Posiada funkcje administracyjne i wdraża we wszystkich środowiskach. |
| Arjun | Specjalista IT | Integrator | Decision Center Konsola biznesowa. Wdraża w środowiskach programistycznych i testowych. Wykonuje testowanie testu porównawczego usługi decyzyjnej. |
Współpraca przy usłudze decyzyjnej
Jako programista reguł Kim używa programu Rule Designer do utworzenia usługi decyzyjnej, wdróż ją w środowisku wykonawczym i opublikuj ją w produkcie Decision Center. Zna język Java™ i rozumie model obiektu przedsiębiorstwa. 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 tworzona jest usługa decyzyjna i powiązane artefakty w programie Rule Designer. W trakcie 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 jest ona publikowana w Centrum decyzyjnym.
Jako menedżer wersji Frank korzysta z struktury zarządzania decyzjami w Centrum decyzyjnym. Tworzy wersję usługi decyzyjnej i konfiguruje działania wprowadzania zmian w wersji i sprawdzania jej poprawności. Gdy zespół zakończy działania sprawdzania poprawności, a reguły są gotowe do przetestowania, to w środowisku programistycznym Frank wdraża wydanie do serwera w celu uruchamiania reguł.
Na poniższym diagramie użytkownik biznesowy, Gary, zaktualizuje usługę decyzyjną w Centrum decyzyjnym, a Frank wdraża usługę decyzyjną z Decision Center do serwera 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 edyuje reguły za pomocą konsoli Decision Center . Gary pracuje w gałęzi aktywności, która śledzi jego zmiany.
Oprócz konfigurowania kont użytkowników w portalu w chmurze, John pracuje 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 chmurowych. 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 aplikacja WWW wypożyczalni samochodów działa na firmowym serwerze aplikacji i wywołuje usługę decyzyjną ze środowiska testowego.
Po zakończeniu projektowania, gdy Frank jest zadowolony z wyników testu porównawczego w środowisku testowym, promuje usługę decyzyjną na serwerze Rule Execution Server w środowisku produkcyjnym jako ostatni krok 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 kolegom marketingowym, że może wdrożyć nową kampanię promocyjną w następnym kwartale, ponieważ może użyć portalu w chmurze, aby skorygować reguły dot. cen w usłudze decyzyjnej.