API eller EDI? Att välja rätt kanal för varje partner

Två kunder onboardar dig samma månad. Den ena skickar en fyrtiosidig EDI-anvisning med en katalogversion på försättsbladet. Den andra frågar, på en rad i ett mejl, om ni har ett API.

Det är frestande att behandla det som en enda fråga med ett enda svar: välj en kanal och låt alla använda den. Den instinkten ger antingen ett EDI-projekt du inte har råd med eller ett API som ingen av dina motparter någonsin kommer att anropa. De är inte konkurrerande svar på samma fråga. De svarar på olika frågor, och vilket som passar följer motpartens storlek och vanor betydligt mer än det följer något tekniskt.

Skillnaden är semantik, inte bara rörmokeri

Båda flyttar en transportorder från deras system in i ditt utan att någon skriver av något. Det som skiljer är arbetsenheten — och vem som väntar.

EDI:s enhet är utväxlingen: en fil, inlindad i ett kuvert, med ett eller flera meddelanden, skickad enligt schema eller när en bunt är full. Ingen sitter online när den kommer fram. Formatet inom europeisk vägtransport är oftast UN/EDIFACT, publicerat via UNECE i versionerade kataloger, och uppsättningen meddelanden är etablerad. IFTMIN, instruktionsmeddelandet, bär ordern. IFTSTA, International multimodal status report message, bär statusen tillbaka. INVOIC, fakturameddelandet, kräver betalt. Eftersom ingen väntar rapporteras problem i efterhand av egna meddelanden: CONTRL, syntax- och servicerapporten, kvitterar eller avvisar själva utväxlingen, och APERAK, meddelandet för applikationsfel och kvittens, talar om att deras applikation tog emot meddelandet och avvisade det under bearbetningen. EDI-artikeln går igenom den uppsättningen ordentligt.

Ett API:s enhet är anropet. Någons programvara anropar din och väntar på svaret. Valideringen sker i samma ögonblick som ordern skickas — ett saknat postnummer kommer tillbaka som ett avslag till den som fortfarande kan rätta det, i stället för som ett kvittensmeddelande en timme senare, ställt till den som råkar läsa den brevlådan. Motsatt riktning är en webhook: ditt system anropar deras när något händer, i stället för att de hämtar en statusfil med jämna mellanrum.

Den skillnaden avgör det mesta av resten.

Vad EDI faktiskt är bra på

Det är lika mycket en överenskommelse som ett format. Anvisningen, kodmappningen och kvittensreglerna är den dyra delen — och också den hållbara. När överenskommelsen väl finns är volymen genom den nästan gratis.

Motparten har det redan. En stor varuägare har personer vars jobb är att lägga till en EDI-partner. Samma personer får sällan budget för att bygga en egen klient mot ett enskilt åkeris API. Ditt API är ditt projekt; deras EDI är deras process, och processer vinner.

Batchlogik passar kontrakterad trafik. Återkommande, förutsägbar volym som tål en fördröjning mätt i minuter är precis vad en utväxling är till för.

Det överlever den som satte upp det. En katalogversion och en skriven anvisning är dokument. Utvecklaren som kopplade ihop det går vidare; dokumenten ligger kvar, och nästa person kan läsa dem.

Vad ett API faktiskt är bra på

Det är billigt att sätta upp. Ingen anvisning att förhandla, ingen katalogversion att enas om. Nycklar, endpoints, dokumentation — dagar i stället för ett kvartal.

Det är interaktivt. Felet landar hos den som orsakade det, medan bokningen fortfarande är uppe på skärmen. Bara den egenskapen tar bort en hel kategori av fredagseftermiddagar: den avvisade filen som ingen tittade på förrän på måndagen.

Det betjänar den långa svansen. En kund som skickar ett fåtal laster i veckan kan koppla ihop ett skript, ett formulär eller sitt eget kontor med det utan att kalla det ett projekt.

Det betjänar dina egna kanter. Kundportalen, förarappen, kalkylbladsmakrot någon på kontoret skrev — alla är API-klienter, vilket betyder att API:et gör nytta redan innan en extern partner anropar det.

