Środowisko systemowe

Dla potrzeb tworzenia i dostarczania rozszerzeń i dostosowań w Comarch ERP Enterprise oraz ich dystrybucji konieczne jest zarezerwowanie różnych systemów i zestawienie ścieżek transportu pomiędzy tymi systemami. Wymagania w tym zakresie mogą być bardzo zróżnicowane. Różne wymagania wynikają z liczby systemów, które mają być zaopatrywane, oraz z tego, czy chodzi wyłącznie o dostosowania, czy też mają być tworzone rozszerzenia standardowego systemu Comarch ERP Enterprise.

W niniejszym artykule opisano możliwe scenariusze – od prostej architektury systemowej z kilkoma systemami aż po architekturę systemową przeznaczoną do tworzenia samodzielnych rozszerzeń, które następnie mogą być dostosowywane do różnych zastosowań.

Ścieżka transportu określa kolejność, w jakiej aktualizacje oprogramowania są przenoszone z jednego systemu Comarch ERP Enterprise do kolejnego. Poniżej zamieszczono informacje dotyczące konfiguracji kompletnego krajobrazu transportowego – od systemu zapewnienia jakości aż po system produkcyjny – a także informacji o ustawieniach, które należy w tym celu wprowadzić.

Dodatkowo opisano, które parametry systemowe należy ustawić w danej konfiguracji.

Grupa docelowa

Osoby odpowiedzialne za wsparcie, planowanie rozwoju, zapewnienie jakości oraz dostarczanie oprogramowania.

Definicje terminów

• Adaptacja — adaptacja to zmiana poziomu wydania. Dodawane są nowe obiekty deweloperskie lub modyfikowane są istniejące obiekty deweloperskie. Funkcje standardowe są w ten sposób rozszerzane lub zmieniane.
• Rozwiązanie branżowe — rozwiązanie branżowe to rozwinięcie partnerskie, które zawiera rozszerzenia umożliwiające dostosowanie do określonej branży. Z technicznego punktu widzenia nie ma różnicy między rozwinięciem partnerskim a rozwiązaniem branżowym.
• System deweloperski — systemy deweloperskie są używane do (nowych) rozszerzeń i adaptacji. W systemach deweloperskich można tworzyć i zmieniać obiekty deweloperskie. Z reguły system deweloperski dostarcza aktualizacje oprogramowania wyłącznie do systemów niższego szczebla.
• System wewnętrzny — system wewnętrzny/system wsparcia służy do koordynowania i dokumentowania rozwinięć oraz odpowiadających im dostaw wsparcia (czyli aktualizacji oprogramowania). W tym systemie rejestrowane są zgłoszenia wsparcia, zlecenia deweloperskie, dostawy wsparcia i aktualizacje oprogramowania, które następnie są udostępniane do pobrania w systemach niższego szczebla. System ten powinien przejmować te zadania dla wszystkich wydań. Dlatego zasadniczo potrzebny jest tylko jeden system wewnętrzny/system wsparcia.
• System korekcyjny — system korekcyjny jest systemem deweloperskim. Jednak pewne zmiany obiektów deweloperskich nie są dopuszczalne albo są możliwe tylko po potwierdzeniu ostrzeżenia. Usunięcia są możliwe jedynie po potwierdzeniu ostrzeżenia, ponieważ mogą być niezgodne z dostosowaniami w systemach deweloperskich niższego szczebla. Podobnie jak systemy deweloperskie, systemy korekcyjne dostarczają korekty do systemów niższego szczebla. Korekty te mogą być jednak również przekazywane do systemów deweloperskich.
• System niższego szczebla — z punktu widzenia systemu, systemami niższego szczebla są wszystkie systemy Comarch ERP Enterprise, do których importowane są aktualizacje oprogramowania eksportowane z tego systemu. Systemy niższego szczebla mogą znajdować się w kilku równoległych gałęziach rodziny systemów, lecz nie mogą należeć do innej rodziny systemów.
• Rozwinięcie partnerskie — rozwinięcie partnerskie to nieukierunkowane na konkretnego klienta rozszerzenie lub adaptacja standardowego systemu Comarch ERP Enterprise, które może być ponownie dostosowywane dla klientów – na przykład jako rozwiązanie branżowe lub aplikacja.
• System produkcyjny — system produkcyjny, czyli system P, to system u klienta, który jest używany w pracy operacyjnej. System ten zawiera rzeczywiste dane klienta i jest ostatnim systemem na ścieżce transportu, który otrzymuje aktualizacje oprogramowania.
• System zapewnienia jakości — system zapewnienia jakości jest specjalnym systemem testowym. Wszystkie aktualizacje oprogramowania z systemów deweloperskich wyższego szczebla są importowane i testowane w tym systemie. System ten powinien mieć zawsze aktualny stan aktualizacji oprogramowania.  Na przykład partner powinien importować wszystkie aktualizacje oprogramowania dostarczone przez SoftM Software und Beratung AG do swojego systemu zapewnienia jakości. W tym systemie partner może testować aplikacje istotne dla siebie. Jeśli w dostosowanych systemach wystąpi błąd, system zapewnienia jakości może zostać użyty do sprawdzenia, czy błąd występuje w standardzie. Wymaga to aktualnego stanu aktualizacji oprogramowania, ponieważ w przeciwnym razie nie byłoby możliwe stwierdzenie, czy błąd został już usunięty.
• Standard Comarch ERP Enterprise — standard Comarch ERP Enterprise obejmuje aktualne wersje wszystkich obiektów deweloperskich danego wydania, włącznie ze wszystkimi aktualizacjami oprogramowania dla tego wydania dostarczonymi przez Comarch. Ponadto wszystkie numery wersji tych obiektów deweloperskich mogą mieć maksymalnie 2 cyfry, przy czym pierwsza i druga cyfra numeru wersji są zarezerwowane dla Comarch. Oznacza to w sposób dorozumiany, że obiekty deweloperskie nie mogą być tworzone ani modyfikowane przez strony trzecie. Standard Comarch ERP Enterprise jest definiowany wyłącznie przez Comarch. Oprócz obiektów deweloperskich standard Comarch ERP Enterprise obejmuje konwencje programistyczne oraz wiążące wytyczne.
• System standardowy — system standardowy to system dostarczony przez Comarch, który nie został zmodyfikowany
• Aktualizacja oprogramowania — aktualizacje oprogramowania służą do aktualizacji systemu Comarch ERP Enterprise w ramach danego wydania. Aktualizacja oprogramowania zawiera nowe lub zmodyfikowane obiekty deweloperskie bądź ich kombinację. Aktualizacje oprogramowania dostarczają poprawek błędów oraz nowe funkcjonalności. Podczas eksportu aktualizacji oprogramowania tworzone są dwa pliki: plik source refresh (sr) zawierający kod źródłowy oraz plik code refresh (cr) zawierający skompilowany kod obiektowy.
• Transport oprogramowania — transporty oprogramowania odbywają się pomiędzy systemami o różnych poziomach kontroli wersji. Rozróżnia się (regularne) transporty oprogramowania oraz transporty krzyżowe oprogramowania. W zwykłym transporcie oprogramowania poziom kontroli wersji systemu źródłowego jest niższy niż poziom systemu docelowego lub w systemie źródłowym zostały zgrupowane aktualizacje oprogramowania. W transporcie krzyżowym oprogramowania poziom kontroli wersji systemu źródłowego jest wyższy niż systemu docelowego.
• Grupa systemów — grupa systemów to zbiór systemów Comarch ERP Enterprise tego samego wydania. Aktualizacje oprogramowania są dostarczane w zdefiniowany sposób dla wszystkich systemów w obrębie grupy.
• Grupa systemów produkcyjnych — grupa systemów produkcyjnych to grupa systemów składająca się co najmniej z jednego systemu produkcyjnego i co najmniej jednego poprzedzającego go systemu testowego lub systemu zapewnienia jakości. Preferowane jest posiadanie dwóch systemów testowych w rodzinie systemów produkcyjnych, z których jeden jest regularnie zasilany kopiami danych OLTP, a ewentualnie także danych OLAP, z systemu produkcyjnego. Ten system testowy poprzedza system produkcyjny i następuje po drugim systemie testowym.
• Topologia systemu — topologia systemu obejmuje wszystkie grupy systemów. Grupy systemów w topologii systemu mogą mieć różne poziomy wydań. Topologia systemu powinien zawierać dokładnie jeden system wewnętrzny używany przez wszystkie systemy w topologii systemu. Ponadto mianem topologii systemu określa się również rozdzielenie poszczególnych komponentów instalacji Comarch ERP Enterprise, takich jak baza danych, Serwer aplikacji Comarch ERP Enterprise (SAS), Menedżer wydruków Comarch ERP Enterprise itd.
• System testowy — w systemie testowym nie prowadzi się rozwoju – nie można tworzyć ani zmieniać obiektów deweloperskich. Jedynym zadaniem systemu testowego jest testowanie zaimportowanych aktualizacji oprogramowania oraz związanych z nimi rozwinięć i poprawek. Ponadto zaimportowane aktualizacje oprogramowania mogą być przekazywane do systemów niższego szczebla.
• Ścieżka transportu — ścieżka transportu definiuje sekwencję systemów, do których importowane są aktualizacje oprogramowania. Ścieżka transportu obejmuje systemy deweloperskie o poziomach kontroli wersji 1, 2, 3, 4 i 6, w których zmiana numerów wersji obiektów deweloperskich powoduje powstanie aktualizacji oprogramowania. W systemach o poziomie kontroli wersji 7 aktualizacje oprogramowania z systemu deweloperskiego mogą być grupowane w większe jednostki. Na drodze do systemu produkcyjnego aktualizacje oprogramowania nie mogą pomijać żadnego z systemów na ścieżce transportu. Aktualizacje oprogramowania nie mogą być importowane do systemów wyższego szczebla. Ścieżka transportu jest tzw. drogą jednokierunkową. Rozbudowana topologia transportowa składa się z kilku systemów, które tworzą różne ścieżki transportu dla różnych grup systemów Comarch ERP Enterprise. Na ścieżce transportu komunikują się ze sobą kilka Serwerów aplikacji Comarch ERP Enterprise (SAS) należących do różnych systemów Comarch ERP Enterprise.
• Poziom wersjonowania — każdemu systemowi Comarch ERP Enterprise przypisany jest poziom kontroli wersji. Na podstawie tego poziomu określany jest sposób użycia systemu. Poziomy kontroli wersji 3, 4, 5, 6 i 7 są do dyspozycji partnerów. Rozwój może być prowadzony w systemach o poziomach kontroli wersji 3, 4, 5 i 6, ale nie 7. Jeżeli rozwój odbywa się w systemie, poziomy te określają sposób rozdzielania numerów wersji obiektów deweloperskich. Numer wersji obiektu deweloperskiego składa się z sześciu liczb oddzielonych kropkami (n1.n2.n3.n4.n5.n6). Podczas tworzenia nowej wersji zwiększana jest o jeden ta liczba, która odpowiada poziomowi kontroli wersji. Późniejsza zmiana poziomu kontroli wersji systemu prowadzi do tego, że numery wersji zmienionych obiektów deweloperskich nie odzwierciedlają już prawidłowego poziomu kontroli wersji. Aktualnie istnieje siedem poziomów, które można wykorzystywać w następujący sposób:
  • Poziom 1 — system deweloperski Comarch
  • Poziom 2 — system korekcyjny Comarch
  • Poziom 3 — system adaptacyjny partnera, np. rozwiązania branżowe
  • Poziom 4 — system korekcyjny partnera
  • Poziom 5 — system deweloperski
  • Poziom 6 — system adaptacyjny
  • Poziom 7 — system produkcyjny, testowy, zapewnienia jakości
