Konteneryzacja WEBCON – wersja 2026

Dotyczy wersji 2026.1.x i powyżej, autor: Jakub Kawa, Tomasz Błach

Jest to zaktualizowana wersja artykułu: https://kb.webcon.pl/konteneryzacja-webcon-bps/

Wprowadzenie

Wraz z pojawieniem się wersji 2023.1.x systemu wprowadzono możliwość konteneryzacji komponentów WEBCON. Od wersji 2026.1.x model uruchamiania kontenerów został uproszczony – zamiast osobnych obrazów dla Portalu i Serwisu udostępniany jest jeden obraz bootstrappera, który w zależności od przekazanej zmiennej środowiskowej STARTUP_MODE startuje jako WEBCON Portal albo jako WEBCON Workflow Service. Search Server (Solr) pozostaje osobnym obrazem, ponieważ jest zbudowany na systemie Linux.

Konteneryzacja stanowi alternatywę dla standardowej instalacji komponentów WEBCON i znajduje szczególnie zastosowanie w przypadku korzystania z usług chmurowych, znacznie ułatwiając instalację systemu w takim środowisku.

Niniejszy artykuł zawiera instrukcję krok po kroku przygotowania instalacji systemu WEBCON, którego podstawowe komponenty są uruchomione w niezależnych kontenerach (Portal i Serwis w osobnych kontenerach).

Uwaga: uruchomienie składowych WEBCON w kontenerach jest możliwe wyłącznie dla użytkowników posiadających licencje subskrypcyjne. Uruchomienie następnego kontenera będzie wiązało się z wykorzystaniem kolejnej licencji. Jeśli kontener został poprawnie wyłączony, to licencja jest zwalniana. Raport dotyczący wykorzystywanych licencji jest dostępny w WEBCON Designer Studio.

Ponadto wymagany będzie zewnętrzny dostawca uwierzytelnienia, np. Microsoft Entra ID lub OpenID Connect, gdyż uwierzytelnienie Windows nie działa poprawnie w kontenerach.

Wybór platformy do konteneryzacji

Dzięki zastosowaniu obrazów Docker instalacja i uruchomienie WEBCON w kontenerach są możliwe na wielu platformach (większość z platform do konteneryzacji wykorzystuje obrazy Docker).

W tym artykule kontenery będą tworzone i uruchamiane za pomocą platformy Docker Desktop. Niezbędne jest wcześniejsze zainstalowanie tego programu oraz uruchomienie wszystkich kroków instalacji na tym samym komputerze.

Postępując analogicznie jak w opisanym przykładzie, WEBCON można zainstalować w kontenerach w dowolnej platformie do konteneryzacji (np. Azure Container Instances lub Azure Kubernetes Service).

Jeden obraz – tryby uruchomienia

Portal i Workflow Service są uruchamiane z tego samego obrazu webconbps/bootstrapper. Rola kontenera wynika wyłącznie ze zmiennej środowiskowej STARTUP_MODE:

Przy starcie kontenera skrypt wejściowy odczytuje STARTUP_MODE, ustawia flagi enabled w plikach konfiguracyjnych modułów i uruchamia proces WebCon.WorkFlow.Bootstrapper.exe. Nie ma potrzeby ręcznej edycji plików konfiguracyjnych w obrazie.

Lokalizacja obrazów

Obrazy są publikowane w rejestrze Docker Hub:

• bootstrapper (Portal i Workflow Service): https://hub.docker.com/r/webconbps/bootstrapper
• Search Server (Solr): https://hub.docker.com/r/webconbps/search

Lista dostępnych wersji znajduje się w zakładce Tags w obu repozytoriach.

Tag obrazu

Tag obrazu bootstrappera składa się z numeru wersji WEBCON oraz nazwy obrazu bazowego systemu operacyjnego:

webconbps/bootstrapper:-windowsservercore-ltsc2022
W tym artykule wykorzystywana jest wersja 2026.2.2.121, czyli obraz:

webconbps/bootstrapper:2026.2.2.121-windowsservercore-ltsc2022
Obraz bootstrappera jest zbudowany na bazie mcr.microsoft.com/dotnet/aspnet:10.0-windowsservercore-ltsc2022, dlatego wymaga uruchomienia Docker Desktop w trybie kontenerów Windows z izolacją procesową (–isolation=process). Obraz Search Server jest obrazem linuxowym, więc jest tworzony przy przełączonym trybie kontenerów Linux.

Plan instalacji

