Apex wykonuje się na serwerach Salesforce, w sąsiedztwie innych firm korzystających z tej samej platformy, i stąd biorą się jego twarde limity oraz sposób pisania kodu.
Apex różni się od zwykłego języka backendowego jedną rzeczą: nie decyduje o tym, ile zasobów zużyje. Kod działa na serwerach Salesforce, obok kodu tysięcy innych firm, więc platforma przerywa go w połowie, gdy przekroczy przydzielony limit. Nazwa myli się z Oracle APEX, czyli środowiskiem do budowania aplikacji nad bazą Oracle, i poza zbieżnością liter łączy te dwa produkty wyłącznie nazwa.
Obraz porządkujący całą resztę to mieszkanie w bloku. Instalacja jest wspólna, przydział mocy na mieszkanie stały, a bezpiecznik wybija, kiedy ktoś włączy naraz zbyt wiele urządzeń. Nie da się poprosić o mocniejszy, bo sąsiedzi korzystają z tego samego przyłącza.
Apex jest językiem obiektowym o składni przypominającej Javę, wymyślonym przez Salesforce do jednego zadania: dokładania własnej logiki do gotowego systemu obsługi klientów. Kod pisze się, kompiluje i uruchamia po stronie platformy, nigdy na maszynie firmy. Nie ma tu serwera do zalogowania, nie ma pliku na dysku, nie ma własnego procesu w tle.
Do danych sięga się wbudowanym językiem zapytań, a zapis, zmianę i kasowanie rekordów obsługują polecenia będące częścią składni. Struktura obiektów w danej organizacji jest sprawdzana przy kompilacji, więc odwołanie do pola, którego ktoś w międzyczasie nie utworzył, zatrzymuje wdrożenie zamiast wysypać się przy pierwszym kliknięciu użytkownika.
Najczęstsza forma kodu w tej platformie to fragment podpięty pod zdarzenie na rekordzie. Uruchamia go zapis nowej pozycji, zmiana istniejącej, usunięcie albo przywrócenie z kosza, a wersja przed zapisem pozwala jeszcze poprawić dane, zanim baza je przyjmie.
Ważny szczegół: taki fragment nigdy nie dostaje jednego rekordu. Dostaje ich paczkę, bo import z pliku, wywołanie z zewnętrznego systemu albo masowa aktualizacja z listy podają je hurtem. Kod napisany z założeniem pojedynczego rekordu działa bez zarzutu podczas testu przy biurku i wywraca się przy pierwszym imporcie z arkusza.
Platforma liczy zużycie w granicach jednej transakcji i przerywa ją po przekroczeniu progu, zgłaszając wyjątek, którego nie da się przechwycić i zignorować. Progi są opisane w dokumentacji i podane wprost: sto zapytań w trybie synchronicznym i dwieście w asynchronicznym, sto pięćdziesiąt operacji zapisu, dziesięć sekund czasu procesora w trybie synchronicznym i sześćdziesiąt w asynchronicznym, sześć megabajtów pamięci roboczej oraz sto wywołań do systemów zewnętrznych.
Tych wartości nie podnosi się na wniosek i to jest najważniejsza informacja dla osoby planującej budżet. Ograniczenie nie jest ustawieniem do zmiany za dopłatą, tylko warunkiem, w którym trzeba się zmieścić. Zadania cięższe przenosi się do trybu asynchronicznego, gdzie część progów jest wyższa, a przetwarzanie dużych zbiorów dzieli na porcje wykonywane osobno.
Zapytanie umieszczone wewnątrz pętli po dwustu rekordach zużywa dwieście zapytań i kończy się przerwaniem. To samo zapytanie wykonane raz, przed pętlą, z wynikiem odłożonym do słownika, zużywa jedno.
Trzymając się bloku: to różnica między dwustoma osobnymi praniami po jednej sztuce a jednym wsadem. Pralka ta sama, moc ta sama, rachunek zupełnie inny. Cała codzienna dyscyplina pisania w tej platformie sprowadza się do tego jednego nawyku, a przepisanie kodu z jednej formy na drugą jest najczęstszą naprawą po zgłoszeniu „system przestał przyjmować import”.
Salesforce daje narzędzie do budowania przepływów bez programisty i większość reguł biznesowych da się w nim ułożyć klikaniem: wyślij powiadomienie, uzupełnij pole, utwórz zadanie, zapytaj o zgodę. Kod wchodzi tam, gdzie tamto narzędzie się kończy, czyli przy złożonych obliczeniach, operacjach na wielu obiektach naraz, integracjach wymagających przetworzenia odpowiedzi i regułach, których nie da się zapisać jako sekwencji kroków.
Różnica w utrzymaniu jest jednak realna. Przepływ zmieni osoba administrująca systemem, kod wymaga programisty, środowiska testowego i wdrożenia. Przy tej samej funkcjonalności wybór między jednym a drugim jest wyborem między krótszym czasem reakcji a większą swobodą.
Wdrożenie kodu na organizację produkcyjną wymaga, żeby testy jednostkowe pokrywały co najmniej 75 procent kodu i żeby wszystkie przechodziły. Nie ma obejścia ani zgody na wyjątek. Skutek uboczny jest znany każdemu, kto przejmował starszą organizację: część testów została napisana wyłącznie po to, żeby przepchnąć liczbę, i nie sprawdza niczego poza tym, że kod się wykonał.
Do tego dochodzą trzy wydania platformy w roku. Zmiany zachowania bywają drobne, ale kod odziedziczony po kilku dostawcach i pisany przez kilkanaście lat reaguje na nie w sposób trudny do przewidzenia z góry, bo wszystko działa w jednej wspólnej przestrzeni i wzajemnie się przeplata.
Gdy tę samą regułę da się złożyć w przepływie. Gdy zadanie polega na przemieleniu setek tysięcy rekordów w nocy, bo takie przetwarzanie lepiej wykonać poza platformą i wgrać gotowy wynik. Gdy chodzi o połączenie kilku systemów, a rolę pośrednika może wziąć narzędzie integracyjne stojące obok.
Ostatni przypadek jest najczęstszy i najdroższy: kod pisany po to, żeby ominąć limit, który sygnalizuje błąd projektowy. Wywołanie zewnętrznej usługi w wyzwalaczu przy każdym zapisie rekordu spełni wymaganie na demonstracji i przewróci import przy pierwszym pliku z tysiącem wierszy.
Mogę Ci jakoś pomóc?
Luka w konsoli Trend Micro Apex One na własnym serwerze pozwala bez logowania wykonać polecenia i sterować ochroną wszystkich komputerów. CISA potwierdza ataki. Zainstaluj Critical Patch 14081 i odetnij konsolę od internetu.
Czytaj wpis
Błąd w lokalnym serwerze Apex One pozwala osobie z dostępem administratora wstrzyknąć kod, który serwer roześle do agentów na wszystkich komputerach. CISA i Trend Micro potwierdzają ataki. Zainstaluj poprawkę i sprawdź konta administratorów.
Czytaj wpisKlikając „Akceptuję”, zgadzasz się na przechowywanie plików cookie przez UXU w celu poprawy działania strony, analizy i wsparcia działań marketingowych.