• System wyższego szczebla — z punktu widzenia systemu, systemami wyższego szczebla są wszystkie te systemy Comarch ERP Enterprise, przez które aktualizacja oprogramowania musi zostać przetransportowana, zanim może zostać zaimportowana do danego systemu. Każdy system ma dokładnie jeden system wyższego szczebla, który dostarcza mu aktualizacje oprogramowania. Bezpośredni system wyższego szczebla jest definiowany przez ograniczenia importu. Systemy wyższego szczebla danego systemu należą do tej samej rodziny systemów. System wyższego szczebla jest albo systemem deweloperskim, albo systemem testowym, w którym aktualizacje oprogramowania są grupowane.
• System wyższego i niższego szczebla — system b jest systemem niższego szczebla dla systemu a, jeżeli otrzymuje aktualizacje oprogramowania z systemu a i jeśli poziom kontroli wersji systemu b jest wyższy niż poziom systemu a. W odwrotnej relacji system a jest systemem wyższego szczebla dla systemu b. Jeżeli w systemie wyższego szczebla aktualizacje oprogramowania są grupowane, system ten ma poziom kontroli wersji 7 i powinien być skonfigurowany jako system testowy.

Wstępne rozważania

Ścieżki transportu

Zasadniczo (zwykłe) transporty oprogramowania mają miejsce podczas prac rozwojowych. Transporty krzyżowe oprogramowania występują zazwyczaj jedynie przy przekazywaniu poprawek z systemu korekcyjnego do przypisanego systemu deweloperskiego kolejnego wydania.

Poziom kontroli wersji systemu źródłowego jest zapisywany w aktualizacji oprogramowania. Podczas importu w systemie docelowym sprawdzane jest, jaki (źródłowy) poziom kontroli wersji zapisano w aktualizacji oprogramowania. Informacja ta stanowi podstawę do podjęcia decyzji, czy mamy do czynienia z transportem krzyżowym oprogramowania.

W standardowej logistyce oprogramowania system ma dokładnie jeden system źródłowy. Jest to konieczne ze względu na ograniczenia pomiędzy aktualizacjami oprogramowania. Każdy system może być systemem źródłowym dla kilku innych systemów. W każdym przypadku powstaje w ten sposób struktura drzewa.

Ograniczenia pomiędzy aktualizacjami oprogramowania

Istnieją nieuniknione zależności pomiędzy aktualizacjami oprogramowania, które zostały wyeksportowane z określonego systemu. Aktualizacja oprogramowania może zostać zainstalowana w systemie docelowym tylko wtedy, gdy wszystkie aktualizacje, od których zależy, zostały wcześniej zaimportowane do tego systemu. Zapewnia to, że wersje aktywnych obiektów deweloperskich w systemie są zawsze technicznie spójne.

Zmiana tożsamości aktualizacji oprogramowania

Gdy aktualizacje oprogramowania są importowane do systemu o poziomie 3, 4, 5 lub 6, nowe aktualizacje oprogramowania są generowane automatycznie. Powiązane pliki (*.cr, *.tr, *.hr, *.sr) nie są eksportowane automatycznie. Aktualizacje te zawierają zaimportowane obiekty deweloperskie. Poziom kontroli wersji tych aktualizacji odpowiada poziomowi systemu, który je tworzy.

Tylko w systemach z poziomem kontroli wersji 7 do eksportowanych aktualizacji zapisywany jest inny poziom kontroli wersji. Aktualizacje oprogramowania zawierają te same obiekty deweloperskie, lecz mają różne tożsamości. Zależności pomiędzy aktualizacjami oprogramowania zostają odpowiednio przekształcone.

Odwzorowanie ograniczeń aktualizacji oprogramowania podczas zmiany tożsamości

Systemy z poziomem wersjonowania 7

Systemy o poziomie kontroli wersji 7 odgrywają szczególną rolę w logistyce oprogramowania. Ponieważ w tych systemach nie prowadzi się rozwoju, nie generują one automatycznie aktualizacji oprogramowania. Jeżeli w tych systemach aktualizacje oprogramowania są tworzone za pomocą aplikacji Panel Aktualizacja oprogramowania, aktualizacje te zawierają wyłącznie obiekty deweloperskie utworzone w innym systemie. Z tego względu w tych aktualizacjach zapisywany jest poziom kontroli wersji nadrzędnego systemu deweloperskiego lub korekcyjnego.

Systemy te nie są istotne z punktu widzenia ścieżki transportu, jednak zapewniają istotne korzyści dla zapewnienia jakości i logistyki oprogramowania. System o poziomie 7 jest zawsze opcjonalny. Jeżeli jednak system ten został początkowo włączony w ścieżkę transportu, nie można go później z tej ścieżki usunąć.

Aktualizowanie systemu docelowego i systemów poziomu 7

Funkcja [Aktualizuj system docelowy] w aplikacji Panel Aktualizacja oprogramowania nie generuje nowych aktualizacji oprogramowania. Wykorzystuje wyłącznie aktualizacje oprogramowania, które są już dostępne w systemie.

Jeżeli w systemie poziomu 7 tworzone są niesymultaniczne aktualizacje oprogramowania, system ten można w dowolnym momencie usunąć ze ścieżki transportu lub do niej włączyć, ponieważ aktualizacje oprogramowania nie zmieniają swojej tożsamości, lecz są jedynie przekazywane dalej. Innymi słowy, system poziomu kontroli wersji 7, w którym wykorzystywana jest wyłącznie funkcja [Aktualizuj system docelowy], nie jest systemem źródłowym.

Dotyczy to następujących systemów:

• system wewnętrzny
• wszystkie systemy testowe, które nie tworzą dostaw wsparcia – przede wszystkim system testowy poprzedzający system produkcyjny

Prefiks deweloperski

Każdemu systemowi, w którym prowadzi się rozwój, przypisany jest prefiks deweloperski. Nowe obiekty deweloperskie mogą być w tym systemie tworzone wyłącznie w przestrzeniach nazw pod com<development_prefix>. Ponadto bez ograniczeń mogą być zmieniane tylko te obiekty deweloperskie.

Po utworzeniu obiektu deweloperskiego jego nazwa – łącznie z obszarem nazw – nie może być już zmieniona. Z tego powodu zazwyczaj nie ma sensu dokonywanie późniejszych zmian prefiksu deweloperskiego. Po zmianie prefiksu deweloperskiego możliwości dalszego przetwarzania wcześniej utworzonych obiektów deweloperskich są bardzo ograniczone.

Topologie systemu

Przed zbudowaniem krajobrazu systemowego należy w szczególności wyjaśnić następujące kwestie:

• Czy na pewno nie jest planowane rozwinięcie partnerskie? W razie wątpliwości należy raczej założyć rozwinięcie partnerskie.
• Ilu klientów ma zostać zaopatrzonych i w jakich terminach?

Rozwinięcie partnerskie a adaptacja

Rozwinięcie partnerskie i dostosowanie różnią się w następujących aspektach:

• poziom kontroli wersji,
• prefiks deweloperski.

Rozwinięcia partnerskie mają prefiks deweloperski przypisany partnerowi, natomiast dostosowania mają prefiks deweloperski przypisany klientowi.

Jak opisano powyżej, późniejsza zmiana jednej z tych konfiguracji w istniejącym systemie ma niewielki sens. W takim przypadku trzeba założyć nowy system, a odpowiednie obiekty deweloperskie przenieść do tego systemu ręcznie lub z użyciem Business Integration Service, tzn. za pomocą aplikacji Import danych i Eksport danych. Generuje to dodatkowy nakład pracy i wiąże się z ograniczeniami. Dlatego rozwinięcie partnerskie powinno od początku być zakładane jako system z poziomem kontroli wersji 3 lub 4. Obowiązuje to nawet wtedy, gdy początkowo obsługiwany jest tylko jeden klient. W takim przypadku można na początku zrezygnować z zakładania systemu dostosowawczego klienta.

Z punktu widzenia samego procesu rozwoju nie ma znaczenia, czy prace prowadzone są w systemie rozwinięcia partnerskiego, czy w systemie adaptacyjnym. Istotna różnica między tymi systemami pojawia się natomiast w kontekście topologii systemu i przyszłych zmian.

