Testen Gateway API's (OData) met Postman

Door Toine Pothuizen

Testen Gateway API’s (OData) met Postman

Met S/4HANA krijg je de beschikking over API's. Vergelijkbaar met BAPI's, maar dan in een ander jasje. Deze variant is te gebruiken als een OData service via SAP Gateway. Op api.sap.com vind je een lijst met S/4HANA API's die niet alleen in de cloud maar ook on-premise kunnen worden gebruikt. Let wel op, want SAP rolt eerst services uit in de cloud-edition en later pas naar on-premise. Is dus afhankelijk van je on-premise release. In het overzicht zijn de API's van het type REST zijn in deze context het meest interessant.

Testen van odata-services kan natuurlijk prima met de gateway client, die in Gateway beschikbaar is. Maar als je reeksen van requesten wilt maken en geautomatiseerd wil testen, dan schiet die client tekort en ga je op zoek naar andere testtools. OData services zijn REST-based en veel gebruikte tools op dit gebied zijn SoapUI en Postman.

In deze blog een voorbeeld van een testreeks van 3 aaneengeschakelde requesten:

Eerst halen we een token op. Een csrf-token is nodig om een object in SAP te kunnen bewerken.
Dan maken we een salesorder
En tot slot lezen we die salesorder

In postman ziet dat er dan als volgt uit:

Postman installatie

Download en installeer Postman van https://www.getpostman.com/apps.

Voorbereidingen in Postman

Start Postman. We leggen eerst een zgn. Environment aan. Hierin gaan we tussen het aanroepen van requesten enkele variabelen opslaan, zodat we die we weer kunnen gebruiken bij een volgend request.

Rechtsboven via het 'settings' icoontje kom je in het 'Manage environments' menu. Voeg een environment toe. De naam ervan is niet zo belangrijk. In dit voorbeeld maken we een environment met de naam 'SUPERP_API'.

Bij Collections (links) leggen we een folder aan: Superp API. Hieronder zetten we straks onze requesten.

Voorbereidingen in SAP

In SAP heb je een OData service geactiveerd in Gateway m.b.v. transactie /IWFND/MAINT_SERVICE. In dit voorbeeld maken we gebruik van de salesorder-API (API_SALES_ORDER_SRV).
Je hebt een salesorder-soort beschikbaar. In dit voorbeeld maken we gebruik van ordersoort BV (Cash Sales)
Je hebt een klant en een artikel verzorgd, inclusief een verkoopprijs. Hierdoor kunnen we de order relatief eenvoudig aanleggen. Probeer zoveel mogelijk gegevens al in de klant en artikel te verzorgen, zodat we minder kans lopen op een onvolledige order. Je kan vervolgens in SD een verkooporder aanleggen met die klant en artikel, zonder dat die order onvolledig is.
Specifiek voor deze Salesorder API is een user parameter vereist bij de gebruiker die het request verwerkt: ODATA_SD_SLS_CHANGE met waarde X

Eerste request: Token ophalen

We hebben een csrf-token nodig om in ons volgend request een order te kunnen aanleggen. Zo'n token kan je met een GET of HEAD request krijgen.

In Postman, voeg een nieuw request toe onder je folder.

In bovenstaande afbeelding staan al enkele requesten. In jouw geval is het nog leeg.

Vul bij request naam 'Get Token' en kies de folder waarin je je request wilt koppelen. Sluit de popup af met [Save to ..].

In de details van het request gaan we een en ander toevoegen.

Het request heeft de URL nodig naar je API-service. Eindig met een '/' en wijzig de methode naar HEAD. HEAD is een vereenvoudigde GET methode waarbij we geen body gebruiken en is dus sneller.

Bij de authenticatie, kies je via welke manier je wilt aanloggen. In dit voorbeeld gebruiken we basic authentication met user/password, die je vervolgens vult.

Bij de header zetten we de token variabele 'x-csrf-token' met waarde 'Fetch'.

Druk op [Send]. Als het goed is krijg een succesvolle response terug.

Daarin vind je in de header een token en bij de cookies ook nog enkele gegevens, waaronder een sessie-id. Dat sessie-id gaan we net als het token opslaan in een environment-varaiabele. Daarvoor gebruiken we een test-script bij het request. Ga hiervoor naar het 'tabje' Test bij het request.

