Tworzenie poprawki

Zarządzanie ekranem

Karta Ekran wpisów

Typy elementów, które mogą stanowić przedmiot poprawek

Ta tabela umożliwia wprowadzanie listy elementów, które mają zostać poprawione. Ta lista jest identyfikowana za pomocą typu obiektu oraz nazwy. Definicja różnych typów oraz znaczenie nazwy są wyjaśnione poniżej. Kolumna Priorytet wskazuje porządek, w jakim typy elementów są ułożone w pliku poprawki (zob. akapit poniżej). Elementy, które znajdują się w wierszu 100 w tabeli są zawsze umieszczane na końcu poprawki (w porządku alfabetycznym kodów elementów).

Ważne punkty do rozważenia

Transfer wszystkich danych tabeli

Kod TAB umożliwia transfer danych tabeli poprzez ponowne załadowane w bazie jej struktury i danych. Natomiast elementy słownika dotyczące tej tabeli nie są tworzono i nie mogą więc wyświetlić się jako widoczne. Ten kod jest również dobrze przystosowany, jeśli użytkownik chce ponownie załadować już utworzoną tabelę w folderze do poprawy i która nie zmieniła struktury. Jeśli tak nie jest to należy umieścić dwie pozycje w definicji poprawki: pierwsza dotyczy definicji tabeli (ATB XXXXX), druga jej zawartości (TAB XXXXX). Nawet jeśli nie są one ustawione w tej kolejności wprowadzania, funkcja wgrywania poprawek ustawi je w takim porządku. W momencie integracji poprawki tabela zostanie utworzona w słowniku i w bazie, jeśli nie istnieje (w przeciwnym razie jej struktura zostanie zaktualizowana, jeśli się różni). Następnie ładowana jest ponownie tabela z danymi.

Transfer części danych tabeli

Możliwość transferu części zawartości tabeli jest otrzymywana poprzez ustawienie w kolumnie typu skrótu tabeli i poprzez wskazanie w kolumnie Nazwy warunku logicznego, który zostanie użyty w momencie wyodrębniania folderu wyjściowego oraz w celu integracji z folderem docelowym. Należy zauważyć, że wyodrębnione w ten sposób dane mogą zmodyfikować istniejące dane przy pomocy tych samych kluczy, lub utworzyć nowe dane. Natomiast ze względów bezpieczeństwa, w żadnym przypadku nie dochodzi do usunięcia danych podczas integracji poprawki. W ten sposób, np. jeśli uwzględniana jest poprzednia sytuacja dla tabeli krajów (skrót TCY):

Jeśli w poprawce wskazano pozycję z TCY, a warunek CRY=”AL” to poprawka będzie zawierała tylko pozycję odpowiadającą Albanii, a integracja poprawki w folderze docelowym nadpisze AL, więc Niemcy zostaną zastąpione przez Albanię.

Jeśli w poprawce wskazano pozycję z TCY i warunkiem pat(CRY,”A*”), poprawka będzie zawierała 4 pozycje AD, AE, AF i AR. W momencie integracji utworzony zostanie plik AE, Zjednoczone Emiraty Arabskie, plik AR, Argentyna, nastąpi zamiana AL, Niemcy na AL, Albania oraz zachowanie A, Afganistan i AU, Australia, które nie zostały dostarczone, ale istniały już w folderze docelowym.

Jeśli w poprawce wskazywana jest pozycja TCY z warunkiem find(CRY,”AD”,”AE”,”AL”), wynik będzie taki sam oprócz tego, co dotyczy AR, Argentyny, która nie zostanie przekazana.

Jedyny sposób usunięcia danych polega na:

• albo globalnej zamianie zawartości całej tabeli (poprawka typu TAB),
• albo dostarczeniu procesu za pomocą kodu EXE (zob. poniżej). Na przykład, jeśli użytkownik chce się upewnić, że spośród krajów, których nazwa zaczyna się od A, tylko kraje o kodach AD, AE i AL pozostaną na liście, należałoby dostarczyć proces (nazywany np. MAJPATCHnnn), który zawierałby pozycje opisane w poniższym przykładzie.

Wykonanie procesu

W danym przypadku należy wskazać: kod EXE, który umożliwia podanie nazwy procesu lub skryptu do wykonania. Pomimo numeru wiersza ten proces jest wykonywany na końcu integracji poprawki (może on istnieć wcześniej lub zostać dostarczony w ramach samej poprawki, ponieważ zostanie on wykonany na końcu integracji).