Z tego względu już na początku należy rozważyć, czy planowane rozszerzenia są istotne wyłącznie dla jednego klienta, czy też mogą mieć znaczenie jako potencjalne rozwiązanie branżowe. W tym drugim przypadku system rozwinięcia partnerskiego jest zawsze preferowanym systemem. Jego użycie nie powoduje na starcie żadnego dodatkowego nakładu pracy.

Jeśli tworzone będą wyłącznie dostosowania specyficzne dla klienta, należy je zawsze realizować w systemie dostosowawczym z prefiksem deweloperskim klienta. W przeciwnym razie przy późniejszym wprowadzeniu systemu rozwinięcia partnerskiego powstanie dodatkowy nakład pracy, ponieważ prefiks deweloperski został już przypisany.

Poziom wersjonowania 3 a 4

Tak długo, jak rozwój prowadzony jest tylko dla jednego wydania i systemy dostosowawcze nie będą zaopatrywane, preferowany jest poziom kontroli wersji 3. Poziom ten zawiera istotnie mniej ograniczeń (ostrzeżeń) dotyczących zmian obiektów deweloperskich.

Jeżeli systemy adaptacyjne mają być zaopatrywane, ograniczenia w systemach poziomu 4 zapobiegają wprowadzaniu zmian, które byłyby niezgodne z ewentualnymi dostosowaniami w systemach adaptacyjnych.

Jeśli zaopatrywane będą wyłącznie systemy produkcyjne, w których nie prowadzi się rozwoju, można również wybrać poziom 3.

Z chwilą, gdy istnieje rozwinięcie partnerskie dla starszego wydania i rozpoczyna się rozwój partnerski dla nowego wydania, stare rozwinięcie partnerskie powinno mieć poziom 4, a nowe rozwinięcie – poziom 3. Umożliwia to transporty krzyżowe oprogramowania z poprawkami ze starego wydania.

Zazwyczaj rozwinięcia i adaptacje powstają w nowym wydaniu w ramach podnoszenia wersji ze starego wydania i tym samym nowe wydanie również zawiera błędy, które nadal występowały w starym wydaniu. Jeżeli błędy te zostaną usunięte w starym wydaniu, a powstałe w ten sposób aktualizacje oprogramowania zostaną również przekazane do systemu deweloperskiego nowego wydania, nakład pracy (podwójne utrzymanie) ulega znacznemu ograniczeniu.

Jeżeli poprawki obejmują zmiany schematu (zmiany obiektów biznesowych), proces ten jest w istocie konieczny, ponieważ podwójne utrzymanie znacznie utrudniłoby późniejsze podniesienie wydania. W przypadku podwójnego utrzymania nowy system nie rozpoznaje wersji obiektów biznesowych ze starego systemu, a tym samym usługa persystencji nie ma dostępu do danych w starym systemie.

Równoległy system deweloperski (transport XML)

W ramach większych prac rozwojowych w partnerskim systemie adaptacyjnym i dostarczania systemom odbiorczym poprawek błędów często nie da się zrealizować wszystkiego w jednym systemie. Wynikają z tego dwa główne problemy:

• poprawek błędów nie można zainstalować, ponieważ zawarte w nich obiekty deweloperskie są zablokowane;
• ze względu na ograniczenia poprawki błędów mogą zostać wyeksportowane z partnerskiego systemu deweloperskiego tylko wtedy, gdy do eksportu zostaną dołączone także części nowych rozwojów. Te nowe rozwoje mogą jeszcze nie być w pełni zaimplementowane lub przetestowane, a więc nie mogą zostać wyeksportowane. W konsekwencji nie można też wyeksportować poprawek błędów.

Rozwiązaniem jest utworzenie równoległego systemu deweloperskiego. System ten otrzymuje aktualizacje oprogramowania z tego samego systemu co system dla poprawek błędów. Nie zasila jednak żadnych systemów odbiorczych, z wyjątkiem systemu testowego dla nowych rozwojów. Całość nowych rozwojów jest realizowana właśnie w tym systemie.

Gdy nowe rozwoje mają zostać dostarczone, można je wyeksportować za pomocą funkcji Eksport danych (BIS) i zaimportować do systemu w ścieżce transportowej. Powstałe w ten sposób zlecenia deweloperskie można łatwo przetworzyć, ponieważ w tym systemie nie ma nierozpoznanych aktualizacji oprogramowania ani zmian. Korekty w systemie dla poprawek błędów są albo ręcznie dodawane do systemu deweloperskiego, albo transportowane poprzez operację eksportu/importu.

Idealnym podejściem jest skonfigurowanie równoległego systemu deweloperskiego jako kopii partnerskiego systemu deweloperskiego. Dzięki temu stan kodu w obu systemach będzie taki sam. Dokument INF-000337: Copying and Cleaning Up a Comarch ERP Enterprise System zawiera przydatne informacje dotyczące kopiowania systemu deweloperskiego.

Przed wykonaniem kopii stan systemu deweloperskiego musi spełniać następujące kryteria:

• wszystkie zlecenia deweloperskie muszą być aktywowane,
• wszystkie zaimportowane aktualizacje oprogramowania muszą być zainstalowane, tzn. nie może być żadnych nieukończonych procesów instalacji.

W systemie deweloperskim oraz w powiązanym z nim równoległym systemie deweloperskim należy ustawić ten sam poziom kontroli wersji oraz ten sam prefiks deweloperski.

Oba systemy deweloperskie muszą otrzymywać dostawy wsparcia z tego samego systemu poprzedzającego. Moment wysyłki dostaw wsparcia do danego systemu zależy jednak od odpowiedniego poziomu rozwoju. W systemie deweloperskim do poprawek błędów prawdopodobnie wszystkie potrzebne dostawy wsparcia będą przenoszone niezwłocznie. Do równoległego systemu deweloperskiego nowe dostawy wsparcia będą przenoszone zgodnie z poziomem rozwoju systemu.

Rozwój można transportować pomiędzy dwoma systemami deweloperskimi w dowolnym momencie za pomocą BIS. Jeśli stany kodu w standardowym rozwoju znacznie się od siebie różnią, prowadzi to do zwiększonego nakładu pracy adaptacyjnej w systemie docelowym. Dlatego przy każdym przeniesieniu większego rozwoju z równoległego systemu deweloperskiego do systemu do poprawek błędów należy stosować poniższą procedurę:

1. Zamknąć odpowiednie prace rozwojowe.
2. Doprowadzić równoległy system deweloperski (poprzez dostawy wsparcia) do tego samego stanu kodu w standardowym rozwoju, jaki ma system do poprawek błędów – o ile nie zostało to jeszcze wykonane.
3. Dostosować rozwój do tego stanu.
4. Przetestować ten rozwój.
5. Aktywować wszystkie zlecenia deweloperskie w systemie do poprawek błędów.
6. Przenieść rozwój do systemu do poprawek błędów.
7. W systemie do poprawek błędów należy również zmienić programy aktualizacji dla zmodyfikowanych obiekty biznesowych.
8. Przetestować rozwój w systemie do poprawek błędów.

Taka procedura minimalizuje czasy realizacji w systemie do poprawek błędów, ponieważ kroki mogą być szybko przetworzone w tym systemie.

Jeśli cały rozwój został przeniesiony z równoległego systemu deweloperskiego do systemu testowego, dalsze postępowanie z równoległym systemem deweloperskim może przebiegać na dwa sposoby:

1. Kontynuować pracę na istniejącym równoległym systemie deweloperskim.
2. Zastąpić równoległy system deweloperski kopią systemu do poprawek błędów.

Zaletą pierwszej alternatywy jest możliwość natychmiastowego kontynuowania rozwoju bez konieczności oczekiwania na przetworzenie (transportowego) zlecenia deweloperskiego w systemie do poprawek błędów. Druga alternatywa umożliwia skopiowanie również klientów OLTP i OLAP systemu do poprawek błędów, dzięki czemu w równoległym systemie deweloperskim dostępne są dane testowe. Wymiana klientów OLTP i OLAP pomiędzy dwoma systemami deweloperskimi zasadniczo nie jest możliwa.

Równoległe wydania

W Comarch ERP Enterprise 4.4 i wyższych istnieje możliwość uruchamiania różnych wydań tego samego (deweloperskiego) systemu. Dokładny opis procedury oraz sposobu dostarczania do tych systemów aktualizacji oprogramowania znajduje się w rozdziale Równoległe utrzymanie w artykule Wprowadzenie: logistyka oprogramowania.

Późniejsza zmiana ścieżek transportowych

Ścieżki transportowe można zmieniać później. Nie jest to jednak standardowa operacja i wymaga wsparcia centrum wsparcia. Problematyczne są następujące aspekty przy zmianie ścieżki transportowej:

• Jeśli do systemu zostanie przypisany nowy system źródłowy, musi on obejmować dokładnie te same aktywne obiekty deweloperskie co poprzedni system źródłowy. Dotyczy to głównie adaptacji na obiekty deweloperskie firmy Comarch Software und Beratung AG. Z tego powodu system adaptacji klienta nie może być zasilany z dwóch partnerskich systemów deweloperskich. W dwóch partnerskich systemach deweloperskich mogą zostać wykonane różne adaptacje na tym samym obiekty deweloperskie Comarch Software und Beratung AG, co prowadzi do zasadniczo nierozwiązywalnych niespójności w systemie adaptacji klienta.
• Jak opisano wyżej, pomiędzy aktualizacjami oprogramowania istnieją ograniczenia, a aktualizacje oprogramowania w niemal każdym systemie zmieniają swoją tożsamość. Aktualizacje oprogramowania pochodzące od Comarch Software und Beratung AG muszą zatem docierać do systemu docelowego dokładnie jedną ścieżką. W przeciwnym razie ograniczenia nie będą już możliwe do rozwiązania, a instalacja aktualizacji oprogramowania się nie powiedzie.

Możliwe jest późniejsze wciśnięcie nowego systemu. Wyjaśniono to na przykładzie partnerskiego systemu deweloperskiego. Na początku rozwoju często zasilany jest tylko jeden klient i początkowo nie przewiduje się adaptacji dla tego klienta, dlatego osobny system adaptacji jest na ten moment pomijany. Później dołączani są kolejni klienci i adaptacje stają się wymagane. W takim przypadku konfiguruje się system adaptacji (6). Partnerski system deweloperski staje się systemem źródłowym dla adaptacji, a adaptacja staje się systemem źródłowym dla systemów klienta. Wymaga to określonych kroków reorganizacji dla aktualizacji oprogramowania, które nie są tu szczegółowo opisane.

Nie można obniżyć poziomu systemu. Przykładowo nie można przekształcić systemu adaptacji klienta (poziom 6) w partnerski system deweloperski (poziom 3).

Usunięcie (źródłowego) systemu ze ścieżki transportowej jest możliwe tylko w niezwykle ograniczonych warunkach. Dlatego zdecydowanie zaleca się powstrzymanie się od tego działania.

Zastąpienie lub utrata systemu na ścieżce transportowej

Po tym, jak aktualizacje oprogramowania zostały wyeksportowane z systemu i zaimportowane do systemu niższego szczebla, system źródłowy tych aktualizacji oprogramowania nie może zostać usunięty ani zastąpiony, np. poprzez reinstalację opartą na nowym systemie instalacyjnym. Dotyczy to w szczególności systemów deweloperskich.

Jeśli jednak taki system zostanie utracony, na przykład dlatego, że nawet kopie zapasowe nie mogły zostać ponownie zaimportowane po awarii, należy niezwłocznie skontaktować się z centrum wsparcia, aby uzyskać wsparcie w odtworzeniu danych rozwojowych.

W przypadku takiej całkowitej utraty systemu zazwyczaj nie można zagwarantować pełnego odtworzenia (bez żadnych strat). Dlatego należy podjąć działania zapewniające sprawne procedury tworzenia kopii zapasowych i odtwarzania.

Tworzenie dostawy wsparcia/pakietu aktualizacji oprogramowania

Comarch ERP Enterprise udostępnia kilka funkcji ułatwiających logistykę aktualizacji oprogramowania, aby wspierać rozbudowane krajobrazy systemowe. Na samym początku, gdy istnieje tylko jeden system deweloperski i tylko systemy docelowe dla jednego klienta, korzystanie z tych funkcji generuje dodatkowy nakład pracy, który może nie być tego wart. Z tego powodu na start można z tych funkcjonalności zrezygnować i przejść na nie później.

Wewnętrzne systemy/systemy wsparcia do dystrybucji aktualizacji oprogramowania można w razie potrzeby włączyć do ścieżki transportowej. Przykładowo partner może wykorzystać taki system do udostępniania klientowi aktualizacji oprogramowania (dostaw wsparcia – patrz poniżej) do pobrania.

Te funkcje ułatwiające zapewniają poniższe korzyści. Bardziej szczegółowy opis znajduje się również w artykule Dostawy wsparcia.

• Pakietowanie aktualizacji oprogramowania — aktualizacje oprogramowania powinny być pakietowane, jeśli aktualizacje są od siebie zależne technicznie. W takim przypadku mogą być zainstalowane wyłącznie jako pakiet. Użycie jednego pliku jest wówczas prostsze lub aktualizacje są od siebie zależne merytorycznie, ale nie technicznie. Dzieje się tak np. wtedy, gdy zmieniono sposób obsługi danych w aplikacji i wcześniej trzeba wykonać aktualizację danych. Aplikacja nie zależy technicznie od aktualizacji danych, ale zależy od niej merytorycznie. Chociaż w takim przypadku aktualizacje można instalować pojedynczo, aplikacja nie będzie działać poprawnie. Pakietowanie aktualizacji zapobiega instalacji aplikacji bez wcześniejszej aktualizacji danych.
• Tworzenie dostaw wsparcia — każda dostawa wsparcia zawiera teksty opisujące lub wyjaśniające rozwiązanie problemu zawarte w tej dostawie wsparcia. Jednej dostawie wsparcia przypisuje się jedną pakietowaną aktualizację oprogramowania. Korzyści: każdej dostawie wsparcia towarzyszy opis zmian/korekt zawartych w dostawie wsparcia; pobieranie dostaw wsparcia i uproszczona logistyka aktualizacji. Dostawy wsparcia można wyszukiwać po opisie, a następnie pobierać. System wsparcia rejestruje ten proces, co umożliwia w dowolnym momencie sprawdzenie, kto pobrał daną dostawę wsparcia. Umożliwia to równie dokumentowanie dostawy.
• Zgłoszenia wsparcia, dokumentowanie błędów i zapytań — pracownicy, partnerzy lub klienci mogą tworzyć w tym systemie zgłoszenia wsparcia. Zgłoszenie wsparcia obejmuje każde przychodzące zapytanie, zgłoszenie błędu, prośbę itd.
• Sprawdzanie statusu zgłoszeń wsparcia — weryfikacja, czy zgłoszenie wsparcia jest w trakcie realizacji, czy zakończone oraz sprawdzenie, czy dostawy wsparcia przypisane do zgłoszenia wsparcia zostały dostarczone

Minimalne topologie systemu

Partnerski system deweloperski bez adaptacji

Sam partnerski system deweloperski powinien składać się co najmniej z dwóch systemów:

1. Partnerski system deweloperski (3 lub 4) (prefiks deweloperski partnera)
2. Przypisany system testowy (7)

Dodatkowo dla każdego klienta wymagane są następujące systemy:

1. System testowy DT (7) dla partnera. Jeśli to możliwe, system ten powinien zawierać przynajmniej częściowo rzeczywiste dane klienta. Dopóki realnie obsługiwany jest tylko jeden klient, punkt 2 lub 3 można pominąć.
2. System testowy klienta T (7) dla klienta
3. System produkcyjny klienta P (7)

Możliwe ścieżki transportowe:

Bezpośrednie zasilanie z partnerskiego systemu deweloperskiego

Bezpośrednie zasilanie nadaje się wyłącznie dla małych instalacji. Już przy jednej parze systemów klienta warto pakietować aktualizacje oprogramowania w partnerskim systemie deweloperskim. Ponadto zapewnia to automatycznie, że przekazywane będą wyłącznie przetestowane aktualizacje oprogramowania. Przy bezpośrednim zasilaniu, wraz ze wzrostem liczby systemów docelowych, rośnie prawdopodobieństwo utraty kontroli nad transportami.

Pakietowanie w partnerskim systemie testowym klienta

Ta opcja jest szczególnie przydatna w sytuacjach, gdy to sam klient instaluje aktualizacje oprogramowania i gdy celem jest ograniczenie liczby plików (aktualizacji oprogramowania). Więcej informacji można znaleźć w rozdziale Tworzenie dostawy wsparcia/pakietu aktualizacji oprogramowania.

Porównanie powyższych wariantów pokazuje dwa różne koncepcje dystrybucji:

1. Dystrybucja gwiaździsta z jednego systemu źródłowego do wszystkich możliwych systemów docelowych.
2. Każdy system przekazuje aktualizacje oprogramowania dokładnie do jednego innego systemu.

Z punktu widzenia zapewnienia jakości lepsze jest podejście drugie. Gwarantuje ono, że żadna aktualizacja oprogramowania nie trafi do systemu produkcyjnego, dopóki nie zostanie zaimportowana do powiązanego systemu testowego. Pierwsze podejście generuje niewielki dodatkowy nakład pracy przy małych instalacjach. Przykładowo wszystkie aktualizacje oprogramowania, które mają zostać przekazane jako grupa, można zebrać, a następnie nagrać na płytę CD. Takiej płyty CD można potem użyć do aktualizacji wszystkich systemów docelowych. W tym przypadku terminy importu aktualizacji oprogramowania muszą być ustalane ręcznie.

Partnerski system deweloperski z adaptacją

Sam partnerski system deweloperski powinien składać się co najmniej z dwóch systemów:

1. Partnerski system deweloperski (3 lub 4) (prefiks deweloperski partnera)
2. Przypisany system testowy (7)
3. System QA, który zawsze zawiera ostatnio dostarczony stan. W tym systemie można analizować błędy, co pozwala zawęzić błędy do tych, które powstały w systemie adaptacji.

Dla każdego klienta wymagającego adaptacji potrzebne są następujące systemy:

1. System adaptacji DV (6) (prefiks deweloperski klienta)
2. System testowy DT (7). Jeśli to możliwe, system ten powinien zawierać przynajmniej częściowo rzeczywiste dane klienta.
3. System testowy klienta T (7) dla klienta
4. System produkcyjny klienta P (7)

Dla tego rozwiązania istnieje kilka możliwych ścieżek transportowych. Aktualizacje oprogramowania z systemów deweloperskich są wysyłane bezpośrednio do systemów niższego szczebla albo są najpierw pakietowane w powiązanym systemie testowym.

Topologia systemu może być kombinacją rozwiązania branżowego bez adaptacji klienta oraz z adaptacją klienta. System adaptacji klienta musi istnieć tylko dla tych klientów, którzy wymagają adaptacji.

Adaptacja (bez partnerskiego systemu deweloperskiego)

W przypadku braku partnerskiego systemu deweloperskiego wymagane są co najmniej następujące systemy:

1. System adaptacji klienta DV (6) dla partnera (prefiks deweloperski klienta)
2. System testowy DT (7) dla partnera. Jeśli to możliwe, system ten powinien zawierać rzeczywiste dane klienta,
3. System testowy T (7) dla klienta
4. System produkcyjny P (7)

Dla tego rozwiązania istnieje również kilka możliwych ścieżek transportowych. Aktualizacje oprogramowania z systemu adaptacji klienta są wysyłane bezpośrednio do systemów niższego szczebla albo są pakietowane w powiązanym systemie testowym DT, a następnie przekazywane do systemów T i P.

Systemy produkcyjne bez adaptacji i bez partnerskiego systemu deweloperskiego

1. System testowy DT (7) dla partnera. Jeśli to możliwe, system ten powinien zawierać przynajmniej częściowo rzeczywiste dane klienta.
2. System testowy T (7) dla klienta
3. System produkcyjny P (7)

Oprogramowanie firmy Comarch Software und Beratung AG może zostać ponownie pakietowane w systemie DT albo wysłane bezpośrednio do systemów T i P.

Możliwe ścieżki transportu:

Schematyczna prezentacja złożonej topologii systemu

Poniższy schemat przedstawia dużą topologię z optymalnymi ścieżkami transportowymi. Dzięki temu aktualizacje oprogramowania nigdy nie będą importowane do systemów produkcyjnych zbyt wcześnie. Jak opisano powyżej, cały rozdział Partnerski system deweloperski lub rozdział Adaptacja klienta może nie mieć zastosowania.

Konfiguracja topologii transportowej

Systemy Comarch ERP Enterprise tworzą topologię transportową, w której pomiędzy poszczególnymi systemami mogą występować zależności. Zależności te definiują ścieżkę transportową, którą podąża aktualizacja oprogramowania, aż trafi do systemu produkcyjnego.

W tym rozdziale opisano możliwe topologie transportowe, zależności transportowe pomiędzy systemami Comarch ERP Enterprise oraz ustawienia systemowe, które należy wykonać w panelu systemowym.

Konwencje

• Systemy deweloperskie są przedstawiane na grafach kolorem niebieskim.
• Systemy Comarch ERP Enterprise o poziomie wersjonowania 7 są przedstawiane na grafach kolorem zielonym.
• Opcjonalne (logiczne) ścieżki transportowe są przedstawiane przerywaną strzałką. Są one również nazywane zabezpieczonymi ścieżkami transportowymi.
• Obowiązkowe (fizyczne lub wymagane) ścieżki transportowe są przedstawiane ciągłą strzałką. Są one również nazywane niezabezpieczonymi ścieżkami transportowymi.

Zalecana topologia transportowa

Zalecana topologia transportowa w sposób spójny wykorzystuje wszystkie funkcje oferowane przez Comarch ERP Enterprise do wspierania procesu rozwoju, zapewnienia jakości oraz logistyki aktualizacji oprogramowania.

W zalecanej topologii transportowej dla partnera wykorzystywane są następujące systemy Comarch ERP Enterprise:

• system zapewnienia jakości (QAS) do dystrybucji dostarczonych aktualizacji oprogramowania. QAS może zostać włączony w kilku miejscach topologii transportowej.
• system wewnętrzny (INT) do korzystania z usługi obsługi zleceń deweloperskich oraz do zarządzania dostawami wsparcia
• systemy deweloperskie (partnerski system deweloperski lub systemy adaptacji)
• systemy testowe
• systemy demo

Na końcu dla klienta konfiguruje się system testowy produkcji oraz system produkcyjny.

Kiedy instaluje się poszczególne systemy?

Od momentu zawarcia umowy, poprzez możliwe fazy rozwoju i adaptacji, aż do uruchomienia w pełni operacyjnego systemu Comarch ERP Enterprise może minąć kilka miesięcy. Systemy Comarch ERP Enterprise wykorzystywane w kolejnych fazach projektu są zwykle instalowane w różnych momentach. Istnieje kilka opcji, jednak muszą zostać spełnione określone warunki wstępne.

Na początku instaluje się system dostawczy Comarch ERP Enterprise (wydanie utrzymaniowe). Na jego podstawie można skonfigurować QAS, system wewnętrzny, partnerski system deweloperski i partnerski system testowy oraz systemy adaptacji (deweloperski i testowy).

Zasadniczo systemy deweloperskie i testowe muszą zostać skonfigurowane na podstawie tego samego stanu kodu, a wszystkie aktualizacje oprogramowania wyeksportowane z systemu deweloperskiego muszą zostać zaimportowane do systemu testowego. Dodatkowo istnieje możliwość instalacji systemów jako oczyszczonej kopii. Więcej informacji można znaleźć w INF-000337: Copying and Cleaning Up a Comarch ERP Enterprise System.

Partnerski system deweloperski na poziomie kontroli wersji 3 lub 4 może obejmować bardzo rozbudowane rozszerzenia systemu i tworzenie nowych obiekty deweloperskich, co skutkuje powstawaniem dużej liczby aktualizacji oprogramowania. Wszystkie powstałe aktualizacje oprogramowania muszą zostać zaimportowane do systemu testowego. Jeśli system testowy jest instalowany później niż system deweloperski, to w miarę postępu rozwoju coraz mniej czasochłonne (w porównaniu do ciągłego importowania aktualizacji oprogramowania) staje się przygotowanie systemu testowego jako oczyszczonej kopii systemu deweloperskiego. Jest to szczególnie istotne, gdy rozwój osiągnął zdefiniowany stan i od tego momentu oczekuje się głównie korekt.

Podobna sytuacja dotyczy systemów adaptacji. Jeżeli trzeba wprowadzić tylko niewiele zmian, system testowy powinien zostać skonfigurowany niezwłocznie na podstawie tego samego wydania utrzymaniowego. Jeśli testowy system adaptacji jest konfigurowany później, należy albo zastosować przy instalacji ten sam stan systemu co w systemie adaptacji i wdrożyć wszystkie utworzone aktualizacje oprogramowania, albo użyć oczyszczonej kopii systemu adaptacji. Więcej informacji można znaleźć w INF-000337: Copying and Cleaning Up a Comarch ERP Enterprise System.

Jeśli system adaptacji jest oparty na partnerskim systemie deweloperskim, wymagane jest jedno z poniższych podejść:

• adaptacja musi zostać skonfigurowana z tym samym wydaniem utrzymaniowym co partnerski system deweloperski, a wszystkie utworzone aktualizacje oprogramowania muszą zostać zaimportowane
• system jest instalowany jako oczyszczona kopia partnerskiego systemu deweloperskiego, jeśli aktualizacje oprogramowania nie są pakietowane w partnerskim systemie testowym
• system jest instalowany jako oczyszczona kopia partnerskiego systemu testowego, jeśli aktualizacje oprogramowania są pakietowane w partnerskim systemie testowym

Systemy konfigurowane w środowisku produkcyjnym muszą zostać przygotowane albo na podstawie wydania utrzymaniowego i z tym samym stanem kodu co nadrzędny system deweloperski, albo jako oczyszczona kopia nadrzędnego systemu testowego, w którym aktualizacje oprogramowania są pakietowane.

Ścieżki transportowe i grupy systemów

Ścieżka transportowa opisuje drogę, jaką zmiana obiekty deweloperskie w postaci aktualizacji oprogramowania przechodzi przez zaangażowane systemy, zanim zostanie ostatecznie zaimportowana do systemu produkcyjnego.

Systemy połączone ścieżką transportową zwykle pochodzą zawsze z tego samego głównego wydania Comarch ERP Enterprise VxRy.

Systemy połączone w ramach ścieżki transportowej tworzą grupę systemów.

Przykłady grup systemów

Z perspektywy partnera grupa systemów zaczyna się od pierwszego systemu deweloperskiego, którym zarządza. Może to być partnerski system deweloperski albo system adaptacji. Do odpowiedniej grupy systemów należą również nadrzędne systemy firmy Comarch Software und Beratung AG jako źródło wszystkich grup systemów Comarch ERP Enterprise. Nie będą one jednak dalej omawiane.

Podane tutaj przykłady ścieżek transportowych mają wyłącznie charakter ilustracyjny.

Grupa systemów dla partnerskiego systemu deweloperskiego

Wszystkie zmiany wytworzone w partnerskim systemie deweloperskim i przeniesione do systemu produkcyjnego muszą zostać przetransportowane przez wszystkie systemy w ścieżce transportowej znajdujące się w górę od systemu produkcyjnego, w których aktualizacje oprogramowania są pakietowane albo które są systemami deweloperskimi.

Zmiany powstające w systemie adaptacji są transportowane wyłącznie przez systemy niższego szczebla należące do tego systemu adaptacji.

Transporty krzyżowe pomiędzy poszczególnymi gałęziami grup systemów są możliwe tylko raz – na początku rozwoju jednej z gałęzi.

Każdy system ma tylko jeden bezpośredni system nadrzędny, który jest zdefiniowany przez określenie ograniczeń importu. Nie ma już możliwości zmiany systemu poprzednika, gdy tylko pierwsze aktualizacje oprogramowania zostały zaimportowane z tego systemu poprzednika.

Grupa systemów do adaptacji

Jeżeli system nie jest wykorzystywany do partnerskiego systemu deweloperskiego, poszczególne systemy oparte na systemach adaptacji tworzą samodzielne grupy systemów.

Transporty krzyżowe pomiędzy poszczególnymi gałęziami grup systemów są możliwe tylko raz – na początku rozwoju jednej z gałęzi.

W tym scenariuszu systemy adaptacji są konfigurowane jako kopia wydania utrzymaniowego.

Przykłady ścieżek transportowych

Zabezpieczona ścieżka transportowa

Zmiana lub korekta zaimportowana do systemu poprzez aktualizację oprogramowania może zostać pakietowana w danym systemie razem z innymi aktualizacjami oprogramowania i utworzyć nową aktualizację oprogramowania. Poniższe grafy przedstawiają połączenia pomiędzy systemami za pomocą linii przerywanej, jeśli system poprzedzający dostarcza pikietowane aktualizacje oprogramowania.

Ścieżka transportowa jest uznawana za zabezpieczoną, jeśli wszystkie systemy uczestniczące w ścieżce transportowej są zasilane aktualizacją oprogramowania dokładnie w tej kolejności. W szczególności wykorzystanie systemów testowych zapewnia prawidłowe działanie importów aktualizacji oprogramowania oraz to, że wszystkie wymagane aktualizacje oprogramowania zostaną zaimportowane. Dzięki temu nie występują nierozwiązane zależności. Zastosowanie systemów testowych zapewnia nie tylko techniczną spójność aktualizacji oprogramowania, ale także możliwość przetestowania poprawności ERP zaimportowanych aktualizacji oprogramowania przy stanie kodu obecnym w systemie niższego szczebla.

W przedstawieniu systemy deweloperskie (poziom kontroli wersji 1, 2, 3, 4, 6) są oznaczone kolorem niebieskim, a systemy produkcyjne, testowe i demo (poziom kontroli wersji 7) – kolorem zielonym.

System wewnętrzny, używany do zarządzania zleceniami deweloperskimi oraz dostawami wsparcia, jest systemem poziomu 7 i został tutaj wyróżniony innym kolorem niż pozostałe systemy, ponieważ jest wykorzystywany między wydaniami. Jednak jest on zasilany aktualizacjami oprogramowania tylko z jednego wydania.

Aktualizacje oprogramowania systemu korekt firmy Comarch Software und Beratung AG są pakietowane w testowym systemie korekt.

Aktualizacje oprogramowania wyeksportowane z tego systemu poziomu 2 są udostępniane jako pliki babel-* w centrum wsparcia Comarch.

Aktualizacje oprogramowania udostępnione przez centrum wsparcia są importowane do QAS. QAS nie służy do pakietowania aktualizacji oprogramowania, lecz stanowi środek dystrybucji do pozostałych systemów.

Z QAS aktualizacje oprogramowania są przekazywane przez funkcję Aktualizuj system docelowy do następujących systemów:

• system wewnętrzny
• standardowe systemy demo
• partnerski system deweloperski
• systemy adaptacji

Następnie aktualizacje oprogramowania są importowane do systemów docelowych.

W wyniku rozszerzeń oraz obsługi konfliktów w partnerskim systemie deweloperskim lub w partnerskim systemie korekt deweloperskich generowane są nowe aktualizacje oprogramowania z nowym prefiksem eksportu.

Aktualizacje oprogramowania partnerskiego rozwoju/korekt są importowane do testowego systemu partnerskiego rozwoju i mogą być tam opcjonalnie pakietowane.

Zebrane aktualizacje oprogramowania są importowane do systemów adaptacji opartych na partnerskim systemie deweloperskim.

Aktualizacje oprogramowania utworzone w systemie adaptacji (opartym na standardowym rozwoju lub partnerskim systemie deweloperskim) są importowane do odpowiedniego testowego systemu adaptacji i tam pakietowane.

Aktualizacje oprogramowania zebrane w testowym systemie adaptacji są najpierw importowane do testowego systemu produkcyjnego i mogą być tam z kolei pakietowane.

Na końcu udostępnione aktualizacje oprogramowania są importowane do systemu produkcyjnego.

Każdy system, do którego importowane są aktualizacje oprogramowania, zmienia nazwy tych aktualizacji i eksportuje je z nowym prefiksem eksportu albo pakietuje je z innymi aktualizacjami oprogramowania, tworząc nową aktualizację oprogramowania.

W tym ujęciu pakietowanie aktualizacji oprogramowania można traktować jako ponowne zebranie lub połączenie aktualizacji oprogramowania w nowy pakiet pod nową nazwą. Informacje o aktualizacjach oprogramowania zawartych w nowym pakiecie są zachowywane i można je przeglądać w aplikacji Aktualizacje oprogramowania.

Jeżeli systemy testowe są wykorzystywane do pakietowania, dla ograniczenia importu bezpośrednio do systemu niższego szczebla obowiązuje następująca zasada:

1. Poziom kontroli wersji systemu poprzedzającego jest zawsze poziomem systemu deweloperskiego.
2. Prefiks eksportu jest prefiksem eksportu testowego systemu deweloperskiego.

Niebezpieczna ścieżka transportu

Zmiany w obiektach deweloperskich powstają wyłącznie w systemach rozwojowych. Jeżeli wynikowe aktualizacje oprogramowania (SA) nie zostaną dalej scalone, te SA mogą być równolegle wgrane do bezpośrednio następujących systemów. Systemów znajdujących się na ścieżce transportu nie można ani nie wolno pomijać. W tym scenariuszu do danego systemu można i wolno wgrać wyłącznie SA pochodzące z bezpośrednio poprzedzającego systemu rozwojowego.

Ścieżka transportu jest niezabezpieczona, jeśli SA utworzone w systemie rozwojowym mogą zostać wgrane do systemu następczego bez scalenia lub przetestowania w systemie testowym.

Począwszy od systemu rozwojowego, w którym wprowadzono zmianę, SA w drodze do systemu produkcyjnego musi również przejść przez wszystkie kolejne systemy rozwojowe znajdujące się na ścieżce transportu, zanim będzie mogła zostać wgrana do systemu o poziomie 7.

Na powyższym grafie systemy deweloperskie (poziom wersjonowania 1, 2, 3, 4 lub 6) są wyróżnione kolorem niebieskim, a systemy produkcyjne, testowe i demonstracyjne (poziom wersjonowania 7) — kolorem zielonym. System wewnętrzny, wykorzystywany do zarządzania zleceniami deweloperskimi i dostawami oprogramowania, jest systemem poziomu 7 i został tu oznaczony innym kolorem niż pozostałe systemy, ponieważ jest używany niezależnie od wydań. Jest on jednak zasilany aktualizacjami systemu tylko z jednego wydania.

W niezabezpieczonej ścieżce transportu uczestniczą wyłącznie systemy, w których zmienia się wersja obiektów deweloperskich, czyli systemy deweloperskie i korekcyjne poziomu 1, 2, 3, 4 lub 6. Systemy produkcyjne są zasilane bezpośrednio z poprzedzającego systemu deweloperskiego.

W tym scenariuszu aktualizacje oprogramowania nie są scalane w żadnym z systemów. Dostarczane aktualizacje oprogramowania są zawsze scalonymi aktualizacjami oprogramowania, które powstały w systemie poziomu 1 i zostały scalone w systemie poziomu 7. Te aktualizacje oznaczone prefiksem babel- z kolei zawierają właściwe zmiany w aktualizacjach oprogramowania cisag-.

Udostępnione aktualizacje oprogramowania mogą zostać wykorzystane przez dział wsprcia do aktualizacji następujących systemów:

• QAS
• systemu wewnętrznego
• standardowych systemów demonstracyjnych
• partnerskiego systemu deweloperskiego lub partnerskiego systemu korekcyjnego
• systemów adaptacyjnych opartych na standardzie

Aktualizacje oprogramowania powstające w partnerskim systemie deweloperskim lub partnerskim systemie korekcyjnym mogą być bezpośrednio wgrywane do następujących systemów podrzędnych:

• partnerskiego systemu testowego
• partnerskich systemów demonstracyjnych
• systemów adaptacyjnych opartych na rozwoju partnerskim

Aktualizacje oprogramowania powstające w systemie adaptacyjnym mogą być bezpośrednio wgrywane do następujących systemów podrzędnych:

• powiązanego adaptacyjnego systemu testowego
• produkcyjnego systemu testowego
• systemu produkcyjnego

Jeżeli na ścieżce transportu nie korzysta się z funkcjonalności scalania aktualizacji oprogramowania to dla systemów podrzędnych oznacza to, że ograniczenia importu (poziom wersjonowania i wzorzec) muszą zostać ustawione na system deweloperski poprzednika (poziom i prefiks eksportu).

Jeżeli systemy testowe nie są wykorzystywane do scalania, obowiązują następujące zasady dotyczące ograniczeń importu systemu bezpośrednio podrzędnego:

• Poziom wersjonowania systemu poprzednika jest zawsze poziomem systemu deweloperskiego.
• Prefiks eksportu jest prefiksem eksportu poprzedzającego systemu deweloperskiego.

Na ścieżce transportu (czyli w zakresie systemów uczestniczących, do których wgrywane są aktualizacje oprogramowania) nic się nie zmienia także wtedy, gdy funkcja scalania aktualizacji oprogramowania nie jest używana, a jedynie poprzez działania organizacyjne zapewnia się, że aktualizacje oprogramowania przechodzą przez systemy w opisanej kolejności.

Jeżeli aktualizacje oprogramowania są wgrywane do systemów testowych w celu testów, ale nie są tam scalane przed wgraniem do systemów podrzędnych, to ograniczenia importu systemów — w porównaniu z przypadkiem, w którym nie używa się systemów testowych — nie ulegają zmianie.

Dla ograniczeń importu obowiązuje:

• Poziom wersjonowania systemu poprzednika jest zawsze poziomem systemu deweloperskiego.
• Prefiks eksportu jest prefiksem eksportu poprzedzającego systemu deweloperskiego.

Zasady te obowiązują również wtedy, gdy nie stosuje się deweloperskiego systemu testowego, a system deweloperski zasila bezpośrednio systemy podrzędne.

Ustawienia systemu

W poniższym rozdziale wyszczególniono niezbędne ustawienia dla poszczególnych systemów, wymagane dla opisanego w danym przypadku zastosowania.

Każdy system wymaga własnego zainstalowanego systemu ERP-Enterprise, który powstaje na podstawie dostarczonych plików oraz importów bazy danych z wydania serwisowego, albo został udostępniony przez partnera jako wydanie serwisowe rozwoju partnerskiego.

Ustawienia są wprowadzane w aplikacji Panel System. Wiele ustawień wynika z licencji systemowej, której wymaga każdy system (szczegóły w dokumentacji dotyczącej licencjonowania). Pozostałe ustawienia niezbędne do działania systemu są opisane w dokumentacjach dotyczących instalacji nowego systemu Comarch ERP Enterprise.

Poniżej wymieniono ustawienia dla następujących systemów:

• System demonstracyjny — system demonstracyjny oparty na standardowym wydaniu serwisowym
• QAS450PAR — QAS wydania Comarch ERP Enterprise 4.5 partnera o skrócie PAR
• INT450PAR — system wewnętrzny wydania Comarch ERP Enterprise 4.5 partnera o skrócie PAR
• PAR450DV — partnerski system deweloperski (DV – Development) wydania Comarch ERP Enterprise 4.5 partnera o skrócie PAR
• PAR450DT — partnerski system testowy dla rozwoju (DT – Development Test) wydania Comarch ERP Enterprise 4.5 partnera o skrócie PAR
• CU450DV — system adaptacyjny (DV – Development) utworzony w oparciu o wydanie Comarch ERP Enterprise 4.5 dla klienta o skrócie CUS (Customer)
• CU450DT — system testowy adaptacji (DT – Development Test) utworzony w oparciu o wydanie Comarch ERP Enterprise 4.5 dla klienta o skrócie CUS (Customer)
• CU450T — produkcyjny system testowy (T – Test) utworzony w oparciu o wydanie Comarch ERP Enterprise 4.5 dla klienta o skrócie CUS (Customer)
• CU450P — system produkcyjny (P – Productive System) utworzony w oparciu o wydanie Comarch ERP Enterprise 4.5 dla klienta o skrócie CUS (Customer)

Zastosowane skróty PAR (skrót partnera) i CUS (skrót klienta) należy zastąpić konkretnymi oznaczeniami.

Systemy demonstracyjne

Zainstalowane wydanie serwisowe (np. CIS450PBOR) może być początkowo wykorzystywane wyłącznie jako system demonstracyjny. Niezbędne ustawienia systemowe dla zastosowania jako system demonstracyjny są już skonfigurowane.

Systemy zapewnienia jakości

System Quality Assurance (QAS) jest tworzony na podstawie plików instalacyjnych dla systemu demonstracyjnego. Do działania nie wymaga źródeł Java. Jest jednak wykorzystywany do testowania wgrywania klas oraz źródeł Java.

Z poziomu QAS można doprowadzić logicznie podrzędne systemy, takie jak systemy demonstracyjne, partnerski system deweloperski lub systemy adaptacyjne, do wymaganego stanu za pomocą funkcji aktualizacji systemu docelowego.

Ograniczenia importu

System zleceń deweloperskich – system wewnętrzny

System wewnętrzny jest tworzony na podstawie plików instalacyjnych dla systemu demonstracyjnego. Do działania nie wymaga źródeł Java. Służy do zarządzania zleceniami deweloperskimi między systemami deweloperskimi oraz między wydaniami. Ponadto przechowuje informacje dotyczące dostaw wsparcia.

Ograniczenia importu:

System wewnętrzny musi być utrzymywany w synchronizacji z systemami deweloperskimi, dla których zarządza zleceniami deweloperskimi, aby zachować niezbędne informacje dotyczące zadań deweloperskich.

Rozwój partnera

Jeżeli partner chce np. opracować rozwiązanie branżowe albo rozwijać funkcjonalność, która ma być udostępniana w kilku systemach adaptacyjnych, zasadne jest wykorzystanie partnerskiego systemu deweloperskiego.

Dzięki dwóm poziomom wersjonowania 3 – partnerski system deweloperski oraz 4 – partnerski system korekcyjny możliwe jest także rozdzielenie cyklu rozwoju na fazę rozwoju, w której API oraz model danych nie są jeszcze ostatecznie ustalone, oraz fazę korekcyjną, w której usuwane są wyłącznie błędy.

Konsekwencją takiego podejścia jest wydłużenie ścieżki transportu poprawek w standardzie aż do systemu produkcyjnego klienta, jeżeli systemy produkcyjne bazują na partnerskim systemie deweloperskim.

Ścieżka transportu wydłuża się dodatkowo, jeżeli po partnerskim systemie deweloperskim na ścieżce transportu znajduje się jeszcze indywidualny system adaptacyjny klienta.

Aktualizacja oprogramowania musi zostać przetransportowana przez wszystkie uczestniczące systemy i w systemach deweloperskich może prowadzić do zadań konfliktowych. Zadania konfliktowe muszą zostać rozwiązane, zanim powstałe aktualizacje oprogramowania będą mogły zostać przetransportowane dalej. Powstające aktualizacje oprogramowania mogą z kolei budować między sobą zależności, które opóźniają transport do kolejnego systemu.

Przy tworzeniu systemów wzdłuż ścieżki transportu należy spełnić określone warunki wstępne. Nie każdy system może zostać utworzony na bazie dowolnego wydania serwisowego.

Z tego względu wykorzystanie partnerskiego systemu deweloperskiego powinno być ściśle uzgodnione z działem wsparcia.

Partnerski system deweloperski oraz partnerski system testowy rozwoju są tworzone jednocześnie na podstawie jednego wydania serwisowego. Jeżeli partnerski system testowy rozwoju zostanie utworzony w późniejszym terminie, jest on tworzony jako oczyszczona kopia partnerskiego systemu deweloperskiego. Więcej informacji na ten temat można znaleźć również INF-000337: Kopiowanie i czyszczenie systemu Semiramis.

Języki wyświetlania i aktualizacje językowe

Zasadniczo w partnerskim systemie deweloperskim oraz w partnerskim systemie testowym rozwoju powinny być skonfigurowane jako języki wyświetlania wszystkie języki, które będą potrzebne w kolejnych systemach klienckich. Tylko w ten sposób możliwe jest tłumaczenie dostosowań w ramach rozwoju partnerskiego.

To, czy do dostarczania tłumaczeń rozwoju partnerskiego wykorzystywane będą aktualizacje językowe czy aktualizacje oprogramowania, zależy od zakresu wprowadzonych dostosowań oraz liczby systemów deweloperskich znajdujących się dalej na ścieżce transportu.

Jeżeli można założyć, że w kolejnych systemach deweloperskich powstanie niewiele konfliktów, zalecane jest wykorzystanie aktualizacji oprogramowania. Pozwala to uniknąć konieczności tworzenia nowych aktualizacji językowych.

W partnerskim systemie deweloperskim oraz w partnerskim systemie testowym rozwoju należy zainstalować aktualizacje językowe dla tych języków, które są wymagane w systemach podrzędnych. Do eksportu tłumaczeń z partnerskiego systemu deweloperskiego należy używać aktualizacji oprogramowania, a nie aktualizacji językowych. Aktualizacje oprogramowania należy następnie importować do partnerskiego systemu testowego rozwoju.

Należy rozważyć następujące scenariusze:

• Jeżeli w partnerskim systemie deweloperskim występują niewielkie dostosowania, do transportu zmian z partnerskiego systemu testowego rozwoju można wykorzystać aktualizacje oprogramowania. We wszystkich systemach podrzędnych musi być zainstalowana standardowa aktualizacja językowa.
• Jeżeli w partnerskim systemie deweloperskim występują rozległe dostosowania, które mogą prowadzić do wielu konfliktów w systemach podrzędnych, zalecane jest wykorzystanie aktualizacji językowych. W tym celu z systemu testowego eksportuje się dany język jako dostawę językową. Pozwala to uniknąć konfliktów w kolejnych systemach deweloperskich, np. w systemie adaptacyjnym klienta.

W aplikacji Konfiguracja, w obszarze Aktualizacje oprogramowania, w polu Języki eksportowalne można określić, dla których języków mają być tworzone odświeżenia tekstów.

Jeżeli nie mają być używane aktualizacje językowe, tzn. jeżeli dla każdego języka dostępnego w systemie ma być tworzony odświeżony tekst, w polu Języki eksportowalne w partnerskim systemie testowym rozwoju należy wprowadzić wartość *.

Jeżeli tłumaczenia mają być dostarczane za pomocą aktualizacji językowych, w polu Języki eksportowalne w partnerskim systemie testowym rozwoju należy wpisać język rozwoju. Pozostałe języki nie będą wówczas eksportowane jako odświeżenia tekstów.

Partnerski system deweloperski

Podstawą dla partnerskiego systemu deweloperskiego jest system partnerski dostarczony w ramach wydania serwisowego. Zawiera on źródła Java niezbędne do rozwoju. Wymaga własnego prefiksu deweloperskiego oraz prefiksu eksportu, które są udostępniane przez dział wsparcia.

Rozwój partnerski można rozpocząć na systemie poziomu 3 lub 4. Na poziomie 4 w środowisku deweloperskim wykonywane są rozszerzone kontrole; na tym poziomie nie jest już możliwe np. bezpośrednie usuwanie obiektów deweloperskich.

Ograniczenia importu:

Aplikacja Konfiguracja, funkcja Aktualizacje oprogramowania:

Rozwój partnera – system testowy

System testowy rozwoju partnera powinien być tworzony równolegle z partnerskim systemem deweloperskim i na bazie tego samego wydania serwisowego, aby wszystkie aktualizacje oprogramowania kiedykolwiek wgrane do systemu deweloperskiego mogły zostać wgrane również do systemu testowego.

Utworzenie go na bazie późniejszego wydania serwisowego nie jest możliwe. Aktualizacje oprogramowania powstałe w systemie deweloperskim mogą nie dać się wgrać do nowszego wydania serwisowego.

Ponieważ partnerski system testowy rozwoju może zasilać podrzędne systemy adaptacyjne aktualizacjami oprogramowania, musi — podobnie jak partnerski system deweloperski — zostać utworzony na bazie systemu partnerskiego dostarczonego w ramach wydania serwisowego, który zawiera źródła Java.

Jeżeli system testowy zostanie utworzony później niż partnerski system deweloperski, wówczas wykorzystywana jest oczyszczona kopia systemu deweloperskiego. Więcej informacji można znaleźć również INF-000337: Kopiowanie i czyszczenie systemu Semiramis. Jeżeli jako szablon instalacyjny zostanie użyty oczyszczony partnerski system deweloperski, należy wykorzystać skopiowane źródła partnerskiego systemu deweloperskiego. Procedura czyszczenia systemu jest opisana w podręczniku systemu.

Ograniczenia importu:

Ustalenie, czy partnerski system testowy rozwoju ma być wykorzystywany do scalania aktualizacji oprogramowania, nie może zostać dokonane poprzez ustawienia systemu.

Aplikacja Konfiguracja, funkcja Aktualizacje oprogramowania:

Systemy adaptacyjne

Zmiany wprowadzane w systemie adaptacyjnym są indywidualne dla klienta i zazwyczaj nie mogą być bezpośrednio wykorzystane w innych projektach. System adaptacyjny może bazować na rozwoju partnerskim albo na systemie standardowym.