Podczas instalacji WEBCON w kontenerach tylko baza danych jest tworzona z wykorzystaniem instalatora. Pozostałe składowe systemu muszą być pobrane jako obrazy Docker i uruchomione w kontenerach za pomocą odpowiednich komend.

Z tego względu dobrą praktyką jest wcześniejsze zaplanowanie środowiska z wyszczególnieniem komponentów systemu, ich adresów sieciowych oraz komunikacji między nimi.

Poniższy diagram pokazuje instalację opisaną w tym artykule wraz z adresami poszczególnych serwisów.

W tym artykule posługujemy się programem Docker Desktop. Wszystkie podstawowe składowe WEBCON mogą być w nim zainstalowane. Jedynie bazy danych systemu muszą być utworzone na istniejącej instancji Microsoft SQL Server dostępnej z komputera, na którym uruchomiono WEBCON w kontenerach.

Kroki instalacji:

1. Utworzenie kontenera WEBCON Search Server i inicjalizacja indeksów wyszukiwania Solr.
2. Kreacja baz danych SQL z wykorzystaniem instalatora WEBCON.
3. Utworzenie sieci Docker oraz plików ze zmiennymi środowiskowymi.
4. Utworzenie kontenera WEBCON Workflow Service.
5. Utworzenie kontenera WEBCON Portal.
6. Utworzenie kontenera z reverse proxy.
7. Uruchomienie Designer Studio i aktywacja licencji.

Przechowywanie danych

Platforma wykorzystuje dwa rodzaje baz danych. Wszystkie dane wprowadzone przez użytkowników oraz dane konfiguracyjne są przechowywane w relacyjnych bazach danych Microsoft SQL Server. Dodatkowo duża część tych danych zasila indeksy wyszukiwania Solr obsługiwane przez Search Server.

Utworzenie kontenera Search Server

1) Obraz kontenera Search Server jest zbudowany w oparciu o oficjalny obraz platformy Solr w wersji dla systemu operacyjnego Linux. W związku z tym należy przełączyć Docker Desktop w tryb obsługi kontenerów linuxowych – kliknij prawym przyciskiem myszy na ikonę programu w zasobniku systemowym i z rozwijanej listy wybierz następującą opcję:

2) Po chwili zobaczysz ostrzeżenie jak poniżej. Kliknij Switch, aby możliwa była obsługa kontenerów Linux.

3) Kontener jest co do zasady obiektem nietrwałym. W związku z tym, należy dopilnować, aby dane nie zostały utracone po wyłączeniu kontenera. W programie Docker Desktop odpowiada za to mechanizm Docker Volume, dzięki któremu możliwe jest tworzenie dedykowanych woluminów odpowiedzialnych za przechowywanie danych generowanych i wykorzystywanych przez wspomniany program.

Utwórz nowy wolumin na potrzeby Solr o nazwie solr-bps – otwórz konsolę CMD i wpisz polecenie:

docker volume create solr-bps

4) Podgląd utworzonego woluminu jest możliwy w Docker Desktop w zakładce Volumes:

5) Aby uruchomić kontener, wpisz w konsoli CMD polecenie:

docker run -d --name bps_search -p 8983:8983 -e SOLR_HEAP=2g --mount source=solr-bps,target=/var/solr --add-host host.docker.internal:host-gateway --entrypoint /bin/sh webconbps/search:2026.2.2.121 -c "/opt/bps-solr/scripts/run-precreate-cores.sh"

gdzie:

• -d – uruchomienie kontenera w tle,
• --name bps_search – nazwa kontenera,
• -p 8983:8983 – mapowanie portu hosta 8983 na port kontenera 8983 (domyślny port, na którym jest uruchomiony Solr),
• -e SOLR_HEAP=2g – ograniczenie pamięci przydzielonej procesowi Solr. Można w ten sam sposób przekazać dodatkowe zmienne środowiskowe Solr,
• --mount source=solr-bps,target=/var/solr – mapowanie utworzonego woluminu do katalogu w kontenerze, gdzie będą przechowywane pliki z indeksami wyszukiwania, konfiguracja uprawnień oraz pliki logów,
• --add-host host.docker.internal:host-gateway – umożliwia kontenerowi odwołanie się do usług działających na maszynie hosta pod nazwą host.docker.internal,
• webconbps/search:2026.2.2.121 – obraz, na podstawie którego uruchamiany jest kontener; tutaj należy zadbać o wybór właściwej wersji odpowiadającej wersji WEBCON BPS,
• --entrypoint /bin/sh wraz z argumentem -c "/opt/bps-solr/scripts/run-precreate-cores.sh" – ścieżka do skryptu inicjalizującego struktury indeksów Solr. Skrypt ten musi być przekazany przy pierwszym uruchomieniu kontenera, aby indeksy mogły zostać utworzone. Można go przekazywać zawsze, gdyż przy ponownym uruchomieniu kontenera skrypt wykrywa istniejące indeksy i pomija ich ponowne tworzenie.

