Dotyczy wersji: 2022 R1 i powyżej; autor: Konrad Keppert
Wstęp
Do niedawna udostępnianie aplikacji pod dwoma niezależnymi adresami URL (np. Helpdesk i portal HR) wymagało utrzymywania dwóch osobnych środowisk. Niedogodność tę wyeliminowano jednak wraz z wprowadzeniem w wersji 2025 R2 funkcjonalności Hubu aplikacyjnego. W rezultacie posiadanie dwóch środowisk we wspomnianym celu stało się bezzasadne, a ich połączenie pożądane.
W niniejszym artykule opisano kroki, jakie należy podjąć, aby scalić ze sobą dwa środowiska WEBCON BPS, przenosząc w ten sposób aplikacje biznesowe wraz z utworzonymi w nich dokumentami, ich historią oraz załącznikami.
UWAGA: operację scalenia środowisk należy przeprowadzać wyłącznie w uzasadnionych przypadkach, wcześniej poprzedzając całą procedurę testami na środowiskach nieprodukcyjnych. Ryzyka zostały wymienione na końcu artykułu.
Procedura
Procedura zakłada, że jedno ze środowisk (dalej: środowisko źródłowe) zostanie przeniesione do innego, już działającego środowiska (dalej: środowisko docelowe).
-
Aktualizacja obu środowisk WEBCON BPS do tej samej wersji
Wszystkie bazy danych WEBCON BPS muszą znajdować się w dokładnie tej samej wersji [z dokładnością do numeru kompilacji (builda)], aby działały poprawnie na jednym środowisku po scaleniu. W związku z tym oba środowiska należy zaktualizować do tej samej wersji.
Dobrą praktyką jest zaktualizowanie środowiska do najnowszej możliwej wersji. Instalator można pobrać ze strony WEBCON Community.
-
Zadbanie o dostępność licencji
W wyniku scalenia środowisk przeniesione aplikacje będą działały w oparciu o paczkę licencji, która jest aktywowana na środowisku docelowym.
Należy sprawdzić, czy liczba licencji dostępnych na środowisku docelowym jest wystarczająca do obsługi wszystkich procesów, użytkowników i funkcjonalności. W przeciwnym wypadku konieczny jest kontakt z opiekunem handlowym i zapewnienie dostępności licencji na środowisku docelowym.
W odniesieniu do każdego rodzaju licencji:
- możliwy jest wzrost liczby licencjonowanych użytkowników Portalu, Designer Studio lub Designer Deska,
- możliwy jest wzrost liczby dostępów opartych na Single-Solution Access License,
- w przenoszonych aplikacjach mogą być wykorzystywane funkcjonalności nieobjęte licencją na środowisku docelowym (np. OCR Framework, SDK Framework, Advanced Analytics Framework, AI Tokens).
Szczegółowe informacje o dostępnych licencjach znajdują się w artykule Licencje WEBCON BPS – Blog techniczny WEBCON BPS.
-
Utworzenie pustej bazy zawartości na środowisku docelowym
Aby baza zawartości współpracowała ze środowiskiem WEBCON BPS, muszą być spełnione dwa warunki:
- w tabeli ContentDatabases (baza konfiguracyjna) musi znaleźć się odpowiedni wpis z nazwą takiej bazy zawartości,
- bazę należy powiązać z serwisem Workflow Service, aby ten ją obsługiwał.
Aby uprościć konfigurację, możliwe jest utworzenie nowej bazy zawartości na środowisku docelowym za pomocą Narzędzi do zarządzania systemem (instalator WEBCON BPS). Nazwa takiej bazy powinna odpowiadać nazwie, z jaką odtworzona zostanie baza źródłowa. W takim wypadku instalator sam zadba o spełnienie powyższych warunków. Dzięki temu po odtworzeniu bazy środowiska źródłowego system od razu rozpozna nową bazę zawartości.
Jeśli przenoszona jest więcej niż jedna baza zawartości, powyższą operację należy wykonać dla każdej z nich.
Nie ma potrzeby przygotowywania wcześniej struktury pod bazy załączników i archiwum – odwołania do nich znajdą się w odtworzonej bazie zawartości.
-
Utworzenie nowych grup i użytkowników BPS
Lista użytkowników zewnętrznych (BPS Users) oraz grup BPS przechowywana jest w bazie konfiguracyjnej. Zważywszy, że baza ta nie będzie odtwarzana, konieczne jest wcześniejsze utworzenie danych na środowisku docelowym.
Szczegółowe informacje na temat użytkowników i grup BPS można znaleźć we wpisie pomocy kontekstowej Użytkownicy i grupy BPS | WEBCON BPS.
UWAGA: jeśli scalane środowiska WEBCON BPS posiadają różne źródła synchronizacji, może być konieczna migracja uprawnień w przenoszonej bazie zawartości.
-
Odtworzenie baz źródłowych z kopii zapasowej (backupu)
Bazy zawartości, załączników oraz archiwum środowiska źródłowego należy odtworzyć na tej samej instancji SQL Server, na której znajdują się bazy środowiska docelowego.
Jeśli nazwy baz źródłowych są już zajęte na docelowej instancji (np. baza zawartości obu środowisk to „BPS_Content”), wówczas bazy trzeba odtworzyć pod nowymi nazwami.
Nazwa odtwarzanej bazy zawartości powinna być taka sama, jak nazwa nowej bazy utworzonej w punkcie 3 (należy ją nadpisać).
Bazy konfiguracyjnej nie wolno odtwarzać.
-
Nadanie uprawnień do odtworzonych baz
Do poprawnej pracy platformy WEBCON BPS wymagane jest, aby konto wskazane podczas instalacji jako Właściciel baz danych (dedykowany login SQL lub domenowe konto puli aplikacji) posiadało uprawnienia db_owner do wszystkich baz środowiska.
Po odtworzeniu baz źródłowych na docelowej instancji SQL Server należy nadać te uprawnienia odpowiedniemu kontu.
-
Zmiana nazw baz BPS
Odtworzenie baz źródłowych pod nowymi nazwami skutkuje utratą relacji między nimi. Relacje między bazami przechowywane są wewnątrz tabel.
Przykład: w bazie zawartości, w tabeli WFAttachmentDatabases, kolumna ADB_Name przechowuje nazwy baz załączników powiązanych z bieżącą bazą zawartości.
Lista wystąpień wszystkich odwołań do poszczególnych nazw baz znajduje się w artykule Zmiana nazwy baz danych WEBCON BPS – Blog techniczny WEBCON BPS. Wartości te trzeba zmodyfikować w odtworzonych bazach.
-
Dostosowanie infrastruktury sieciowej
Konfiguracja środowiska źródłowego WEBCON BPS mogła umożliwiać jego komunikację z systemami zewnętrznymi, np. serwer SMTP do wysyłki powiadomień, skrzynki Exchange, udziały sieciowe. Z poziomu docelowego serwera aplikacyjnego komunikacja taka może nie być możliwa. W takim przypadku należy wprowadzić zmiany, które umożliwią komunikowanie się z tymi systemami (albo zastąpić je innymi, dostępnymi).
-
Aktualizacja adresu Portalu w konfiguracji procesów
Przeniesione ze środowiska źródłowego aplikacje będą działały pod nowym adresem. W związku z tym, jeżeli adres taki jest wykorzystywany w konfiguracji procesów, np. w regułach biznesowych, formularza, akcjach/atrybutach typu Odsyłacz, należy go nadpisać.
-
Aktualizacja połączeń MSSQL i nazw baz w konfiguracji
Odtworzenie i zmiany nazw baz źródłowych w nowej instancji SQL Server (zob. pkt 5 i 7) wpływa na działanie ewentualnych dedykowanych połączeń MSSQL (Baza MSSQL | WEBCON BPS) do bazy zawartości, które w rezultacie przestają działać. W związku z tym należy je nadpisać, zmieniając adres, nazwę i/lub poświadczenia konta używanego do połączeń.
Jeśli w zapytaniach SQL (źródła danych, akcje Wykonaj procedurę SQL, reguły biznesowe zawierające funkcję SQL Command) nazwy baz zostały jawnie wprowadzone, należy je także nadpisać, o ile uległy zmianie.
-
Dostosowanie integracji z publicznym API Portalu BPS
Odtworzenie baz danych na nowym środowisku spowoduje, że integracje z publicznym API Portalu środowiska źródłowego przestaną działać. Nie tylko zmieni się adres URL Portalu, ale też utracone zostaną poświadczenia aplikacji API. Te przechowywane są w bazie konfiguracyjnej i nie zostaną przeniesione w trakcie migracji.
W związku z tym, KONIECZNE jest:
- zarejestrowanie nowych aplikacji API na środowisku docelowym,
- zaktualizowanie adresu Portalu i poświadczeń aplikacji API w zewnętrznych systemach, które integrują się z migrowanymi aplikacjami WEBCON BPS.
Więcej informacji o integracjach można znaleźć we wpisie pomocy kontekstowej Integracje | WEBCON BPS.
-
Pełna reindeksacja baz danych w Solr
Ostatnim krokiem jest dodanie zadania Indeksuj proces lub całą bazę danych do kolejki indeksowania Solr, aby dane instancji przeniesionych obiegów zostały dodane do bazy wyszukiwania Solr. Dzięki temu możliwe będzie ich wyszukanie w Portalu BPS, a także będą dostępne w raportach opartych o źródło SearchIndex.
Ten krok należy wykonać na samym końcu, po wcześniejszym upewnieniu się, że zmigrowane aplikacje działają poprawnie na docelowym środowisku, uwzględniając uprawnienia do procesów i poszczególnych instancji obiegów. Dane o uprawnieniach na poziomie instancji obiegu wysyłane są do bazy Solr.
Więcej informacji o kolejce indeksowania Solr: Kolejka indeksowania SOLR | WEBCON BPS.
Ryzyka
- Konieczność zaplanowania okna serwisowego na prace związane z dostosowaniem odtworzonych aplikacji na środowisku docelowym. W tym czasie praca na środowisku źródłowym powinna zostać wstrzymana, aby uniknąć rozbieżności lub strat danych.
- Możliwość wydłużenia czasu okna serwisowego w przypadku zaangażowania w proces dostawców zewnętrznych (np. integratorów wykorzystujących publiczne API Portalu BPS).
- Dodatkowe obciążenie środowiska docelowego:
- większa ilość danych w bazach SQL Server oraz Solr,
- większa liczba żądań do przetworzenia przez serwer aplikacyjny,
- większa liczba operacji do przetworzenia i kolejek do obsłużenia przez serwis Workflow Service.
W związku z tym należy zadbać o wcześniejsze przygotowanie przestrzeni dyskowej w docelowej infrastrukturze. Ponadto po zakończeniu procesu scalania należy monitorować usługi, aby w razie potrzeby zwiększyć zasoby serwerów lub rozszerzyć środowisko o dodatkowe komponenty WEBCON BPS (Expanding the WEBCON BPS installation).
- Niedobór licencji w paczce wykorzystywanej na środowisku docelowym.
- Odmienne kodowanie baz danych (collation) środowiska źródłowego i bazodanowego. Taka sytuacja może uniemożliwić poprawną pracę systemu i wymaga dostosowania kodowania baz źródłowych do kodowania środowiska docelowego.
Dobrą praktyką pozwalającą zminimalizować ryzyko jest wykonanie całej procedury na środowisku nieprodukcyjnym. Aby możliwie wiernie odwzorować warunki środowiska produkcyjnego, warto rozważyć wcześniejsze wyrównanie środowisk TEST/DEV w oparciu o bazy produkcyjne. Procedurę wyrównania środowisk opisano w artykule Instrukcja wyrównywania środowiska WEBCON 2023 StandAlone – Blog techniczny WEBCON BPS.
Należy również pamiętać o dostosowaniu planu konserwacji (Maintenance Plan) działającego na docelowej instancji SQL Server, tak aby uwzględniał on utrzymanie indeksów i statystyk w odtworzonych bazach. Procedurę utworzenia takiego planu opisano w artykule # SQL Maintenance – Dedykowany mechanizm utrzymania dużych baz danych BPS: indeksów i statystyk – Blog techniczny WEBCON BPS.
Podsumowanie
W artykule omówiono ogólną procedurę scalania dwóch środowisk, tj. przeniesienia aplikacji biznesowych (wraz z utworzonymi w nich danymi) z jednego środowiska na inne, zakładając, że oba z nich działają produkcyjnie.
W artykule wspomniano też o potencjalnych ryzykach, które warto mieć na względzie przed rozpoczęciem migracji. Najlepszą praktyką na zminimalizowanie ryzyka jest wcześniejsze przejście tej procedury z wykorzystaniem środowisk nieprodukcyjnych.
W przypadku bardziej niestandardowych scenariuszy nieuwzględnionych w tym artykule może być konieczny kontakt z Działem Wsparcia Technicznego WEBCON dostępnym pod adresem WEBCON Support.