Creatief met Claim Check VNSG Tips & Tricks juni 2017

Transcriptie

1 1 Creatief met Claim Check VNSG Tips & Tricks juni 2017 Auteur: Wouter Luijten Datum:

2 2 Inleiding Het Claim-Check pattern is een pattern dat geïmplementeerd kan worden in SAP Netweaver PO ten einde de payload te reduceren in de verschillende integratie scenario s. Buiten het verkleinen van de message footprint in het systeem is dit pattern ook te gebruiken in andere scenario s. In dit artikel illustreer ik een aantal voorbeelden van Claim-Check cases en geef voor één van deze voorbeelden weer hoe deze te implementeren. Requirements Het Claim-Check pattern is een integratie pattern dat beschikbaar is in SAP Netweaver PO EhP1 voor SAP Netweaver 7.3 SP5. Voorbeeld Cases Reductie message footprint Bij een vliegmaatschappij hebben ze een online boeking site. Bij het boeken ben je verplicht om een scan van je paspoort op te sturen. Aangezien de maatschappij duizenden orders per dag moet verwerken wilt u niet dat de binary data van het paspoort (wat vele MBs kan zijn) in alle flows meegenomen wordt. Periodiek versturen van geaggregeerde orders Dit is het voorbeeld van SAP waarin een bedrijf dagelijks orders vast legt in hun systeem en deze drie keer per week verstuurd naar de fabriek: Buffering van in- en uitgaand verkeer Bij een energieleverancier kan het zijn dat een klant opbelt met het bericht dat de meterstanden verkeerd zijn. Op de desbetreffende installatie (meterkast) dient een rectificatie uitgevoerd te worden. Alle in- en uitgaande berichten die betrekking hebben op die installatie moeten tijdelijk gebufferd worden tot de rectificatie volledig uitgevoerd is zodat er te allen tijde gewerkt wordt met correcte informatie. Zodra de rectificatie voltooid is mag de buffer weer worden vrijgegeven en worden alle berichten volgens de oorspronkelijke routering weer verstuurd. Claim-Check Pattern Het Claim-Check pattern bestaat over het algemeen uit de volgende stappen: Ontvangen van het bericht met payload Opstellen van een key (die later weer gebruikt wordt bij de claim check) Extract en persist (de key en de data van het ontvangen bericht worden gepersist)

3 3 Message reductie en taggen van de claim check Data retrieval (via de claim check) en verdere verwerking Uitwerking Buffering Als voorbeeld heb ik het derde scenario genomen: buffering van in- en uitgaand verkeer. De andere twee scenario s zijn eenvoudig te implementeren wanneer het derde scenario duidelijk is. Stap 1: Ontvangen van bericht Het Claim-Check pattern kan maar overweg met één bericht soort. Dat wil zeggen, om meerdere bericht soorten te ondersteunen zou je het volledige patroon moeten implementeren pér bericht soort. Aangezien dit niet wenselijk is bij buffering, is de eerste stap het transformeren van het specifieke bericht naar een generiek bericht: Na het ontvangen van het specifieke bericht (Message A) dient er gecontroleerd te worden of het bericht gebufferd moet worden of niet. Hiervoor hebben we een eenvoudige CAF tabel gemaakt die alle installatie IDs (headpoints) vasthoudt die in rectificatie staan. Het CAF framework genereert op basis van deze tabel een CRUD-service die we in een Extended Receiver Determination kunnen aanroepen om te bepalen of we linksaf of rechtsaf moeten. Indien we linksaf moeten (lees: oorspronkelijke ontvanger) volgen we gewoon de reguliere routering. Indien we rechtsaf moeten (lees: naar de buffer) dan mappen we het specifieke bericht via een XSLT mapping om naar een generiek bericht:

4 4 Dit generieke bericht bevat de unieke ID van de installatie (die we uit het oorspronkelijke bericht halen), de message ID van het bericht dat ge-persist gaat worden (op dit moment onbekend, dus 0) en de volledige payload van het specifieke bericht in een CDATA sectie. Voor ieder bericht soort wat we willen bufferen zullen we deze stap opnieuw moeten inrichten aangezien de XSLT mapping uniek is per bericht soort. Stap 2: Extract en persist In deze stap schrijven we het resultaat uit stap 1 weg naar een dedicated message store op PO. Vervolgens sturen we een gereduceerde variant van het bericht naar een collect proces op PO. Voor deze stap maken we gebruik van een adapter module die door SAP is uitgeleverd: SCPMappingBean. Uiteindelijk willen we dat het lean bericht dat we naar BPM sturen er als volgt uit ziet:

5 5 Om dit te bewerkstelligen moeten we de adapter module configureren in de receiver adapter: Hiervoor dienen drie parameters gevuld te worden: mappingid: Object ID van de operation mapping van Message Generic naar Message Generic (Lean) persistsuntil: Aantal dagen dat het bericht in de message store moet blijven staan. Let wel, ook als deze periode verstrijkt gebeurt er in feite niets behalve dat het bericht een vlaggetje krijgt in de store. Via een aparte custom delete job kunnen deze gevlagde berichten verwijderd worden. Reguliere archivering is niet van toepassing op de message store. xpath: Xpath expressie die aangeeft waar het message ID veld zich bevindt in de lean interface. Stap 3: Collect en retrieve Het lean bericht dat uit stap 2 volgt wordt opgevangen in een BPM proces. Dit proces ontvangt het bericht en gaat vervolgen via een intermediate event wachten op nieuwe berichten (die gecorreleerd kunnen worden aan deze instance) tot het een trigger van buitenaf krijgt om te stoppen:

6 6 Stap 3.1: Collect Via een intermediate event wordt gewacht op nieuwe berichten met hetzelfde headpoint. Iedere keer als er een bericht binnen komt wordt deze toegevoegd aan een lijst en wordt de intermediate opnieuw geïnstantieerd.

7 7 Dit blijft zich herhalen tot de kill switch van buitenaf getriggerd wordt. Zodra deze trigger heeft plaatsgevonden mappen we de lijst met ontvangen berichten om naar een lijst met messageids voor verdere verwerking: Stap 3.2: Retrieve Zodra de kill switch getriggerd wordt is de allereerste stap het ophalen van alle payloads voor de messageids die ontvangen zijn. Hiervoor kan gebruikt worden gemaakt van de OriginalMessageAccessor EJB (standaard uitgeleverd via de service registry). Deze service verwacht een lijst van messageids en een operation mapping:

8 8 De operation mapping is nodig om van N payloads in de message store, 1 aggregated message te maken. Een n:1 mapping dus: Kleine correctie: message ID is uiteraard niet 0 Het resultaat van de N:1 mapping komt in de output van de getmergedmessageusingmultimapping terecht en is eenvoudig te casten naar een data object van het correcte type: Stap 3.3: Update Zodra alle payloads opgehaald zijn dient de status van ieder bericht geüpdate te worden in de message store van R (Ready) naar P (Processed). Dit heeft als gevolgd dat de reguliere garbage collector van PO deze automatisch verwijdert. Hiervoor kunnen we ook een standaard EJB gebruiken, namelijk de MessageStatusUpdater bean welke simpelweg een lijst met message Ids verwacht:

9 9 Stap 3.4: Send Ieder bericht in de aggregated list dient vanuit het proces verstuurd te worden naar de Advanced Adapter Engine voor verdere verwerking. De verwerking in de AAE omvat het mappen van generieke bericht terug naar het specifieke bericht en routering naar de oorspronkelijke ontvanger. Het kan zijn dat er additionele stappen benodigd zijn om de ontvanger te bepalen. Een optie is bijvoorbeeld om het oorspronkelijke verzendende systeem in het generieke bericht op te slaan. Dit kan dan vervolgens weer gebruikt worden om te bepalen hoe de verdere routering dient plaats te vinden. Ten slotte leest de XSLT mapping de content uit het payload veld en zet dit om naar het specifieke bericht. Conclusie Resultaat van de voorgaande stappen is dat we een buffer scenario hebben dat per installatie geïnstantieerd kan worden. Je kan hier nog extra dingen aan toevoegen zoals een slimmere kill switch die de buffer stapsgewijs kan legen (berichten binnen een bepaald tijdinterval uitlezen en versturen). Voor het periodiek versturen van orders kun je hetzelfde principe hanteren maar is het niet nodig om eerst te mappen naar een generiek bericht. Voor simpelweg payload reductie geldt hetzelfde: ook hier zijn stap 1 en stap 3.4 niet nodig. Door deze stappen te volgen is hopelijk duidelijk geworden hoe het Claim Check principe te implementeren is binnen SAP PO en welke business requirements je hier mee zoal kan afdekken. Over de auteur Deze Tips & Tricks is u aangeleverd door Wouter Luijten, Senior Consultant bij Creetion.