6) Podgląd uruchomionego kontenera jest możliwy w zakładce Containers.

7) Serwis Solr będzie dostępny na tym komputerze pod adresem: http://nbdemo:8983/solr (gdzie nbdemo to nazwa komputera z Docker Desktop).

Kreacja baz danych SQL

1) Pobierz instalator WEBCON w odpowiedniej wersji (w przypadku tego artykułu jest to wersja 2026.2.2.121).

2) Uruchom instalator i po zaakceptowaniu licencji wybierz tryb instalacji Nowa instalacja WEBCON.

3) Następnie wybierz typ środowiska Standalone. W kroku Weryfikacja systemu wybierz opcję Dalej, a w kroku Wybór komponentów opcję Pomiń.

Wszystkie komponenty będą uruchamiane z obrazów Docker, a instalator zostanie użyty wyłącznie do utworzenia i skonfigurowania bazy danych.

4) W kolejnych krokach instalatora: Parametry kreacji baz danych, Kreacja bazy konfiguracyjnej, Kreacja bazy procesów, Kreacja bazy załączników, postępuj analogicznie jak przy standardowej instalacji WEBCON.

Zalecane jest skopiowanie nazwy bazy konfiguracyjnej, gdyż będzie ona potrzebna przy uruchamianiu kontenerów Portalu i Serwisu.

5) W kroku Konfiguracja adresu Portalu należy wprowadzić adres, pod którym zgodnie z planem infrastruktury będzie udostępniony BPS Portal. W opisywanym przykładzie WEBCON BPS Portal będzie dostępny przez reverse proxy pod zewnętrznym adresem: https://nbdemo.webcon.pl:48440

Wpisz tutaj adres Portalu zgodnie z obowiązującym planem infrastruktury i wybierz Dalej.

6) W kroku Konto administracyjne wpisz i zapamiętaj hasło dla użytkownika administracyjnego, który po zalogowaniu do Designer Studio będzie mógł dokończyć konfigurację instalacji WEBCON BPS.

7) Ostatni krok to Adres Search Server. W tym kroku instalator musi wykonać dwie czynności: zmienić domyślne hasła użytkowników w Search Server oraz zarejestrować tę instancję Search Server w bazie konfiguracyjnej.

W tym celu w polu Podłącz wybierz opcję Domyślna instalacja Search Server w kontenerze. Następnie wpisz adres kontenera z Search Server. W omawianym przykładzie jest to adres: http://nbdemo:8983/solr/.

Dodatkowo podaj hasła, jakie mają być ustawione dla użytkowników Solr i WEBCON_BPS.

Uwaga: użytkownik Solr jest administratorem tej instancji Solr. Zadbaj o to, by nie zgubić jego hasła, ponieważ nie jest ono nigdzie dodatkowo zapisywane.

Podczas wykonywania tego kroku uruchomiony musi być kontener z Search Server, gdyż instalator połączy się z nim w celu zmiany haseł i weryfikacji poprawności zawartości kontenera.

Sieć Docker i pliki ze zmiennymi środowiskowymi

Kontenery Portalu, Serwisu i reverse proxy komunikują się między sobą po nazwach hostów, dlatego muszą pracować we wspólnej sieci Docker. Utwórz ją przed uruchomieniem kontenerów:

docker network create webcon_net

W dalszych krokach kontenery otrzymują następujące nazwy hostów w tej sieci: Portal – webcon, Serwis – webcon_service, reverse proxy – caddy_proxy.

Konfiguracja kontenerów jest przekazywana w plikach ze zmiennymi środowiskowymi. Są to dokładnie te same wartości, które można ustawić przy pomocy pliku appsettings.json w standardowej instalacji WEBCON. Przygotuj trzy pliki w bieżącym folderze:

• user.env – wspólny plik z danymi połączenia do baz danych, wykorzystywany zarówno przez Serwis, jak i Portal. Podmień <SERVER>, <DBNAME>, <USER> i <PASS> na własne wartości; jako <DBNAME> podaj nazwę bazy konfiguracyjnej skopiowaną podczas kreacji baz:

