Aplikacje oraz logika systemu Comarch ERP Enterprise są rozwijane w systemach deweloperskich. Powstałe aktualizacje oprogramowania mogą być importowane do kolejnego systemu deweloperskiego w środowisku. Taki łańcuch systemów deweloperskich umożliwia specjalizację nadrzędnego rozwoju poprzez dostosowania.
Typowy łańcuch systemów deweloperskich obejmuje system deweloperski standardowy, system deweloperski działowy oraz system deweloperski klienta. Z systemu deweloperskiego standardowego wyprowadzanych jest kilka systemów deweloperskich działowych wraz z odpowiednimi aktualizacjami oprogramowania.
Każdy system deweloperski działowy zazwyczaj zasila wiele systemów deweloperskich klienta. Z reguły dla każdego klienta istnieje odrębny system deweloperski. Z perspektywy systemu deweloperskiego standardowego łańcuch dostaw ma strukturę drzewa. Z perspektywy systemu deweloperskiego klienta istnieje tylko jedna ścieżka prowadząca do systemu deweloperskiego standardowego.
Jeżeli to samo rozszerzenie jest wymagane w dwóch systemach deweloperskich, może ono zostać zaimplementowane w nadrzędnym systemie deweloperskim działowym lub w poszczególnych systemach deweloperskich. W przypadku realizacji w systemie deweloperskim działowym rozszerzenie jest dostępne również we wszystkich powiązanych systemach deweloperskich klienta, co w niektórych sytuacjach może być niepożądane. Jeśli rozszerzenie zostanie wykonane w indywidualnych systemach deweloperskich klienta, musi zostać wdrożone i aktualizowane oddzielnie w każdym z nich, co może prowadzić do błędów oraz różnic w statusie rozwoju. W najbardziej niekorzystnym przypadku dwa systemy deweloperskie klienta nie posiadają tego samego nadrzędnego systemu deweloperskiego działowego, co oznacza, że rozwój musiałby teoretycznie zostać zrealizowany w systemie deweloperskim standardowym.
Technologia aplikacji umożliwia zastosowanie nowych koncepcji w obszarze logistyki oprogramowania. Aplikacje są rozwijane w odrębnym systemie deweloperskim i mogą być importowane do systemów deweloperskich klienta. W tych systemach są dostępne jako rozszerzenia i transportowane standardową ścieżką transportową do systemu produkcyjnego.
Aplikacja może obejmować pojedyncze aplikacje wraz z ich logiką lub kompletne obszary zawierające wiele aplikacji i powiązaną logikę. Przy wykorzystaniu odpowiednich interfejsów możliwa jest integracja aplikacji z istniejącymi procesami. Rozwiązania, które dotychczas mogły być realizowane wyłącznie w klasycznych systemach deweloperskich, mogą być obecnie wdrażane alternatywnie w systemie deweloperskim aplikacji.
Niniejszy artykuł ma na celu przedstawienie możliwości oraz ograniczeń aplikacji, aby zapewnić ich prawidłowe i spójne wykorzystanie w procesie rozwoju.
Grupa docelowa
- Programiści
- Konsultanci techniczni
Czym jest aplikacja?
Aplikacja to zbiór obiektów deweloperskich oraz ich wersji, które mogą zostać zaimportowane do systemu deweloperskiego klienta jako rozszerzenie. Zakres aplikacji może obejmować pojedyncze obiekty deweloperskie aż po kompletne obszary zawierające wiele obiektów. Aplikacja różni się od standardowego rozwoju w Comarch ERP Enterprise. Technologia aplikacji umożliwia po raz pierwszy odejście od klasycznych ścieżek transportowych. Różnice te zostały szczegółowo opisane poniżej.
Opis procesu bez aplikacji
Proces rozwoju w Comarch ERP Enterprise przebiega w następujący sposób. W systemie deweloperskim standardowym tworzone i dostarczane są obiekty deweloperskie. Następnie są one transportowane za pomocą aktualizacji oprogramowania do systemu deweloperskiego branżowego, gdzie są dostosowywane do specyficznych wymagań. Obiekty deweloperskie wraz z wprowadzonymi dostosowaniami trafiają następnie do systemu deweloperskiego klienta. Tam mogą być realizowane kolejne dostosowania i rozszerzenia, przeznaczone w szczególności dla danego klienta. Ostateczny stan jest importowany do systemu produkcyjnego klienta.
Decyzja o tym, w którym systemie deweloperskim zostanie wykonane dane dostosowanie, zależy od liczby systemów, które wymagają tej zmiany. Jeżeli dostosowanie dotyczy wyłącznie jednego klienta, zazwyczaj realizowane jest w jego systemie deweloperskim. Jeżeli dostosowanie może zostać wykorzystane przez wszystkich klientów, wykonywane jest w systemie deweloperskim działowym. Możliwa jest zatem decyzja pomiędzy realizacją dla jednego klienta, dla wszystkich klientów lub na poziomie działu.
Jeżeli tylko wybrani klienci otrzymują dane rozszerzenie, rozwój musi zostać przeprowadzony w poszczególnych systemach deweloperskich klienta. W przypadku dalszego rozwoju lub konieczności usunięcia błędów prace muszą być prowadzone równolegle w kilku systemach. Procedury aktualizacji stają się bardziej złożone, jeżeli poszczególne systemy deweloperskie klienta posiadają różne statusy rozwoju.
Jeżeli rozszerzenia są realizowane w systemie deweloperskim działowym, można uniknąć równoległego rozwoju w systemach deweloperskich klienta, jednak rozszerzenia specyficzne dla klienta są wtedy dodawane do systemu działowego. Może to powodować błędy w innych środowiskach klientów oraz zwiększać koszty dostosowań i utrzymania.
Mogą również wystąpić sytuacje, w których wymagane jest rozszerzenie, którego realizacja wewnętrzna wiązałaby się ze znacznym wzrostem kosztów. Niezbędna wiedza specjalistyczna musiałaby zostać wcześniej pozyskana, co mogłoby czynić rozwój nieopłacalnym dla pojedynczego klienta. Pożądane byłoby wówczas nabycie odpowiednich komponentów od zewnętrznego dostawcy lub, w przypadku rozwoju wewnętrznego, udostępnienie ich innym partnerom. W środowisku bez aplikacji dostarczenie może odbywać się poprzez import/eksport. Procedura importu, obejmująca dostosowania, rozwiązywanie konfliktów itp., wymaga jednak znacznego nakładu pracy ręcznej. Nakład pracy wzrasta, jeżeli systemy, do których importowane są rozszerzenia, posiadają różne statusy systemowe i dostosowań. Dodatkowo dostosowania generują potencjalne konflikty. Należy określić, kto i w jaki sposób wprowadza zmiany oraz jaka procedura obowiązuje w przypadku błędu, jeżeli zarówno partner, jak i zewnętrzny dostawca chcą modyfikować te same obiekty deweloperskie. Jeszcze trudniejsza jest sytuacja, gdy dwa obiekty deweloperskie muszą zostać zmienione w sposób wzajemnie niekompatybilny. Aktualizacja rozwoju poprzez import/eksport XML wiąże się z dużym nakładem pracy ręcznej.
Wymagania wobec aplikacji
Opis procesu wskazuje, że w poszczególnych obszarach standardowe możliwości rozwoju stanowią rozwiązanie, jednak wiążą się z ograniczeniami i nie zawsze są ekonomicznie uzasadnione. Poniżej sformułowano oczekiwania i wymagania wobec aplikacji:
- Odporność na wersje (release-proof) — rozwój oraz późniejszy import aplikacji powinny w możliwie najmniejszym stopniu zależeć od statusu systemu, do którego aplikacja jest importowana. W idealnym przypadku powinny być niezależne od wersji systemu.
- Bezkonfliktowość — procedura importu powinna być możliwie bezkonfliktowa, aby uprościć procesy aktualizacji. Rozwój realizowany w ramach aplikacji nie może naruszać własnych rozszerzeń, co oznacza, że istniejące obiekty deweloperskie muszą pozostać niezmienione przez importowane obiekty.
W celu spełnienia tych wymagań należy przestrzegać określonych zasad oraz odpowiednio skonfigurować systemy deweloperskie. Szczegóły opisano poniżej.
Poprawka (fix)
Gdzie może być rozwijana aplikacja?
Aplikacja powinna móc zostać zaimportowana do możliwie największej liczby systemów. Wymagania dotyczące statusu systemu docelowego powinny być ograniczone do minimum. Istotnym wymogiem jest zainstalowany status obiektów deweloperskich oraz ich wersji.
W systemie deweloperskim Comarch ERP Enterprise istnieją zależności wobec innych aktualizacji oprogramowania. Zależności te stanowią podstawę do tego, że aktualizacja może zostać zaimportowana wyłącznie wtedy, gdy wymagane aktualizacje zależne zostały już zainstalowane lub są instalowane w tym samym procesie.
W środowisku Comarch ERP Enterprise występują różne systemy deweloperskie o odmiennym statusie. Jeżeli w jednym systemie wymagane są poprawki, są one transportowane w postaci aktualizacji oprogramowania do odpowiednich systemów. Mogą jednak istnieć systemy, które nie wymagają tych poprawek i w związku z tym posiadają starszy status.
Jeżeli aplikacja ma zostać zaimportowana do możliwie największej liczby systemów deweloperskich klienta, należy zapewnić, aby odwoływała się wyłącznie do tych obiektów deweloperskich oraz wersji, które są już dostępne w systemie docelowym lub są instalowane równolegle z aplikacją.
System, w którym rozwijana jest aplikacja, określa poprzez zainstalowane aktualizacje oprogramowania status, jaki musi posiadać co najmniej system, do którego aplikacja ma zostać zaimportowana. Ze względu na zależności aktualizacji oprogramowania aplikacje mogą być importowane wyłącznie do systemów posiadających co najmniej taki sam status jak system aplikacji. Aby możliwy był import aplikacji do możliwie największej liczby systemów, system aplikacji musi posiadać stary status.
Dla systemów deweloperskich w standardowym łańcuchu dostaw obowiązuje następująca zasada: system, który ma zostać zasilony, posiada co najmniej taki sam status jak ostatni system zasilający.
Aplikacja nie może być zatem rozwijana w jednym z systemów należących do standardowej ścieżki transportowej. Jeżeli jest to konieczne, odpowiedni system musi zostać podniesiony do statusu systemu, w którym opracowano aplikację, przed jej importem.
Aplikacje są tworzone w wewnętrznym systemie deweloperskim. System ten jest zazwyczaj zasilany z systemu deweloperskiego standardowego. Alternatywnie może być zasilany z systemu deweloperskiego działowego. Oznaczałoby to, że aplikacje mogłyby być importowane wyłącznie do systemów klienta zasilanych przez ten sam system działowy. Za systemem deweloperskim powinien następować system testowy, na którym przeprowadzane są testy oraz przygotowywane jest wydanie.
Które obiekty deweloperskie mogą być wykorzystywane w odwołaniach?
Obiekt deweloperski może ulegać zmianom w czasie. Zmiany są zazwyczaj wprowadzane w sposób zapewniający kompatybilność z poprzednimi wersjami. Może jednak wystąpić sytuacja, w której obiekt deweloperski przestaje być kompatybilny.
Obiekty deweloperskie wykorzystywane w aplikacji mogą odwoływać się do obiektów spoza aplikacji. Jeżeli obiekt, do którego następuje odwołanie, stanie się niekompatybilny, aplikacja może przestać działać.
W celu zapewnienia bezpieczeństwa rozwoju aplikacji niektóre obiekty deweloperskie są w Comarch ERP Enterprise oznaczone jako Stabilne. Obiekty te nie podlegają dalszym zmianom i pozostają niezmienne również poza granicami wersji. Jeżeli aplikacja zostanie zbudowana wyłącznie w oparciu o takie obiekty, istnieje większe prawdopodobieństwo jej wykorzystania w przyszłych wersjach bez konieczności dostosowań. W takim przypadku aplikacja staje się niezależna od wersji.
Bezkonfliktowość
Wymaganiem wobec aplikacji jest realizacja procedury importu w systemie z możliwie najmniejszą liczbą konfliktów. Konflikt w Comarch ERP Enterprise występuje w sytuacji, gdy zmieniony obiekt deweloperski jest importowany z nadrzędnego systemu deweloperskiego w nowej wersji. Oznacza to, że konflikt może powstać wyłącznie w odniesieniu do obiektów deweloperskich, które nie pochodzą z danego systemu. Muszą one pochodzić z jednego z systemów nadrzędnych, na przykład z systemu deweloperskiego standardowego lub działowego.
Drugim warunkiem jest to, że dany obiekt deweloperski został zmieniony w systemie deweloperskim, czyli utworzono jego nową wersję. Jeżeli następnie zostanie zaimportowana nowa wersja z systemu nadrzędnego, może dojść do konfliktu, ponieważ zawartość wersji zaimportowanej i wersji zmodyfikowanej prawdopodobnie różni się od siebie.
Jak wynika z przykładu, odpowiedzialność za scalenie obu wersji spoczywa na programiście. Konieczne jest podjęcie decyzji, które elementy i w jaki sposób mają zostać uwzględnione. Decyzja ta może być trudna, zwłaszcza gdy obiekt deweloperski został zmieniony w obu systemach, na przykład poprzez różne implementacje tej samej metody klasy Java. Sytuacja jest mniej problematyczna, gdy ta sama osoba odpowiadała za rozwój w systemie działowym. W przypadku zmian pochodzących z zewnętrznych źródeł proces jest bardziej złożony.
Jak opisano, konflikt występuje wyłącznie wtedy, gdy zmieniony zostaje obiekt deweloperski pochodzący z innego systemu deweloperskiego lub zewnętrznej przestrzeni nazw. Konfliktu można w prosty sposób uniknąć poprzez modyfikowanie wyłącznie obiektów deweloperskich z własnej przestrzeni nazw.
Jeżeli aplikacja ma być importowana bez konfliktów, powinna zawierać wyłącznie obiekty deweloperskie z własnej przestrzeni nazw. Jeżeli aplikacja obejmuje obiekty z innej przestrzeni nazw, może to prowadzić do konfliktów w tych obiektach.
Rozszerzenia
Jeżeli obiekty deweloperskie aplikacji znajdują się w odrębnej przestrzeni nazw i nie mogą być zmieniane inne obiekty deweloperskie, nie jest możliwa głęboka integracja, taka jak w przypadku dostosowań. W sytuacji, gdy nie wolno modyfikować „zewnętrznych” obiektów, pojawia się pytanie, w jaki sposób aplikacja ma być wywoływana, jak zostanie powiązana z istniejącymi procesami oraz w jaki sposób nowe pola pojawią się w interfejsie istniejących aplikacji.
Problemy te mogą zostać rozwiązane poprzez rozszerzenia. Zmiana lub dostosowanie oznacza, że kilka podmiotów może modyfikować ten sam zasób w sposób wzajemnie niekompatybilny. Rozszerzenia umożliwiają uzupełnienie zasobu o dodatkowe informacje bez wpływu na inne podmioty. Przykładem mogą być dodatkowe atrybuty w obiektach biznesowych. Jeżeli posiadają one unikalną nazwę, nie kolidują z istniejącymi elementami.
W związku z tym wszystkie obiekty deweloperskie w Comarch ERP Enterprise, które posiadają od 1 do n zależności, mogą być rozszerzane, o ile możliwe jest dodawanie dodatkowych instancji zależnych bez konfliktów.
Niektóre obiekty deweloperskie nie spełniają tego warunku i nie mogą być rozszerzane. Dotyczy to na przykład klas Java, logicznych typów danych, akcji itp.
Nie wszystkie rozszerzenia są celowe lub technicznie możliwe w obiektach, które zasadniczo można rozszerzać. Tabele tekstowe nie powinny być rozszerzane, ponieważ w przestrzeni nazw aplikacji można bez problemu utworzyć własną tabelę tekstową. Rozszerzenia typu ValueSet nie są obecnie technicznie możliwe. Nie można zagwarantować, że kilka aplikacji użyje tej samej wartości liczbowej dla elementu ValueSet. Nie można również zapewnić, że istniejąca logika będzie w stanie obsłużyć nowe wpisy. Może to prowadzić do niespójności danych.
W pierwszej kolejności zaimplementowano te rozszerzenia, które umożliwiają możliwie najgłębszą integrację aplikacji z istniejącym systemem.
Rozszerzenia
Jeżeli obiekt biznesowy wymaga nowych atrybutów, mogą one zostać utworzone w ramach rozszerzenia. Nowe atrybuty stają się składnikiem tabeli obiektu biznesowego w bazie danych. Zaletą tego rozwiązania jest automatyczne uwzględnianie atrybutów we wszystkich operacjach logiki, takich jak wczytywanie czy zapisywanie.
Rozszerzenia widoków obiektów
Obiekty ERP są w Comarch ERP Enterprise zarządzane w złożonych kontenerach, tzw. encjach APP. Oprócz dostępu do odczytu i zapisu danych kontenery zawierają również złożone operacje, takie jak dodawanie lub usuwanie obiektów zależnych. Dla encji APP można zdefiniować interfejs niezależny od wersji przy użyciu widoków obiektów. Dodatkowe właściwości dla istniejącego widoku obiektu mogą zostać dodane poprzez rozszerzenie widoku obiektu.
Rozszerzenia aplikacji
Konfigurowalne interfejsy umożliwiają klasyfikację elementów interfejsu aplikacji. Wynikowy układ jest zapisywany w rozszerzeniu aplikacji. Jeżeli w ramach aplikacji udostępniane są nowe pola dla istniejącej aplikacji, układ może zostać zapisany w dodatkowym rozszerzeniu aplikacji.
Rozszerzenia dla klas Java
Aby umożliwić integrację aplikacji z Comarch ERP Enterprise, aplikacje muszą zostać włączone do przebiegu programu. Klasy Java nie mogą być rozszerzane z przyczyn opisanych wcześniej. W związku z tym aplikacje muszą być uwzględniane w rozwoju standardowych klas Java. W określonych miejscach kodu źródłowego udostępniane są wywołania. Aby aplikacja mogła zostać wywołana w tych miejscach, musi się wcześniej zarejestrować.
W odniesieniu do obiektu deweloperskiego mechanizm ten określany jest jako hook contract.
Hook contracts są udostępniane w systemach deweloperskich należących do standardowej ścieżki transportowej, czyli w systemie deweloperskim standardowym oraz działowym. Aplikacja może zostać wywołana wyłącznie poprzez hook utworzony w tych systemach. System deweloperski aplikacji musi być zatem oparty na systemie, który udostępnia wymagane hooki.
Aplikacja może również udostępniać własne hook contracts. Mogą one być wykorzystywane w systemach, do których aplikacja została zaimportowana. Technologia ta może być zatem używana także do rozszerzania aplikacji bez konieczności jej modyfikacji.
Zastępowanie aplikacji
W klasie Java można określić klasy, które mają zostać zastąpione. Mechanizm ten działa również w aplikacjach w odniesieniu do klas Java. Przy wykorzystaniu zastąpień może wystąpić problem polegający na tym, że kilka klas Java z różnych źródeł próbuje zastąpić tę samą klasę. W takiej sytuacji nie można już zagwarantować bezkonfliktowego importu. Aplikacje nie powinny wykorzystywać mechanizmu zastępowania.
Rejestracje
W poprzednich wersjach Comarch ERP Enterprise centralne klasy w obszarze technicznym musiały być dostosowywane w celu realizacji rejestracji, na przykład dla importu/eksportu. Od wersji 5 rejestracje te są zapisywane w obiekcie deweloperskim business object registry. Odpowiednie rejestracje dla własnych obiektów biznesowych mogą być zatem realizowane bez konfliktów.
Tworzenie systemu aplikacji
Zgodnie z opisem w sekcji Independent of release, do tworzenia aplikacji wymagany jest odrębny system deweloperski. System ten obejmuje system deweloperski oraz system testowy deweloperski.
Systemy te są zazwyczaj tworzone jako kopia istniejącego systemu deweloperskiego lub na podstawie dostarczonego nośnika instalacyjnego. Obowiązują w tym zakresie te same zasady, które dotyczą systemów deweloperskich w dalszej części łańcucha.
Dla obu systemów wymagane są specjalne licencje. System deweloperski musi być zarejestrowany w ramach licencji app development system, natomiast system testowy w ramach licencji app development test system.
System, na podstawie którego utworzono system aplikacji, określany jest dalej jako system bazowy. Z tego systemu system aplikacji może być w razie potrzeby zasilany aktualizacjami oprogramowania.
Wybór systemu bazowego
Wybór systemu bazowego zależy przede wszystkim od systemów, do których aplikacje mają być importowane. Jeżeli wymagane są funkcjonalności dostępne wyłącznie w określonym systemie deweloperskim lub w systemach o wyższym poziomie, należy to uwzględnić przy podejmowaniu decyzji.
Jako podstawę systemu aplikacji należy wykorzystać system deweloperski standardowy lub system deweloperski działowy. Nie można wykorzystać systemu deweloperskiego klienta na poziomie rozwoju 6.
Standard development system (development level 1)
System aplikacji może zostać utworzony na podstawie dostarczonego nośnika instalacyjnego Comarch ERP Enterprise. Aplikacje utworzone w takim systemie mogą być importowane do wszystkich systemów deweloperskich klienta.
Department development system (development level 3, 4, or 5)
Jeżeli aplikacja zostanie utworzona na podstawie systemu deweloperskiego działowego, utworzone aplikacje mogą być importowane wyłącznie do systemów deweloperskich klienta zasilanych przez ten sam system działowy.
Taki system bazowy należy wybrać wyłącznie wtedy, gdy aplikacja ma wykorzystywać obiekty deweloperskie lub logikę specyficzną dla danego działu.
Tworzenie aplikacji
System deweloperski aplikacji może być wykorzystywany do tworzenia jednej lub wielu aplikacji. Każda aplikacja posiada w tym systemie unikalną nazwę. W połączeniu z prefiksem deweloperskim systemu tworzona jest unikalna nazwa rozpoznawalna we wszystkich systemach Comarch ERP Enterprise.
Aplikacje mogą posiadać zależności wobec obiektów deweloperskich z innych przestrzeni nazw. Aplikacje nie mogą jednak posiadać zależności względem siebie nawzajem. Jeżeli obiekt deweloperski odwołuje się do jednej aplikacji z poziomu innej aplikacji, wyświetlany jest komunikat o błędzie.
Za pomocą odpowiedniej właściwości można określić, które aplikacje mogą odwoływać się do innej aplikacji. Dodatkowe informacje znajdują się w artykule Właściwości ERP.
Przygotowanie systemu deweloperskiego
Na początku w nowym systemie deweloperskim aplikacji należy utworzyć następujące przestrzenie nazw:
-
com.<developmentprefix>
-
com.<developmentprefix>.ext
-
com.<developmentprefix>.ext.app
Obiekty deweloperskie należy utworzyć w odrębnym zadaniu, a następnie zwolnić.
Tworzenie aplikacji
Aplikacje tworzone są w specjalnej przestrzeni nazw: com.<developmentprefix>.ext.app
W tej przestrzeni nazw należy najpierw utworzyć aplikację. Nazwa aplikacji może składać się maksymalnie z ośmiu znaków.
Po utworzeniu aplikacji należy utworzyć przestrzeń nazw o takiej samej nazwie jak aplikacja, zapisaną małymi literami.
Przykład
App: com.xyz.ext.app.MyApp Następnie w tej przestrzeni nazw można tworzyć obiekty deweloperskie aplikacji.
Namespace: com.xyz.ext.app.myapp
Obiekt deweloperski typu app, powiązana przestrzeń nazw oraz wszystkie obiekty deweloperskie znajdujące się w tej przestrzeni nazw tworzą razem aplikację.
Odniesienia
Obiekty deweloperskie mogą odwoływać się do innych obiektów deweloperskich. W przypadku aplikacji dostępne są trzy kategorie odwołań.
Odwołania do obiektów deweloperskich z tej samej aplikacji
Odwołania te są dozwolone bez ograniczeń, ponieważ wszystkie obiekty aplikacji są eksportowane łącznie. W związku z tym nie może wystąpić odwołanie, którego nie będzie można zainicjować w systemie docelowym.
Odwołania do obiektów deweloperskich innej aplikacji w tym samym systemie
Takie zależności nie są dozwolone. W przypadku ich utworzenia aplikacja, do której następuje odwołanie, ma pierwszeństwo podczas importu. Za pomocą właściwości systemowej można określić, która aplikacja może odwoływać się do innych aplikacji. Właściwość ta może zostać rozszerzona wyłącznie w późniejszym czasie.
Odwołania do innych obiektów deweloperskich
Co do zasady obiekty deweloperskie z innych systemów deweloperskich nie powinny być referencjonowane lub mogą podlegać ograniczeniom. Obiekty deweloperskie mogą różnić się w zależności od wersji. Zazwyczaj zmiany są kompatybilne z poprzednią wersją, jednak możliwe są również zmiany niekompatybilne. Jeżeli aplikacja opiera się na takich obiektach deweloperskich, może się zdarzyć, że po jej zaimportowaniu nie będzie mogła zostać uruchomiona. W skrajnym przypadku, przy zmianach modelu danych, cały system może zostać doprowadzony do stanu nienaprawialnego.
W celu umożliwienia bezpiecznego odwoływania się do obiektów deweloperskich z innego systemu poza aplikacją wprowadzono stabilne obiekty deweloperskie. Obiekty te nie mogą być modyfikowane w systemie deweloperskim. Są one stabilne i mogą być referencjonowane w aplikacji bez ryzyka.
W przypadku odwołań do innych obiektów deweloperskich wyświetlany jest komunikat o błędzie lub ostrzeżenie, w zależności od sposobu wykorzystania. Jeżeli istnieje potencjalne ryzyko dla systemu, do którego aplikacja jest importowana, wyświetlany jest komunikat o błędzie. W pozostałych przypadkach po potwierdzeniu ostrzeżenia mogą wystąpić błędy w czasie wykonywania.
Dostarczanie aplikacji
Aplikacja jest rozwijana w systemie deweloperskim aplikacji. W celu przeprowadzenia testów oraz późniejszego dostarczenia obiekty deweloperskie wraz z ich wersjami są importowane do podrzędnego systemu testowego aplikacji. Do tego momentu logistyka oprogramowania przebiega tak jak w standardowym systemie deweloperskim z podrzędnym systemem testowym. Dostarczenie aplikacji z systemu testowego odbywa się poprzez aktualizację oprogramowania. W przeciwieństwie do standardowych dostaw w Comarch ERP Enterprise dostawa aplikacji zawsze obejmuje całą aplikację. Aby zainstalować określoną wersję aplikacji, nie jest konieczne sekwencyjne importowanie wszystkich wcześniejszych wersji.
Zaletą tego rozwiązania jest możliwość bezpośredniego zaimportowania na przykład wersji 4 aplikacji. Możliwe jest również przejście bezpośrednio z wersji 1 do wersji 5. Uproszczona metoda dostarczania posiada jednak wadę – w przypadku poprawek konieczne jest ponowne dostarczenie całej aplikacji.
Do dostarczania aplikacji służy aplikacja Eksport App. Dostawa za pomocą aplikacji Software update cockpit nie jest możliwa.
Eksportowanie aplikacji
Możliwe jest wyeksportowanie aplikacji za pomocą aplikacji Eksport App w systemie testowym tworzenia aplikacji. W aplikacji możliwy jest wybór aplikacji opracowanych w powiązanym systemie tworzenia aplikacji. Proces zazwyczaj przebiega w następujący sposób:
-
utworzyć nową wersję aplikacji w systemie tworzenia aplikacji i przenieść ją do systemu testowego tworzenia aplikacji
-
utworzyć aktualizację oprogramowania w systemie testowym tworzenia aplikacji
-
przenieść zależności (tylko w wyjątkowych przypadkach)
-
wyeksportować aktualizację oprogramowania
Tworzenie aktualizacji oprogramowania
Aby utworzyć aktualizację oprogramowania, aktywna wersja obiektu deweloperskiego typu app nie może być jeszcze przypisana do aktualizacji oprogramowania. Jeżeli aktualizacja oprogramowania została już utworzona i wyeksportowana z tą wersją, konieczne jest utworzenie nowej wersji obiektu deweloperskiego. Wersja obiektu deweloperskiego jest jednocześnie wersją eksportowanej aplikacji.
Aktualizacja oprogramowania jest tworzona podczas eksportu. Zostaje ona przypisana do wszystkich aktywnych wersji obiektów deweloperskich z przestrzeni nazw aplikacji oraz do samej aplikacji. Wersje historyczne są uwzględniane razem z wybranymi obiektami deweloperskimi z tej przestrzeni nazw. Dodatkowo uwzględniane są nadrzędne przestrzenie nazw, tak aby przy pierwszej instalacji zostały utworzone z prawidłową tożsamością. Obiekty deweloperskie w przestrzeniach nazw UPD oraz NLS również należą do aplikacji i są uwzględniane w aktualizacji oprogramowania.
Przyjmowanie zależności
Obiekty deweloperskie aplikacji mogą odwoływać się do innych obiektów deweloperskich. Na podstawie tych odwołań określane są aktualizacje oprogramowania zawierające referencjonowane obiekty. Aktualizacje te mają pierwszeństwo podczas instalacji aplikacji w systemie docelowym.
Zazwyczaj wymagania te są niewielkie, ponieważ system aplikacji powinien posiadać możliwie najniższy status. W niektórych przypadkach konieczne jest jednak zaimportowanie do systemu aplikacji aktualizacji oprogramowania zawierających poprawki. Może to zwiększyć minimalne wymagania wobec systemu, do którego aplikacja ma zostać zaimportowana. W najbardziej niekorzystnym przypadku system docelowy musi zostać najpierw zaktualizowany do tego statusu przed importem aplikacji. Niekiedy nie jest to możliwe, na przykład gdy system nadrzędny nie udostępnił jeszcze odpowiednich aktualizacji oprogramowania.
Jeżeli poprawki zaimportowane do systemu aplikacji nie mają wpływu na zdolność działania aplikacji, istnieje możliwość odrzucenia nowo nabytych zależności i przyjęcia zależności z poprzedniej wersji aplikacji. Procedura ta jest nieodwracalna i nie powinna być stosowana bez uzasadnienia.
Akceptacja zależności może prowadzić do utworzenia aktualizacji oprogramowania, których nie można uruchomić w systemie docelowym z powodu braku wymaganych obiektów deweloperskich. Mechanizm kontroli mający ograniczać takie błędy zostaje w tym przypadku częściowo pominięty.
Powstałe w wyniku tego usługi wsparcia są zawsze odpłatne.
Eksportowanie aktualizacji oprogramowania
Na zakończenie aktualizacja oprogramowania jest eksportowana. W tym procesie aktualizacja zapisywana jest w postaci plików. Procedura może być powtarzana dowolną liczbę razy.
Jeżeli zależności zostaną zaakceptowane w późniejszym czasie, aktualizację oprogramowania należy wyeksportować ponownie.
Testowanie aplikacji
Działanie aplikacji może zostać przetestowane w systemie deweloperskim aplikacji. Oprócz tego zaleca się przetestowanie instalacji wyeksportowanej aplikacji.
W tym celu wymagany jest system deweloperski klienta (poziom rozwoju 6). Dopiero po pomyślnym zakończeniu testów aplikacja powinna zostać dopuszczona do dostarczenia.
Inne
Licencjonowanie
W aplikacji może zostać zdefiniowany kod licencyjny. Aktywacja lub dezaktywacja aplikacji odbywa się poprzez licencjonowanie.
Jeżeli aplikacja nie jest objęta licencją, w niektórych przypadkach nie jest widoczna dla użytkownika. W takim przypadku logika aplikacji nie jest automatycznie wywoływana.
Licencjonowanie realizowane jest centralnie przez wsparcie Comarch ERP Enterprise. W systemie aplikacji nie można tworzyć własnych kodów licencyjnych. W przypadku potrzeby uzyskania kodów licencyjnych należy złożyć zamówienie poprzez wsparcie Comarch ERP Enterprise.
Dezinstalacja
Obecnie nie ma możliwości odinstalowania aplikacji. W przypadku konieczności dezaktywacji aplikacji możliwe jest to wyłącznie poprzez licencję.
Konserwacja starszych wersji aplikacji
Równoległa aktualizacja aplikacji w ramach tej samej wersji systemu nie jest możliwa.
Cykl wydania
System deweloperski aplikacji jest powiązany ze standardową ścieżką transportową Comarch ERP Enterprise. Jeżeli system zasilający zmieni wersję, system aplikacji zostaje zaktualizowany do nowej wersji wraz z jego aktualizacją.
System deweloperski aplikacji jest powiązany ze standardowym cyklem wydawniczym Comarch ERP Enterprise.