Systemy adaptacyjne (testowy i deweloperski) są tworzone jednocześnie na podstawie wydania serwisowego, jeżeli bazują na systemie standardowym lub na podstawie oczyszczonej kopii partnerskiego systemu deweloperskiego, jeżeli nie jest wykorzystywany system testowy albo aktualizacje oprogramowania nie są scalane w systemie testowym lub na podstawie oczyszczonej kopii partnerskiego systemu testowego rozwoju, jeżeli w tym systemie aktualizacje oprogramowania z partnerskiego systemu deweloperskiego są scalane.

Jeżeli adaptacyjny system testowy jest tworzony w późniejszym terminie niż system adaptacyjny, wówczas jest on zakładany jako oczyszczona kopia systemu adaptacyjnego.

Adaptacja oparta na partnerskim systemie deweloperskim

Systemy adaptacyjne bazujące na partnerskim systemie deweloperskim są instalowane znacznie później niż sam partnerski system deweloperski. Dla systemów adaptacyjnych opartych na rozwoju partnerskim nie można użyć najnowszego standardowego wydania serwisowego.

Należy użyć oczyszczonej kopii partnerskiego systemu testowego rozwoju, jeżeli aktualizacje oprogramowania są tam scalane. Należy użyć oczyszczonej kopii partnerskiego systemu deweloperskiego, jeżeli aktualizacje oprogramowania nie są scalane w systemie testowym. Procedura czyszczenia systemu jest opisana w podręczniku systemowym. Dodatkowe informacje dotyczące kopiowania i czyszczenia systemów znajdują się również w INF-000337: Kopiowanie i czyszczenie systemu Semiramis.

Ograniczenia importu, jeżeli w partnerskim systemie testowym rozwoju aktualizacje oprogramowania są scalane:

Ograniczenia importu, jeżeli aktualizacje oprogramowania nie są scalane:

Adaptacja oparta na rozwoju standardowym

Do utworzenia systemu adaptacyjnego opartego na rozwoju standardowym należy użyć zawsze najnowszego wydania serwisowego. Należy wykorzystać dostarczony system partnerski zawierający źródła Java.

Ograniczenia importu:

Adaptacyjny system testowy

Adaptacyjny system testowy jest instalowany jednocześnie z systemem adaptacyjnym i na bazie tego samego systemu źródłowego.

Dla systemu adaptacyjnego opartego na rozwiązaniu partnerskim wykorzystywana jest oczyszczona kopia partnerskiego systemu testowego rozwoju.

Dla adaptacyjnego systemu testowego opartego na rozwoju standardowym stosowane jest to samo wydanie serwisowe co dla systemu adaptacyjnego. Można użyć wersji demonstracyjnej wydania serwisowego bez źródeł Java, ponieważ adaptacyjny system testowy nie musi zasilać żadnych systemów podrzędnych wykorzystywanych do rozwoju.

Alternatywnie możliwe jest skopiowanie systemu adaptacyjnego i jego oczyszczenie.

System testowy służy do testowania oraz scalania zmian powstałych w systemie adaptacyjnym.

Ograniczenia importu:

System produkcyjny

U klienta musi istnieć system testowy, do którego wgrywane są dostarczone aktualizacje oprogramowania. System testowy służy również do testowania wprowadzonych zmian na rzeczywistych danych klienta oraz do ich scalania, zanim zostaną one wgrane do systemu produkcyjnego.

Systemy produkcyjne (produkcyjny system testowy oraz system produkcyjny) są tworzone jednocześnie na podstawie:

• wydania serwisowego, jeżeli nie mają być wykonywane żadne adaptacje
• oczyszczonej kopii adaptacyjnego systemu testowego, jeżeli w adaptacyjnym systemie testowym aktualizacje oprogramowania są scalane, a systemy produkcyjne są tworzone znacznie później niż systemy adaptacyjne
• tego samego wydania serwisowego co poprzedzające systemy adaptacyjne, jeżeli w adaptacyjnym systemie testowym aktualizacje oprogramowania nie są scalane i wszystkie utworzone tam aktualizacje oprogramowania są wgrywane do systemów produkcyjnych
• oczyszczonej kopii adaptacyjnego systemu testowego, w którym aktualizacje oprogramowania nie są scalane, ale wszystkie aktualizacje oprogramowania z systemu adaptacyjnego zostały wgrane

Produkcyjny system testowy

Systemy produkcyjne są z reguły tworzone znacznie później niż partnerskie systemy deweloperskie. Natomiast odstęp czasowy między instalacją systemu adaptacyjnego a systemami produkcyjnymi jest zazwyczaj niewielki.

Jeżeli systemy produkcyjne bazują bezpośrednio na rozwoju partnerskim, system produkcyjny musi zostać utworzony jako oczyszczona kopia partnerskiego systemu testowego rozwoju. Nie jest możliwe użycie aktualnego wydania serwisowego.

Jeżeli rozwój bazuje na adaptacji, system produkcyjny musi zostać utworzony na bazie tego samego systemu co system adaptacyjny i adaptacyjny system testowy. Należy zainstalować wszystkie aktualizacje oprogramowania wyeksportowane z adaptacyjnego systemu testowego (jeżeli aktualizacje oprogramowania są scalane) albo z systemu adaptacyjnego (jeżeli aktualizacje oprogramowania nie są scalane). Alternatywnie można użyć oczyszczonej kopii adaptacyjnego systemu testowego.

Jeżeli rozwój bazuje na standardzie, do instalacji systemów produkcyjnych należy użyć edycji demonstracyjnej aktualnego wydania serwisowego. System ten nie zawiera źródeł Java.

Do systemu produkcyjnego nie są wgrywane źródła Java (.sr refreshes), jeżeli obszar Rozwój oprogramowania nie jest licencjonowany.

Ograniczenia importu, jeżeli w systemach adaptacyjnych aktualizacje oprogramowania nie są scalane:

Ograniczenia importu, jeżeli system bazuje na partnerskim systemie deweloperskim i aktualizacje oprogramowania nie są scalane:

Ograniczenia importu, jeżeli system bazuje na partnerskim systemie testowym rozwoju, w którym aktualizacje oprogramowania są scalane:

Ograniczenia importu, jeżeli system bazuje na partnerskim systemie testowym rozwoju, w którym aktualizacje oprogramowania są scalane:

Ograniczenia importu, jeżeli system bazuje na standardzie:

System produkcyjny

Jeżeli system produkcyjny bazuje bezpośrednio na rozwoju partnerskim, musi zostać utworzony jako oczyszczona kopia partnerskiego systemu testowego rozwoju. Nie jest możliwe użycie nowszego wydania serwisowego.

Jeżeli rozwój bazuje na adaptacji, system produkcyjny musi zostać utworzony na bazie tego samego systemu co system adaptacyjny i adaptacyjny system testowy. Wszystkie aktualizacje oprogramowania muszą zostać przeniesione. Alternatywnie można użyć oczyszczonej kopii adaptacyjnego systemu testowego.

Jeżeli rozwój bazuje na standardzie, należy użyć edycji demonstracyjnej aktualnego wydania serwisowego, która nie zawiera źródeł.

Do systemu produkcyjnego nie są wgrywane źródła Java (.sr refreshes).

Ograniczenia importu, jeżeli w produkcyjnym systemie testowym aktualizacje oprogramowania są scalane:

Ograniczenia importu, jeżeli w adaptacyjnym systemie testowym aktualizacje oprogramowania są scalane, ale w produkcyjnym systemie testowym nie:

Ograniczenia importu, jeżeli istnieje system adaptacyjny, ale aktualizacje oprogramowania nie są scalane:

Ograniczenia importu, jeżeli system bazuje na partnerskim systemie deweloperskim i aktualizacje oprogramowania nie są scalane:

Ograniczenia importu, jeżeli system bazuje na partnerskim systemie testowym rozwoju, w którym aktualizacje oprogramowania są scalane:

Ograniczenia importu, jeżeli system produkcyjny bazuje na standardzie:

Przykłady innych topologii systemu

Pomija się przedstawienie najprostszego przypadku, w którym system produkcyjny bazuje bezpośrednio na rozwoju standardowym.

Niezabezpieczona minimalna topologia transportu

W minimalnej topologii transportu aktualizacje oprogramowania są wgrywane bezpośrednio do partnerskich systemów deweloperskich lub systemów adaptacyjnych, a powstałe w ten sposób aktualizacje oprogramowania są następnie wgrywane do systemów produkcyjnych bez dodatkowych testów.

W przedstawionej konfiguracji przynajmniej wgrywanie aktualizacji oprogramowania do produkcyjnego systemu testowego oraz systemu produkcyjnego musi następować w różnych momentach, aby umożliwić minimalny test.

Taka topologia transportu jest możliwa, jednak ze względu na ograniczone możliwości zapewnienia jakości zdecydowanie odradza się stosowanie takiej konfiguracji.

Późniejsze dodanie kolejnych systemów do ścieżki transportu nie jest automatycznie możliwe.

Mieszana topologia transportu

W mieszanej topologii transportu dla części systemów wykorzystywana jest funkcjonalność scalania aktualizacji oprogramowania, natomiast w przypadku prostszych systemów można ewentualnie zrezygnować z tego działania zapewniającego jakość. W ramach rodzin systemów istnieją więc bezpieczne i niezabezpieczone ścieżki transportu.

Przed systemem produkcyjnym zawsze musi istnieć co najmniej jeden system testowy.

Późniejsza zmiana ścieżki transportu z bezpośredniego zasilania przez system deweloperski na zasilanie przez system testowy, który scala aktualizacje oprogramowania, nie jest automatycznie możliwa.

Pomiędzy systemem deweloperskim (rozwój partnera, system adaptacyjny) powinien znajdować się w topologii transportu co najmniej jeden system testowy.

System produkcyjny powinien zostać skonfigurowany poprzez ograniczenia importu w taki sposób, aby zawsze pobierał aktualizacje oprogramowania z systemu testowego, który scala aktualizacje oprogramowania.