SUPlabs

SUPlabs is de kraamkamer van innovatieve SUPERP-diensten en producten en wordt gevoed door de markt-, klant- en technologische ontwikkelingen. Om onze klanten sneller en beter te kunnen bedienen met slimme innovatieve SAP-oplossingen ontwikkelt SUPERP haar eigen SAP-diensten en producten via SUPlabs. Onze klanten worden actief betrokken bij de dienst– en productontwikkeling en profiteren daarmee optimaal van SUPlabs. Tegelijkertijd hebben onze consultants met SUPlabs de mogelijkheid om continu SAP-innovaties bij te houden en te vertalen naar SAP-oplossingen.    

Producten / bedrijven voortgekomen uit SUPlabs

onerax logo

OneraX

Bij OneraX komen unieke vaardigheden samen. Het beschikt over diepe kennis van de financiële (Tax, Legal en Accounting) processen bij bedrijven (multinationals). SAP developers die niet alleen kennis van SAP hebben maar ook in staat zijn om de complexe financiële processen te doorgronden en te vertalen naar nieuwe oplossingen.

Lees meer

logo-lizapp

Lizapp

Met de Lizapp heeft SUPERP het juiste antwoord gevonden op de vraag naar mobile, op basis van diepgaande SAP-, mobility-, industrie-, klant- en beheerkennis. De Lizapp maakt het toepassen van mobiele oplossingen, zoals pure productivity apps, toegankelijk en laagdrempelig voor elke organisatie die met SAP werkt.

mxblue logo 2

MxBlue

Om in het digitale tijdsperk concurrerend te blijven moeten organisaties hun digitale ambities kunnen omzetten naar werkende applicaties.

MxBlue combineert de innovatieve kracht van het Mendix platform met de solide basis van SAP zodat onze klanten het beste van beide werelden krijgen.

Lees meer

 

mijnsuperp

mijn.SUPERP

Sinds mei 2022 zijn we als SUPERP volledig overgestapt op onze zelfontwikkelde mijn.SUPERP-omgeving. Elke sprint worden er nieuwe functionaliteiten opgeleverd, waarbij we steeds kijken naar verdere verbeteringen van de functionaliteit en het automatiseren van handmatige taken.

Lees meer

Uitnodiging tot co-innovatie

Het platform SUPlabs bestaat dit jaar 7 jaar. In 2016 zijn we in bescheiden vorm gestart met co-innovatie binnen SUPlabs. In 2017 lanceerden wij SUPlabs 2.0! De belangrijkste verandering ten opzichte van 1.0 is dat SUPlabs sinds 2017 een innovatieplatform is waar wij zoveel mogelijk ontwikkelingen samen met klanten oppakken. Daarvoor was SUPlabs hoofdzakelijk een intern innovatieplatform (om SAP-ontwikkelingen te vertalen naar de opbouw van kennis binnen onze consultancydiensten).

 

Jaarlijks wordt er een aantal tracks (projecten) opgezet waar wij ons innovatiebudget in investeren. Door hierbij gebruik te maken van concrete klant- en usecases wordt de interne kennisopbouw concreet toepasbaar en daarmee een stuk relevanter. Klanten kunnen meeprofiteren van het innovatiebudget dat wij beschikbaar hebben en eveneens kennis opdoen door deel te nemen in een of meerdere tracks. In onze ogen een absolute win-winsituatie.

 

Innovatie kenmerkt zich vandaag de dag door de mogelijkheid om in een vroegtijdig stadium te beginnen met het ‘ervaren’ van de mogelijkheden. Op basis hiervan zijn vooronderzoeken, businesscases, pilots en Proof of Concepts binnen handbereik. Dus mocht je zelf geen of een beperkt innovatiebudget hebben om SAP HANA, SAP Fiori, SAP IDM of andere SAP-innovaties op te pakken, neem dan contact op met SUPERP om te kijken welke mogelijkheden wij bieden om te co-innoveren.   

 

 

iamSUPERP

 

iamsuperplogo small

Bij SUPERP zijn wij dagelijks bezig met goed blijven in de dingen die we doen, en goed worden in de dingen die we willen doen. Uiteindelijk willen we dat onze klanten ons als “superb” bestempelen. Omdat we vanuit deze visie niet alleen intern maar ook extern mensen met diezelfde ambitie willen ondersteunen hebben we het iamSUPERP “fonds” opgericht.

 

We gaan naast standaard sponsoring kijken waar verbeteringen mogelijk zijn, waar mogelijkheden liggen en gaan daarnaast vanuit onze SUPlabs op zoek naar wat innovatie, SAP en IT kunnen betekenen in dit proces.

Lees meer

Huidige projecten


X

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:

 

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.

Top