ConnectionStrings__ConfigDb=Server=<SERVER>;Database=<DBNAME>;User ID=<USER>;Password=<PASS>;Trust Server Certificate=True;
ConnectionStrings__LogsDb=Server=<SERVER>;Database=<DBNAME>;User ID=<USER>;Password=<PASS>;Trust Server Certificate=True;
Serilog__MinimumLevel__Default='Information'

Należy pamiętać, że kontener nie znajduje się w domenie, w związku z czym konieczne jest zdefiniowanie nazwy użytkownika i hasła do bazy danych jako alternatywy dla częściej stosowanego logowania domenowego.

• service_env.env – zmienne kontenera Workflow Service:

STARTUP_MODE=service

ExternalWebService__Port=58002
ExternalWebService__LicenseServicePort=8002
Kestrel__Endpoints__Http__Url=http://*:48442
modulesOrchestration__webconWorkflowServicePort=48443
modulesOrchestration__serviceModuleRunnerPort=48450

DOTNET_gcServer=1
DOTNET_GCDynamicAdaptationMode=1
ASPNETCORE_FORWARDEDHEADERS_ENABLED=True

Service__Config__InitServiceRoles__BasicFeatures=true
Service__Config__InitServiceRoles__LicenseService=true

• portal_env.env – zmienne kontenera Portalu:

STARTUP_MODE=portal
Kestrel__Endpoints__Http__Url=http://*:48441

DOTNET_gcServer=1
DOTNET_GCDynamicAdaptationMode=1
DataProtection__ApplicationName='bps_container'
ASPNETCORE_FORWARDEDHEADERS_ENABLED=true

Znaczenie najważniejszych zmiennych:

• STARTUP_MODE – rola, w jakiej ma wystartować kontener (portal lub service),
• ConnectionStrings__ConfigDb, ConnectionStrings__LogsDb – connection stringi do bazy konfiguracyjnej i bazy logów,
• Kestrel__Endpoints__Http__Url – adres i port, na którym nasłuchuje serwer HTTP w kontenerze (48441 dla Portalu, 48442 dla Serwisu),
• modulesOrchestration__webconWorkflowServicePort – port, na którym Serwis udostępnia usługę workflow,
• modulesOrchestration__serviceModuleRunnerPort – port komunikacji z modułami uruchamianymi przez Serwis,
• ExternalWebService__Port, ExternalWebService__LicenseServicePort – porty usługi zewnętrznej oraz usługi licencji,
• ExternalWebService__Host – nazwa hosta, pod którą Serwis jest widoczny dla pozostałych komponentów (przekazywana bezpośrednio w komendzie docker run),
• DataProtection__ApplicationName – nazwa aplikacji dla mechanizmu ASP.NET Data Protection; wszystkie kontenery Portalu tej instalacji muszą mieć tę samą wartość,
• ASPNETCORE_FORWARDEDHEADERS_ENABLED – obsługa nagłówków przekazywanych przez reverse proxy,
• Serilog__MinimumLevel__Default – poziom logowania.

Jeżeli kontenery muszą rozwiązywać nazwy hostów z sieci firmowej (np. nazwę serwera SQL), należy dodać do komend docker run parametr --dns <adres serwera DNS>.

Utworzenie kontenera Workflow Service

1) Obrazy kontenerów Workflow Service oraz BPS Portal są zbudowane w oparciu o obrazy Docker systemu operacyjnego Windows Server Core. W związku z tym, analogicznie jak poprzednio, należy przełączyć Docker Desktop w tryb obsługi kontenerów typu Windows.

2) Upewnij się, że pliki service_env.env oraz user.env są przygotowane zgodnie z poprzednią sekcją i znajdują się w bieżącym folderze.

3) Uruchom kontener wprowadzając w CMD polecenie:

docker run -d --name webcon_service_container --hostname webcon_service --network webcon_net --isolation=process -p 48442:48442 -p 48443:48443 -p 48450:48450 -e ExternalWebService__Host=webcon_service -e ServiceName=webcon_service -e Hostname=webcon_service --env-file service_env.env --env-file user.env webconbps/bootstrapper:2026.2.2.121-windowsservercore-ltsc2022

gdzie:

• -d – uruchomienie kontenera w tle,
• --name webcon_service_container – nazwa kontenera,
• --hostname webcon_service – nazwa hosta kontenera; pod tą nazwą Serwis jest widoczny dla Portalu w sieci webcon_net
• --network webcon_net – podłączenie kontenera do utworzonej wcześniej sieci,
• --isolation=process – tryb izolacji procesowej wymagany dla kontenerów Windows Server Core,
• -p 48442:48442 -p 48443:48443 -p 48450:48450 – mapowanie portów hosta na odpowiednie porty kontenera (numery portów muszą odpowiadać tym ustawionym w pliku service_env.env),
• -e ExternalWebService__Host=webcon_service, -e ServiceName=webcon_service, -e Hostname=webcon_service – nazwa hosta i nazwa serwisu rejestrowane w bazie konfiguracyjnej; muszą odpowiadać wartości parametru --hostname,
• --env-file service_env.env --env-file user.env – kontener zostanie uruchomiony ze zmiennymi środowiskowymi zdefiniowanymi w tych plikach,
• webconbps/bootstrapper:2026.2.2.121-windowsservercore-ltsc2022 – obraz, na podstawie którego uruchamiany jest kontener; tutaj należy zadbać o wybór właściwej wersji odpowiadającej wersji WEBCON.

4) Poprawność uruchomienia Serwisu można sprawdzić, otwierając adres http://localhost:48442/health. Podgląd uruchomionego kontenera jest możliwy w zakładce Containers, a logi startowe (w tym wybrany tryb STARTUP_MODE) komendą:

docker logs webcon_service_container

5) Porty 58002 (ExternalWebService__Port) oraz 8002 (ExternalWebService__LicenseServicePort) nie są w tej konfiguracji publikowane na hoście – wewnątrz sieci webcon_net Portal komunikuje się z Serwisem bezpośrednio. Jeżeli z tych usług mają korzystać klienci spoza sieci kontenerów, dodaj do komendy docker run parametry -p 58002:58002 -p 8002:8002.

Uruchomienie kontenera BPS Portal

1) Kontener Portalu należy uruchomić po kontenerze Serwisu.

2) Analogicznie jak dla Serwisu, przed uruchomieniem kontenera przygotuj pliki portal_env.env oraz user.env (ten sam plik user.env, który jest wykorzystywany przez Serwis).

3) Portal korzysta z katalogu hotfolder do przetwarzania plików umieszczanych przez użytkowników. Aby dane nie zostały utracone po wyłączeniu kontenera, utwórz dla niego wolumin:

docker volume create hotfolder

4) Uruchom kontener z wykorzystaniem polecenia:

docker run -d --name webcon_portal_container --hostname webcon --network webcon_net --isolation=process -p 48441:48441 -v hotfolder:C:/hotfolder -e ServiceName=webcon -e Hostname=webcon --env-file portal_env.env --env-file user.env webconbps/bootstrapper:2026.2.2.121-windowsservercore-ltsc2022

gdzie:

• -d – uruchomienie kontenera w tle,
• --name webcon_portal_container – nazwa kontenera,
• --hostname webcon – nazwa hosta kontenera; ta nazwa będzie użyta w konfiguracji reverse proxy,
• --network webcon_net – podłączenie kontenera do tej samej sieci, w której pracuje Serwis,
• --isolation=process – tryb izolacji procesowej wymagany dla kontenerów Windows Server Core,
• -p 48441:48441 – mapowanie portu hosta 48441 na port kontenera 48441. Ten port musi odpowiadać portowi ustawionemu w zmiennej Kestrel__Endpoints__Http__Url w pliku portal_env.env,
• -v hotfolder:C:/hotfolder – mapowanie woluminu na katalog hotfolder w kontenerze,
• -e ServiceName=webcon -e Hostname=webcon – nazwa hosta rejestrowana w bazie konfiguracyjnej,
• --env-file portal_env.env --env-file user.env – kontener zostanie uruchomiony ze zmiennymi środowiskowymi zdefiniowanymi w tych plikach,
• webconbps/bootstrapper:2026.2.2.121-windowsservercore-ltsc2022 – obraz, na podstawie którego uruchamiany jest kontener; jest to ten sam obraz co dla Serwisu, o roli kontenera decyduje wyłącznie zmienna STARTUP_MODE.

Przygotowanie kontenera z reverse proxy dla Portalu

Uruchomienie Portalu w kontenerze często ma na celu łatwe skalowanie aplikacji internetowej przez uruchamianie kolejnych kontenerów. W takiej konfiguracji kontener Portalu nie jest zazwyczaj udostępniony bezpośrednio dla użytkowników, lecz wymaga wykorzystania load balancera.

