Z życia wdrożeniowca – podejście do konfiguracji aplikacji w WEBCON BPS 2019 zgodnej z DEV/TEST/PROD

Facebooktwittergoogle_pluspinterestlinkedinmail
Dotyczy wersji: 2017.x i 2019.x; Autorzy: Kamil Nędza i Mariusz Burek

Wstęp

Koncepcja DEV/TEST/PROD opiera się na podziale infrastruktury na trzy odseparowane środowiska, odpowiednio:

  • Deweloperskie (DEV) – środowisko przeznaczone do rozwijania aplikacji biznesowych, testowania konfiguracji oraz funkcjonalności.
  • Testowe (TEST) – środowisko przeznaczone do weryfikacji aplikacji przez Biznes lub dział IT. Środowisko pozwala na przetestowanie czy aplikacja spełnia oczekiwania użytkowników oraz zweryfikować poprawność procesu zarówno pod kątem konfiguracyjnym, jak i poprawności migracji procesu. Przy złożonych procesach, podczas migracji aplikacji na środowisko testowe, można przygotować pełny plan przeniesienia aplikacji (np. przeniesienie widoków, tabel, interfejsów, witryn itp.), który później może posłużyć przy migracji na środowisko produkcyjne.
  • Produkcyjne (PROD) – środowisko docelowe, na którym na co dzień pracują użytkownicy końcowi.

 

Rys.1 Schemat implementacji zmian w podejściu DEV/TEST/PROD

 

Dobre praktyki

W trakcie tworzenia nowych aplikacji lub modyfikacji istniejących warto przestrzegać dobrych praktyk. Stosowanie się do poniższych wskazówek, na pierwszy rzut oka wydaje się być bardziej czasochłonne, jednak pozwala uniknąć wielu pomyłek oraz pozwoli całemu zespołowi pracować w uporządkowany sposób.

  • Blokowanie środowiska – w designer STUDIO istnieje możliwość zablokowania środowiska. Dzięki temu nie ma możliwości wprowadzania ręcznych zmian na żadnym z istniejących procesów na danym środowisku. Zmiany można realizować wyłącznie poprzez import aplikacji. Dobrą praktyką jest blokowanie środowiska produkcyjnego, jednak warto także rozważyć opcję blokady środowiska testowego.

 


Rys.2 Element konfiguracji środowiska umożliwiający zablokowanie ręcznej edycji procesów

 

  • Używanie zmiennych – każdy element konfiguracyjny aplikacji posiada swoje unikalne w skali środowiska ID (procesy, obiegi, atrybuty itp.). Jednak identyfikatory te różnią się pomiędzy poszczególnymi środowiskami. Dlatego podczas konfigurowania procesów, należy używać zmiennych dostępnych w prawym menu kontekstowym. Dzięki temu w momencie migracji aplikacji na środowisko docelowe, zmienne te zostaną zmapowane na identyfikatory występujące na środowisku docelowym.

Więcej na ten temat można dowiedzieć się w tym artykule:
http://kb.webcon.pl/eksport-import-dobre-praktyki-tworzenia-procesow/

  • Używanie stałych – w ramach procesu (stała procesowa) lub środowiska (stała globalna) można zdefiniować stałą, która będzie zwracać jedną konkretną wartość. Wartość ta może być różna dla każdego ze środowisk. Przykłady stałych:
    • Stała globalna zwracająca adres witryny
    • Stała globalna zwracająca ID konkretnej grupy SharePoint
    • Stała globalna zwracająca typ środowiska, umożliwiająca np. blokowanie wpisów do systemów zewnętrznych ze środowisk DEV oraz TEST
    • Stała globalna zawierająca tekst, który będzie „doklejany” w temacie maila informujący, że mail jest wysłany ze środowiska testowego
    • Stała procesowa zawierająca inne progi kwotowe dla środowisk testowych oraz produkcyjnego, dzięki czemu użytkownicy będą mogli przetestować funkcjonalności niedostępne dla nich na środowisku produkcyjnym
    • Stała procesowa zawierająca listę użytkowników rozdzielonych średnikami, pozwala np. zdefiniować grupę testerów, która będzie dodatkowo otrzymywać zadanie na środowiskach testowych

Więcej na ten temat można dowiedzieć się w tym artykule:
http://kb.webcon.pl/eksport-import-dobre-praktyki-tworzenia-procesow/

  • Uzupełnianie sekcji DEV/TEST/PROD – w elementach systemu, które różnią się pomiędzy środowiskami (np. połączenia, źródła danych, stałe) występują zakładki do uzupełnienia danych dla każdego typu środowiska. Istnieje także możliwość uzupełnienia wartości wspólnej, która jest wykorzystywana w momencie kiedy nie została zdefiniowana wartość dla docelowego środowiska. Podczas tworzenia aplikacji dobrą praktyką jest uzupełnianie wszystkich zakładek od razu – nawet w przypadku, jeżeli na etapie implementacji nie znamy jeszcze wartości dla danego środowiska warto pozostawić ją pustą. Dzięki takiemu podejściu możemy uniknąć sytuacji, że użyta zostanie niepoprawna wartość, np. wpis do systemu produkcyjnego z środowiska testowego.

Więcej na ten temat można dowiedzieć się w tym artykule:
http://kb.webcon.pl/nowe-podejscie-do-zrodel-danych-w-webcon-bps-polaczenia-ang-connections/

 


Rys.3 Przykład zakładek DEV/TEST/PROD dla połączenia do bazy MSSQL

  • Różny layout strony SharePoint dla każdego ze środowisk – pozwala w łatwy sposób odróżnić środowisko, na którym obecnie się znajdujemy. Prosta zmiana, a pozwala uniknąć omyłkowego zarejestrowania elementów workflow na środowisku produkcyjnym.
  • Używanie linków relatywnych – używanie linków relatywnych (zarówno w procesie jak i na witrynach SharePoint oraz warstwie prezentacji BPS Portal) umożliwia eksportowanie procesów bez obaw o to, że na środowisku docelowym linki będą prowadziły do innego serwera.
  • Dedykowane zewnętrzne zasoby dla każdego środowiska – warto, aby każde środowisko posiadało niezależne zasoby. Każde środowisko powinno posiadać niezależne HotFoldery oraz HotMailBoxy, aby środowiska nie rywalizowały między sobą i nie „podbierały” sobie wzajemnie plików. Jeżeli aplikacja komunikuje się z systemami zewnętrznymi (np. ERP, HR itp.), warto zatroszczyć się o ich testowe odpowiedniki lub tak zwane mocki, które będą taki system symulowały.
  • Analogiczne nazewnictwo witryn – wraz z migracją procesu, przenoszona jest informacja o powiązanych witrynach i Web Partach WEBCON. Jeżeli witryny na środowisku docelowym będą miały inną ścieżkę dostępu (np. inna nazwa witryny lub podwitryna będzie znajdować się w innej lokalizacji), to konfiguracja Web Partów WEBCON nie przeniesie się poprawnie.
  • Czy zachowanie dla środowisk DEV/TEST/PROD ma być analogiczne? – podczas tworzenia aplikacji należy mieć na uwadze, czy zachowanie na obu środowiskach będzie identyczne. Ma to szczególne znaczenie w przypadku procesów o poufnych danych oraz tam gdzie z workflow wysyłane są dane do systemów zewnętrznych. Przykładowo, dla obiegów zawierających informacje o zarobkach pracowników warto przygotować dedykowane testowe źródła danych zwracające nieprawdziwe dane. Z kolei jeżeli przewidujemy modyfikację danych kont użytkowników w AD z poziomu workflow, warto sobie zadać pytanie, czy z poziomu środowiska testowego, taka akcja powinna być w ogóle wykonywana.
  • GUID, czyli furtka bezpieczeństwa – wszystkie elementy konfiguracyjne systemu oprócz ID, posiadają dodatkowo GUID, który w przeciwieństwie do ID, jest identyczny na każdym ze środowisk. Zdecydowaną większość funkcjonalności da się osiągnąć z wykorzystaniem stałych, zmiennych oraz uzupełniając zakładki DEV/TEST/PROD. Istnieją jednak scenariusze w których mechanizmy dostarczone przez WEBCON BPS okazują się niewystarczające. Można wtedy posłużyć się GUIDem. Posługując się GUIDem należy pamiętać o tym, że:
    • GUID jest jednoznacznym oznaczeniem danego elementu konfiguracyjnego systemu (Proces, Obieg, Typ formularza, Atrybut itp.). Na każdym ze środowisk GUID danego komponentu jest identyczny
    • Na tabelach w bazie danych contentu BPS jest założony indeks na kolumnie z GUIDEM
    • Pomimo indeksu, wyszukiwanie po GUID jest wolniejsze niż po ID

Do czego można wykorzystać GUID:

  • Kolumny wyliczane na Web Partach SWE – podczas migracji procesu mamy pewność, że kolumna będzie zwracała poprawne dane
  • Raporty RS – posługując się GUIDem zamiast ID, można przygotować jeden raport, który będzie działał dla wszystkich środowisk. Należy jednak pamiętać, że raport będzie mniej wydajny w stosunku do raportów opartych na ID.

 

Eksport/Import procesu

Eksport procesu przenosi znaczną część konfiguracji. Ale co konkretnie?

  • Proces/aplikację oraz procesy/aplikacje powiązane – podczas eksportu środowisko jest weryfikowane jest pod kątem powiązań. W kreatorze można wybrać które aplikacje i procesy mają zostać wyeksportowane
  • Połączenia – połączenia są zawsze eksportowane i importowane. Krytyczne jest uzupełnienie dla nich wszystkich zakładek DEV/TEST/PROD
  • Spółki – przenoszone są wszystkie spółki
  • Źródła danych – przy imporcie istnieje możliwość odznaczenia nadpisania istniejących źródeł danych
  • Języki oraz tłumaczenia procesu – definicja języków oraz tłumaczenia są przenoszone automatycznie
  • Stałe globalne, Atrybuty globalne, Reguły globalne – Importowane są te globalne elementy konfiguracji, które są wykorzystywane w procesie. W przypadku gdy już się znajdują na środowisku docelowym przy imporcie, istnieje możliwość odznaczenia ich nadpisania.
  • Konfiguracja Web Partów – przenoszona jest konfiguracja Web Partów. Należy jednak pamiętać, aby struktura witryny była taka sama.
  • Komendy MailApproval
  • Raporty i widoki BPS Portal (wersja 2019) – istnieje możliwość odznaczenia konkretnych elementów warstwy prezentacji zarówno na etapie eksportu jak i importu aplikacji
  • Startery BPS Portal (wersja 2019) – istnieje możliwość odznaczenia konkretnych elementów warstwy prezentacji zarówno na etapie eksportu jak i importu aplikacji
  • Dashboardy BPS Portal (wersja 2019) – istnieje możliwość odznaczenia konkretnych elementów warstwy prezentacji zarówno na etapie eksportu jak i importu aplikacji

Proces został już przeniesiony. To wszystko? Nie – pewne elementy konfiguracji procesu należy przenieść ręcznie:

  • Grupy SharePoint – grupy SharePoint powinny zostać przeniesione przed importem aplikacji. W przypadku jeżeli grupy, używane w aplikacji nie znajdują się na środowisku docelowym, kreator nie zezwoli na import aplikacji.
  • Witryny SharePoint – jeżeli do warstwy prezentacji wykorzystywany jest SharePoint, lub jakakolwiek witryna jest wykorzystywana w aplikacji, na przykład do hostowania plików w bibliotekach SharePoint, lub istnieją słowniki oparte o listy SharePoint, to należy także przenieść witryny na środowisko docelowe. Należy pamiętać, aby nazwy i lokalizacje witryn, były tożsame z tymi na środowisku źródłowym.
  • HotFoldery i HotMailBoxy – należy utworzyć osobne dedykowane dla środowiska docelowego oraz dodatkowo je skonfigurować
  • Punkty rejestracji – każde środowisko posiada osobno definiowane punkty rejestracji
  • Projekty OCR AI – istnieje dedykowany mechanizm do przenoszenia sieci neuronowych OCR AI. Sieć eksportuje się na środowisku źródłowym i importuje na środowisku docelowym. Jeżeli sieć została douczona na środowisku źródłowym, nie musi być ponownie douczana na środowisku docelowym.
  • Konfiguracja serwisów – konfiguracja serwisu jest definiowana dla danego środowiska. Import procesu na nią nie wpływa
  • Widoki/Tabele/Procedury SQL – jeżeli proces korzysta z dodatkowych struktur danych SQL, które zostały utworzone na środowisku źródłowym, należy pamiętać, aby również je przenieść na środowisko docelowe
  • Szablony Word – od wersji 2017.1.3.33 wprowadzono możliwość używania tego samego pliku szablonu WORD niezależnie od typu środowiska DEV/TEST/PROD. Zmiana eliminuje konieczność definiowania trzech niezależnych szablonów WORD dedykowanych dla środowisk DEV, TEST oraz PROD. Jeżeli szablony WORD zostały przygotowane na starej wersji, należy pamiętać o tym, aby przygotować także szablony WORD dla środowiska docelowego. W przypadku wersji 2017.1.3.33 lub wyższej nie ma takiej potrzeby, jeżeli szablon został utworzony na takiej wersji, to można go użyć na wszystkich środowiskach.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *