Zawartość paczki projektu
VSoft archITekt zapisuje definicję zbudowanej aplikacji w postaci pliku o nazwie {Nazwa paczki}.arch.zip
- Paczkę projektu można wygenerować z poziomu archITekt Studio. Służy ona zarówno do zainicjowania nowego środowiska (poprzez wskazanie jej podczas operacji tworzenia środowiska) jak również do operacji aktualizacji definicji istniejącego już środowiska - patrz: Eksportowanie paczki.
- Operację wczytania paczki konfiguracyjnej wykonuje się z poziomu VSoft archITekt Launcher lub skryptów instalacyjnych.
Struktura paczki projektu
Paczka projektu jest dystrybuowana jako archiwum zip o następującej strukturze:
{Nazwa paczki}.arch.zip
- \Files - (tu umieszczone mogą być pliki do nadpisania w odpowiednich folderach aplikacji końcowej)
- \SQL - (tu umieszczone mogą być skrypty SQL użytkownika do uruchomienia na bazach danych aplikacji końcowej)
- \VS - (tu umieszone mogą być archiwa serwera wersji do aktualizacji w aplikacji końcowej)
- \version.json - (w tym pliku zapisane są informacje, na której wersji archITekta została utworzona paczka projektu).
Ze względu na otwarty charakter paczki projektu zaawansowany użytkownik może za jej pomocą rozszerzać konfigurację aplikacji końcowej w sposób opisany poniżej.
Dodawanie własnych plików do aplikacji końcowej
W przypadku chęci zmiany konfiguracji aplikacji lub wgrania własnych rozszerzeń do aplikacji należy je umieścić w katalogu Files.
Umieszczając w nim pliki należy pamiętać, że katalog Files mapuje się na główny katalog w runtime zainstalowanej aplikacji.
W związku z tym, przykładowo chcąc dodać plik z rozszerzeniem do procesów - Workflow - czyli który powinien znaleźć się w katalogu:
{katalog runtime aplikacji}\App\Workflow.Host
należy umieścić go w katalogu
{nazwa paczki}.arch.zip\Files\App\Workflow.Host
- Dodając własne pliki konfiguracyjne należy zaznajomić się z działaniem mechanizmu konfiguracji aplikacji opisanym w rozdziale Konfiguracja techniczna aplikacji.
- Należy również zadbać o to, by miały one format wspierany przez narzędzie do łączenia konfiguracji. Sposób działania narzędzia i format plików akceptowanych przez narzędzie opisany jest w rozdziale Mechanizm łączenia konfiguracji.
Dodawanie własnych skryptów SQL do aplikacji końcowej
W celu uruchomienia na bazach danych wdrażanej wersji aplikacji własnych specyficznych skryptów SQL, należy dodać je do katalogu SQL.
- W katalogu tym automatycznie są zapisywane skrypty aktualizujące strukturę bazy danych oraz zawartość słowników systemowych przy każdym generowaniu paczki.
- Aktualizacja bazy danych wykonywana jest za pomocą narzędzia DatabaseUpgrader, którego opis działania znajduje się w rozdziale Narzędzie DatabaseUpgrader.
- Należy również przestrzegać konwencji nazewniczej katalogów skryptów.
Skrypty muszą być umieszczone w katalogach:
{Nazwa paczki}.arch.zip
\SQL
\{nazwa bazy: DATA, CONFIG, VIP, SCHEDULER, VERSION_SERVER}
\{nazwa silnika bazy danych: SQLServer, PostgreSQL}
\{nazwa katalogu}
\pliki skryptów o nazwach akceptowanych przez narzędzie (np. 001_mój_skrypt.sql)
W powyższym formacie:
- Nazwa bazy określa, na której z baz danych aplikacji ma być wykonany skrypt. Najczęściej będzie to wartość DATA określająca bazę danych operacyjnych aplikacji.
- Podczas aktualizacji środowiska będą uruchamiane wyłącznie skrypty z katalogu odpowiadającemu danemu silnikowi baz danych.
- Nazwa katalogu powinna mieć format
[wersja archITekta]@[numer lokalnej wersji][dowolny tekst], gdzie:
- [numer lokalnej wersji] – jest to nazwa w formacie "YYMMDD.HHmm" czyli np. "241122.1233"; skrypty będą wykonywane w kolejności alfabetycznej. Zastosowanie nazwy w takiej postaci.
- [dowolny tekst] – opcjonalny, dowolny tekst opisujący co znajduje się w katalogu, nie zawierający znaków $ oraz @.
Przykładowy katalog ze skryptami:
* katalogi pierwszy i trzeci zostały dodane przez użytkownika
* katalog drugi (kończący się na "$auto_gen") został wygenerowany automatycznie podczas eksportu paczki i następnie zaimportowany z paczką na dane środowisko.
W trakcie aktualizacji środowiska (lub tworzenia nowego środowiska) katalogi skryptów użytkownika łączone są z katalogami skryptów archITekta, a następnie wykonywane w kolejności alfabetycznej.
Obowiązuje sortowanie „naturalne”, czyli takie jakie jest obecne w Eksploratorze Windows – szczegółowy opis w jakiej kolejności wykonywane są skrypty bazodanowe znajduje się w rozdziale Narzędzie DatabaseUpgrader.
Modyfikacja archiwów serwera wersji do importu
W podkatalogu VS paczki projektu znajduje się jedno lub więcej archiwów zip zawierających konfigurację aplikacji.
- Domyślnie przez archITekta jest tworzony w tym katalogu plik o nazwie
vs.zipzawierający konfigurację środowiska (zawartość serwera wersji), z którego generowana jest paczka projektu. - Zaawansowany użytkownik może modyfikować zawartość tego katalogu poprzez dodanie do niego nowych plików z archiwami serwera wersji do zaimportowania lub modyfikując zawartości istniejących archiwów w tym katalogu.
Dodając kolejne pliki *.zip zawierające konfigurację z serwera wersji do zaimportowania, należy pamiętać o tym, że podczas operacji importu każde z archiwów jest importowane osobno, a pobieranie archiwów do importu następuje w kolejności alfabetycznej. Jest to ważne w przypadku umieszczenia w katalogu archiwów zawierających te same pliki. W takim przypadku definicje z archiwum o nazwie późniejszej nadpiszą definicje zaimportowane z archiwum o nazwie wcześniejszej.