postman.setEnvironmentVariable("session", pm.cookies.get("SAP_SESSIONID_GTW_001") );
postman.setEnvironmentVariable("token", pm.response.headers.get("x-csrf-token") );

pm.test("Token received", function () {
pm.response.to.be.success;
});

console.log('Token received');

Een korte toelichting van dit script:

in de eerste regel lezen we het cookie waarin de sessie staat. Let op, het laatste deel van de naam (..GTW_001) van het cookie zal anders zijn in jouw geval. Verander dat in het script. Neem de naam over die je in de response terug krijgt bij je cookies. Deze sessie slaan we op in onze environment als 'session'.
in de tweede regel lezen we de token uit de header en slaan we ook op in de environment onder de naan 'token'.
met pm.test voegen we een test-criterium toe. Als het request goed verloopt, zal deze teststap een positief resultaat laten zien.
met console.log voegen we een tekst toe in de logging in het console. In postman kan je dit log bekijken in een andere view die je via het menu kan vinden.

Om te zorgen dat we bij een volgende keer schoon beginnen, maken we met een pre-request script eerst onze environment schoon:

pm.environment.clear();

Voor het request nog een keer handmatig uit via [Send], en controleer of in de environment de session en token gevuld zijn. Je kunt de environment met variabelen bekijken via het 'oogje' icoontje rechtsboven:

Tweede request: aanleggen salesorder

Dan volgt nu het echte werk: het aanleggen van een salesorder. Aanleggen van een object gaat met een POST request.

In de body geven we de gegevens mee voor die order en in de header gaat het csrf-token mee, dat we uit de environment variabele halen, net als het sessie-id cookie.

Header:

Body:

{
"SalesOrderType":"BV",
"SalesOrganization":"1000",
"DistributionChannel":"20",
"OrganizationDivision":"00",
"SoldToParty":"1200000449",
"PurchaseOrderByCustomer":"12345",
"CustomerPaymentTerms": "0001",
"IncotermsClassification":"EXW",
"IncotermsTransferLocation":"De Meern",
"to_Item": [ {
"Material":"22",
"RequestedQuantity":"1",
"RequestedQuantityUnit":"EA",
"ProductionPlant":"1000",
"ShippingPoint":"1000"
}]
}

In dit voorbeeld staan natuurlijk enkele waarden die in jouw geval moeten worden aangepast naar waarden die voor jouw systeem gelden.

In het testscript bij dit request zetten we een paar regels code via een json-kunstje om het ordernummer op te slaan in een environment-variabele, net als wat controle-logica als bij het eerste request:

pm.test("Salesorder created", function () {
pm.response.to.be.success;
});

var jsonObject = JSON.parse(responseBody);
postman.setEnvironmentVariable("salesorder", jsonObject.d.SalesOrder);
console.log("Salesorder: "+jsonObject.d.SalesOrder);

Voer het request uit.

Als dit is gelukt, verschijnt in de responsebody, in de console log en in de environment een salesorder nummer.

Derde request: lezen salesorder

In feite zie je in de response van het vorige request al een en ander van de order terug. Maar je kunt via een $expand meer gegevens bekijken. Bijvoorbeeld met het volgende request: ../sap/opu/odata/sap/API_SALES_ORDER_SRV/A_SalesOrder('{{salesorder}}')?$expand=to_Item

Het ordernummer wordt via {{salesorder}} dynamisch in het request geplaatst.

Bij dit request heb je geen token en session meer nodig in de header en ook geen body, want het is een GET en daarbij niet relevant.

Voeg een derde request toe en druk [Send]. In de response zal in de body naast de salesorder-kop nu ook informatie van de items te vinden zijn:

Testen van de hele reeks

Nu we afzonderlijk 3 requesten kunnen uitvoeren, kunnen we ook de hele reeks aftrappen.

Klik in de folder op het driehoekje, en vervolgens op [Run].

In het volgende scherm, druk weer op [Run ..(folder naam) ].

En zie de testresultaten:

Tot slot

Als je de test later nog eens wilt uitvoeren, kan je ervaren dat cookies met een verouderde waarde van een token met session worden vastgehouden door Postman. Daar is momenteel (bij mijn weten) nog geen nette geautomatiseerde oplossing voor. Verwijder dan eerst handmatig de cookies bij het token request via de Cookies-link helemaal rechts in het scherm: