Mendix: Szkolenie Techniczne
Poziom 1 - Podstawy Tworzenia Aplikacji i Administracji
Jacek Pietsch
Dzień 1: Fundamenty i Dobre Praktyki
01
Wprowadzenie
Architektura platformy i ekosystem Mendix
02
Modelowanie Danych
Dogłębna analiza encji, relacji i zdarzeń
03
Projektowanie UI/UX
Łączenie danych z interfejsem użytkownika
04
Logika Aplikacji
Anatomia Microflow i Nanoflow, wzorce projektowe
Problem: Rosnące Zapotrzebowanie na Złożone i Skalowalne Aplikacje
Wyzwanie
Świat pożera oprogramowanie szybciej niż możemy je tworzyć. Zapotrzebowanie na nowe aplikacje rośnie wykładniczo, podczas gdy liczba programistów pozostaje ograniczona.
Tradycyjne podejście do developmentu nie nadąża za tempem zmian biznesowych.
Rozwiązanie Low-Code
Abstrakcja i automatyzacja w celu poprawy przewidywalności jakości, skalowalności i możliwości zarządzania aplikcjami i rozproszonymi systemami.
Filozofia Mendix
Model-Driven Development
Aplikacja jest modelem. Model jest aplikacją. To fundamentalna zasada - tworzysz wykonywalny model, nie kod, który wymaga kompilacji.
Szybkość i Kontrola
Równowaga między wizualnym developmentem a możliwością rozszerzenia poprzez Java Actions i JavaScript.
Współpraca
Deweloperzy bliżej biznesu, szybsza implementacja i skupienie na funkcjach a nie narzędziach.
Komponenty Ekosystemu Mendix
Mendix Studio Pro
Dla profesjonalnych deweloperów i architektów. Pełna kontrola nad modelem - modelowanie domeny, złożona logika, integracje REST/SOAP, bezpieczeństwo, rozszerzenia Java.
Kod JavaScript i Java
Umożliwia rozszerzanie funkcjonalności platformy Mendix, tworzenie niestandardowych integracji oraz implementację zaawansowanych fnukcji wykraczającej poza standardowe możliwości aktywności.
Control Center
Zarządzanie i governance portfolio aplikacji. Użytkownicy platformy, środowiska, monitoring, backupy - wszystko w jednym miejscu.
Marketplace
Ekosystem reużywalnych komponentów - widgety UI, gotowe moduły, konektory do systemów zewnętrznych, motywy graficzne.
Jak Działa Aplikacja Mendix?
Design Time
Tworzysz model wizualnie w Studio Pro - encje, UI, logika biznesowa
Deployment
Model jest kompilowany do pakietu .mda gotowego do wdrożenia
Runtime
Serwer Mendix (Java) interpretuje model i wykonuje go - zarządza bazą, wykonuje Microflows
Client
Przeglądarka renderuje UI i wykonuje logikę kliencką (Nanoflows)
Struktura Projektu Mendix
Główne Foldery
  • theme/ - Definicje stylów SASS/CSS dla interfejsu użytkownika
  • javasource/ - Kod źródłowy niestandardowych akcji Java
  • userlib/ - Zewnętrzne biblioteki .jar
  • resources/ - Pliki statyczne, tłumaczenia, dane do importu
  • mprcontents/ - MPR documents
  • widgets/ - pliki widgetów wykorzystywanych w projekcie
  • .mpr - Plik zawierający model aplikacji
Model Danych
Modelowanie struktury danych i relacji między encjami.
Encje: Podstawowy Element Modelu Danych
W Mendix, encja to fundamentalny blok konstrukcyjny modelu danych, który reprezentuje typ danych lub obiekt biznesowy w Twojej aplikacji. Możesz myśleć o encji jako o tabeli w tradycyjnej relacyjnej bazie danych.
Każda encja posiada zestaw atrybutów (kolumn), które przechowują konkretne informacje, oraz relacje (powiązania), które łączą ją z innymi encjami, odzwierciedlając złożone struktury danych i zależności biznesowe.
Mendix ORM
Mendix zapewnia wewnętrzny Object-Relational Mapper (ORM). Oznacza to, że Ty, jako deweloper, pracujesz z obiektami (instancjami encji) w warstwie aplikacji, a Mendix automatycznie zajmuje się tłumaczeniem tych obiektów na zapytania SQL i przechowywaniem ich w bazach danych.
Encje: Persistent vs. Non-Persistent
Encja Persistent
Przechowywanie: Zapisywana w bazie danych jako tabela z własnymi kolumnami
Cykl życia: Trwała, istnieje pomiędzy sesjami użytkowników
Transakcyjność: Pełna obsługa Commit, Rollback
Zastosowanie: Podstawowe dane biznesowe - Klienci, Produkty, Zamówienia
Encja Non-Persistent (Transient)
Przechowywanie: Istnieje tylko w pamięci RAM serwera
Cykl życia: Znika po zakończeniu sesji lub Microflow
Transakcyjność: Brak - zmiany nie są trwałe
Zastosowanie: DTO, formularze-wizardy, parametry wyszukiwania, tymczasowe dane UI
Typy Danych i Atrybuty
Podstawowe Typy
  • String - Tekst o zmiennej długości
  • Integer / Long - Liczby całkowite
  • Decimal - Liczby zmiennoprzecinkowe
  • Boolean - Wartość prawda/fałsz
  • DateTime - Data i czas
  • Enumeration - Zestaw predefiniowanych wartości
