Miksi Apexin pitäisi olla ensisijaisia vaihtoehtoja nykyaikaisessa Salesforce-toteutuksessa

Pohdin äskettäin, miksi Flow’ta pidetään yhä lähes ensisijaisena vaihtoehtona, kun Salesforcessa toteutetaan jotain.

Flow on heti käyttövalmis. Se on visuaalinen ja rakenteellinen. Värit ovat kauniita. Sitä markkinoidaan ratkaisuna, jota pääkäyttäjät voivat ylläpitää. Apexia puolestaan moititaan usein erittäin monimutkaiseksi, pitkälle räätälöidyksi, kalliiksi toteuttaa ja vaikeaksi ylläpitää.

Monissa Flow’ta ja Apexia vertailevissa artikkeleissa Flow esitetään oletusarvoisesti parempana vaihtoehtona. Samat edut toistuvat: se on yksinkertaisempi ja helpompi ylläpitää, vaatii vähemmän teknistä osaamista ja on yleensä suositeltu valinta.

Aloin pohtia, onko tämä näkemys edelleen pätevä. Tekoälyavusteisen ohjelmoinnin ja vibe coding -työkalujen myötä monet Apexia vastaan perinteisesti esitetyt perustelut eivät ole enää yhtä vahvoja kuin ennen. Samalla Flow esitetään mielestäni usein paljon yksinkertaisempana kuin se todellisuudessa on.

Pääajatukseni on yksinkertainen: Apex ei ole niin vaikea, eivätkä Flow-työnkulut ole niin helppoja. Niiden monimutkaisuudessa on paljon vähemmän eroa kuin yleensä oletetaan.

Flow näyttää yksinkertaiselta, koska se on visuaalinen

Aloitetaan Flow-työnkuluista. Niissä on monia samoja rakenteita kuin Apexissa: toistoja, kyselyjä, toimintoja, ehtoja, arvonmäärityksiä ja niin edelleen.

Yleensä tarvitaan tietoa siitä, miten sovellus ja algoritmi rakennetaan. Flow-työnkulku on algoritmi aivan kuten koodikin.

Taustalla Flow on tämän algoritmin XML-esitys, kun taas Apex on ohjelmointikieli, joka niin ikään esittää algoritmin. Molemmissa tapauksissa algoritmi muutetaan sitä suorittavan koneen ymmärtämään muotoon.

Onko Flow’n logiikka suoraviivaista? Ei aivan. Flow’n logiikka esitetään visuaalisesti.

Tämä visuaalinen esitystapa saa ihmiset ajattelemaan, että Flow on Apexia yksinkertaisempi. Mielestäni tämä yksinkertaisuus voi olla harhaanjohtavaa.

Flow’lla voi toteuttaa monia samantyyppisiä asioita kuin Apexilla, ja Flow’n ja Apexin voi yhdistää kutsuttavien toimintojen avulla. Ne palvelevat monissa tapauksissa samaa tarkoitusta, ja niiden suoritus käynnistyy samankaltaisista tapahtumista, kuten tietueiden päivityksistä, ajastuksista ja käyttäjien toimista Salesforcessa.

Monimutkaisuuden kannalta Flow-työnkulut voivat vaikuttaa yksinkertaisemmilta, koska ne ovat visuaalisia kaavioita. Apex puolestaan edellyttää koodinlukutaitoa. Flow’ta on kuitenkin käsiteltävä yhtä huolellisesti kuin Apexia. Aiheeseen pääset alkuun lukemalla Salesforce Flow Builderin yleiskatsauksemme.

Vähäkoodinen kehittäminen vaatii silti ohjelmistoteknistä ajattelua

Kun sanomme, että pääkäyttäjätiimit riittävät automaation ylläpitoon, se voi pitää paikkansa – mutta vain yhdellä tärkeällä ehdolla. Flow’ta ylläpitävien ihmisten on osattava rakentaa algoritmeja.

He tarvitsevat ajattelutavan, jonka avulla he osaavat rakentaa vaiheittain eteneviä algoritmeja, huomioida virhetilanteiden varamenettelyt, ennakoida mahdollisia ongelmia ja miettiä tulevia tarpeita. He tarvitsevat myös keinon testata tätä toiminnallisuutta automaattisesti.

Odottaisin jokaiselta tällaisia automaatioita toteuttavalta järjestelmällistä ajattelua ja ymmärrystä siitä, miten algoritmeja, järjestelmiä ja sovelluksia rakennetaan.

Sinun pitäisi osata pohtia, mitkä syötteet ovat algoritmille virheellisiä, millaisia tuloksia odotat, mitkä virheet pystyt käsittelemään ja mitä virheitä et pysty käsittelemään.

Vähäkoodinen kehittäminen ei poista ohjelmistoteknisen ajattelun tarvetta. Tekoälyn tuottama koodi ei poista sitä myöskään.

Missä Flow toimii hyvin ja milloin alan harkita Apexia

Flow sopii erinomaisesti yksinkertaiseen automaatioon. Jos vaatimus on ”Kun myyntimahdollisuuteni tila on Closed Won, lähetä sähköposti-ilmoitus”, sitä voi kyllä ylläpitää aivan hyvin Flow’lla.

Flow sopii erinomaisesti myös silloin, kun haluat asiakaspalvelijoillesi käyttöliittymän ohjaaman prosessin. Jos haluat nyt lähettää markkinointisähköpostin, luoda kampanjalle työnkulun ja sitten poistaa sen käytöstä tai muuttaa sitä kolmen kuukauden kuluttua, Flow on hyvä valinta. Juuri tällaisissa tilanteissa Flow on vahvimmillaan.

Jos kuitenkin haluat jotain monimutkaisempaa – kuten etsiä kaikki liidit, joiden Company-kenttä muistuttaa juuri tekemässäsi muunnossa syntyneen Account-tietueen nimeä, ja sitten muuntaa nämä liidit – tilanne on toinen.

Oma nyrkkisääntöni on, että jos Flow-työnkulussa on enemmän kuin noin kymmenen elementtiä, alan jo tarkastella sitä huolellisemmin. Jos työnkulussa yhdistyvät toistot ja kyselyt tai sen täytyy hakea, kerätä, yhdistellä, ryhmitellä tai analysoida tietueita, se alkaa mielestäni jo olla monimutkainen. Tämä ei ole Salesforcen virallinen suositeltu käytäntö. Se on vain oma nyrkkisääntöni.

Tässä vaiheessa saman asian toteuttaminen Apexilla voi olla paljon helpompaa, varsinkin tekoälyn tuottaman koodin avulla. Välttäisin logiikan sijoittamista Flow’hun, kun minun on määritettävä vastaavuus yhden tietuearvon ja toisen välille, analysoitava tai ryhmiteltävä tietueita, käsiteltävä tietoja massana tai toteutettava logiikkaa, johon liittyy runsaasti transaktioita.

Syynä ei ole se, ettei Flow pystyisi tähän. Kyllä se pystyy. Mutta se, että jotain voi rakentaa Flow’lla, ei tarkoita, että Flow olisi paras tapa esittää algoritmi. Hyvin suuren Flow-työnkulun voisi korvata pienellä määrällä Apex-koodia.

Kun sanon, että tehokäyttäjät voivat epäonnistua Flow’n kanssa surkeasti, en tarkoita, että Flow olisi huono. Ratkaisevaa ei ole työkalu vaan se, miten sitä käytetään. Ongelma on näppäimistön ja tuolin välissä.

Vastaan tulee toteutuksia, joissa Salesforce-organisaatioon on kasautunut paljon aktiivisia ja käytöstä poistettuja Flow-työnkulkuja, käyttämättömiä kenttiä sekä päällekkäisiä kenttiä, työnkulkuja ja logiikkaa. Järjestelmä saattaa silti toimia, mutta tällaisessa kokonaisuudessa jokainen uusi ohjelmointivirhe tai ongelma kasvattaa ylläpitokustannuksia.

Flow’ta pitäisi käsitellä koodina

Toisin kuin Apexissa, Flow-työnkuluissa ei ole pakollisia yksikkötestejä. Flow-automaation logiikan kattavia testejä voi kyllä rakentaa, mutta se ei ole pakollista – ja se, mikä ei ole pakollista, jätetään usein tekemättä.

Kyse ei ole siitä, etteikö Flow’ta voisi testata. Kyse on siitä, että Flow’n visuaalisuus voi luoda harhakuvan, ettei se jotenkin olisi koodia eikä vaatisi samanlaista kurinalaisuutta.

Sitä pitäisi käsitellä koodina. Mukana pitäisi olla nimeämiskäytännöt, siivous, versionhallinta, testaus, vertaisarviointi ja käyttöönottoprosessi.

Tämä eroaa Apexista, jossa testit ovat pakollisia tuotantoon viennissä ja vaadittu koodikattavuuden raja on saavutettava. Flow-työnkulun voi viedä tuotantoon ilman automaattisia testejä. Kyse ei ole siitä, etteikö Flow’ta voisi testata, vaan siitä, että testaus on helpompi jättää väliin, kun alusta ei sitä vaadi.

Vertaisarvioinnin näkökulmasta Flow voi itse asiassa olla Apexia vaikeampi katselmoida. Jos avaan Apex-koodin GitHubissa, jopa Java-ohjelmoija voi tunnistaa päällekkäisyyksiä, valtavia metodeja, huonoa arkkitehtuuria, monimutkaisia ehtoja ja silmukoita tai epäselviä vastuunjakoja.

Flow’n XML-esityksen kanssa se on paljon vaikeampaa. Edes Salesforce-ohjelmoijat eivät pysty kunnolla katselmoimaan Flow-työnkulkua GitHubissa pelkkää XML:ää tarkastelemalla, vaan heidän on avattava työnkulku visuaaliseen näkymään. Vaikka Flow näyttää Salesforcessa yksinkertaiselta, se voi siis olla versionhallinnan ja koodikatselmoinnin näkökulmasta vaikeammin hahmotettava.

Miksi Apexilla on nyt enemmän etuja

En yritä sanoa, että Apexin pitäisi nyt olla oletusarvoinen tapa rakentaa kaikki Salesforce-automaatio. Tarkastelen ajatusta siitä, että Apexilla on paljon enemmän etuja kuin vaikkapa kuusi vuotta sitten.

Monet Apexia vastaan perinteisesti esitetyt perustelut – monimutkaisuus, kehityskustannukset ja ylläpitokustannukset – eivät ole enää yhtä vahvoja kuin ennen. Tärkein syy ovat tekoälyavusteiset ohjelmointityökalut.

Apex muistuttaa Javaa ja C#:a. C#:a suosiva löytää siitä paljon yhtäläisyyksiä C#:n kanssa, ja Javaa suosivan silmissä se näyttää tutulta. Näin yleisiä kieliä muistuttavasta ohjelmointikielestä on hyötyä.

Javalla, C#:lla, JavaScriptillä, HTML:llä ja monilla muilla teknologioilla on kirjoitettu paljon koodia. Nykyaikaiset suuret kielimallit ovat erittäin hyviä näiden kielten kanssa ja kokemukseni mukaan myös Apexin ja Lightning Web Componentsin kanssa.

Epäilen, että tämä on myös yksi syy siihen, miksi suuret kielimallit suoriutuvat Flow-metatietojen kanssa paljon heikommin: Salesforce Flow’n XML:stä ei ole yhtä paljon koulutusdataa, ja julkisista GitHub-tietovarastoista on vaikea löytää suuria määriä Flow-työnkulkuja. Tämä on oma epäilyni, enkä pysty todistamaan sitä.

Kokemukseni mukaan suuret kielimallit tuottavat huomattavasti paremmin Apex-koodia kuin Flow-metatietoja tyhjästä. Flow’n kohdalla olen nähnyt epäonnistumisia, joissa malli yksinkertaistaa tehtävää, luo paljon kutsuttavia toimintoja ja jättää Flow’n käytännössä pelkäksi käynnistyspisteeksi. Olen myös nähnyt tuotettua XML:ää, jonka käyttöönotto Salesforcessa ei onnistunut oikein.

Olemassa olevan Flow-työnkulun muokkaaminen on suurelle kielimallille helpompaa kuin uuden luominen tyhjään Salesforce-organisaatioon, mutta silloinkin se voi tehdä virheitä.

Tekoäly muuttaa Apex-kehityksen taloudellisia lähtökohtia

Codexin, Claude Coden ja OpenCoden kaltaisilla työkaluilla kehittäjät voivat nyt yhdistää suuren kielimallin suoraan kehitysprojektiin tai Salesforce-koodipohjaan.

Suuri kielimalli voi löytää koodipohjasta tiettyjä osia, tunnistaa ongelmia ja ohjelmointivirheitä, seurata logiikan kulkua ja tuottaa muutoksia huomattavasti nopeammin kuin kehittäjä pystyisi tekemään käsin. Myös itse koodin tuottaminen on hyvin nopeaa, joten kehittäjät voivat rakentaa ja kehittää ratkaisuja iteratiivisesti paljon nopeammin.

Tämä ei kuitenkaan poista ohjelmistoteknisen osaamisen tarvetta.

Kehittäjät, jotka ymmärtävät, miten Salesforce-ratkaisut pitäisi suunnitella, voivat ohjata suurta kielimallia oikeisiin arkkitehtuuripäätöksiin, toteutustapoihin ja koodausmalleihin. Näin he voivat tuottaa selkeää ja toimivaa koodia käyttämättä yhtä paljon aikaa kaiken kirjoittamiseen itse.

Työ, johon aiemmin saattoi kulua kuukausi, voidaan nyt joskus saada valmiiksi muutamassa päivässä.

Ero ei ole pelkästään nopeudessa.

Kehittäjät voivat käyttää enemmän aikaa asioihin, joilla on todella merkitystä: ydinlogiikkaan, arkkitehtuuriin, rajatapauksiin, käyttökokemukseen ja ylläpidettävyyteen. He voivat parantaa käyttöliittymää, kattaa testeillä useampia tilanteita ja tehdä lisää viimeistelyä sen sijaan, että jättäisivät ne pois, koska niiden vaatima kehitystyötuntien määrä ylittäisi budjetin.

Suuri kielimalli nopeuttaa toteutusta huomattavasti, mutta laatu riippuu edelleen sitä ohjaavasta kehittäjästä. Kehittäjien on yhä ymmärrettävä, millainen oikean Salesforce-arkkitehtuurin pitäisi olla, mitä suunnittelumalleja kannattaa käyttää ja millaisia kompromisseja he tekevät.

Tekoäly ei korvaa arkkitehtuuria

En oikeastaan enää kirjoita koodia itse, mutta en myöskään vain hyväksy kaikkea tekoälyagentin tuottamaa. Otan täyden vastuun sen tuotoksista.

Katselmointini ei rajoitu koodin läpikäyntiin rivi riviltä. Määrittelen ensin arkkitehtuurin: millainen sen pitäisi olla, mitä ohjelmistokehystä sen pitäisi käyttää ja mitä lähestymistapaa noudattaa. Sitten tarkistan tuotetusta koodista arkkitehtuurivirheet, tarpeettoman monimutkaisuuden, päällekkäisyydet, skaalautumisongelmat ja asiat, joissa ei yksinkertaisesti ole järkeä.

Olennaista ei ole tarkistaa jokaista riviä käsin. Olennaista on ymmärtää jo ennen toteutuksen alkua, millaista arkkitehtuuria odotat.

Jos esimerkiksi koontilaskenta laskee yhteen projektiin tai tehtävään käytetyt tunnit vaikkapa henkilöittäin, minun on otettava rekursio huomioon. Jos sijoitan laskennan kenttien päivityslogiikkaan, se voi käynnistää rekursiivisia päivityksiä. Tämä voi johtaa Salesforcessa hankaliin SOQL 101 -virheisiin tai CPU-rajan ylittymiseen.

Tekoälyagentti saattaa tuottaa ratkaisun, joka toimii kymmenellä tietueella. Se ei tarkoita, että ratkaisu toimisi kunnolla suurilla tietomäärillä. Koska kuitenkin ymmärrän, mitä pitäisi tehdä, voin ohjata tekoälyagenttia.

Voimme käyttää trigger-kehyksiä ja välittää ohjauslippuja. Joissakin tapauksissa yhteenvetolaskentaa tehtäessä triggereitä ei tarvitse suorittaa uudelleen. Näin voimme rakentaa ylläpidettävän infrastruktuurin. Juuri tässä ohjelmistoteknisellä osaamisella on edelleen merkitystä.

Kun rakenne on määritelty, iteratiiviset päivitykset helpottuvat huomattavasti. Virheiden korjaaminen, uusien ominaisuuksien lisääminen ja refaktorointi helpottuvat, ja monissa tapauksissa työn voi delegoida konsultille tai pääkäyttäjälle.

LWC on toinen hyvä esimerkki

Yhdistämällä tekoälyn ja kehittäjän osaamisen voimme parantaa tuottavuutta merkittävästi Apexin ja Lightning Web Componentsin (LWC) käytössä.

Esimerkiksi LWC:n avulla OpenAI Codex voi luoda vaikuttavia sovelluksia Salesforceen. Joissakin projekteissa en halua tuoda kaikkea työtä, tehtäviä tai työkirjauksia Salesforcen tietoihin. Voin sen sijaan rakentaa joustavia, tietueisiin liittyviä luettelonäkymiä, jotka tunnistavat, ettei tietoja ole Salesforcessa, ja hakevat ne API-rajapinnasta.

Tekoälystä on hyötyä myös käyttöliittymän pienissä yksityiskohdissa, kuten latausilmaisimen sijoittamisessa painikkeeseen. Tiedän, että CSS ja HTML ovat heikkouksiani; en nauti käyttöliittymäominaisuuksien ja animaatioiden työstämisestä. Codex pystyy hoitamaan tämän työn aivan hyvin samalla, kun minä keskityn näkemääni ja kuvailen, mitä pitäisi muuttaa.

Mitä ydinlogiikan sitten pitäisi olla?

Tämä ei vieläkään anna yhtä selkeää vastausta siihen, minkä työkalun pitäisi olla Salesforcen ensisijainen automaatiotyökalu. Mielestäni Apexia voi käyttää ydinlogiikan rakentamiseen.

Ydinlogiikalla tarkoitan logiikkaa, joka muodostaa organisaation toiminnan selkärangan ja kattaa Salesforce-toteutuksen keskeiset liiketoimintaprosessit. Se voi tarkoittaa asiakaspalvelijoiden tai agenttien käytettävissä olevia toimintoja, kuten Flow-työnkuluista kutsuttavia toimintoja. Se voi tarkoittaa Apexilla kirjoitettuja integraatioita. Se voi tarkoittaa tietojen käsittelyä.

Kun esimerkiksi olen muuntanut liidin asiakkuudeksi, saatan haluta etsiä samannimisiä yrityksiä, tunnistaa niihin liittyvät yhteyshenkilöt ja muuntaa myös ne. Tai saatan haluta paremman tavan suorittaa ajastettuja töitä. Nämä ovat ydintoimintoja, jotka voivat tukea kokonaisia liiketoimintaprosesseja.

Integraatioilla tarkoitan suoria API-integraatioita Salesforcesta silloin, kun valmista yhdistintä ei ole saatavilla eikä käytössä ole jo muuta integraatiotyökalua, kuten MuleSoftia, Talendia tai Jitterbitiä. Tällainen logiikka sopii erittäin hyvin Apexiin.

Käyttäisin Flow’ta enemmän orkestrointiin ja joustaviin muutoksiin: johonkin, joka muuttuu melko usein tai jota et ole varma tarvitsevasi pysyvästi. Saatat esimerkiksi haluta lähettää sähköpostin potentiaalisen asiakkaan edettyä tiettyyn vaiheeseen, toteuttaa tilapäisen markkinointikampanjan tai tarjota asiakaspalvelijoille käyttöliittymän ohjaaman prosessin. Tässä Flow on todella hyvä.

Flow ja Apex toimivat myös erittäin hyvin yhdessä. Voit sijoittaa ydinlogiikan Apexiin, muokata tai orkestroida toimintaa ennen tallennusta ja tallennuksen jälkeen suoritettavilla Flow-työnkuluilla sekä tuoda Apexin käytettäväksi kutsuttavien toimintojen kautta. En näe tätä tiukkana Flow’n ja Apexin välisenä vastakkainasetteluna. Ne voivat täydentää toisiaan erittäin hyvin.

Kehitysprosessi on työkalua tärkeämpi

