Dotyczy wersji 2020.1.3.x; autor: Mateusz Syrek
1. Migracja WEBCON BPS do najnowszej opublikowanej wersji
Przed przystąpieniem do prac należy zaktualizować WEBCON BPS do najnowszej wersji. Jeśli obecna wersja BPS to 2019 lub niższa, należy wykonać migrację do BPS 2020.
W przypadku migracji z wersji BPS 2017 i starszych można wspomóc się artykułem WEBCON BPS 2019 – procedura upgrade ze starszych wersji Migracja do wersji 2020 jest analogiczna.
W przypadku migracji SDK zachęcam do zapoznania się z artykułem Dokument migracyjny SDK 2020.1
Wykonanie migracji WEBCON BPS można również zlecić na portalu https://support.webcon.com
2. Migracja uprawnień
Bardzo ważnym punktem działania aplikacji WEBCON BPS są uprawnienia. Bez uprawnień nie da się pracować. Jeśli uprawnienia w procesach oparte są na grupach SharePoint, to ważny jest dobry projekt migracji grup na jedno z wybranych rozwiązań (zależny od infrastruktury):
- grupy Active Directory
- grupy Azure Active Directory
- grupy BPS
Mając poprawnie zamienione grupy SharePoint na jedno z powyższych rozwiązań można pomyślnie rozpocząć kolejny etap przejścia do środowiska BPS StandAlone.
3. Zmiana interfejsu BPS Classic na BPS Modern
- Zapoznanie się z listą funkcjonalności niedostępnych w WEBCON BPS Portal
- Przygotowanie Procesów do Aplikacji
- Usunięcie wszystkich powiązań do SharePoint poprzez rekonfigurację aplikacji i włączenie widoku formularza BPS Modern:
- Zmianie JavaScript na reguły formularza lub JavaScript składający się z dostępnych funkcji edytora z zachowaniem logiki formularza Modern.
- Zmianie źródeł danych typu listy/biblioteki SharePoint na procesy słownikowe lub tabele SQL.
- Zmianie SOAP WebService na REST WebService. Dotyczy również integracji z BPS, jeśli wywoływany był SOAP to należy zmienić na REST.
- Zmianie w SDK.
Wszelkie informacje dotyczące konfiguracji WEBCON BPS Portal są w bazie wiedzy https://kb.webcon.pl/, która jest sukcesywnie powiększana.
Testy wszystkich aplikacji w celu weryfikacji czy po zmianie konfiguracji została zachowana logika i działanie aplikacji.
Zmiana interfejsu z BPS Classic na BPS Modern i zerwanie wszystkich odwołań do SharePoint’a spowoduje, że po przeniesieniu baz do instalacji StandAlone, aplikacje w dalszym ciągu będą działać. Dodatkowo podczas zmiany można zrobić refaktoring wdrożonych aplikacji poprzez uproszczenie konfiguracji czy uzupełnienie dokumentacji procesowej.
4. Przygotowanie nowych serwerów pod BPS StandAlone (nie zalecamy migracji inplace)
Zlikwiduje to m.in. ryzyko błędu spowodowane deinstalacją SharePoint’a.
5. Wyłączenie Synchronizacji użytkowników SharePoint
Wyłączenie synchronizacji przed wykonaniem backupów jest bardzo ważne, ponieważ po przywróceniu baz na nowym środowisku nie ma prostego sposobu na zmianę.
Konfiguracja znajduje się w narzędziach do zarządzania systemem w konfiguracji listy użytkowników.
Nie wyłączenie skutkuje tym, że synchronizacja listy użytkowników BPS będzie wołać witrynę SharePoint. Do czasu gdy będzie aktywna synchronizacja powinna się wykonać, natomiast po zlikwidowaniu SharePoint’a zakończy się niepowodzeniem.
6. Instalacja WEBCON BPS StandAlone na nowych serwerach
Instalowana wersja musi być taka sama co w instalacji w SharePoint, a nowe bazy muszą mieć takie same nazwy jak w dotychczasowej instalacji.
Nowa instalacja StandAlone i wygenerowanie czystych baz spowoduje, że BPS Portal i BPS Search Server zostaną poprawnie zainstalowane. Instalacja na przywróconych może spowodować, że niemożliwe będzie korzystanie z portalu.
Dodatkowo przygotowanie nowych serwerów i przeniesienie na nich BPS’a zminimalizuje m.in. ryzyko błędów spowodowanych instalacją SharePoint’a i innych aplikacji.
Po zakończonej instalacji należy zweryfikować działanie portalu i search serwera.
Należy dodać certyfikat SSL jeśli BPS Portal działał wcześniej po https.
7. Restore baz BPS_Content i BPS_Content_Att w miejscu nowych baz BPS StandAlone i nadanie uprawnień db_owner kontu serwisu i puli aplikacji
8. Restore bazy BPS_Config i nadanie uprawnień db_owner kontu serwisu i puli aplikacji
Po tej operacji należy:
- Zmienić typ instalacji na StandAlone
Typ instalacji należy zmienić poprzez update tabeli GlobalParameters
update GlobalParameters set PRM_Value = 2 where PRM_Name = 'InstallationType'
- Zmienić adres portalu na adres bez wirtualnego katalogu WEBCONBPS, ponieważ takiego nie ma instalacji StandAlone
- Zmienić adres IP search serwera
Adres portalu i IP search serwera należy zmienić w narzędziach zarządzania systemem w instalatorze WEBCON BPS.
Zmiana adresu URL portalu jest o tyle ważna, że wstawiany jest m.in. do powiadomień e-mail do linków do elementów.
Przywrócenie bazy BPS_Config jest szczególnie ważne jeśli WEBCON BPS zintegrowany jest z innymi aplikacjami, w których wykorzystywane jest API Secret Key.
Do czasu zakończenia wszystkich prac, można dodać wpis w hosts w celu weryfikacji wprowadzanych zmian.
9. Przeniesienie indeksu SOLR
Jeśli WEBCON BPS Search Server zainstalowany był na serwerze aplikacyjnym to, konieczne jest jego przeniesienie na nowy serwer oraz zmiana konfiguracji połączenia.
Przeniesienie indeksu SOLR należy wykonać po wcześniejszym zatrzymaniu WEBCON BPS Search Service na serwerach aplikacyjnych. Polega na skopiowaniu całego katalogu WEBCON BPS Search Server ("\Program Files\WEBCON\WEBCON BPS Search Server") bezpośrednio na nowy serwer.
Dzięki temu, że przeniesienie zostanie wykonane przy zatrzymanych serwisach spowoduje, że poprawnie zostanie przeniesiony cały indeks razem z aktywnościami użytkowników.
10. Zmiana źródła danych BPS Portal
Polega na zmianie w pliku appsettings.user.json (domyślnie jest w katalogu "C:\Program Files (x86)\WEBCON\WEBCON BPS Portal") źródła danych. W ConfigConnection i LogsConnections należy podać nazwę nowej instancji SQL.
11. Reset licencji WEBCON BPS
Należy dezaktywować serwis WEBCON BPS na starym środowisku.
Następnie, za pomocą narzędzia Resource Kit należy zmienić typ bazy danych na inny niż aktualny, zapisać zmianę, zresetować pule aplikacji i serwis WEBCON BPS. Następnie w analogiczny sposób należy przywrócić poprzedni typ bazy danych.
Po tej zmianie serwis zostanie uruchomiony jako DEMO i będzie możliwa jego aktywacja.
Reset licencji WEBCON BPS jest ważny, ponieważ bez tego nie uda się uruchomić serwisu WebCon Workflow Service.
Po uruchomieniu serwisu i zalogowaniu się do Designer Studio należy zweryfikować Serwisy w Konfiguracja Serwisów w Konfiguracji Systemu.
Jeśli będą 2 serwisy (stary i nowy) należy przepiąć role na nowy serwis, a stary należy usunąć.
12. Zmiana serwera w połączeniach źródeł danych oraz HotFolderach i HotMailBoxach w Designer Studio
Jeśli w konfiguracji systemu są skonfigurowane połączenia do starej instancji SQL, to należy zmienić ich konfigurację na nową instancję.
Jeśli jakieś systemy, np. ERP są zintegrowanie z WEBCON BPS i bezpośrednio odwołują się do instancji SQL to należy zmienić ich konfigurację na nową instancję SQL.
W konfiguracji HotFolder i HotMailBox należy zmienić serwis BPS na nowy.
Po zakończeniu zmian należy jeszcze wczytać ponownie konfigurację serwisu i zrestartować BPS Portal poprzez restart IIS.
13. Testy wszystkich aplikacji oraz zmiany w konfiguracji konieczne do działania jako BPS StandAlone:
- Zmiana wszystkich odwołań w konfiguracji procesów, akcji, szablonów maili na nowy adres portalu
W tym miejscu najlepszym rozwiązaniem będzie zastąpienie adresu URL stałą globalną lub procesu. Dzięki temu konfiguracja będzie w jednym miejscu BPS’a co w przyszłości ułatwi zmianę.
- Opracowanie polityki przekierowań z starego adresu instalacji w SharePoint (domena/WEBCONBPS) na adres w instalacji Stand Alone (domena/).
Dotyczy to również integracji WEBCON BPS z innymi systemami.
Z pomocą może przyjść moduł serwera IIS o nazwie URL Rewrite. Umożliwia tworzenie zaawansowanych reguł, które przekierują użytkownika na nowy adres portalu. Reguły tworzone są przez użycie wyrażeń regularnych.
14. Zmiana wpisu w DNS
Po zakończeniu wszystkich kroków i zweryfikowaniu należy zmienić wpis w DNS i przekierować na nowe środowisko WEBCON BPS StandAlone.
