Kto chce tworzyć oprogramowanie biznesowe obsługujące wielu najemców, podejmuje wczesne decyzje architektoniczne, których później praktycznie nie da się „usunąć” jedynie poprzez zmianę konfiguracji. Wielodostępność to nie tylko kwestia licencji czy interfejsu użytkownika, lecz oddziałuje bezpośrednio na model danych, uprawnienia, interfejsy, procesy aktualizacji, wsparcie i – co nie mniej ważne – na dowody bezpieczeństwa. W praktyce przedsięwzięcia Multi-Tenant rzadko zawodzą z powodu samej logiki domenowej, a częściej z powodu nieostrych linii rozgraniczenia: Gdzie dokładnie zaczyna się najemca? Jak dane są izolowane? Które komponenty mogą działać między najemcami (np. Monitoring, Backup, wysyłka e-mail) – i jak to jest audytowane?
Ten artykuł jest przeznaczony dla kierownictwa IT, administratorów i odpowiedzialnych technicznie za projekt. Opisuje sprawdzone wzorce, typowe fałszywe założenia oraz konkretne pytania decyzyjne dotyczące eksploatacji i dalszego rozwoju. Skupiono się celowo na wpływach w codziennej pracy: provisioning nowych najemców, modele ról i uprawnień, migracja danych, obsługa interfejsów, logowanie, Backup/RESTore i zdolność do aktualizacji. Celem jest architektura trwała w dłuższej perspektywie – niezależnie od tego, czy rozwiązanie działa jako system wewnętrzny, w kilku jednostkach korporacji, czy później jako hostowana platforma.
Co wielodostępność w kontekście przedsiębiorstwa naprawdę oznacza
Wielodostępność (często także Multi-Tenancy nazywana) oznacza, że oprogramowanie odwzorowuje na wspólnej platformie technicznej kilka organizacyjnie oddzielonych jednostek („najemców”). Najemcą może być firma, spółka zależna, lokalizacja, klient lub dział biznesowy. Decydujące jest: najemcy nie mogą widzieć ani wpływać na dane lub funkcje innego najemcy, chyba że jest to wyraźnie przewidziane i zweryfikowane (np. raportowanie korporacyjne).
W projektach pomocne jest zdefiniowanie wielodostępności wzdłuż trzech osi:
- Izolacja danych: Jak zapewnia się, że dane są możliwe do odczytu i zapisu tylko w właściwym kontekście najemcy?
- Tożsamość & uprawnienia: Jak użytkownik jest przypisany do najemcy i jak weryfikuje się role/zakresy?
- Izolacja operacyjna: W jakim stopniu najemcy mają wpływ na siebie nawzajem pod względem obciążenia, awarii, aktualizacji i okien konserwacyjnych?
Te osie prowadzą do różnych wariantów. Na przykład rozwiązanie może rygorystycznie oddzielać dane (oddzielne bazy danych), a jednocześnie być silnie powiązane operacyjnie (wspólne wdrożenia, wspólna kolejka, wspólne indeksy wyszukiwania). Dla decydentów ważne jest, że wielodostępność nie jest „przełącznikiem”, lecz spektrum z konsekwencjami kosztowymi i ryzykownymi.
Decyzje architektoniczne dla oprogramowania biznesowego obsługującego wielu najemców
Zanim rozszerzą Państwo tabele lub uczynią interfejsy „mandantenfähig”, warto wyjaśnić granice systemu: które komponenty należą do platformy, które trzeba skonfigurować per najemca i które dane można analizować centralnie? W dojrzałych środowiskach przedsiębiorstw kluczowe są również integracje z ERP, DMS, CRM lub Identity Provider (IdP).
Single-Tenant vs. Multi-Tenant: merytorycznie podobne, technicznie bardzo różne
Single-Tenant oznacza: na każdego najemcę odrębna instancja (co najmniej osobna baza danych, często także odrębny stack aplikacyjny). Multi-Tenant oznacza: wielu najemców współdzieli instancje i infrastrukturę – z separacją logiczną. Multi-Tenant często obniża nakład na rollout i eksploatację, ale zwiększa wymagania dotyczące izolacji, pokrycia testami i obserwowalności (Beobachtbarkeit przez Logging/Metriken/Tracing).
Pragmatyczne podejście często brzmi: „Multi-Tenant w kodzie, Single-Tenant w eksploatacji” dla krytycznych najemców. To znaczy: kod obsługuje konteksty najemcy w sposób jednoznaczny, ale poszczególni najemcy mogą opcjonalnie być uruchamiani oddzielnie (np. ze względów zgodności z przepisami lub wydajności). W tym celu konfiguracja, wdrożenie i monitoring muszą być od początku przygotowane na obie warianty.
Kontekst najemcy jako spójna zasada architektury
Wiele błędów powstaje, ponieważ kontekst najemcy jest dodawany tylko w pojedynczych miejscach (np. filtry w SQL, dodatkowe parametry w usługach). Stabilniejsze jest, gdy kontekst najemcy staje się zasadą spójną:
- Każde żądanie ma jednoznacznie określonego najemcę (na podstawie tokena/SSO, subdomeny, nagłówka, certyfikatu klienta lub skonfigurowanego endpointu).
- Kontekst najemcy jest w logice serwera traktowany jako informacja obowiązkowa (brak domyślnych najemców, brak „jeśli puste, to…”).
- Warstwy dostępu do danych i interfejsy wymuszają filtry najemcy lub powiązanie z najemcą, zamiast traktować je jako opcję.
- Logowanie i audyt zawierają najemcę, użytkownika/konto serwisowe oraz identyfikator korelacji, tak aby operacje i wsparcie mogły odtworzyć, co się wydarzyło.
Podejście „kontekst najemcy najpierw” redukuje klasę błędów, które ujawniają się dopiero w eksploatacji: błędne raporty, przypadkowe mieszanie danych, trudno wyjaśnialne przypadki uprawnień oraz niekompletne ścieżki audytu.
Model danych: trzy powszechne wzorce izolacji i ich konsekwencje
Najważniejsza decyzja techniczna dla obsługi wielu najemców dotyczy sposobu przechowywania danych. Kształtuje ona kopie zapasowe/przywracanie, migracje, wydajność i dowody dotyczące bezpieczeństwa. W praktyce wyróżnia się trzy wzorce, które mogą występować także w kombinacjach.
1) Baza danych na najemcę
Każdy najemca ma własną bazę danych (lub własny klaster bazodanowy). Zalety: bardzo klarowna izolacja, proste przywracanie per najemca oraz dobra podstawa do zróżnicowanych okien konserwacyjnych. Wady: większy nakład na provisioning, więcej połączeń, więcej migracji schematów i wyższa złożoność eksploatacji (np. monitoring obejmujący wiele baz danych).
Typowe przypadki użycia: bardzo rygorystyczne wymagania zgodności, najemcy o wyraźnie różnej masie danych lub sytuacje, gdy najemcy potrzebują odrębnych cykli wydawniczych. Z punktu widzenia administracji: potrzebna jest solidna automatyzacja dla aktualizacji schematu, zarządzania indeksami, kopii zapasowych i uprawnień – w przeciwnym razie nakład pracy rośnie wraz z liczbą najemców.
2) Schemat na najemcę
Jeden serwer bazodanowy, ale dla każdego najemcy osobny schemat (lub przestrzeń nazw). To średnia forma izolacji: łatwiej separowalna niż czyste filtry wierszy, ale mniej obciążająca niż kompletne bazy danych. Kopie zapasowe/przywracanie per najemca są w zależności od technologii bazy danych możliwe, ale nie zawsze trywialne. Migracje są łatwiejsze do skoordynowania niż w przypadku „DB na najemcę”, jednak liczba obiektów pozostaje wysoka.
Istotne dla eksploatacji: sprawdź wcześnie, jak narzędzia do monitoringu, tworzenia kopii zapasowych i migracji radzą sobie z wieloma schematami oraz czy standardowe raportowanie i dostęp BI mogą być poprawnie realizowane między schematami, bez osłabiania zasad bezpieczeństwa.
3) Wspólne tabele z identyfikatorem najemcy (oddzielenie na poziomie wiersza)
Wszyscy najemcy współdzielą tabele; każdy wiersz zawiera identyfikator najemcy (Tenant-ID). W wielu scenariuszach jest to rozwiązanie wydajne, zmniejsza liczbę obiektów i upraszcza globalne migracje. Jednocześnie rośnie odpowiedzialność aplikacji i/lub bazy danych za niezawodne egzekwowanie separacji.
Jeżeli stosują Państwo separację opartą na wierszach, należy zwrócić szczególną uwagę na dwa aspekty:
- Wymuszenie techniczne: Nie opierajcie się wyłącznie na „filtrujemy wszędzie po Tenant-ID”. Wykorzystujcie tam, gdzie to możliwe, mechanizmy bazodanowe, takie jak Row-Level Security (RLS; filtrowanie wierszy po stronie bazy danych oparte na kontekście sesji lub rolach), widoki lub polityki bezpieczeństwa. To, która opcja jest właściwa, zależy od używanej bazy danych.
- Oddziaływania przekrojowe między najemcami: Duzi najemcy mogą wpływać na indeksy, wskaźniki trafień w pamięci podręcznej oraz zachowanie blokad. To nie musi być powód do rezygnacji z tego podejścia, ale musi być uwzględnione w planowaniu pojemności i testach.
Hybridmodelle: häufig realistischer als „entweder/oder”
W praktyce modele hybrydowe są powszechne: transakcje rdzeniowe w wspólnych tabelach (dla prostych aktualizacji), szczególnie wrażliwe dane w oddzielnych bazach danych lub schematach oraz centralny obszar „Control Plane” do zarządzania najemcami, rozliczeń, flag funkcji i konfiguracji globalnej. Kluczowe jest, by te granice były udokumentowane i zabezpieczone technicznie.
Berechtigungen und Identitäten: Mandant, Rolle, Scope
Obsługa wielu najemców zależy od solidnej koncepcji uprawnień. W operacji nie liczy się tyle elegancja modelu, ile jego możliwość weryfikacji i diagnostyki w codziennym użyciu: dlaczego użytkownik X mógł wykonać akcję Y? Która rola została użyta? Która polityka zdecydowała?
SSO und Mandantenzuordnung: SAML 2.0, OIDC und Verzeichnisse
W środowiskach korporacyjnych często stosuje się Single Sign-on (SSO). Oznacza to, że logowanie odbywa się przez centralny Identity Provider, a aplikacja jedynie weryfikuje tokeny/assertions. Powszechne są SAML 2.0 (oparty na asercjach, często w klasycznych środowiskach Enterprise) oraz OpenID Connect (OIDC; oparty na tokenach, częsty w nowocześniejszych stosach IdP). Ważne: przypisanie najemcy musi być jednoznaczne i odporne na manipulacje.
Sprawdzone opcje:
- Najemca poprzez Issuer/IdP (jeden IdP na najemcę) – bardzo jasne, ale organizacyjnie bardziej pracochłonne.
- Najemca poprzez Claim/Atrybut (np. Tenant-ID w tokenie) – elastyczne, wymaga rzetelnej walidacji i mapowania.
- Najemca poprzez subdomenę lub oddzielne endpointy – dobre dla portali, ogranicza błędy obsługi, ale musi być poprawnie skoordynowane z przekierowaniami SSO.
Rollenmodell und Mandantenadministration ohne „Support-Tickets”
Częstym źródłem kosztów jest sytuacja, w której każda zmiana dotycząca najemcy (nowy użytkownik, nowa rola, nowe przypisanie lokalizacji) trafia jako manualna interwencja. Celem powinno być: najemcy mogą sami zarządzać swoimi użytkownikami i rolami w zdefiniowanym zakresie, bez konieczności, by centralni administratorzy zajmowali się każdym szczegółem.
W praktyce sprawdzają się wielopoziomowe role:
- Administrator platformy (zarządza środowiskiem, widzi metadane najemców, niekoniecznie dane najemcy).
- Administrator najemcy (zarządza użytkownikami, rolami, konfiguracją w obrębie najemcy).
- Role funkcjonalne (np. obsługa spraw, kierownik zespołu, zatwierdzanie).
- Konta serwisowe techniczne (dla interfejsów, zadań, automatyzacji) z minimalnymi uprawnieniami.
Operacyjnie istotne: role powinny być wersjonowalne i audytowalne. Jeśli uprawnienia można „szybko” zmienić poprzez bezpośrednią aktualizację lub nieśledzoną konfigurację, tracisz możliwość odtworzenia działań — a tym samym czas podczas audytów i rozwiązywania awarii.
Schnittstellen und Integration: Mandantenfähigkeit endet nicht am API-Gateway
Wiele rozwiązań cyfrowych w przedsiębiorstwie opiera się na integracjach: ERP, DMS, CRM, hurtownie danych, portale partnerskie, podłączenia maszyn. Obsługa wielu najemców musi być dlatego konsekwentnie wdrożona także w warstwie interfejsów. Dotyczy to REST-APIs (interfejsy oparte na HTTP), eventingu/kolejek, interfejsów plikowych oraz procesów e-mail/Webhook.
REST-API: Tenant-Scoping als Vertrag
W przypadku REST-API kluczowe jest, w jaki sposób najemca jest określany w żądaniu. Często stosowane wzorce to subdomena/host, nagłówek określający najemcę lub claim w access token. Ważne jest, aby nie pozostało to jedynie konwencją, lecz zostało dokumentowane jako element umowny API i egzekwowane po stronie serwera.
W eksploatacji liczy się także: API potrzebuje jasnych komunikatów o błędach i logów zawierających najemcę, endpoint, użytkownika/klienta, Request-ID oraz istotne parametry — bez niepotrzebnego logowania danych osobowych. Dzięki temu administratorzy i wsparcie mogą odtwarzalnie rozwiązywać przypadki, nie naruszając danych innych najemców.
Asynchrone Prozesse: Jobs, Queues und Scheduler mandantenfähig planen
Zadania wsadowe, importy, generowanie raportów czy nocne porównania często działają asynchronicznie. To miejsce, gdzie mieszanie najemców powstaje szczególnie łatwo, ponieważ worker „w tle” działa bez aktywnego kontekstu użytkownika. Planuj zatem:
- Powiązanie najemcy z każdym zadaniem: Każde zadanie musi zawierać ID najemcy i „kontekst wyzwalający” (użytkownik lub konto serwisowe).
- Limity zasobów: Duzi najemcy nie powinni całkowicie zdominować przetwarzania zadań (uczciwość, kwoty, priorytety).
- Oddzielne artefakty per najemca: Pliki tymczasowe, eksporty, bucket’y S3/ścieżki współdzielone, szablony e-mail oraz sekretne klucze webhook muszą być zarządzane specyficznie dla najemcy.
Betrieb und Sicherheit: Was Admins später wirklich brauchen
W eksploatacji wielodostępność działa jak multiplikator: jeden błąd, nieudane wdrożenie lub niejasny alarm może wpłynąć na wielu najemców. Z drugiej strony poprawnie prowadzona platforma może szybciej i spójniej wprowadzać aktualizacje. Kluczowe jest, aby operacje i bezpieczeństwo nie były „doklejane” później, lecz stanowiły element projektu architektury.
Logging, Audit und Nachvollziehbarkeit
Dla oprogramowania korporacyjnego należy rozróżnić dwa rodzaje logów:
- Logi techniczne: Błędy, wydajność, problemy integracyjne, timeouty. Muszą zawierać najemcę i ID korelacji, aby w rozproszonych komponentach można było odnaleźć transakcję.
- Logi audytowe: Kto wykonał jaką operację biznesową (np. zmiana danych podstawowych, uruchomienie eksportu, nadanie uprawnień)? Logi audytowe są istotne z punktu widzenia bezpieczeństwa i wymagają jasnych zasad przechowywania oraz kontroli dostępu.
Ważne: audyt to nie „kolejny log”. Audyt musi być odporny na manipulacje, odtwarzalny i możliwy do analizy. Równocześnie obowiązuje minimalizacja danych: nie każda informacja szczegółowa powinna być przechowywana trwale w audycie, lecz tylko fakty niezbędne do wykazania i rekonstrukcji zdarzeń.
Backup/Restore: Mandanten selektiv wiederherstellen können
Pytanie o przywracanie (RESTore) jest testem lakmusowym dla modelu danych. Globalny backup można szybko wykonać, ale szkody pojawiają się, gdy pojedynczy najemca zgłasza utratę danych, a można przywrócić tylko „wszystko albo nic”. W zależności od wzorca izolacji stosowne są różne strategie:
- DB pro Mandant: Przywracanie jest najprostsze do zrozumienia, wymaga jednak orkiestracji, jeśli kilka komponentów musi zostać spójnie zresetowanych (np. baza danych + indeks wyszukiwania + magazyn plików).
- Shared DB: Przywracanie dla pojedynczego najemcy jest zdecydowanie bardziej złożone. Pomocne są mechanizmy eksportu/snapshotów specyficzne dla najemcy, podejścia z Event Sourcing lub dodatkowe zabezpieczenia (soft-delete, wersjonowanie, procesy zatwierdzania).
Dla administratorów kluczowa jest udokumentowana procedura: Ile czasu zajmuje przywracanie? Jakie systemy są zaangażowane? Jak testuje się, czy najemca działa znowu „prawidłowo“ (smoke testy, kontrole integracyjne)?
Strategia patchowania i aktualizacji: migracje schematu bez przestojów
Kluczową zaletą podejść platformowych jest zdolność do jednolitego wdrażania aktualizacji. To działa tylko wtedy, gdy planuje się migracje schematu (zmiany struktur bazy danych) i aktualizacje aplikacji jako powiązany proces. Dobrą praktyką jest:
- Wdrożenia z kompatybilnością w przód: Nowe wersje oprogramowania mogą działać ze starym schematem (przez krótki czas), i/lub stare oprogramowanie może działać z nowym schematem. To redukuje czas niedostępności.
- Migracje małymi krokami: Zamiast „Big Bang“ przebudów: dodawać nowe kolumny, stopniowo uzupełniać dane (backfill), dopiero później usuwać stare struktury.
- Feature-Flags per najemca: Funkcje można aktywować dla wybranych najemców, aby ograniczyć ryzyko i uczynić wdrożenia kontrolowanymi.
Dla kierownictwa IT ważne jest: zdolność do aktualizacji to inwestycja. Oszczędza później czas przy aktualizacjach bezpieczeństwa, zmianie systemu operacyjnego, aktualizacjach bazy danych i zmianach integracji — czyli dokładnie w tych obszarach, które przez lata generują koszty.
Provisioning i cykl życia najemcy: od onboardingu do dezaktywacji
Obsługa wielu najemców jest kompletna dopiero wtedy, gdy cykl życia jest w pełni przemyślany. W praktyce istotne są nie tylko nowe instalacje, lecz także zmiany: dodatkowe lokalizacje, nowi dostawcy tożsamości, zmiany umów, eksporty danych i dezaktywacje.
Onboarding: co powinno być zautomatyzowane
Czysty proces onboardingu redukuje błędy i obciążenie wsparcia. Typowe elementy składowe:
- Utworzenie najemcy (Tenant-ID, nazwa, kontakt, status).
- Ustawienie konfiguracji (region, język, strefa czasowa, domeny e-mail, branding jeśli przewidziano).
- Skonfigurowanie integracji tożsamości (metadane SSO, certyfikaty, URL-e przekierowań).
- Utworzenie początkowych ról i użytkowników administracyjnych.
- Zapewnienie zasobów technicznych (baza danych/schemat, storage, indeks wyszukiwania, kolejki).
- Włączenie monitoringu i alarmowania dla najemcy.
Im więcej z tych czynności jest powtarzalnie zautomatyzowanych, tym mniej pojawia się „przypadków specjalnych”. To nie tylko efektywność, ale redukcja ryzyka: kroki ręczne są najczęstszym źródłem niespójnych konfiguracji.
Eksport danych i offboarding: niedoszacowane, ale krytyczne dla bezpieczeństwa
Offboarding to kwestia bezpieczeństwa i zgodności: które dane muszą być eksportowalne (np. do przekazania), które dane muszą zostać usunięte lub zanonimizowane i jak to udokumentować? Nawet bez konkretnej porady prawnej technicznie obowiązuje: potrzebne są jasne odpowiedzialności, zdefiniowane terminy oraz proces, który jest odtwarzalny.
Jeśli dane znajdują się w kilku systemach (baza danych, magazyn plików, indeks wyszukiwania, logi, kopie zapasowe), Offboarding musi uwzględniać te warstwy. Szczególnie kopie zapasowe są wrażliwe: pełne usunięcie z historycznych kopii zapasowych często jest w praktyce niemożliwe. Tym ważniejszy jest koncept, który to transparentnie opisuje (przechowywanie, ochrona dostępu, rotacja) i jednocześnie odpowiednio chroni dane najemców poza systemami produkcyjnymi.
Typische Fehlerbilder aus der Praxis – und wie Sie sie vermeiden
Obsługa wielu najemców rzadko zawodzi spektakularnie, częściej przez wiele drobnych luk w projekcie. Poniższe scenariusze błędów pojawiają się w projektach regularnie:
- Tenant-ID als „optional“: Poszczególne endpoints, joby lub raporty zapominają filtr. Rozwiązanie: techniczne wymuszenie (Policies/RLS), testy i konsekwentne reguły architektoniczne.
- Geteilte Konfiguration ohne Versionierung: Zmiany w modelu ról lub w przełącznikach funkcji później nie są odtworzalne. Rozwiązanie: wersjonować konfigurację, audytować zmiany.
- Mandantenübergreifende Caches: Buforowanie bez klucza najemcy prowadzi do wycieków danych. Rozwiązanie: klucz cache zawsze zależny od najemcy, wrażliwe dane lepiej przechowywać w cache krótko.
- Support kann Probleme nicht eingrenzen: Brak korelacji i metryk związanych z najemcą. Rozwiązanie: ID korelacji, tagi najemcy w logach/metrykach, przejrzyste dashboardy.
- Migrationen dauern zu lange: Duże przebudowy tabel blokują działanie. Rozwiązanie: migracje inkrementalne, procesy w tle, zaplanowane okna czasowe.
Te punkty to mniej „szczegóły programistyczne”, a bardziej rzeczywistość operacyjna. Kto je wcześnie adresuje, redukuje późniejsze koszty związane z hotfixami, oknami awaryjnymi i niejasnymi odpowiedzialnościami.
Mandantenfähige Business-Software entwickeln: Checkliste für belastbare Entscheidungen
Jeśli w projekcie ustalają Państwo kluczowe założenia, pomocne są konkretne pytania, które ujawnią architekturę i zdolność operacyjną:
- Jaka izolacja jest wymagana: techniczna (dane), organizacyjna (dostępy), operacyjna (okna konserwacji/obciążenie)?
- Jak jednoznacznie określa się najemcę (SSO-Claim, subdomena, własny endpoint)?
- Jak wymuszana jest izolacja (mechanizmy bazy danych, centralna warstwa dostępu, polityki)?
- Jak wygląda przypadek przywracania: per najemca, z jakimi zależnościami, w jakim czasie?
- Jak przebiegają aktualizacje: migracja schematu, strategia rollbacku, feature flags?
- Jaką obserwowalność zapewniono: metryki per najemca, audyt, alertowanie, runbooki?
- Jak integracje są obsługiwane wielonajemczo (konta serwisowe, sekrety, limity zapytań, webhooks)?
Te pytania są celowo sformułowane operacyjnie. Jeśli potrafią Państwo na nie odpowiedzieć, zwykle oznacza to, że architektonicznie znajdują się Państwo na stabilnej ścieżce.
Fazit: Mandantenfähigkeit ist ein Betriebsversprechen, kein UI-Feature
Zdolność do obsługi wielu najemców decyduje o tym, czy oprogramowanie biznesowe może być przez lata eksploatowane ekonomicznie i bezpiecznie rozwijane. Kluczowe jest wyznaczenie jasnych linii rozgraniczenia: kontekst najemcy jako obowiązek, odporna izolacja danych, weryfikowalne uprawnienia, interfejsy zgodne z modelem wielonajemcowym oraz cykl życia obejmujący provisioning, aktualizacje i offboarding. Kto poprawnie ustawi te fundamenty, zyskuje w codziennej eksploatacji: mniej zakłóceń z powodu dryfu konfiguracji, szybsze aktualizacje, przejrzystsze procesy wsparcia i wiarygodne dowody wobec wymagań wewnętrznych i zewnętrznych.
Jeżeli chcą Państwo konkretnie ocenić wielodostępność dla istniejącego lub nowego rozwiązania cyfrowego w przedsiębiorstwie albo opracować koncepcję migracji i architektury, przeanalizujmy wspólnie warunki ramowe w sposób uporządkowany:
W kontekście merytorycznym istotną rolę odgrywają także architektura Multi-Tenant i izolacja tenantów, gdy integracje, przepływy danych i dalszy rozwój muszą współgrać bez zakłóceń.
Omówić projekt lub przedsięwzięcie modernizacyjne z Net-Base.