DevTalk #140 – O Salesforce CRM ze Stanisławem Zaniem

limity platformy. I to powoduje, że kod, który napiszemy musi się skończyć wykonywać np. w 10 sekund. I nie może trwać ani sekundy dłużej, bo inaczej aplikacja nam po prostu przerwie działanie i... Z powrotem do bazy i jest nieużywana. Kolejnym nitem jest to, że pamięć nie może przekroczyć 3 MB albo nie możemy zrobić więcej niż 100 zapytań do bazy danych w czasie działania tego programu. Names mentioned. Mamy bezpośrednie połączenie do bazy danych na platformie, to nie korzystamy na ogół z żadnych ORM-ów, żadnych mapperów bazanowych, tylko jak chcemy sobie coś wyciągnąć z bazki, to sobie po prostu piszemy, lista równa się, nawias kwadratowy, zapytanie SOQL-owe w zasadzie i zwraca nam to wszystkie rekordy z bazy, które chcemy.

Wspomniałeś o tym, że kod musi być pokryty testami w minimum 75%, a następnie od razu przeskoczyłeś do tego, że 10 testerów klepie manualnie na jednym serwerze i testuje tę aplikację. To o jakich testach mówimy? No właśnie i tutaj zależy jak też te testy zdefiniujemy. Teoretycznie mówimy o... Wymóg pokrycia 75% jest dla testów unitowych, jednostkowych. Chociaż wiem, że jakby ktoś spojrzał takim purystycznym okiem na te testy, to by powiedział, że to nie są wcale testy jednostkowe, tylko to są testy prawie że integracyjne, ponieważ sam Salesforce w dokumentacji wymaga, żeby... W czasie pisania testów stworzyć sobie rekord w bazie danych testowej, po prostu przez te nasze DML-owe i SQL-owe zapytania, pobrać ten rekord i coś sobie sprawdzić.

I ten kod później się nie kompiluje na przykład. Nie jest to tak 100% autopilot, jednak trzeba tam trochę popatrzeć, żeby zobaczyć, czy na pewno to w ogóle się zapisze poprawnie. Czy ja bym na ten moment zostawił wszystko agentowi takiemu? Chyba nie, no bo jednak te limity potrafią czasem uderzyć w taki sposób, że no agent może o tym nie wiedzieć, tak? I z jego perspektywy jest dobrze, a z drugiej strony nam się baza danych lokuje, bo robimy zapytania w zły sposób i finalnie użytkownik nie może otworzyć na przykład rekordu, bo SOQLka się nie może dokończyć. Jak sobie radzisz z tymi różnymi ograniczeniami? Czy tam radzicie jako społeczność? Na przykład jeśli koniecznie musicie zrobić jakieś operacje na więcej niż 10 tysiącach rekordów, albo jak mówiłeś na samym początku, że coś tam działa wolniej, bo akurat na tym samym serwerze bank puszcza jakieś obliczenia, no to prawdopodobnie operują na większych...

To pytanie, o co pytasz. Mamy dostęp do bazy, która jest w naszej instancji, natomiast przez to, że to środowisko jest multi-tenant i jest takie elastyczne, to jakbyśmy chcieli czytać, jak to działa pod spodem, to tak naprawdę my działamy na zwirtualizowanym, zdormalizowanym modelu, który się na bieżąco dla naszej instancji Salesforce'a buduje. Więc my operujemy w zasadzie na takich dużych widokach. I jestem w stanie jako developer, jako użytkownik sobie zrobić SQL-kę do bazy. Nie ma problemu. Mogę zrobić DML-a, dodać jakieś rekordy albo usunąć. Natomiast jak to wygląda faktycznie na serwerze Salesforce pod spodem, no to tam już dostępu nie mamy. I na przykład jak chcemy sobie zrobić jakieś lepsze indeksy, to też trzeba do Salesforce pisać, żeby nam po swojej stronie włączył indeks na konkretnym polu, żeby nam QR-ka szybciej działała, no bo po naszej stronie mamy trochę ograniczone te możliwości indeksowania.

Bo sam produkt jako taki jest znany, jest popularny. Gdyby był słaby, to by padli. Natomiast właśnie ta perspektywa czysto techniczna twoja jest interesująca. No dobra, to z mojej strony to chyba by było tyle. Powiedz proszę jeszcze, gdzie można cię znaleźć, co planujesz, jeśli chodzi o Salesforce i swoją karierę dalej tutaj. No to można mnie znaleźć na pewno na Linkedin. Staram się czasem coś napisać, czasem jakieś blog posty wstawię lub przejdę się na konferencję i wystawię jakiś panel. Być może będę w tym roku bardziej aktywny, zobaczymy. I też myślałem, żeby otworzyć podcast, więc jeżeli się do tego dojdzie, to na pewno na moim Linkedinie się pokażę. SOQL w pętli. O Salesforce. Tak, o Salesforce.