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:
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:
Via de kruisjes alles verwijderen en dan kan je wel weer een nieuw token ophalen.
SAP IDM
SAP Identity Management of SAP IdM biedt een hedendaagse oplossing voor het geautomatiseerd en gecentraliseerd beheren van gebruikerstoegang, zowel voor SAP- als voor non-SAP-systemen. Met de groei en het gebruik van het aantal systemen en applicaties binnen organisaties, neemt de complexiteit van de gehele IT-infrastructuur toe. Gelijktijdig worden er steeds hogere eisen gesteld aan de te nemen maatregelen ter beheersing van compliance en overige risico's, dat wil zeggen het conformeren aan (privacy) wet- en regelgeving, nieuwe beveiligingsstandaarden en bijvoorbeeld functieafhankelijke data en systeemtoegang. In welke mate ben je als organisatie 'in control'?
Anticiperend op een groeide vraag naar kennis van adequate security- en compliance-oplossingen is er een SUPlabs IdM gestart, waarbij er een volledig werkend SAP IdM systeem wordt geïnstalleerd en geconfigureerd op het SUPERP eigen applicatielandschap. Naast datakoppelingen met verschillende bron- en doelsystemen is er voor de extra uitdaging ook een upgrade in de planning opgenomen. Tot slot, om recht te doen aan het integrale karakter van SAP IdM zijn er consultants aangesloten met een verscheidenheid aan specialismen, zodat kennis niet alleen breed gedragen wordt, maar het project tevens kan profiteren van inbreng vanuit verschillende expertise gebieden.
SAP HANA
Binnen het SUPlabs track SAP HANA, zijn gedreven consultants bezig om relevante diensten te ontwikkelen waar onze klanten écht iets aan hebben. Dat SAP HANA al een tijdje bestaat weet iedereen, dat het samen met SAP Fiori de toekomst van SAP is, weten inmiddels ook velen. Echter, wat kan SAP HANA voor onze klanten betekenen? En wanneer? Hoe kom je dan van je huidige landschap naar een SAP HANA gedreven landschap waar je de voordelen ook écht gaat benutten? SUPERP wil hierin op verschillende focusgebieden relevante diensten leveren aan haar klanten. Niet alleen op het gebied van ontwikkeling, maar ook op het gebied van advisering, transitie, testen etc. We staren ons dus niet blind op de techniek, maar blijven de techniek als de 'enabler' zien voor de klantorganisatie. De juiste architectuur, de juiste implementatie, de juiste testtrajecten, de juiste consolidatie en beheer. Allemaal aspecten die bij dit soort ingrijpende veranderingen van SAP komen kijken.
Het track zal zich niet louter focussen op SAP HANA, maar ook de integratie gaan opzoeken met het andere SUPlabs track voor SAPUI5 en Fiori. Waarin op basis van frontend development en integratie met de backend, de échte gebruiksvriendelijke user-interface van SAP ontstaat.
SAPUI5
Initieel doel van het SUPlab 'SAPUI5' was de kennisopbouw van SAPUI5 en het Fiori-designconcept bij de ruim 20 SUPERP developers. Dit doel is in 2014 middels de ontwikkelingen van diverse SAP UI5 apps voor klantcases en ter ondersteuning van interne processen (o.a. declaraties, urenverantwoording, facturabiliteit, inplannen trainingen) gerealiseerd.
Inmiddels is dit SUPlab in 2015 een nieuwe fase ingegaan, door de inhouse ontwikkeling van de Lizapp. Deze oplossing is ontwikkeld om eindgebruikers, gebruikmakende van bestaande kennis van SAP en bedrijfsprocessen, in staat te stellen om zelf hun productiviteit apps te maken. Deze oplossing is volledig gebaseerd op het Fiori-concept van SAP en maakt het implementeren, gebruiken en beheren van mobiele applicaties pas écht simpel.
Als erkenning voor het baanbrekende karakter van de Lizapp voor SAP gebruikende organisaties hebben wij recent een innovatiebijdrage van het ministerie van Economische Zaken ontvangen.
Nu de Lizapp een volwaardige klantoplossing is, worden in het huidige SUPlab 'SAPUI5' de ontwikkelingen in de markt en wensen vanuit de klant direct vertaald en opgenomen in nieuwe releases van deze oplossing. Lees hier meer over de Lizapp.