Teknik
MEC och mappning
Senast verifierad
M3A-funktionens ErrorHandling styr vad mappningen gör när ett API-anrop misslyckas. Välj läge utifrån affärsflödet och prova felvägen med samma omsorg som en lyckad körning.
Ett API-anrop som misslyckas svarar NOK
När ett M3 API-anrop inuti en mappning inte går igenom svarar M3 NOK. Vad som ska hända sedan bestäms av en inställning med tre lägen. Infor listar dem som Exit map on M3 NOK, Exit loop on M3 NOK och Ignore M3 NOK.
→ M3 API (mapping functions) · m3coretech 13.4.x · verifierad 2026-10-03
| Läge | Vad som händer | Vad det innebär i drift |
|---|---|---|
| Exit map on M3 NOK | Hela mappningen avbryts. | Kontrollera vad tidigare anrop redan hann göra och vilka poster som behöver hanteras efter stoppet. |
| Exit loop on M3 NOK | Den pågående loopen avbryts. | Notera vilken loop som stoppas och kontrollera vilka steg som körs vidare. Jämför affärsnycklar i indata och resultat. |
| Ignore M3 NOK | Felet passeras och flödet fortsätter. | Kontrollera hur felet blir synligt för driften och hur ett ofullständigt affärsresultat upptäcks. |
Skriv valt läge och dess motivering i flödets dokumentation. Prova sedan felvägen och låt den som ska förvalta integrationen följa resultatet.
Single eller Repeating
Anropet till ett M3 API i en mappning, en M3A-funktion, deklareras som antingen Single, som returnerar en post, eller Repeating, som returnerar flera. Typen är en egenskap på funktionen och avgörs inte vid körning.
Vårt förslag är att prova en tom resultatmängd och ett resultat med flera poster. Kontrollera loopens placering och att rätt affärsnycklar hamnar i det utgående dokumentet.
→ M3 API (mapping functions) · m3coretech 13.4.x · verifierad 2026-10-03
Krävt eller valfritt API
API Installed kan vara Required, som är standard, eller Optional. Ett valfritt API behöver ligga i ett villkor eller en loop som hindrar anropet när API:et saknas. Optional gör inte ett anrop till ett saknat API framgångsrikt.
Om det saknade API:et ändå anropas beskriver Infor att mappningen avslutas, oavsett ErrorHandling. Kontrollera därför både publiceringen och den gren som kan nå API-anropet i den aktuella miljön.
→ M3 API (mapping functions) · m3coretech 13.4.x · verifierad 2026-10-03
Ger Exit map automatisk rollback?
Det går inte att dra den slutsatsen från den här dokumentationen. Infor beskriver att mappningen stoppas; sidan fastställer inte att tidigare lyckade API-anrop återställs. Vår tidigare formulering om ”allt-eller-inget” var för långtgående och är rättad.
Prova ett fel som inträffar efter ett lyckat anrop. Spara M3-läget före körningen och jämför det efter felet. Kontrollera också dokument som hunnit skickas vidare. Då ser ni vilka ändringar som finns kvar och vad en återkörning behöver ta hänsyn till.
Beskriv exekveringsstopp, affärsresultat och återställning var för sig. Om lösningen behöver kompenserande åtgärder ska de vara planerade och provade innan driften använder dem.
Sju felprov som gör mappningen lättare att förvalta
Följande är vårt förslag till testplan, inte resultat från en M3-installation. Kör den i en avgränsad testmiljö med valda testobjekt och den mappningsversion ni tänker använda.
| Test | Genomförande | Underlag att spara |
|---|---|---|
| Lyckad körning | Kör ett känt objekt med väntade in- och utvärden. | Spara affärsnycklar och jämför både M3 och utgående dokument med testfallet. |
| NOK efter ett lyckat anrop | Låt ett senare API-anrop ge NOK efter ett tidigare lyckat anrop. | Kontrollera vad det första anropet redan ändrade och vad som behöver rättas eller återköras. |
| NOK i en loop | Lägg ett fel i en iteration med giltiga poster före och efter. | Notera vilken loop som avbryts, vilka steg som kör vidare och vilka poster som faktiskt blev behandlade. |
| Ignore M3 NOK | Använd samma fel med Ignore inställt i testmiljön. | Kontrollera hur felet blir synligt för driften och hur ett ofullständigt affärsresultat upptäcks. |
| Repeating med flera poster | Prova en tom resultatmängd och en med flera poster. | Jämför antal och affärsnycklar i resultatet. Kontrollera loopens placering och utgående struktur. |
| Optional när API saknas | Prova en miljö utan det valfria API:et. | Visa att villkoret hindrar anropet. Spara också felutfallet när ett saknat API ändå anropas. |
| Återkörning | Rätta orsaken och kör om samma affärshändelse. | Visa hur redan behandlade poster identifieras och hur en extra affärseffekt undviks. |
Hämta testprotokoll för MEC-felhantering (Markdown). Fyll i faktiskt utfall, loggreferens och vem som godkänner återkörningen. Behåll öppna frågor som öppna tills de är provade.
Använd API-kontraktet för att beskriva anropen och CloudSuite-guiden när samma kontroller behövs i en målmiljö.
Ett exempel: tre poster och ett fel i mitten
Tänk er tre testposter med affärsnycklarna TEST-A, TEST-B och TEST-C. Ett första anrop för TEST-A lyckas och ett senare anrop för TEST-B ger NOK. Exemplet är illustrativt; vilka ändringar som finns kvar ska undersökas i ditt flöde.
- Kontrollera TEST-A i M3. Spara vilka ändringar det lyckade anropet faktiskt gjorde.
- Följ TEST-B till anropet som gav NOK. Notera program, transaktion, fel och valt ErrorHandling.
- Kontrollera om TEST-C alls behandlades. Läs loggen och jämför med M3, inte bara mappningens slutstatus.
- Bestäm vilka poster som behöver köras igen och hur tidigare resultat ska identifieras. Prova återkörningen med samma affärsnycklar.
- Låt en kollega följa instruktionen och kontrollera slutresultatet. Anteckna vad som fortfarande kräver hjälp från den som byggde flödet.
Det användbara utfallet är en lista över behandlade, felaktiga och ännu obehandlade poster, tillsammans med en provad återställningsväg. Därifrån blir det enklare att sätta ett larm som berättar vad driften behöver göra.