Den ärliga avvägningen: ett API:s flexibilitet är också dess instabilitet. Ingenting framtvingar versionsdisciplin på det sätt en publicerad katalog gör, så du äger bakåtkompatibiliteten så länge någon anropar. Och att erbjuda ett API flyttar integrationsarbetet till kunden, som kanske inte har någon som kan göra det. Vi har ett API är inget svar till en partner som hoppades att ni skulle sköta integrationen.

Skiljelinjen är vem som gör jobbet

Skala bort tekniken och frågan blir: vilken sida ska anpassa sig till något som den andra sidan redan har?

• En stor varuägare eller en detaljhandelskedja. EDI, enligt deras anvisning. Deras skala betalar för det, de kommer inte att avvika för ett enskilt åkeri, och att tacka nej är ett kommersiellt beslut snarare än ett tekniskt.
• En medelstor kund med en IT-person, en speditör eller en fraktplattform. Ett API, oftast. De klarar av att anropa ett, och de har ingen EDI-avdelning att tillfredsställa.
• En liten kund. Mycket ofta ingetdera. En kundportal eller en filkatalog svarar mot det de faktiskt vill ha, vilket i regel är att slippa skriva av saker och att sluta ringa dig om status. Det är värt att fråga rakt ut — EDI krävs i en upphandling visar sig ibland betyda just det.

Inget av detta är omdömen om vilken teknik som är bäst. Det är omdömen om var integrationsarbetet realistiskt kan ligga.

Varför båda är det normala — och vad som gör det överkomligt

Att köra två kanaler kostar inte två kanaler. Det kostar två versioner av sanningen, och det är den dyra delen.

En bokning som kommer in som en IFTMIN och en bokning som kommer in som ett API-anrop måste bli samma post, med samma statusar, samma dokument och samma väg till en faktura. Om varje kanal får sin egen tabell, sitt eget statusspråk och sina egna undantag har du köpt två system, och skarven dyker upp någonstans där den kostar — vanligtvis på en faktura, framför en kund.

Den användbara frågan att ställa till systemet under är alltså inte stödjer det EDI eller har det ett API. Den är: landar båda i samma bokning? Och dess motsvarighet på vägen ut — när en förare markerar en leverans som klar, blir den enda händelsen en IFTSTA till kunden som ville ha EDI och en webhook till kunden som ville ha ett API, utan att någon registrerar den två gånger?

Frågorna som gäller båda

Vilken kanal en partner än får är det samma fem saker som avgör om den fortsätter fungera:

1. Vem märker när den slutar? Den överhoppade frågan i varje integrationssamtal. En tyst kanal är värre än ingen kanal, eftersom alla fortsätter anta att orderna flyter in.
2. Vad är kvittensen, och ser en människa den någonsin? EDI har CONTRL och APERAK; ett API har statuskoder och felsvar. Båda är värdelösa om de bara når en logg ingen öppnar.
3. Vilka är dubblettreglerna? En omskickad fil och ett omförsökt anrop är samma risk: en order som blir två laster. Båda sidor behöver en överenskommen identitet på en order och en regel för vad som händer när den kommer in två gånger.
4. Vad är reservvägen? När länken ligger nere — stannar arbetet, eller finns det en mejlväg och ett sätt att stämma av efteråt?
5. Vem betalar när den andra sidan reviderar? Anvisningar uppdateras och API:er får nya obligatoriska fält. Någon gör det arbetet nästa år.

Besvara dem per partner, så slutar valet av kanal att vara en identitetsfråga om ditt företag och blir vad det är: ett beslut per relation, som tas om när relationen ändras.

Var navichain passar in

Poängen med systemet under är att kanalen slutar vara ett arkitekturbeslut och blir ett beslut per partner. navichain har ett REST-API byggt för ERP- och TMS-integration — API-nycklar med behörigheter för bokningar, organisationer, spårning och dokument, med webhooks, anropsgränser och spårbarhet på varje anrop — vid sidan av de fraktpartnerintegrationer de flesta nordiska aktörer redan möter: Opter, LogTrade, EDIFACT och Fraktjakt. Det finns en kundportal för kunderna som inte behöver någotdera. Allt matar en och samma bokningspost, och eftersom alla funktioner ingår i alla planer flyttar en ny partner på en annan kanal dig inte uppåt i pris. Plattformssidan visar vad som ingår, och priser ligger på en sida utan någon rad per integration.