Egy Salesforce integráció szinte soha nem a protokollon bukik el. A hitelesítés megoldott feladat, és egy rekord kiírása is az. A projekteket a napi híváskvóta és az adatmodell alakja zárja le, és mindkettőt jellemzően a bevezetés után nagyjából három héttel fedezik fel, amikor az éjszakai feladat hibákat kezd visszaadni, és senki nem tudja megmondani, miért működött a tesztelés során.

A minta elég következetes ahhoz, hogy előre lehessen jelezni. A fejlesztő egy Developer Edition szervezet ellen épít, minden lefut, az ügyfél elfogadja. A kód ezután találkozik egy éles szervezettel, amelyben már ott van egy marketing csatlakozó, egy adattárházi kinyerés és egy 2019-es Apex trigger, és a bőkezűnek tűnő híváskeretről kiderül, hogy közös kassza, amelyből mások már költenek.

Ez a cikk előrehozza a meglepetéseket: melyik API-t érdemes használni, hogyan számolják a kvótát, mi történik, ha az írásod olyan kódot indít el, amelyet nem te írtál, hogyan változott a hitelesítés, és mely adatmodell döntéseket drága visszacsinálni.

Mi dönti el, hogy egy Salesforce integráció sikerül-e? A kvóta és az adatmodell, nem a protokoll. A napi API híváskvóta a teljes szervezetre vonatkozik, és a kiadásból meg a licencszámból adódik, így egy jól viselkedő integrációt kiéheztethet egy rosszul megírt másik ugyanabban a szervezetben. Az első kódsortól tervezz kötegelt feldolgozásra, még bármilyen írás előtt egyezzetek meg az external ID-król és az upsertről, és számolj azzal, hogy minden elküldött rekord valaki más Apex kódját indítja el.

Mit kell eltalálnia egy Salesforce integrációnak

Négy dolog van, és nem egyforma súlyúak.

Az első a kvóta. A kódod minden szinkron hívása egyetlen, a teljes szervezetre érvényes napi keretből fogy, amelyen a szervezet összes többi fogyasztójával osztozik.

A második az alatta lévő platform. A Salesforce nem egy adatbázis HTTP felülettel. Alkalmazásplatform, és az írásaid triggereket, folyamatokat, érvényesítési szabályokat, duplikátumszabályokat és összesítőket futtatnak, amelyeket olyan adminisztrátorok állítottak be, akik soha nem hallottak a projektedről.

A harmadik az adatmodell. A Lead, a Contact, az Account és az Opportunity nem cserélhető fel egymással, a köztük lévő átalakítás egyirányú és mellékhatásai vannak, a rossz választás pedig adatmigrációt jelent, nem kódmódosítást.

A negyedik az azonosság: hogyan egyezik meg a rendszered és a Salesforce arról, melyik rekord melyik. Ha ezt elrontod, gépi sebességgel gyártasz duplikátumokat. Itt minden más ebből a négyből következik.

Az API-k tájképe, és amelyikre tényleg szükséged van

A Salesforce nagy API-családot ad ki. A Salesforce API index a mérvadó lista, és az alábbi nevek onnan származnak, nem emlékezetből.

REST API és SOAP API

A REST API az alapértelmezés mindenre, aminek rekord alakja van: létrehozás, olvasás, frissítés, törlés, lekérdezés, leírás. Ez a helyes választás egy Leadet író webes űrlaphoz, egy ügyfél nyitott Case-eit olvasó portálhoz és minden kis forgalmú interaktív útvonalhoz.

A SOAP API ugyanezt a munkát végzi WSDL-en keresztül, és azért marad életben, mert nagyon sok vállalati middleware natívan beszéli, és mert erősen típusos szerződést ad, amelyből kliens generálható. A gyakori tévedés az, hogy a SOAP elavult, a REST pedig modern. Mindkettő aktuális, és a SOAP create() meg update() hívása egyenként legfeljebb 200 rekordot fogad, ami többet számít, mint az átviteli formátum.

Bulk API 2.0

A Bulk API 2.0 az aszinkron, feladat alapú út a nagy mennyiséghez. Feltöltesz egy CSV-t, a Salesforce feldarabolja és a háttérben feldolgozza, te pedig lekérdezed az eredményt. A Bulk API korlátai legfeljebb 15 000 köteget engednek gördülő 24 óránként, és legfeljebb 150 millió beolvasott rekordot ugyanabban az ablakban, feladatfájlonként 150 MB felső határral.

A gyakori tévedés az, hogy a Bulkot későbbi hangolásnak tekintik. Ez másik programozási modell: az eredmények aszinkron módon, rekordonként érkeznek vissza, és a kódodnak az első pillanattól így kell fogyasztania őket.

Composite és sObject Collections

Ez a kettő a REST API legértékesebb és legkevésbé használt része. Egy composite kérés legfeljebb 25 alkérést visz egyetlen hívásban, ezek közül legfeljebb 5 lehet lekérdezés vagy sObject Collections művelet, a későbbi alkérések pedig hivatkozhatnak a korábbiak által visszaadott azonosítókra. Az sObject Collections egy kérésben legfeljebb 200 rekordot kezel ugyanabból az objektumból. Mindkettő egyetlen hívásnak számít a napi kvótádból, és pontosan ez a lényeg.

A gyakori tévedés az, hogy nem tudnak a létezésükről. Egy Account, majd egy Contact, majd egy Opportunity létrehozása három egymás utáni hívással háromszor annyi kvótába kerül, mint egy composite kérés, és háromszor annyi késleltetésbe.

Streaming, Change Data Capture és Pub/Sub

A Streaming API a CometD alapú feliratkozási csatorna a PushTopic, az általános, a Platform és a Change eseményekhez. A Change Data Capture közel valós idejű értesítéseket ad ki, amikor rekordokat hoznak létre, módosítanak, törölnek vagy visszaállítanak, így egy külső tároló lekérdezgetés nélkül követheti a Salesforce-t. A Platform Events a saját eseménydefinícióid.

A Pub/Sub API az újabb, gRPC és HTTP/2 alapú felület, amely a közzétételt, a feliratkozást, a séma lekérését és a témák felderítését egyetlen API-ba fogja össze, JSON helyett Avro tartalommal. Új, eseményvezérelt építkezéshez innen indulj.

A gyakori tévedés az, hogy az eseményeket garantált adatfolyamnak tekintik. Nem váltják ki az egyeztetést, a következő szakaszban leírt okból.

Az API híváskorlátok a valódi korlát

Ez az a szakasz, amely eldönti az architektúrádat, és ez az, amelyet a leggyakrabban a tervezés befejezése után olvasnak el.

Hogyan számolják a napi kvótát

Az API híváskorlátok dokumentációja a kiadás és a licencszám alapján állapítja meg a keretet, nem felhasználónként vagy alkalmazásonként. Az API hozzáféréssel rendelkező Enterprise és Professional kiadás 100 000 hívást kap, plusz 1 000 hívást minden Salesforce vagy Salesforce Platform licenc után. Az Unlimited és a Performance kiadás 100 000 hívást kap, plusz 5 000 licencenként. A Developer Edition átalányban 15 000 hívást kap, egy Full sandbox pedig 5 000 000 hívást.

Ebből két dolog következik. Egy hatvan felhasználós Enterprise szervezetnek nagyjából 160 000 hívása van naponta, nem korlátlan készlete. És mivel a keret a licencekből származik, csak több felhasználói licenccel vagy külön vásárolt API hívásokkal emelhető, mindkettő a Salesforce Your Account alkalmazásán keresztül.

Mi számít bele, és mi történik, ha elfogy