Typy Specjalne
  • Hashed String - Jednokierunkowy hash do haseł
  • AutoNumber - Unikalny, inkrementowany numer
Calculated Attributes: Pułapka Wydajnościowa
Jak Działają?
Wartość jest obliczana przez Microflow za każdym razem, gdy obiekt jest pobierany z bazy danych (Retrieve).
Problem Wydajnościowy
Na listach (Data Grid) powoduje wykonanie Microflow N razy dla N obiektów.
Lepsza Alternatywa
Użyj Event Handlera Before Commit do obliczenia wartości i zapisz ją w zwykłym, trwałym atrybucie. Wyłącz prawo do edycji atrybutu.
Relacje (Associations): Łączenie Danych
Relacja 1-1
Jeden do jednego - jeden obiekt powiązany z maksymalnie jednym innym obiektem
Relacja 1-*
Jeden do wielu - najczęstsza relacja. Klucz obcy po stronie "wielu"
Relacja *-*
Wiele do wielu - wymaga osobnej tabeli łączącej (junction table)
Właścicielstwo (Ownership): Owner = Default (referencja po jednej stronie) vs. Owner = Both (referencje po obu stronach - szybsze zapytania, wolniejszy zapis)

Nowy sposób przechowywani relacji 10.21 - Bezpośredni lub Tabela
Dziedziczenie: Generalizacja i Specjalizacja
Pracownik i Klient mogą dziedziczyć po wspólnej encji Osoba, aby współdzielić atrybuty jak Imię czy Nazwisko.
Implementacja Dziedziczenia: Plusy i Minusy
Implementacja Techniczna
Mendix tworzy jedną dużą tabelę dla całej hierarchii z kolumną objectType i wszystkimi atrybutami ze wszystkich specjalizacji.
Zalety
  • Model jest czysty i czytelny
  • Łatwe pobieranie polimorficzne
  • Współdzielenie logiki biznesowej
Wady i Kiedy Unikać
  • Bardzo szerokie tabele z dużą ilością NULL
  • Negatywny wpływ na wydajność zapytań
  • Problemy z indeksowaniem

Reguła: Stosuj tylko gdy specjalizacje mają dużo wspólnych atrybutów i logiki (prawdziwa relacja "is-a"). W innych przypadkach rozważ kompozycję (asocjacja 1-1).
Event Handlers: Cykl Życia Obiektu
1
Before Create
Wywoływany przed utworzeniem obiektu w pamięci
2
Before Commit
Przed zapisem do bazy - walidacja, ustawianie wartości
3
After Create
Po utworzeniu obiektu w pamięci
4
After Commit
Po pomyślnym zapisie - wysyłka maili, integracje, audyt
Validation Rules vs. Event Handlers
Validation Rules
Dla prostych, pojedynczych walidacji na atrybucie - wymagalność, unikalność, format. Są szybkie, deklaratywne i wystarczające w większości przypadków.
Event Handlers
Dla złożonych reguł wymagających pobrania innych obiektów lub skomplikowanej logiki biznesowej. Pełna elastyczność, ale większy narzut.
DEMO: Budowa Solidnego Modelu Danych
Tworzenie Encji
Rezerwacja (Persistent) i ParametryWyszukiwania (Non-Persistent) z odpowiednimi atrybutami
Changing and deleting objects of an entity with indexes takes longer, because the index needs to be updated in addition to the actual data. Therefore, for attributes that are rarely used as criteria in a search or query, only create an index if the increase in retrieval performance justifies the decrease in update performance.
Calculated Attribute
StatusRezerwacji - omówienie wad wydajnościowych
Event Handler
Before Commit zapisujący status w trwałym atrybucie - lepsza wydajność
Indeksowanie
Dodanie indeksu na Email w encji Klient dla szybszych wyszukiwań
Wdrażanie UI/UX
Od danych do pikseli
Data Containers: Kontenery Danych
Data View
Przechowuje i wyświetla jeden obiekt. Niezbędny do budowy formularzy edycji i stron szczegółów. Idealny do operacji CRUD.
List View
Przechowuje i wyświetla listę obiektów w elastycznym, wizualnym układzie. Świetny do kart produktów, galerii.
Data Grid 2
Przechowuje i wyświetla listę obiektów w formacie tabeli. Oferuje sortowanie, filtrowanie, paginację. Idealny do list biznesowych.
Data Sources: Zasilanie UI w Dane
Context
Najprostsze - dane przekazane do strony (np. po kliknięciu Edit). Najszybsze, brak zapytań.
XPath
Język zapytań Mendix. Pobiera bezpośrednio z bazy. Niezwykle wydajne filtrowanie i sortowanie. Preferowany dla list.
Microflow
Gdy dane wymagają złożonego przetworzenia, utworzenia lub logiki niemożliwej w XPath.
Nanoflow
Jak Microflow, ale w przeglądarce. Idealne do dynamicznego UI bez odświeżania strony.
Association
Podąża za relacją z obiektu w kontekście (np. z Data View). Automatyczne, wydajne.
Reużywalność: Atlas UI Framework
Layout
"Ramka" strony z górnym menu i boczną nawigacją. Strony są wstrzykiwane w Layout.
Page Template
Gotowe wzorce stron (List with details, Dashboard) jako punkt startowy.
Building Block
Gotowe, pre-stylowane sekcje do kopiowania i wklejania.
Snippet
Reużywalny fragment UI na wielu stronach. Może przyjmować parametry - potężne narzędzie do komponentów!
Logika Aplikacji
Microflows i Nanoflows
Microflows vs. Nanoflows: Porównanie
Microflow (Server-side)
Kontekst: Mendix Runtime (Java)
Dostęp do bazy: Pełny, bezpośredni
Transakcyjność: Pełna - błąd = automatyczny rollback
Możliwości: Integracje, Java Actions, operacje na plikach
Zastosowanie: Złożona logika biznesowa, transakcje, integracje
Nanoflow (Client-side)
Kontekst: Przeglądarka (JavaScript)
Dostęp do bazy: Tylko obiekty zsynchronizowane z serwerem
Transakcyjność: Brak
Możliwości: Ograniczone - brak integracji i Java
Zastosowanie: Walidacja UI real-time, dynamiczne interfejsy, aplikacje offline
Microflow: Podstawowe Elementy
Events
Start (początek wykonania) i End (zakończenie, zwrócenie wartości)
Activities
Operacje na obiektach: Create, Retrieve, Change, Commit, Delete, Rollback, Aggregate list
Przepływ Sterowania
Decision (if/else), Merge (połączenie ścieżek), Loop (iteracja po liście)
Error Handling
Custom with/without rollback - działa jak blok try-catch
Dobre Praktyki w Microflows
Single Responsibility Principle (SRP)
Jeden Microflow = jedna logiczna operacja. Łatwiejsze testowanie, debugowanie i reużywalność.
Nie więcej niż 50 elementów
Nie więcej niż 50 elementów w jednym microflow
Spójne Nazewnictwo
ACT_ dla Command (ACT_Zamowienie_Zatwierdz), BCO_ before bommit lub CAL_ dla kalkulacji pola, DS_ dla datasource.
Wydajność Microflows: Pułapki
Commit w Pętli
Każdy Commit to osobna transakcja bazy danych. W pętli 1000 obiektów = 1000 transakcji. Zbieraj na liście i commituj listę!
Problem N+1
Retrieve w pętli - dla każdego obiektu osobne zapytanie. Pobierz wszystkie dane jednym zapytaniem przed pętlą.
Batch Processing
Operacje na listach zamiast pojedynczych obiektów. Wykorzystuj Aggregate List do obliczeń na zbiorach.
XPath w Mendix
XPath (XML Path Language) to deklaratywny język zapytań używany w Mendix do efektywnego pobierania, filtrowania i sortowania danych bezpośrednio z bazy danych. Jest to wysoce zoptymalizowana i preferowana metoda do zasilania list danych w interfejsie użytkownika, zapewniająca wysoką wydajność.
Podstawowe Filtrowanie
[Encja/Atrybut = 'Wartość']
Filtruje obiekty na podstawie wartości atrybutu. Obsługuje operatory porównania (=, >, <, >=, <=, !=).
Relacje (Associations)
[Relacja/Encja_Związana/Atrybut = 'Wartość']
Pozwala na przechodzenie przez powiązania między encjami w celu filtrowania danych.
Funkcje Wbudowane
Dostęp do przydatnych funkcji tekstowych (starts-with(), contains(), ends-with()), daty (currentDateTime()) i innych, dla zaawansowanego filtrowania.
Operatory Logiczne
Użycie operatorów and, or do łączenia wielu warunków filtrowania, tworząc złożone zapytania.
Przykład XPath
Pobierz wszystkie obiekty Rezerwacja ze statusem "Potwierdzona", które są powiązane z obiektem Klient, którego adres e-mail zaczyna się na "anna":

//MyFirstModule.Rezerwacja
[Status = 'Potwierdzona']
[MyFirstModule.Rezerwacja_Klient/MyFirstModule.Klient[starts-with(Email, 'anna')]]
Rezerwacja.Status
Rezerwacja.Rezerwacja_Klient → Klient
Ten przykład pokazuje, jak efektywnie połączyć warunki na atrybutach encji (Status) z warunkami na atrybutach encji powiązanej (Email z Klient), wykorzystując funkcję starts-with().
DEMO: Implementacja Logiki Biznesowej
Strona z Listą
Data Grid 2 z dostępnymi slotami czasowymi, źródło danych: XPath
Przycisk Zarezerwuj
Wywołuje Microflow ACT_Rezerwacja_Zarezerwuj
Logika w Microflow
Pobranie Klienta, utworzenie Rezerwacji, ustawienie asocjacji, zmiana statusu Slotu
Commit i Walidacja
Zapis obiektów z obsługą błędu dla zajętego slotu
Potwierdzenie
Wyświetlenie strony z potwierdzeniem rezerwacji
Expressions w Mendix
Expressions to potężne narzędzie w Mendix, które pozwala na dynamiczne obliczanie wartości, filtrowanie danych oraz podejmowanie decyzji w oparciu o złożoną logikę. Są one fundamentalne dla tworzenia elastycznych i reaktywnych aplikacji.
Podstawy Składni
Użyj $ dla elementów nazwanych (np. $customer). Atrybuty i asocjacje obiektów są dostępne za pomocą / (np. $customer/Name, $customer/CRM.Customer_Order).
Typy Operatorów
Wspierają operatory arytmetyczne (+, -, *, div, mod), relacyjne (=, !=, <, >) oraz logiczne (and, or, not).
Funkcje Wbudowane
Szeroka gama funkcji dla typów matematycznych (np. max(), round()), tekstowych (np. toUpperCase(), substring()) i datowych (np. beginOfDay(), addDays()).
Zmienne Systemowe
Dostęp do danych bieżącej sesji użytkownika poprzez $currentUser (obiekt System.User) i $currentSession (obiekt System.Session).
Expressions
if $package/weight < 1.00 then 0.00 else 5.00
Input:
Product Name: SuperWidget, PRICE: 49,99, quantity: 150
Wyodrębnij nazwę produktu, cenę i ilość z ciągu i sformatuj je w przejrzysty, uporządkowany sposób, jak poniżej:
⁠Produkt: SUPERWIDGET, Cena: 49,99, Ilość: 150
⁠Rozwiązanie
'Produkt: ' +
    toUpperCase(
        trim(
            substring(
                $input,
                find($input, ':') + 1,
                find($input, ',') - find($input, ':') - 1  //25 - 12 - 1
            )
        )
    ) +

', Cena: ' +
    trim(
        substring(
            $input,
            find($input, 'PRICE:') + 1,
            find($input, ',', find($input, 'quantity:') - 2) - find($input, 'PRICE:') - 6
        )
    ) +

', Ilość: ' +
    trim(
        substring(
            $input,
            find($input, 'quantity: ') + 10 //od tej pozycji do końca stringu
        )
    )
Dzień 2
Architektura, Bezpieczeństwo i Integracje
Agenda Dnia 2
01
Warsztat Praktyczny
Utrwalenie wiedzy z Dnia 1 poprzez praktyczne zadanie
02
Bezpieczeństwo i Uprawnienia
Dogłębna konfiguracja i best practices
03
Architektura Aplikacji
Wprowadzenie do Domain-Driven Design
04
Wzorce Architektoniczne
Mapowanie DDD na Mendix: Aplikacje i Moduły
05
Integracje Systemowe
Komunikacja ze światem zewnętrznym przez API
Studio Pro
Ogólna Konfiguracja Aplikacji
Warsztat: Budujemy Aplikację
Cel Warsztatu
Samodzielna implementacja pełnej funkcjonalności w oparciu o wiedzę z Dnia 1.
Zadanie
Rozbudowa aplikacji o nowy moduł "Zarządzanie Zasobami":
  • Stworzenie modelu domeny (Encje, Relacje)
  • Zbudowanie interfejsu (Strony, Formularze, Listy)
  • Implementacja logiki biznesowej (Microflows)
  • Konfiguracja podstawowego bezpieczeństwa
Dlaczego Bezpieczeństwo Jest Krytyczne?
Ochrona Danych
Błędy w konfiguracji mogą prowadzić do wycieku wrażliwych danych klientów i naruszeń RODO.
Integralność Systemu
Nieautoryzowane modyfikacje mogą zniszczyć dane biznesowe i przerwać procesy.
Zaufanie Klientów
Incydenty bezpieczeństwa niszczą reputację i prowadzą do utraty biznesu.

Model bezpieczeństwa Mendix jest deklaratywny i wymuszany przez Runtime, co zapewnia spójność. Zasada "Deny by Default" - jeśli nie nadasz uprawnień jawnie, dostęp jest zablokowany.
Poziomy Bezpieczeństwa Projektu
Off
Brak zabezpieczeń, brak logowania. Tylko do wczesnych prototypów!
Prototype/Demo
User Roles i strony nawigacyjne, ale BRAK wymuszania Entity Access. Dane nie są chronione!
Production
Jedyny słuszny wybór dla produkcji. Wszystkie reguły aktywne: strony, Microflows i dane.
Konfiguracja Uprawnień w Mendix
User Roles
Zdefiniowane na poziomie projektu. Odwzorowują role biznesowe (Administrator, Sprzedawca, Użytkownik).
Module Roles
Zdefiniowane na poziomie modułu. Opisują uprawnienia w kontekście modułu (Manager, Viewer, Editor).
Mapowanie
User Role = zbiór Module Roles. Granularne i reużywalne zarządzanie uprawnieniami.
Entity Access: Zabezpieczanie Danych
Uprawnienia CRUD
  • Create: Czy rola może tworzyć nowe obiekty?
  • Read: Które atrybuty rola może widzieć?
  • Write: Które atrybuty rola może modyfikować?
  • Delete: Czy rola może usuwać obiekty?
XPath Constraints
Dynamicznie filtruje dane na poziomie bazy (dodaje WHERE do SQL).

Przykład: [MyFirstModule.Rezerwacja_Owner = '[%CurrentUser%]'] - użytkownik widzi tylko swoje rezerwacje.
Zabezpieczanie Widoków UI
Dostęp do stron (Pages) jest kluczowym elementem bezpieczeństwa, który kontroluje, jakie ekrany i funkcjonalności są dostępne dla poszczególnych użytkowników w aplikacji.
Przypisywanie Ról
W Mendix Studio Pro, każdej stronie (Page) można przypisać określone Module Roles, które mają uprawnienia do jej wyświetlania.
Zasada "Deny by Default"
Jeśli rola użytkownika nie posiada jawnie nadanych uprawnień do danej strony, Mendix automatycznie blokuje możliwość jej wyświetlenia, zapewniając bezpieczeństwo.
Granularna Kontrola Elementów
Dodatkowo, widoczność pojedynczych elementów UI (widgetów, kontenerów) na stronie może być dynamicznie kontrolowana za pomocą Conditional Visibility, bazującej na rolach użytkownika lub złożonych wyrażeniach.
Uprawnienia do Microflow
Kontrola Dostępu
Dostęp do każdego Microflowa jest kontrolowany na poziomie Module Roles. Tylko użytkownicy posiadający przypisaną rolę modułu z odpowiednimi uprawnieniami mogą go wywołać.
Apply entity access
Wymusza stosowanie reguł bezpieczeństwa zdefiniowanych dla encji również w Microflowach. Zapobiega to omijaniu zabezpieczeń danych poprzez bezpośredni dostęp w logice.
XPath Constraints: Przykłady
Row-Level Security
[MyFirstModule.Rezerwacja_Owner = '[%CurrentUser%]']
Użytkownik widzi tylko swoje rekordy - najpopularniejszy wzorzec zabezpieczeń.
Status-Based Security
[Status = 'Zatwierdzony' or MyFirstModule.Zamowienie_Owner = '[%CurrentUser%]']
Wszystkie zatwierdzone zamówienia LUB własne w dowolnym statusie - kombinacja reguł.
Department-Based Security
[MyFirstModule.Dokument_Dzial = '[%CurrentUser%]/Administration.Account_Dzial']
Dostęp do dokumentów tylko z własnego działu - segmentacja organizacyjna.
Zabezpieczanie Widoków UI
Kontroluj, które elementy interfejsu użytkownika są widoczne i dostępne dla poszczególnych ról w aplikacji, zapewniając granularną kontrolę dostępu.
Dostęp do Stron
Definiuj, które role użytkowników mogą otwierać i przeglądać konkretne strony aplikacji.
Elementy Nawigacji
Kontroluj widoczność pozycji w menu nawigacyjnym, dostosowując je do uprawnień roli.
Widżety i Kontrolki
Warunkowo pokazuj lub ukrywaj pojedyncze widżety, przyciski czy pola na stronach, bazując na roli.
Microflows w UI
Ustalaj uprawnienia do wywoływania mikroprzepływów bezpośrednio z elementów interfejsu.
DEMO: Konfiguracja Security Production
Przełączenie Poziomu
Zmiana z Prototype na Production w ustawieniach projektu
User Roles
Utworzenie ról: Administrator i Klient
Module Roles
W module Rezerwacje: Rezerwacje_Admin i Rezerwacje_Wlasciciel
Mapowanie
Administrator → Rezerwacje_Admin; Klient → Rezerwacje_Wlasciciel
Entity Access
Konfiguracja dla Rezerwacja z XPath constraints
Weryfikacja
Testowanie jako różne role użytkowników
Domain-Driven Design
Zarządzanie złożonością przez umieszczenie modelu biznesowego w centrum
Problem Monolitu: Big Ball Of Mud
Trudności w Zarządzaniu
Pojedynczy, duży model staje się niemożliwy do ogarnięcia. Zmiany w jednym miejscu wpływają nieprzewidywalnie na inne.
Problemy ze Skalowaniem
Trudności w pracy wielu zespołów nad jednym modelem. Konflikty, kolejki, blokady.
Rozwiązanie: Dekompozycja
Podział na mniejsze, spójne i autonomiczne części. Domain-Driven Design pokazuje jak to zrobić.
Fundamenty DDD
Ubiquitous Language
Wspólny, precyzyjny język dla ekspertów domenowych i deweloperów. Używany wszędzie: w dyskusjach, dokumentacji i w kodzie/modelu.
Strategic Design
Projektowanie na dużą skalę. Jak podzielić system na niezależne części? Bounded Contexts i Context Mapping.
Tactical Design
Projektowanie na małą skalę. Jak modelować obiekty wewnątrz części? Aggregates, Entities, Value Objects, Services.
Bounded Context: Ograniczony Kontekst
Definicja
Jawna granica, wewnątrz której dany model domeny i wszechobecny język mają jedno, spójne znaczenie.
Różne konteksty mogą używać tych samych słów, ale z innym znaczeniem biznesowym!
Przykład
Kontekst Sprzedaży: Produkt ma cenę, stan magazynowy, kategorie
Kontekst Wsparcia: Ten sam Produkt ma dokumentację, historię zgłoszeń, wersje oprogramowania
To dwa różne modele! Próba połączenia = chaos.
Bounded Context → Aplikacja Mendix
Jeden Kontekst
Jedna aplikacja Mendix
Niezależne Wdrożenie
Osobna baza danych, Runtime
Komunikacja przez API
Nie przez wspólną bazę!
Każdy Bounded Context to osobna, niezależnie wdrażana aplikacja Mendix. Komunikują się przez dobrze zdefiniowane interfejsy (API), zachowując autonomię.
Aggregate: Granica Transakcji
Grupa powiązanych obiektów (encji), które muszą być traktowane jako jedna, spójna całość z punktu widzenia zmiany danych. Agregat definiuje granicę transakcji.
Aggregate Root
1
2
3
4
1
Aggregate Root
2
Jedyny punkt wejścia do modyfikacji
3
Obiekty wewnętrzne agregatu
4
Dostęp tylko przez Root

Przykład: Agregat Zamówienie. Zamówienie jest korzeniem. PozycjaZamówienia jest wewnętrzna. Aby dodać pozycję, wywołujesz operację na Zamówieniu: Zamowienie.DodajPozycje(...), a nie tworzysz PozycjęZamówienia w izolacji.
Aggregate → Moduł Mendix
Mapowanie na Mendix
Moduł w Mendix naturalnie grupuje powiązane encje, logikę i UI.
Encja będąca Aggregate Root to główna, "publiczna" encja modułu.
Publiczne API Modułu
"Publiczne" Microflows modułu tworzą jego API i są jedynym sposobem na modyfikację agregatu.
To gwarantuje spójność i wymusza reguły biznesowe w jednym miejscu.
Integracje
Komunikacja pomiędzy kontekstami i ze światem zewnętrznym
Kierunki Integracji
Consumed Services
Nasza aplikacja Mendix wywołuje API innego systemu, aby pobrać dane lub wykonać operację
Published Services
Nasza aplikacja Mendix wystawia swoje API dla innych systemów, udostępniając dane i funkcjonalność
Najpopularniejszy standard dzisiaj: REST/JSON
Consumed REST: Wywoływanie API
01
JSON Structure
Na podstawie przykładowej odpowiedzi JSON, Mendix generuje strukturę non-persistent encji
02
Import Mapping
Wizualnie zmapuj JSON na swoje encje. Określ jak znaleźć obiekty do update lub create
03
Call REST Service/Send REST Request
W Microflow skonfiguruj endpoint, metodę HTTP, nagłówki autoryzacji
04
Zaimportuj dane
W Microflow, zaimportuj dane zwrócone przez Call Rest Service lub Send REST Request używając mapowania
Autoryzacja API: Metody
Basic Authentication
Username i password w nagłówku Authorization kodowane Base64. Proste, ale wymaga HTTPS.
Bearer Token
Token przekazywany w nagłówku Authorization: Bearer <token>. Najczęstszy wzorzec dla REST API.
API Key
Prosty klucz w nagłówku lub query string. Dobry do publicznych API z rate limiting.
Published REST: Wystawianie API
Zdefiniuj Usługę
Określ metodę HTTP i ścieżkę (np. POST /v1/rezerwacje/{id}/anuluj)
Wybierz Microflow
Wskaż Microflow obsługujący zapytanie. Parametry automatycznie przekazane
Export Mapping
Jeśli zwracasz dane, zmapuj swoje encje do struktury JSON
Publiczne API Gotowe
Dostępne dla innych aplikacji (Bounded Contexts)
Business Events
Business Events to nowoczesne podejście do integracji, które pozwala aplikacjom na asynchroniczną komunikację, reagując na istotne zdarzenia biznesowe, zamiast bezpośrednio wywoływać usługi.
Aplikacja Publisher
System (np. Mendix), który emituje informacje o zdarzeniu, nie dbając o to, kto je odbierze.
Zdarzenie Biznesowe
Niezmienny fakt, który się wydarzył w domenie (np. "Zamówienie zostało złożone", "Płatność otrzymana").
Aplikacja Subskrybent
System, który nasłuchuje na konkretne zdarzenia i reaguje na nie, wykonując swoje własne procesy.
Asynchroniczność i Decoupling
Zwiększa skalowalność, odporność na błędy i elastyczność architektury przez luźne powiązanie systemów.
Implementacja Business Events
Implementacja Business Events w Mendix wymaga konfiguracji zarówno na poziomie platformy, jak i w samej aplikacji Studio Pro. Poniżej przedstawiamy kluczowe etapy i pojęcia.
1
Mendix Event Broker
Mendix Event Broker, oparty na Apache Kafka, to serce integracji. Dla aplikacji produkcyjnych wymagana jest licencja, co zapewnia dedykowane kanały (topics) dla Twojej firmy. Darmowe aplikacje korzystają ze wspólnego brokera.
2
Włączanie Usługi
Administrator techniczny musi aktywować usługę Event Broker w Mendix Portal, zarówno na poziomie aplikacji, jak i dla każdego środowiska (środowiska testowe, produkcyjne itd.).
3
Przestrzenie (Spaces)
Przestrzenie izolują wymianę zdarzeń między aplikacjami. Aplikacje w tym samym "space" (domyślnie oparte na nazwie środowiska, np. "acceptance") mogą wymieniać zdarzenia.
4
Kontrola Dostępu
Możesz precyzyjnie kontrolować, które aplikacje mają dostęp do publikowania i subskrybowania konkretnych zdarzeń. Zarządzanie odbywa się przez Event Broker Manager.
5
Format CloudEvents
Wszystkie zdarzenia muszą być zgodne ze standardem CloudEvents i zawierać obowiązkowe atrybuty: ce_id, ce_source, ce_specversion, ce_type.
6
Zewnętrzne Zdarzenia & Mosty
Możesz zdefiniować zdarzenia spoza Mendix (np. w AsyncAPI) i załadować je do Event Brokera. "Bridges" (SQS, HTTP) pozwalają na integrację z systemami zewnętrznymi.
DEMO: Integracja w Praktyce
Proste wywołanie REST API
  1. Zdefiniuj Consumed REST API
  1. Zdefiniuj JSON Mapping
  1. Zdefniuj Microflow
  1. Przetestuj
Konfiguracja usługi Eventów
  1. Zdefiniuj usługę
  1. Stwórz Microflow publikujące event