Toinen tärkeä aihe on muutostenhallinta. Se ei koske vain Apexia vaan Salesforcen koko metatietokerrosta. Myös Flow on Salesforcen metatietoa. Sitä pitäisi pitää koodina silloinkin, kun se esitetään visuaalisena kaaviona.

Keskeistä on, että käytössä on turvallinen kehitysympäristö, erillinen testausympäristö ja niiden lisäksi tuotantoympäristö. Tuotanto on kuin pyhä Graalin malja: sitä tarkkaillaan ja siellä työskennellään, mutta siellä ei tehdä kokeiluja.

Näen paljon suoraan tuotantoon rakennettuja toteutuksia. Se on suurempi ongelma kuin se, käyttikö joku Flow’ta vai Apexia.

Ihannemaailmassa voit käyttää scratch org -ympäristöjä. Jos aloitat toteutuksen puhtaalta pöydältä, scratch org on hyvä lähtökohta. Voit käyttää ydintoiminnallisuuteen hallittua tai hallitsematonta pakettia, ottaa sen käyttöön ja suorittaa testidatan alustavan komentosarjan. Tällaisten alustuskomentosarjojen luominen on myös suurille kielimalleille helppo tehtävä.

Näin käytössäsi on laadunvarmistusympäristö, jossa voit testata logiikkaa kuvitteellisilla tiedoilla tuotantotietojen sijaan. Sinun ei siis tarvitse pelätä lähettäväsi oikeille asiakkaille tekaistua laskua tai sähköpostia alennuksesta, jota ei ole olemassa.

Testauksen jälkeen viet saman lähdekoodin tai paketin tuotantoon. Työkalut voivat vaihdella: käytössä voi olla scratch org -ympäristöjä, Salesforce-sandbox-ympäristöjä, paketteja tai CI/CD. Se on toissijaista. Olennaista on, että kehitys, testaus ja tuotanto pysyvät erillään.

Yhteenveto

En tarkoita, että kaikkien pitäisi lopettaa Flow’n käyttö ja siirtyä Apexiin. Mielestäni Apexista ei pitäisi tulla oletusvalintaa kaikkialla.

Sanon, että Apexilla on paljon enemmän etuja kuin kuusi vuotta sitten. Apexia vastaan esitetyt perustelut – kustannukset, monimutkaisuus ja ylläpito – ovat nyt heikompia, koska tekoälyavusteiset ohjelmointityökalut ovat muuttaneet kehitystyön taloudellisia lähtökohtia.

Samalla Flow ei koskaan ollut niin yksinkertainen kuin annettiin ymmärtää. Flow on edelleen ohjelmointia. Se vaatii yhä algoritmista ajattelua, arkkitehtuuria, testausta, muutostenhallintaa ja ohjelmistoteknistä osaamista.

Mielestäni ”käytä Flow’ta, ellet ehdottomasti tarvitse Apexia” ei enää ole hyvä oletusohje. En myöskään pidä ohjetta ”käytä Apexia kaikkialla” hyvänä vastauksena. Jokainen toteutus on omanlaisensa.

Sinun on mietittävä, mitä olet rakentamassa. Onko yrityksesi pieni vai suuri? Kuinka paljon räätälöintiä tarvitset? Kuinka vakaata logiikka on? Kuka sitä ylläpitää? Kuinka paljon ohjelmistoteknistä osaamista käytettävissäsi on? Kuinka usein logiikka muuttuu? Millaisia tietomääriä käsittelet? Tee päätös vasta sitten.

Itse sijoitan vakaan, uudelleenkäytettävän ydinlogiikan mieluummin Apexiin. Orkestrointiin, käyttöliittymän ohjaamiin prosesseihin, ilmoituksiin ja joustaviin muutoksiin valitsen useammin Flow’n.

Kun Flow-työnkulku alkaa kasvaa suureksi algoritmiksi, jossa on silmukoita, kyselyjä, ryhmittelyä, vastaavuusmäärityksiä ja monimutkaista logiikkaa, pysähtyisin ainakin harkitsemaan uudelleen, pitäisikö sen yhä olla Flow-työnkulku.

Tämä ei ole yleispätevä sääntö. Tämä on keskustelua – ja nykyään se keskustelu on paljon kiinnostavampaa kuin pelkkä toteamus siitä, että Flow on helppo ja Apex vaikea.