A keretet a szervezethez 24 órán belül érkező összes hívás összegére mérik, és ez együtt fedi le a REST API-t, a SOAP API-t, a Bulk API-t, a Bulk API 2.0-t és a legtöbb Connect REST API hívást. Bizonyos csatlakoztatott Salesforce alkalmazások, például a mobilalkalmazás hívásai kimaradnak belőle.

Éppen ez az összegzés az, ami váratlanul éri az embereket. Az integrációdnak nincs saját kerete. Osztozik rajta a riportáló csatlakozóval, a marketing platformmal és a szervezet minden más integrációjával, és egyetlen rosszul megírt fogyasztó, amely harmincmásodpercenként kérdez rá, ki tudja üríteni, és kiéheztet olyan kódot, amely kifogástalanul viselkedik.

Amikor a szervezet túllépi a keretét, a kérések 403-mal és REQUEST_LIMIT_EXCEEDED hibával hiúsulnak meg. A Salesforce a fizetős éles szervezeteknek megenged némi túllépést, mielőtt szigorúan érvényesítené a korlátot, a próba és a Developer Edition szervezetek viszont semmilyen türelmet nem kapnak. Úgy tervezz, mintha nem is lenne.

Mérj, mielőtt elköteleződsz egy terv mellett

Kérd el az adminisztrátortól a szervezet keretét és a jelenlegi napi fogyasztást, mielőtt kódot írsz; a REST API erre külön szervezeti korlát erőforrást tesz elérhetővé. Ha a meglévő fogyasztók már hetven százalékot használnak, egy rekordonként szinkron integráció nem életképes, és a hangolás sem teszi azzá.

A kötegelés tervezési döntés, nem optimalizálás

Amint elfogadod, hogy a keret véges és közös, a terv magától adódik.

Soha ne tegyél ciklusba egyetlen rekordot kezelő hívást. Egy feladat, amely 5 000 Contactot egyesével hoz létre, 5 000 hívást költ. Ugyanez az 5 000 az sObject Collections révén, kérésenként 200 rekorddal, 25 hívást költ. Ez a 200-as szorzó a különbség egy olyan integráció között, amely befér egy közepes szervezet keretébe, és egy olyan között, amely nem.

Használj Composite-ot ott, ahol a munka gráf, nem lista. Egy szülő és a gyermekei egyetlen kérésben történő létrehozása megszünteti a körutakat és azt a köztes állapotot is, amelyet a kódnak egyébként tartania kellene, amíg egy azonosítóra vár.

Használd a Bulk API 2.0-t mindenre, ami inkább betöltésre vagy kimentésre hasonlít, mint tranzakcióra. Interaktív útvonalakra rossz, mert tervezésénél fogva aszinkron, és nem ad szinkron választ a felhasználónak.

Gyorsítótárazd a törzsadatokat. A választéklisták értékei, a rekordtípus azonosítók és a describe eredmények ritkán változnak, mégis minden futásnál ok nélkül újra lekérik őket. Ez az egyetlen változtatás gyakran egynegyedét viszi el egy naiv integráció híváskeretéből.

Governor limitek: az írásod valaki más kódját futtatja

A Salesforce az ügyfelek által írt Apex kódot szigorú, tranzakciónkénti felső korlátok között futtatja. Az integráció szempontjából számító Apex governor limitek a szinkron tranzakciónkénti 100 SOQL lekérdezés, az 50 000 SOQL-lel lekért rekord, a 150 DML utasítás, a DML által feldolgozott 10 000 rekord, a 10 másodperc szinkron processzoridő és a 6 MB memória.

Ezt az Apexet nem te írod. A korlátokba mégis beleütközöl, mert a beérkező írásod olyan tranzakciót indít, amely lefuttatja az objektumon található összes triggert.

Kötegelt szemlélet, Apex írása nélkül

Az ötletet akkor is érdemes megérteni, ha soha nem nyitsz meg egy Apex fájlt.

