# Przechowywanie danych w modelu

## Inicjalizacja modelu

Model danych dla aplikacji jest tworzony w momencie wystartowania instancji aplikacji (patrz [uruchamianie-aplikacji](https://docs.eximee.com/budowanie-aplikacji/aplikacja-biznesowa/uruchamianie-aplikacji "mention")) . Po stworzeniu modelu może on dostarczać wartości dla pól, zgodnie z definicją źródeł danych. Oraz przyjmować wartości dla pól przechowywanych lokalnie.

## Miejsce zapisu danych

Dane zapisane w modelu możemy podzielić na dwa rodzaje - z uwagi na miejsce przechowywania oraz to, kto nimi zarządza.

### Dane pobierane z usług

Jeżeli aplikacja korzysta z danych zapisanych i zarządzanych przez systemy organizacji lub zewnętrzne, są one pobierane za pomocą usług. Aplikacja low-code nie jest właścicielem tych danych, nie może ich modyfikować i nie kontroluje zmian ich wartości.

Wartości pobierane są z usługi i zawsze aktualne, z dokładnością do cache (patrz [#zrodlo-danych](https://docs.eximee.com/budowanie-aplikacji/edycja-modelu-danych#zrodlo-danych "mention")).

Przykłady

* aktualny adres klienta
  * klient składa wniosek o zakup ubezpieczenia
  * po złożeniu wniosku, a przed wygenerowaniem umowy sprzedaży, klient zmienia dane adresowe zapisane w banku (zazwyczaj przez dedykowany proces)
  * na umowie sprzedaży ubezpieczenia mamy zaktualizowany adres - zostanie on pobrany w procesie zgodnie z definicją danych w modelu
* saldo rachunku
  * podczas przyjmowania dyspozycji aplikacja weryfikuje czy na wskazanym przez klienta rachunku znajdują się odpowiednie środki do pokrycia kosztów obsługi
  * przed faktycznym pobraniem środków aplikacja może ponownie zweryfikować środki, aby poprawnie obsłużyć obciążenie rachunku

### Dane przechowywane w modelu

Kiedy dane są tworzone i zarządzane przez aplikację, są one przechowywane w modelu danych. Aplikacja low-code jest ich właścicielem, może je modyfikować i kontroluje zmiany ich wartości.

Przykłady

* wnioskowany limit karty kredytowej
  * podczas składania wniosku o kartę kredytową klient podaje wartość oczekiwanego limitu
  * aplikacja może zmienić tę wartość w trakcie obsługi procesu (np. zmniejszyć)
  * na wygenerowanej umowie (i zapewne w komunikacji do klienta) mamy aktualną wartość limitu
* adres korespondencyjny klienta do obsługi procesu
  * podczas składania wniosku kredytowego klient podaje adres korespondencyjny
  * domyślnie aplikacja prezentuje adres zapisany w systemach banku (pobrany z usługi)
  * klient jednak może zmienić ten adres i życzyć sobie korespondencji dotyczącej tego procesu na inny adres
  * aplikacja zachowuje wartości wprowadzone przez klienta

## Dane poza modelem

Aplikacja low-code nie musi przechowywać wszystkich danych w modelu. Cześć danych ma charakter tymczasowy i służy jedynie do wyznaczenia docelowej wartości lub podjęcia decyzji, np:

* lista rachunków klienta
  * generuje dziedzinę wyboru konta z komponentu Pola wyboru wartości z listy
  * pozwala klientowi łatwo wybrać konkretny rachunek
  * w modelu danych chcemy mieć tylko wybrany przez Klienta rachunek, cała lista nie jest nam potrzebna
* wiek klienta
  * pozwala podjąć decyzję o możliwości zakupienia produktu (np. *Karta <26*)
  * jest wyliczany z numeru PESEL

Dane tymczasowe, operacyjne mogą być zachowywane w zmiennych sesyjnych na formularzach, zmiennych procesowych lub w zmiennych skryptów.