W opisywanej testowej instalacji taka konfiguracja zostanie zasymulowana poprzez utworzenie kontenera z serwerem reverse proxy dla Portalu. Może to być dowolny serwer z taką funkcjonalnością. W tym artykule wykorzystywany jest serwer Caddy działający w oparciu o obraz systemu Windows.

Kontener serwera Caddy można przygotować w następujący sposób:

1) Utwórz plik konfiguracyjny serwera Caddy o nazwie Caddyfile o poniższej zawartości. Pamiętaj, aby podmienić adres localhost na adres własnego środowiska, natomiast nazwa hosta i port, na który wskazuje reverse proxy, muszą odpowiadać utworzonemu wcześniej kontenerowi Portalu (--hostname webcon, port 48441):

{
    https_port 48440
}

https://localhost:48440 {
    header {
        X-Content-Type-Options nosniff
        X-Frame-Options SAMEORIGIN
        -Server
    }

    reverse_proxy {
        to webcon:48441
        stream_timeout 24h
        stream_close_delay 5m
    }

    tls C:\\etc\caddy\cert.pem C:\\etc\caddy\key.pem
}

Parametry stream_timeout i stream_close_delay są istotne dla poprawnej obsługi długotrwałych połączeń Portalu (np. powiadomień). Nagłówki X-Content-Type-Options i X-Frame-Options podnoszą bezpieczeństwo aplikacji, a -Server usuwa nagłówek identyfikujący serwer.

2) Reverse proxy wykorzystuje protokół HTTPS. Aby adres obsługiwany przez reverse proxy był zaufany, należy użyć zaufanego certyfikatu dla adresu komputera testowego. W tym celu umieść pliki cert.pem i key.pem z certyfikatem w bieżącym folderze.

Utwórz plik Dockerfile z obrazem Caddy o zawartości:

FROM caddy:windowsservercore-ltsc2022

COPY Caddyfile /etc/caddy/Caddyfile
COPY cert.pem /etc/caddy/cert.pem
COPY key.pem /etc/caddy/key.pem

3) Następnie zbuduj obraz Caddy, wykorzystując do tego celu komendę:

docker build -t caddy/reverse.proxy .

4) Uruchom kontener z wykorzystaniem polecenia:

docker run -d --name caddy_proxy --hostname caddy_proxy --network webcon_net --isolation=process -p 48440:48440 caddy/reverse.proxy

Kontener reverse proxy musi być podłączony do tej samej sieci webcon_net, w której pracuje Portal – tylko wtedy nazwa webcon z pliku Caddyfile zostanie poprawnie rozwiązana.

Konfiguracja środowiska

Architektura skonfigurowanego rozwiązania opiera się na następujących składowych:

• Reverse proxy (Caddy) – https://nbdemo.webcon.pl:48440/
• Portal – http://nbdemo.webcon.pl:48441/
• Workflow Service – http://nbdemo.webcon.pl:48442/
• Search Server (Solr) – http://nbdemo:8983/solr

Wykorzystywane porty:

W związku z powyższym, aby uruchomić Portal w kontenerze, należy otworzyć link: https://nbdemo.webcon.pl:48440/.

Poniżej lista kroków, jakie należy wykonać w celu dokończenia konfiguracji zainstalowanej platformy WEBCON. Są to kroki konfiguracyjne wymagane dla każdej instalacji, nie tylko tej wykonanej w kontenerach Docker.

1. Zaloguj się do Portalu WEBCON, wprowadzając hasło użytkownika administracyjnego, które zostało podane podczas kreacji bazy danych.
2. Zainstaluj Designer Studio z poziomu menu użytkownika w Portalu.
3. Zaloguj się do Designer Studio, podając hasło użytkownika administracyjnego.
4. Aktywuj licencje (subskrypcyjne) w Designer Studio. Instrukcja aktywacji licencji została opisana tutaj.
5. Skonfiguruj synchronizację listy użytkowników (np. z Microsoft Entra ID) i wymuś jej uruchomienie.
6. Skonfiguruj dostawcę uwierzytelniania innego niż Admin access, np. Microsoft Entra ID.
7. Po synchronizacji listy użytkowników przydziel licencje odpowiednim użytkownikom.
8. Nadaj uprawnienia globalne użytkownikom z Twojej organizacji, którzy będą zarządzać konfiguracją instalacji.
9. Po wykonaniu tych kroków i sprawdzeniu poprawności ich działania, możesz wyłączyć dostawcę uwierzytelniania Admin access.