A Salesforce a triggernek rekordok gyűjteményét adja át, nem egyetlen rekordot. A helyesen megírt trigger a teljes gyűjteményt egy lekérdezéssel és egy frissítéssel dolgozza fel. Az a trigger, amelyet úgy írtak, mintha mindig egyetlen rekordot kapna, rekordonként futtat egy lekérdezést és egy frissítést.

Ez a második trigger évekig kifogástalanul működik, mert a felhasználók a felületen egyesével mentenek. Aztán az integrációd 200 rekordot küld egy kérésben, a trigger 200 alkalommal futtatja a lekérdezését, átlépi a 100 lekérdezéses határt, és az egész köteg elbukik.

A Bulk API 2.0 a beérkező adatokat 200 rekordos blokkokban dolgozza fel, mindegyiket külön tranzakcióban, tehát ez nem elméleti eset. Ez a szokásos formája egy első tömeges betöltésnek egy múlttal rendelkező szervezetbe.

Mit lehet tenni ellene

Vizsgáld át minden olyan objektum triggereit és folyamatait, amelybe írni fogsz, még mielőtt szállítási határidőt vállalsz. Ha egy trigger nem kötegelésre készült, valakinek meg kell javítania, és ehhez a valakihez Apex tudás és telepítési ablak kell. Tervezd be külön tételként.

Ahol a javítás kívül esik a hatókörön, csökkentsd a köteg méretét. A kérésenkénti kétszáz felső határ, nem kötelezettség, és az ötvenre csökkentés néha elég levegőt vesz ahhoz, hogy szállíts, amíg a triggeren végzett munka ütemezésre kerül. Kvótába kerül, ezért kezeld átmeneti megoldásként.

Olyan hitelesítés, amely jövőre is működni fog

Ez a terület érdemben megváltozott, és sok publikált útmutató mára hibás.

Az OAuth 2.0 felhasználónév és jelszó folyamata az, amelyet kerülni kell. A hitelesítő adatokat közvetlenül a kérésben teszi láthatóvá, a Salesforce az újabb szervezetekben alapértelmezetten tiltja, és a connected appokra vonatkozó kivezetése ütemezve van. Minden integrációnak, amely még ezt használja, dátummal ellátott migrációs terv kell.

A szerver szerver közötti munkához, ember nélkül a folyamatban, a két aktuális válasz a JWT bearer folyamat, amely tanúsítvánnyal ír alá egy állítást, és a client credentials folyamat, amely a fogyasztói kulcsot és titkot tokenre cseréli. A Salesforce útmutatója a REST API-k hívásáról az integrációs felhasználóval és client credentialsszel kimondja, hogy ez a folyamat nem ad ki frissítő tokent, ezért a kliens új hozzáférési tokent kér, amikor a régi lejár.

Connected appok és external client appok

Mindennek a tárolója korábban a connected app volt. Most az external client app. A Salesforce világosan kimondja, hogy a connected appok létrehozása a Spring ‘26 kiadástól korlátozott, és helyettük external client appokat javasol, amelyeket az új generációként ír le, a biztonság javítására és a csomagolási gondok megoldására.

Ha az integrációs dokumentációd azt mondja, “hozz létre egy connected appot”, olyan utat ír le, amelyet az új szervezetek talán nem kínálnak. A munka becslése előtt nézd meg, mi vonatkozik a cél szervezetre.

Fusson dedikált integrációs felhasználóval, és tervezz cserét

Adj az integrációnak saját felhasználót, minimális jogosultságú, csak API-ra korlátozott profillal. Ne futtasd névvel azonosított munkatárs alatt. Amikor az a munkatárs távozik és a fiókját letiltják, az integráció leáll, a lehető legrosszabb pillanatban, olyan hibaüzenettel, amely sehová nem vezet.

A tanúsítványok lejárnak, a titkokat pedig cserélik. Mindkettő csendben marad addig a napig, amíg már nem az, és mindkettő teljesen, nem részlegesen viszi le az integrációt. Tedd a lejárati dátumokat olyan naptárba, amelynek van felelőse, tárold a hitelesítő adatokat titokkezelőben, és próbáld ki a cserét sandboxban, mielőtt élesben lenne rá szükséged.

