API-forbindelser fra ERP til tredjeparter
ERP til tredjeparter: CRM, logistik, skat og identitet
REST-, SOAP-, webhook- og iPaaS-forbindelser mellem dit ERP-system og de services, der omgiver det, med gentagne forsøg og alarmer.
Arkitekturskitse
Rul sidelæns for at se hele tegningen.
ERP til tredjeparter: én platform, mange partnere
Forretningshændelser forlader ERP-systemet én gang, og integrationsplatformen leverer dem til hver partner i det format, partneren forventer. Callbacks kommer tilbage samme vej. En besked, der stadig fejler efter sine gentagne forsøg, går til en dead-letter-kø og udløser en alarm med payloaden vedhæftet.
- Primært flow
- Asynkron
- Undtagelsessti
Forløbet i 9 trin
Forløbet, trin for trin
- Fra ERP til Integrationsplatform: Forretningshændelser, over REST · OData · webhook (primært flow).
- Fra Integrationsplatform til CRM: Kunder og ordrer, over REST/JSON (primært flow).
- Fra Integrationsplatform til Logistik og transportører: Forsendelser booket, over REST/JSON (primært flow).
- Fra Logistik og transportører til Integrationsplatform: Sporingshændelser, over webhook (asynkron).
- Fra Integrationsplatform til E-fakturerings- og skatteplatform: Fakturaer til godkendelse, over SOAP/XML · REST (primært flow).
- Fra Integrationsplatform til KYC- og identitetsudbyder: Identitetstjek, over REST/JSON (primært flow).
- Fra KYC- og identitetsudbyder til Integrationsplatform: Tjekresultater, over webhook (asynkron).
- Fra Integrationsplatform til Dead-letter-kø og alarmer: Fejlet efter gentagne forsøg, til en dead-letter-kø (undtagelsessti).
- Fra Dead-letter-kø og alarmer til Supportteam: Alarm med payloaden og fejlen (undtagelsessti).
Oversigt
Dette er flowet mellem dit ERP-system og de services, der omgiver det: CRM-systemet, transportører og logistikudbydere, platforme til e-fakturering og skat samt udbydere af identitet og KYC. Hver partner har sit eget API, sit eget format og sine egne fejl, og hver enkelt kommer normalt som et separat projekt.
Referencedesignet sender forretningshændelser ud af ERP-systemet én gang til en integrationsplatform, der leverer dem til hver partner i det format, partneren forventer, via REST, SOAP, webhooks eller EDI via AS2, hvor handelspartnere kræver det. Callbacks, f.eks. sporingshændelser eller resultater af kontroller, kommer tilbage via den samme platform.
At en partner er nede, er en normal hændelse, ikke en nødsituation. Midlertidige fejl forsøges igen. En besked, der stadig fejler efter sine gentagne forsøg, går til en dead-letter-kø, og supportteamet får en alarm med indholdet og fejlen, så beskeden kan rettes og genafspilles.
Sådan fungerer flowet
ERP-systemet udgiver en hændelse
Når en kunde, en ordre eller en faktura ændres, udgiver ERP-systemet én forretningshændelse til integrationsplatformen via sit API, OData-services eller webhooks.
CRM-systemet holdes opdateret
Platformen opdaterer konti, kontakter og ordrer i CRM-systemet, så salgs- og serviceteams ser det, ERP-systemet ved.
Forsendelser bookes
Ordrer, der er klar til afsendelse, bookes hos transportøren eller logistikudbyderen via dennes API, og etiketter og referencer kommer tilbage.
Sporing kommer tilbage
Transportøren sender sporingshændelser og hændelser for leveringsbevis via webhook, og platformen opdaterer ordren i ERP-systemet.
Fakturaer godkendes
Fakturaer sendes til platformen for e-fakturering eller skat i det format, myndigheden kræver, og godkendelsesstatus gemmes sammen med fakturaen.
Identiteter kontrolleres
Nye kunder eller leverandører sendes til KYC- eller identitetsudbyderen, og resultatet kommer tilbage via webhook, før kontoen aktiveres.
Når noget fejler
En partner er midlertidigt utilgængelig
Kaldet forsøges igen med stigende ventetid. En idempotensnøgle på hver skrivning betyder, at et nyt forsøg aldrig opretter en ekstra forsendelse eller faktura.
En besked fejler stadig efter sine gentagne forsøg
Den går til en dead-letter-kø med indholdet og partnerens fejl, og supportteamet får en alarm. Når den er rettet, genafspilles den fra køen.
En partner ændrer sit API
Kontrakttests kører mod hver partners testmiljø og opdager ændringen. Varslede ændringer planlægges og testes før partnerens tidsfrist.
Dataene afvises
En partner, der afviser data af en forretningsmæssig grund, f.eks. et manglende skattenummer, sender fejlen tilbage til posten i ERP-systemet, hvor ejeren kan rette den.
Standarder og systemer
- Integration
- REST
- SOAP
- Webhooks
- OpenAPI
- EDI (EDIFACT, ANSI X12)
- AS2
- MuleSoft
- Boomi
- Azure Logic Apps
- Identitet og adgang
- OAuth 2.0
Spørgsmål og svar
Hvilke tredjepartsservices kan I forbinde til?
Enhver service med et dokumenteret API eller en filgrænseflade. Typiske eksempler er CRM-platforme, transportører og logistikudbydere, markedspladser, platforme til e-fakturering og skat, lønsystemer, KYC- og identitetsudbydere og handelspartnere, der udveksler EDI-dokumenter via AS2. Vi gennemgår hver partners API, grænser og testmiljø, før vi forpligter os til en plan.
Har vi brug for en integrationsplatform til det?
Når flere partnere er forbundet med ét ERP-system, samler en platform som MuleSoft, Boomi eller Azure Logic Apps, eller et sæt specialudviklede services bygget på en beskedkø, mapping, gentagne forsøg og overvågning ét sted. Med en eller to partnere kan direkte forbindelser være nok. Vi beskriver fordele og ulemper, herunder licensomkostninger, i dit tilfælde.
Kan I forbinde os med platforme til e-fakturering og skattegodkendelse?
Ja. Mange lande kræver nu, at fakturaer udstedes eller godkendes via en offentlig eller akkrediteret platform i et fastlagt format. Vi integrerer ERP-systemet med den platform, dit land kræver, eller med en akkrediteret udbyder, gemmer godkendelsesstatus og identifikatorer sammen med hver faktura og håndterer afvisninger. Dine skatterådgivere bekræfter de regler, der gælder for dig.
Hvordan sikrer I indgående webhooks?
Hver indgående webhook verificeres, før den behandles: med signatur, hvor partneren signerer sine beskeder, og med kontrol af token, kilde og tidsstempel, hvor den ikke gør. Indholdet valideres mod kontrakten, og hændelser behandles én gang, selv hvis partneren sender dem flere gange.
Hvad sker der, når en partner har et nedbrud?
De øvrige flows kører videre. Beskeder til den partner forsøges igen og sættes derefter i kø, supportteamet får en alarm, og intet går tabt. Når partneren er oppe igen, genafspilles beskederne i køen i rækkefølge. Dashboardet viser, hvilken partner der er berørt, og hvor mange beskeder der venter.
Hvem ejer de konnektorer, I bygger?
De immaterielle rettigheder til det arbejde, vi bygger for dig, er dine fra den første commit, uden noget overdragelsestrin til sidst. Konnektorer leveres med kildekode, tests og dokumentation, så dit team eller en anden leverandør kan vedligeholde dem. XSIS-værktøjer, der fandtes i forvejen, forbliver vores og licenseres til dig. Partneres API’er og licenser til integrationsplatforme er fortsat underlagt disse leverandørers egne vilkår.
Start med en samtale, ikke en kontrakt.
Fortæl os, hvad du skal bygge, forbinde eller sikre. En arkitekt gennemgår det med dig og anbefaler derefter, hvor du skal starte.
Det sker der nu
Aftale om tidspunkt
Vores team sender dig en e-mail for at aftale et tidspunkt for sessionen.
Forhåndskonsultation
En gratis online forhåndskonsultation på 30 minutter: vi gennemgår dine mål, systemer og begrænsninger.
Parathedsanalyse
I en gratis parathedsanalyse på 48 timer tjekker en ledende arkitekt dit projekt op mod de 6 punkter i Definition of Ready og anbefaler det spor, der passer.
Valg af spor
Projekter med et klart omfang modtager et bindende forslag inden for 3 til 5 hverdage. Projekter i konceptfasen starter i Blueprint Studio. Et system i drift, der fejler, er udokumenteret eller skal integreres, starter med en diagnosticering på 1 til 2 uger. Blueprint Studio og diagnosticeringen har hver et fast honorar, som er angivet i forslaget.