Ten proces musi integrować podprogram PATCH z parametrem odpowiadającym kodowi folderu. To ten podprogram zostanie wykonany. W ten sposób dla powyższego przykładu otrzymany zostanie następujący program:

Subprog PATCH(NOMDOS)
Value Char NOMDOS
Local File =NOMDOS+".TABCOUNTRY" [TCU]
Trbegin [TCU]
Delete [TCU] Where pat(CRY,"A*")=1 & find(CRY,"AD","AE","AL")=0
Commit
End

Jak widać powyżej konieczne jest zadeklarowanie tabel w tym podprogramie jasno uwzględniając, że muszą one być zadeklarowane w folderze, który nie musi być koniecznie bieżącym folderem (zapewnia to składnia Local File = NOMDOS + ".NOMTABLE").

Ogólne procesy do wykonania

Jeśli poprawki są wykonywane na elementach szablonów interfejsu użytkownika (ekrany szablonów używane w celu utworzenia okien transakcji) to konieczne jest ponowne zatwierdzenie tych ekranów.

To ponowne zatwierdzenie może zostać wykonane poprzez zadeklarowanie w poprawce wykonania odpowiedniego procesu. Poniżej znajduje się lista procesów standardowych do uruchomienia w zależności od typu elementu stanowiącego przedmiot poprawki:

Ten typ funkcjonalności jest możliwy do zrealizowania dla konkretnej sytuacji (wystarczy dodać podprogram PATCH, wskazany w poprzednim akapicie).

Poprawki dla dokumentacji

Struktura danych dokumentacji nie jest standardowa. Domyślnie do tworzenia i ponownego zatwierdzenia folderu mają zastosowanie następujące reguły:

• Teksty i pliki dokumentacji (tabele ADOCBLB i ADOCCLB) są uzupełniane w folderze administratora i nie są przekazywane w folderach, które od niego zależą (ale można utworzyć teksty pomocy lokalnej w folderze, które będą przechowywane lokalnie).
• Struktura dokumentacji (odnośniki dokumentacji, które są w praktyce elementami słownika, jak również struktura paragrafów) jest przechowywana w każdym folderze i kopiowana do folderów umiejscowionych poniżej w przypadku ponownego zatwierdzenia (z przestrzeganiem wertykalnych i konkretnych kodów działania, które mogły zostać zdefiniowane w folderze podrzędnym).

Co więcej, podczas wgrywania poprawki dokumentacji (typu ADO), obowiązuje następująca zasada:

• Struktura dokumentacji może zostać zintegrowana ze wszystkimi wymienionymi folderami podczas wgrywania poprawki, niezależnie od typu poprawki (w zależności od listy folderów wskazanych do zintegrowania).
• Teksty i pliki są integrowane wyłącznie w folderze administratora, jeśli typ poprawki to Administrator (co wydarza się dla poprawek dokumentacji standardowej). Jeśli poprawka jest innego typu to teksty i pliki mogą zostać zintegrowane ze wszystkimi folderami.
• Poprawka typu ADF (odnośniki) może zostać zintegrowana ze wszystkim folderami nawet, jeśli typ poprawki to Administrator.

Nazewnictwo plików poprawek

Integracja poprawki sprawdza sekwencję przejścia przez pliki poprawek w momencie integracji sekwencji numerycznej w ich nazwie. Zaleca się nazywanie plików poprawek przy użyciu nazwy zdefiniowanej zgodnie z formatem X_yyyy_zzz.dat oznaczającym następujące elementy:

• X to znak (inny niż P, ponieważ P jest zarezerwowane dla poprawek standardowych), który identyfikuje typ poprawki
• yyyy to numer sekwencji (zazwyczaj rozpoczynający się od 0001).
• zzz to identyfikator wersji do zintegrowania.

Jeśli ta zasada jest stosowana to podczas integracji wszystkich plików poprawek w katalogu zostaną wykonane następujące kontrole:

• W ramach jednej integracji nie miesza się plików z różnych wersji.
• Nie przeskakuje się numeru sekwencji, jeśli poprawki zidentyfikowane przy pomocy tego samego znaku i tego samego numeru zostały już zintegrowane. W ten sposób, np. jeśli zintegrowano poprawkę Z_0005_150.dat i użytkownik próbuje zintegrować poprawkę Z_0007_150.dat bez wcześniejszego zintegrowania poprawki Z_006_150.dat, w momencie integracji wyświetli się błąd.

Porządek elementów w pliku poprawki