Az adatmodell csapdái

Ezek azok, amelyek három hetet visznek el, mert a visszacsinálásuk adatmozgatást jelent, nem kódmódosítást.

Lead, Contact, Account és Person Account

A Lead minősítetlen érdeklődő, akit még nem kötöttek céges rekordhoz. A Contact egy Accounthoz kapcsolt személy. Az Account egy szervezet. Az átalakítás a Leadből Accountot és Contactot csinál, választhatóan Opportunityvel együtt, és a SOAP convertLead hívás kifejezetten kimondja, hogy csak a cél üres mezőit írja felül, így a gondosan feltöltött Lead mezőid nem biztos, hogy oda kerülnek, ahová várod.

A Person Account bonyolítja a képet. A fogyasztói piacra dolgozó szervezetek bekapcsolják, hogy egy magánszemély összevont Accountként és Contactként jelenjen meg, és egy céges Account modellre írt integráció változtatás nélkül nem fog működni olyan szervezettel, amely ezt használja. Ezt kiábrándító rendszerességgel későn veszik észre.

Az üzleti oldallal együtt, írásban döntsétek el, melyik objektummá válik egy adott beérkező rekord. Ez nem műszaki döntés.

External ID-k és upsert

Ez az egyetlen ésszerű idempotencia mechanizmus, amelyet a Salesforce ad, és nem szabadna alkuképesnek lennie. Hozz létre az objektumon egy egyedi mezőt External IDként megjelölve, és tárold benne a saját rendszered elsődleges kulcsát. Ezután használhatod az upsert műveletet, egy PATCH kérést a /sobjects/{Object}/{ExternalIdField}/{Value} útvonalra, amely létrehozza a rekordot, ha semmi nem egyezik, és frissíti, ha pontosan egy egyezik. A nulla találat 201-et ad vissza, az egy találat 200-at, a több találat pedig 300-zal hiúsul meg ahelyett, hogy találgatna.

A következményt érdemes kimondani. Upserttel egy sikertelen kérés újrapróbálása biztonságos. Nélküle minden újrapróbálás lehetséges duplikátum, és egy hálózati kiesés az éjszakai feladat közben napokban mérhető takarítássá válik.

Szabályok, amelyek az írásaidra sülnek el

A duplikátumszabályok blokkolhatják vagy jelezhetik az integrációd által létrehozott rekordokat. Az érvényesítési szabályok elutasítják azokat a rekordokat, amelyek nem teljesítik az adminisztrátor által beállított feltételeket. Kötelező mezőket hónapokkal a szállítás után is felvehetnek, és ekkor egy működő integráció minden rekordon hibázni kezd.

Ezek egyike sem hiba; a szervezet úgy működik, ahogy beállították. A tévedés az, hogy az elutasított írást átviteli hibának tekintik és a végtelenségig újrapróbálják, holott a helyes válasz az, hogy mezőszintű indoklással emberhez kerüljön. A külső API-k integrációinak hibamintáiról szóló útmutatónk máshol ugyanezt a kategóriát tárgyalja.

Hibakezelés, idempotencia és újrajátszás

Egy újrajátszási mechanizmus nélküli integrációból kézi adatjavítás lesz. Ez nem jóslat, ez történik.

A részleges siker a normális eset. Az sObject Collections az allOrNone értékét alapértelmezetten hamisra állítja, így egy 200 rekordos kérés visszaadhat 187 sikert és 13 hibát egyedi indoklással, és a Bulk API 2.0 is rekordonként ad eredményt. Az a kód, amely csak a külső HTTP állapotot nézi, sikert jelent, miközben csendben rekordokat veszít.