Dzień 3
Debugowanie i Administracja
Agenda Dnia 3
01
Testowanie i Debugowanie
Profesjonalne techniki rozwiązywania problemów
02
Logowanie i Monitoring
Zrozumienie co dzieje się z aplikacją
03
Administracja Aplikacjami
Przegląd Mendix Control Center
04
Architektura Wdrożeń
Mendix Cloud vs. Private Cloud
05
DevOps Deep Dive
CI/CD dla Mendix for Private Cloud
Debugger w Studio Pro: Podstawy
Breakpoints
Punkt zatrzymania wykonania Microflow. Możesz dodać warunki - zatrzymaj tylko dla konkretnych obiektów.
Step Over / Into / Out
Kontrolowane przechodzenie przez kod. Step Into wchodzi do wywołanego Microflow.
Panel Zmiennych
Śledzenie wartości wszystkich zmiennych i obiektów. Możesz zmieniać wartości w locie!
Konsola
Komunikaty logów w czasie rzeczywistym podczas sesji debugowania.
Zaawansowane Debugowanie
Conditional Breakpoints
Pętla wykonuje się 1000 razy, ale błąd tylko dla jednego obiektu? Ustaw warunek XPath na breakpoincie: $Iterator_Zamowienie/Numer = 'ZAM/123/2024'
Debugowanie Nanoflows
Nanoflowy wykonują się w przeglądarce. Użyj F12 → Console → wpisz mx.debugger; - otworzy interaktywny debugger JavaScript.
Error Handling w Microflows
Domyślne Zachowanie
Błąd zatrzymuje wykonanie i powoduje rollback całej transakcji. Bezpieczne, ale nie zawsze pożądane.
Custom with Rollback
Przechwyć błąd, cofnij zmiany, wykonaj logikę (np. zapisz log, pokaż komunikat). Analogia do try-catch.
Custom without Rollback
Przechwyć błąd, NIE cofaj zmian. Rzadko używane - głównie do logowania niekriytycznych błędów.
Best Practice
Zawsze opakowuj integracje (Call REST) i złożone Commit w bloki obsługi błędów!
Logowanie: Poziomy i Log Nodes
Poziomy Logowania
  • Trace: Najdokładniejsze, krok po kroku
  • Debug: Informacje do debugowania
  • Info: Ogólne info o pracy
  • Warning: Potencjalne problemy
  • Error: Krytyczne błędy
  • Critical: Awarie aplikacji
Log Nodes
Hierarchiczna struktura pozwalająca na niezależne konfigurowanie poziomów dla różnych części aplikacji.
Przykłady: RESTConsume, Database, Security, MyModule
DEMO: Rozwiązywanie Problemów
Scenariusz 1: Błąd Logiczny
Użycie debuggera z conditional breakpoint do znalezienia błędu w skomplikowanym Microflow
Scenariusz 2: Problem N+1
Identyfikacja pobierania danych w pętli - każda iteracja to osobne zapytanie SQL
Analiza SQL
Użycie logów (Trace na Database) do zobaczenia generowanych zapytań
Refaktoryzacja
Wyeliminowanie pętli - pobranie wszystkich danych jednym zapytaniem
Wersjonowanie z Git
Koniec z SVN
Od Mendix 9, każdy nowy projekt domyślnie używa systemu kontroli wersji Git. Starsze projekty SVN można migrować.
Repozytorium Git
Kod źródłowy aplikacji Mendix (pliki .mpr, .mpk, definicje stylów, akcje Java) jest przechowywany w repozytorium Git.
Studio Pro jako Klient Git
Studio Pro posiada wbudowane, wizualne narzędzia do obsługi Git. Znajomość podstawowych koncepcji jest kluczowa.
Co jest wersjonowane?
Każda zmiana w modelu (strona, microflow, encja) jest śledzona przez Git jako zmiana w plikach XML definiujących model.
Podstawowy Cykl Pracy Dewelopera
Pull (Pobierz zmiany)
Zawsze zaczynaj dzień od pobrania najnowszych zmian z repozytorium, aby pracować na aktualnej wersji kodu i minimalizować konflikty.
Pracuj nad zadaniem
Implementuj nowe funkcjonalności, rozwiązuj błędy i rozwijaj aplikację zgodnie z przyjętymi wymaganiami.
Commit (Zatwierdź zmiany)
Regularnie zatwierdzaj swoje postępy lokalnie. Używaj jasnych komunikatów i grupuj małe, logiczne zestawy zmian.
Push (Wyślij zmiany)
Gdy zadanie jest gotowe i przetestowane, wyślij swoje commity do zdalnego repozytorium, aby udostępnić je zespołowi.
Praca w Zespole: Strategia Branchowania
Gałąź (Branch)
Niezależna linia rozwoju kodu. Umożliwia równoległą pracę nad różnymi funkcjonalnościami lub poprawkami bez zakłócania głównej linii projektu.
Gałąź "main" (lub "master")
Główna, stabilna gałąź projektu. Kod w main musi być zawsze działający i gotowy do wdrożenia na środowisko testowe lub produkcyjne. Zasada: Nigdy nie commitujemy bezpośrednio na main!
Gałęzie Funkcjonalne (Feature Branches)
Każde nowe zadanie (funkcjonalność, poprawka, eksperyment) rozpoczynaj od stworzenia nowej gałęzi z main. Stosuj spójne nazewnictwo, np. feature/MX-123-nowa-funkcja lub bugfix/MX-456-poprawka-bledy. Cała praca nad zadaniem odbywa się wyłącznie na tej gałęzi.
Łączenie Zmian: Merging i Pull Requests
Merge (Łączenie)
Gdy praca na gałęzi funkcjonalnej jest zakończona, należy ją połączyć z powrotem do głównej gałęzi main, integrując nowe funkcjonalności.
Konflikty
Pojawiają się, gdy wielu deweloperów zmodyfikowało ten sam element. Mendix Studio Pro oferuje wbudowane, wizualne narzędzia do efektywnego rozwiązywania konfliktów.
Pull Request (Merge Request)
Zalecana praktyka pracy zespołowej. Jest to prośba o połączenie zmian, która umożliwia innym członkom zespołu przegląd kodu, zgłaszanie komentarzy i akceptację przed włączeniem do main.
Mendix Control Center: Centralne Zarządzanie
Apps
Lista wszystkich aplikacji Mendix w organizacji. Zarządzanie środowiskami, członkami zespołu, uprawnieniami.
People
Zarządzanie użytkownikami platformy - developerami, administratorami. NIE użytkownikami końcowymi aplikacji!
Company Settings
Ustawienia firmowe, integracje z IdP (np. Azure AD), SSO, polityki bezpieczeństwa.
Zarządzanie Środowiskami w Cloud
DTAP Cycle
Development → Testing → Acceptance → Production. Standardowy cykl wdrożeń.
Funkcje Środowiska
Start/Stop, Deployment pakietu .mda, Monitoring (alerty, metryki CPU/RAM), Backups, Runtime Settings.
Runtime Configuration
Constants, Scheduled Events, poziomy logowania - wszystko konfigurowalne per środowisko.
Architektura Wdrożeń
Wybór platformy wdrożeniowej ma kluczowe znaczenie dla zarządzania aplikacją. Mendix oferuje dwie główne opcje, dostosowane do różnych potrzeb:
Mendix Cloud
Zalety:
  • Pełna automatyzacja (PaaS)
  • Łatwość obsługi i skalowania
  • Wbudowany monitoring i backupy
Wady:
  • Mniejsza kontrola nad fizyczną infrastrukturą
  • Ograniczona lokalizacja danych (data residency)
Kiedy używać: Domyślny, najszybszy i najprostszy wybór dla większości nowych aplikacji.
Mendix for Private Cloud
Zalety:
  • Pełna kontrola nad infrastrukturą i lokalizacją danych
  • Wdrożenie na dowolnym klastrze Kubernetes (AWS, Azure, GCP, On-Premise)
Wady:
  • Wymaga wiedzy z Kubernetes i DevOps
  • Złożona konfiguracja początkowa
Kiedy używać: Gdy ścisłe regulacje wymagają określonej lokalizacji danych lub firma posiada strategię opartą na Kubernetes.
Porównanie Platform Wdrożeniowych Mendix
¹ Obejmuje usługi dostarczone przez używany serwer baz danych i plikową pamięć masową.
Mendix for Private Cloud
Podstawowe Wymagania
  • Klaster Kubernetes (AKS, EKS, GKE, OpenShift, Rancher).
  • Repozytorium obrazów Docker (ACR, ECR, Harbor).
  • Baza danych PostgreSQL.
  • Storage plików kompatybilny z S3.
Kluczowy Komponent: Mendix Operator
  • Kontroler Kubernetes, który "rozumie" aplikacje Mendix.
  • Automatyzuje procesy: tworzenia Pods, Services, Ingress, zarządzania bazą danych i storage'm.
  • Developer definiuje MendixApp Custom Resource (CRD) w YAML, a Operator zajmuje się resztą.
Proces DevOps dla Private Cloud (CI/CD)
Commit & Push
Developer zatwierdza zmiany w Studio Pro i wysyła je do repozytorium Git (np. GitHub, Azure DevOps).
Trigger Pipeline
Serwer CI/CD (np. Jenkins, GitHub Actions) wykrywa zmianę w repozytorium, automatycznie uruchamiając proces CI/CD.
Build (Budowanie)
Skrypt budujący tworzy pakiet wdrożeniowy (.mda), a następnie buduje obraz Docker na bazie oficjalnego obrazu Mendix.
Push (Repozytorium Obrazów)
Nowo zbudowany obraz Docker jest tagowany i wysyłany do prywatnego lub publicznego repozytorium obrazów.
Deploy (Wdrożenie)
Narzędzie CD (np. ArgoCD) aktualizuje plik manifestu Kubernetes, zmieniając tag obrazu i aplikując go na klaster.
Rollout (Aktualizacja)
Mendix Operator wykrywa zmianę w manifeście i bezpiecznie wdraża nową wersję aplikacji, minimalizując przestoje.
Podsumowanie Szkolenia i Dalsze Kroki
Kluczowe Przesłanie: Mendix to nie tylko narzędzie do "klikania", ale kompletna platforma do tworzenia, wdrażania i zarządzania profesjonalnymi aplikacjami w skalowalny i bezpieczny sposób.
Czego się nauczyliśmy:
Solidne Modele Danych i Reużywalne UI
Jak budować solidne modele danych i reużywalne interfejsy użytkownika, wykorzystując najlepsze praktyki Mendix.
Architektura DDD
Jak projektować architekturę aplikacji opartą na Domain-Driven Design, dzieląc system na moduły (Agregaty) i aplikacje (Bounded Contexts).
Bezpieczeństwo Produkcyjne
Jak konfigurować szczegółowe bezpieczeństwo na poziomie produkcyjnym, chroniąc dane i procesy.
Debugowanie i Monitorowanie
Jak skutecznie debugować, logować i monitorować aplikacje Mendix, aby zapewnić ich stabilne działanie.
Nowoczesny Proces DevOps
Jak wygląda nowoczesny proces DevOps z użyciem Mendix, obejmujący CI/CD i zarządzanie wersjami.
Twoja Droga Dalej:
Mendix Academy
Kontynuuj naukę na platformie Mendix Academy, zwłaszcza kursy takie jak "Advanced Developer", aby pogłębić swoją wiedzę.
Dokumentacja Mendix
Regularnie korzystaj z oficjalnej dokumentacji Mendix – jest to Twoje najważniejsze źródło aktualnej i szczegółowej wiedzy.
Forum Mendix
Dołącz do społeczności Mendix na forum, gdzie znajdziesz wsparcie, odpowiedzi na pytania i inspirację od innych deweloperów.
Dziękuję za Uwagę!
Jacek Pietsch
Tel. 510 899 666