Podczas tworzenia pliku poprawki zgodnie z zasadą, elementy, które się w niej znajdują stanowią całość, a więc aplikacja pozostawia folder w zgodnym stanie. W szczególności, jeśli przez poprawkę tworzona jest nowa funkcja, a ta funkcja jest definiowana przez operację, okno, ekran, tabelę i dwa procesy, logicznym wydaje się, żeby wszystkie te elementy były obecne w poprawce.

Jeśli wszystkie elementy są używane w celu utworzenia pliku poprawki to funkcja tworzenia ustawia je w konkretnym porządku według typu w celu uniknięcia wystąpienia błędów w momencie integracji. Jeśli na przykład integrowane jest okno przed ekranami, które się na niego składają to w momencie zatwierdzania wyświetli się błąd Ekran nie istnieje. W ten sposób zawsze integrowane są najpierw typy danych przed ekranami i tabelami, ekrany przed oknami itd.

Porządek używany podczas generowania poprawki odpowiadają porządkowi podanemu w tabeli powyżej. Jest to również porządek propozycji, który wyświetla się w funkcji poprawka automatyczna.

Należy jednak zauważyć, że nie można rozwiązać wszystkich możliwych konfliktów. Weźmy na przykład typ danych, który odnosi się do operacji, która może odnosić się do okna, które może odnosić się do ekranu, które może odnosić się do typu danych. Aby rozwiązać ten typ konfliktu (co jest rzadkie), należy podzielić plik poprawki na dwa pliki (pierwszy dostarczający wszystkie elementy z typem danych nie odnoszącym się do operacji, a drugi dostarczający typ danych integrujący np. operacje).

Elementy słownika bez poprawek

Jeśli użytkownik instaluje poprawkę zawierającą elementy słownika należy zauważyć, że niektóre pola, uznawane za możliwe do ustawienia elementy słownika, są przestrzegane niezależnie od tego, jaka jest ochrona zapewniana przez kod działania, z którego korzystają. Jest to na przykład przypadek domyślnego miejsca docelowego w raporcie.

Szczegóły zachowywanych pól są opisane w aneksie technicznym.

Szczególny format elementów AAA

Poprawka typu AAA odpowiada pozycji wynikającej z szablonu ustawień. Używa on konkretnego formatu dla kodu elementu. Ten format jest jednym z dwóch następujących formatów:

SZABLON~KOD_LEG~KOD_TRS~='FORMUŁA_WYBORU'

SZABLON~KOD_LEG~KOD_TRS~KLUCZ~POD_KLUCZ~POD_POD_KLUCZ...

W tych pozycjach:

• SZABLON odpowiada szablonowi danych używanemu w celu opisania tabel do wyodrębnienia
• KOD_LEG odpowiada kodowi legislacji, który może być pusty (wyświetlą się wtedy dwa znaki ~)
• KOD_TRS odpowiada kodowi transakcji, który może być pusty
• FORMUŁA_WYBORU to warunek filtrowania. Wszystkie ciągi słowne muszą zostać zawarte w cudzysłowie prostym ("), ponieważ formuła jest zawarta między apostrofami prostymi (').
• KLUCZ~POD_KLUCZ~POD_POD_KLUCZ (liczba podkluczy może się różnić) odpowiada szczególnemu przypadkowi, w którym użytkownik chce po prostu wybrać wartość klucza odpowiadającego głównej tabeli szablonu. Ten typ jest możliwy tylko, jeśli szablon (kod AAA) jest wywoływany z poziomu tworzenia poprawki i, jeśli otwierane jest okno, które umożliwia wybranie szablonu i uzupełnienie klucza poprzez wyszukanie bezpośrednie.

Raporty

Z funkcją domyślnie powiązane są następujące raporty :

 PRTSCR : Drukowanie ekranu

Można to zmienić w ustawieniach.

Zadanie przetwarzania w tle

Tę funkcję można wykonać w trybie wsadowym,. W tym celu przewidziano ZPATCHC zadanie standardowe.

Przyciski określone

Komunikaty o błędzie

Podczas wprowadzania mogą wyświetlić się następujące komunikaty ogólne oraz o błędach :

…. : nieistniejący katalog

Ścieżka dostępu do pliku poprawki nie istnieje

Nieprawidłowy typ obiektu

Typ obiektu nie odpowiada ani żadnemu wstępnie zdefiniowanemu typowi obiektu, ani skrótowi istniejącej tabeli.

Słownik .... XXX rekord nie istnieje

Wystąpiła próba wyodrębnienia nieistniejącego obiektu słownika

Nieprawidłowa wartość

Warunek wyodrębniania powiązany z wyodrębnianiem danych tabeli jest nieprawidłowy pod względem składniowym.

Użyte tabele

Odniesienie do dokumentacji Implementacja