Osztályozd a hibákat, mielőtt újrapróbálnál. Az átmeneti helyzetek, például a sorzárolás, az időtúllépés és a kimerült keret exponenciális várakozást érdemelnek. A determinisztikus hibák, például az érvényesítési hibák és a hiányzó kötelező mezők örökké ugyanúgy fognak elbukni, az újrapróbálásuk pedig olyan keretet éget el, amelyet nem nélkülözhetsz.

Minden menthetetlen rekord a tartalmával és a hibájával együtt egy elfekvő tárba kerül, hogy egy ember megnézze és újraküldje. Mivel az írásaid egy external IDre kulcsolódnak, az újraküldés biztonságos. Naplózd mindkét oldalon a saját azonosítód és a Salesforce azonosító megfeleltetését; fél év múlva ez a napló lesz az egyetlen, ami megmagyarázza, miért hibás az egyik ügyfél rekordja.

És egyeztess. A Platform és a Change események 72 órán át maradnak az eseménybuszban, a platform event keretek pedig napi 25 000 eseményre korlátozzák a kézbesítést Enterprise-on és 50 000-re Unlimiteden és Performance-on. A rekordszámok és a módosítási dátumok ütemezett összevetése elkapja, amit az adatfolyam elejtett.

Middleware vagy közvetlen kapcsolat

A pontból pontba megoldás gyakrabban helyes, mint amennyire a platformszállítók beismerik. Egy forrás, egy cél, egy irány, mérsékelt mennyiség, stabil szerződés: építsd meg közvetlenül, és spórold meg a licencet.

A middleware akkor termeli ki az árát, amikor a topológia megszűnik vonal lenni. Több rendszer cserél adatot, üzleti felhasználóknak telepítés nélkül kell átalakításokat módosítaniuk, egymástól függetlenül hibázó rendszerek között kell vezényelni, és valódi igény van központi felügyeletre és újrapróbálásra.

Az őszinte megjegyzés az, hogy a middleware eltolja a költséget, nem eltünteti. Továbbra is fizetsz a megfeleltetésért, a hibakezelésért és az üzemeltetési tudásért, ráadásul hozzáadsz egy licencet, egy második csővezetéket és egy második, felveendő szaktudást. Az API keret nem változik, mert a middleware ugyanazokat az API-kat hívja, amelyeket a kódod hívott volna.

Azért válaszd, mert a topológiád megköveteli, ne azért, mert kevesebb kódnak látszik. A saját fejlesztés vagy vásárlás döntéséről szóló útmutatónk ugyanezt a mérlegelést járja végig az alatta lévő rendszerekre, a CRM és ERP integrációs útmutató pedig a több rendszeres esetet fedi le. Ha ezt inkább felméretnéd, mint megvitatnád, ott indulnak a szoftverfejlesztési megbízásaink.

Sandboxok, telepítés és API verziók

Sandboxban építkezz. Soha ne éles ellen, és soha ne olyan Developer Edition szervezet ellen, amely nem osztozik az éles beállításokon, mert éppen a beállítások fognak eltörni téged.

Értsd meg, mit csinál egy frissítés. A sandboxot friss másolatra cseréli az éles rendszerből, tehát minden tesztadat, amely csak ott létezett, eltűnik. Aminek túl kell élnie egy frissítést, azt szkriptelni kell és újra futtathatóvá tenni. A csapatok ezt egy hétnyi tesztadat elvesztésével tanulják meg.

Rögzítsd kifejezetten az API verziót minden kérés útvonalában, és ismerd a kivezetési szabályzatot. A Salesforce API életciklus zárási szabályzata vállalja, hogy minden verziót legalább három évig támogat, és a támogatás vége előtt legalább egy évvel értesíti az ügyfeleket. A 21.0 és 30.0 közötti verziókat a Summer ‘25 kiadásban vezették ki, és a kivezetett verzióra küldött kérések 410 Gone választ adnak.

