Teknik

Projektioner och OData

Senast kontrollerad 2026-10-03

Projektioner är sättet OData-tjänster utvecklas i IFS Cloud. Det som definieras som en Projection i IFS Developer Studio distribueras som en OData-tjänst, förmedlad av IFS OData Provider.

Kontrollerad mot IFS OData Provider (25R1) · 2026-10-03

01 / kopplingen

Samma projektioner som gränssnittet använder

Den detalj som får störst praktiska konsekvenser är att projektionerna som IFS Cloud Web använder också kan återanvändas för integration. Det är bekvämt, och det gör det värt att hålla reda på vilka flöden som använder dem.

En ändring i en gemensam projektion kan påverka integrationen som använder den. Ta därför med de berörda flödena när ni planerar och provar ändringen.

Praktisk följd för förvaltningen: en ändring i en projektion som används av integration bör hanteras som en gränssnittsändring med mottagare, inte som en intern justering. Det kräver att man vet vilka projektioner som används av vad, vilket i sin tur kräver ett register.

02 / protokollet

Standardmetoder, egen semantik

Anropen följer OData och använder standardmetoderna GET, POST, PUT, PATCH och DELETE. Autentiseringen sker med OAuth.

Kontrollerad mot IFS OData Provider (25R1) · 2026-10-03

Att protokollet är standardiserat betyder att verktygen finns och att en utvecklare känner igen sig. Det säger däremot ingenting om vad ett enskilt fält betyder i verksamheten, vilka fält som är obligatoriska i praktiken, eller vad som händer med ett halvt bearbetat anrop. Den delen är produktkunskap och står inte i protokollet.

03 / vad som gäller er

Dokumentationen beskriver produkten, inte er installation

IFS dokumentation beskriver vad som är möjligt. Vad som faktiskt är exponerat i en given miljö är en annan fråga, och den besvaras i miljön. Se API Explorer.

Skillnaden är värd att hålla isär i ett designdokument. Ett påstående hämtat ur produktdokumentationen och ett påstående hämtat ur er egen installation har olika hållbarhet, och i ett designdokument är det lätt att luta sig mot det första när det borde ha varit det andra.

Prova en läsning i er testmiljö

Börja med en projektion som ni vill använda och ett känt testobjekt. API Explorer listar tjänster och deras entity sets och länkar till API-dokumentationen. Kopiera serviceadressen därifrån och spara projektion, entity set och release i integrationsregistret.

Kontrollerad mot API Explorer Overview (25R2) · 2026-10-03

Låt miljöns administratör hjälpa er med en IAM-klient och de behörigheter som läsningen behöver. IFS visar hur OAuth-klienten och tokenadressen hittas och används i ett API-verktyg. Följ dokumentationen för er release och förvara klienthemligheten i verktygets skyddade konfiguration.

Kontrollerad mot Authentication and Authorization (25R1) · 2026-10-03

Följande är en illustrativ request med platshållare. Ersätt serviceadress och entity set med värden från er miljö, och låt API-verktygets OAuth-konfiguration lägga till autentiseringen. Exemplet har inte körts mot en kundinstallation.

GET <serviceadress>/<entity-set>?$top=1
Accept: application/json

$top=1 begränsar den första provläsningen. IFS beskriver också $skip för sidindelning och filter för att avgränsa resultatet. Börja litet och jämför det returnerade objektets fält med ert väntade testobjekt.

Kontrollerad mot Read Records (25R2) · 2026-10-03

Spara vad svaret faktiskt visar

Anteckna HTTP-status, affärsnyckel och vilka fält ni behöver. Skilj ett tomt resultat från ett fel: kontrollera urval, testdata och behörigheter innan ni drar slutsatsen att objektet saknas. IFS OData Provider beskriver hur status och svarskropp hör ihop.

Kontrollerad mot IFS OData Provider (25R1) · 2026-10-03

Spara en maskerad request och ett maskerat svar som kontraktstest. Kör samma kontroll efter en releaseändring och jämför fält och beteende. Ert nästa steg finns i API Explorer-guiden och releaseöversikten.

Hur felsöker vi ett OData-svar i IFS Cloud?

Spara HTTP-status och den maskerade svarskroppen tillsammans med requesten. IFS OData Provider beskriver följande exempel. Det är en startpunkt för felsökningen; det faktiskt returnerade felet behöver läsas i sin helhet.

400: Bad Request: IFS nämner felaktig URL, headers eller request body. Kontrollera anropets form innan ni ändrar affärslogiken.
404: Not Found: Kan avse ett objekt som inte finns för den angivna nyckeln. Kontrollera adress, nyckel och testdata.
405: Method Not Allowed: Fel HTTP-metod för endpointen, exempelvis GET mot en OData Action. Jämför med operationens dokumentation.
500: Internal Server Error: IFS beskriver fel i middle-tier eller databas. Svarskroppen kan ge mer information.

Vid debug räcker HTTP 200 inte som framgångskriterium. IFS dokumenterar att odata-debug=json returnerar 200 även när det underliggande anropet misslyckats. Läs den egentliga svarskoden i svarskroppen.

Kontrollerad mot IFS OData Provider (25R1) · 2026-10-03

Gör felutfallet till ett kontraktstest

Prova ett avsiktligt felaktigt anrop i testmiljön och spara det väntade felet.
Kontrollera att klienten skiljer felet från ett lyckat svar och från ett tomt resultat.
Visa hur larmet hjälper en kollega att hitta rätt flöde och testobjekt.
Kör samma kontroll i målmiljön och jämför både status och felinnehåll.

Bestäm vilka fel som får ett nytt försök och prova återkörningen som ett eget testfall. Anteckna resultatet i API-releasekontrollen och koppla det till flödets registerrad.