Ez kemény megállás, nem fokozatos romlás, és ezért tartozik a verzió rögzítése a karbantartási tervbe. Ugyanez a fegyelem vonatkozik minden általad közzétett API-ra is, ahogy az API verziózásról szóló bejegyzésünk leírja.

Brit adatvédelem és CRM adatok

Egy CRM szinte teljes egészében személyes adat: nevek, munkáltatók, telefonszámok, e-mail címek, beszélgetésekről készült feljegyzések. Ezek rendszerek közötti mozgatása adatkezelés a UK GDPR értelmében.

Az első kérdés az, ki az adatkezelő. Az ICO adatkezelőkről és adatfeldolgozókról szóló útmutatója az adatkezelőt úgy határozza meg, mint azt a felet, amely az adatkezelés céljait és eszközeit meghatározza, az adatfeldolgozót pedig mint azt, aki az adatkezelő nevében kezel adatot. Amikor egy ügynökség integrációt épít és üzemeltet neked, ez az ügynökség rendszerint adatfeldolgozó, és a 28. cikk követelményeinek megfelelő írásbeli szerződés kötelező, nem választható.

A második a nemzetközi továbbítás. A Salesforce szervezetek és bármely middleware ülhetnek az Egyesült Királyságon kívül, és az ICO nemzetközi továbbításokról szóló útmutatója ismerteti az elérhető mechanizmusokat és azt, mikor kell átadási kockázatértékelés. Aláírás előtt tisztázd, hol landolnak az adatok.

Ebből három következmény adódik. Ne másolj olyan mezőket, amelyekre nincs szükséged, mert az adattakarékosság egyszerre jogi követelmény és kevesebb megfeleltetési munka. Ne tegyél éles személyes adatot sandboxba megfontolt döntés nélkül. És gondoskodj arról, hogy a törlés továbbterjedjen, mert a Salesforce-ban törölt, az adattárházban viszont érintetlenül hagyott kapcsolat élő megfelelőségi probléma, és ugyanez igaz akkor is, amikor mesterséges intelligencia ügynökök érik el ezeket a rekordokat.

Mennyibe kerül egy Salesforce integráció

A Salesforce a saját árazási oldalain közli a kiadás és licenc árait, és mi itt egyetlen összeget sem idézünk belőlük, mert az integráció tervezését az a keret vezérli, amelyet ezek a licencek termelnek, nem a listaár.

Az alábbi számok a Mecanik saját brit szakmai szolgáltatási becslései, nem gyártói árak, és feltételeznek egy már létező szervezetet olyan adminisztrátorral, aki tud kérdésekre válaszolni.

Egy egyszerű, egyirányú integráció, egy webes űrlap, amely external IDvel és értelmes hibakezeléssel hoz létre egy Leadet, jellemzően GBP 3 000 és GBP 7 000 között alakul. Egy vagy két objektum kétirányú szinkronizálása ütközésfeloldással és egyeztető feladattal általában GBP 15 000 és GBP 40 000 közé esik. Egy Pub/Subra épülő, eseményvezérelt integráció újrajátszással, elfekvő kezeléssel és felügyelettel rendszerint GBP 30 000 és GBP 80 000 között landol.

Mit kell tartalmaznia a szállításnak

Mezőszintű megfeleltetési dokumentumot, amelyet az üzleti oldallal egyeztettek, nem pedig kikövetkeztettek. External IDt minden szinkronizált objektumon. Hibakezelést elfekvő tárral és dokumentált újraküldési folyamattal. Egyeztető feladatot. Az API fogyasztás felügyeletét a szervezet keretéhez képest, jóval a felső határ alatt riasztva. Leírásokat a token cseréjéhez, a tanúsítvány lejáratához és az újrajátszáshoz. Szkriptelt sandbox beállítást, amely túléli a frissítést. Az ilyesmi nélküli integráció prototípus, bármi is áll a számlán.

Folyamatos költség

Tervezz havi GBP 400 és GBP 1 500 közötti összeget a felügyeletre, az évi három Salesforce kiadásra, a hitelesítő adatok cseréjére és azokra a mezőváltozásokra, amelyeket egy adminisztrátor szó nélkül elvégez. Azok a szervezetek, amelyek ezt finanszírozzák, azok, ahol az integrációk tovább működnek.

Hogyan épül meg

A hibaminták itt unalmasan következetesek: későn felfedezett keret, egy trigger, amelyet senki nem vizsgált át, egy Lead, amelynek Contactnak kellett volna lennie, és semmilyen mód egy elbukott köteg újrajátszására. Mind a négyet olcsó megelőzni tervezéskor, és drága javítani, ha már valódi rekordok vannak.

A Mecanik a szoftverfejlesztési munkájának részeként épít és tart karban Salesforce integrációkat, és azzal kezd, hogy még egyetlen kódsor előtt átvizsgálja a szervezet keretét, triggereit és adatmodelljét. Egy körülhatárolt integrációs feladathoz teljes megbízás helyett közvetlenül is felvehetsz webfejlesztőt.

Gyakran ismételt kérdések

Hány API hívást kap naponta egy Salesforce integráció? A kiadástól és a licencszámtól függ, és a keret a teljes szervezetre vonatkozik, nem integrációnként. Az API hozzáféréssel rendelkező Enterprise és Professional kiadás 100 000 hívást kap, plusz 1 000 hívást minden Salesforce vagy Salesforce Platform licenc után, az Unlimited és a Performance 100 000 hívást plusz licencenként 5 000 hívást, a Developer Edition pedig átalányban 15 000 hívást egy gördülő 24 órás időszakban.

A REST API-t vagy a Bulk API-t érdemes használnom a Salesforce-hoz? A REST API-t használd interaktív, kis forgalmú, rekord alakú munkához, a Bulk API 2.0-t pedig betöltésekhez és kimentésekhez, ahol nagy a mennyiség és elfogadható az aszinkron válasz. Minden köztes esetben az sObject Collections kérésenkénti 200 rekorddal és a Composite kérésenkénti 25 alkéréssel egyaránt egyetlen hívásnak számít a keretedből, és leveszi a nyomás nagy részét.

Melyik OAuth folyamatot használja egy szerver szerver közötti Salesforce integráció? A JWT bearer folyamatot vagy a client credentials folyamatot, dedikált, csak API-ra korlátozott integrációs felhasználó alatt futtatva. A felhasználónév és jelszó folyamatot az újabb szervezetek alapértelmezetten tiltják, és kivezetésre van ütemezve, ezért új munkához nem szabad használni. Vedd figyelembe azt is, hogy a connected appok létrehozása a Spring ‘26 kiadástól korlátozott, és a Salesforce már external client appokat javasol.

Miért csak nagy kötegeknél hibázik a Salesforce integrációm? Szinte mindig egy olyan Apex trigger miatt, amelyet nem kötegelt feldolgozásra írtak. A Salesforce rekordok gyűjteményét adja át a triggereknek, és az a trigger, amelyet úgy írtak, mintha egyszerre egy rekordot kapna, rekordonként egyszer futtatja a lekérdezéseit, és a köteged megérkezésekor átlépi a 100 SOQL lekérdezéses korlátot. Az egyesével mentő felületi felhasználóknál kifogástalanul működik, ezért maradt észrevétlen.

Szükségem van middleware-re a Salesforce-szal való integrációhoz? Egy forrás, egy cél és egy irány esetén, mérsékelt mennyiségnél nem, mert ott a közvetlen építés olcsóbb és egyszerűbb. A middleware akkor termeli ki az árát, amikor több rendszer cserél adatot, üzleti felhasználóknak telepítés nélkül kell megfeleltetéseket módosítaniuk, vagy központi vezénylésre és újrapróbálásra van szükséged. Eltolja a költséget, nem eltünteti, és nem növeli az API keretedet.