Organiseer uw verschillende SOAP services in één scenario

Transcriptie

1 1 Organiseer uw verschillende SOAP services in één scenario Wouter Luijten

2 2 Introductie Tijdens de implementatie van een proces heeft u vaak te maken met een veelvoud aan services. Groeperen kan in PO maar vaak eindigt u alsnog met allerlei proxies, scenarios, communications channels etc. Aangezien al deze objecten onderhouden moeten worden is het een stuk handiger als je één service hebt met meerdere operations. Hier loopt u echter tegen de beperking aan dat PO maar één endpoint en één SOAP action ondersteunt. In deze Tips & Tricks laten we u zien hoe u dit dynamisch kan inrichten. Dit artikel is opgedeeld in 4 delen: Beschrijving context Integration Directory Integration Repository Resultaat Beschrijving context Als scenario gebruiken we een real-life scenario wat we bij Stedin geïmplementeerd hebben. Voor het opslaan van allerlei documenten wordt gebruik gemaakt van extern document management systeem genaamd Meridian. Om dit systeem op een correcte manier te gebruiken hebben we verscheidene services die documenten opslaan, ophalen, wijzigen etc. Idealiter zou je hiervoor één Service Interface maken met meerdere operations. Hierdoor hoef je dan ook maar één scenario te configureren en te onderhouden. Echter heeft iedere operation een verschillende SOAP Action waardoor je eigenlijk dus ook meerdere Communication Channels nodig hebt, wat weer leidt tot een veel complexer scenario dan we willen. Integration Directory Doel is dat we dus één simpel scenario hebben met één Communication Channel waarin we dynamisch bepalen wat de SOAP Action is.

3 3 Het inrichten van de Communication Channel is eenvoudig. Waar we normaal een SOAP Action vullen laten we deze nu leeg: In de Advanced tab selecteren we vervolgens Use Adapter-Specific Message Attributes en Variable Transport Binding. Dit geeft ons de optie de waarden voor verschillende header parameters uit variabelen te halen in plaats van ze hard-coded in de Communication Channel te vullen. SAP PI geeft je de mogelijkheid om de volgende attributen uit te lezen: Server URL: TServerLocation Authentication key: TAuthKey Proxy URL: TProxyLocation Proxy authentication key: TProxyAuthKey SOAP action: THeaderSOAPACTION Echter ben je gelimiteerd aan maximaal 3 variabelen die je tegelijkertijd kan uitlezen. Voor dit scenario willen we alleen THeaderSOAPACTION gebruiken:

4 4 Verdere configuratie is niet nodig in de directory. Integration Repository We hebben nu een scenario wat dynamisch gestuurd kan worden door middel van een variabele. We moeten deze variabele nu vullen tijdens run-time. Dit doen we door middel van een java functie die we tijdens de mapping kunnen aanroepen: DynamicConfiguration conf = (DynamicConfiguration)container.getTransformationParameters().get(StreamT ransformationconstants.dynamic_configuration); DynamicConfigurationKey key=dynamicconfigurationkey.create(" "THeaderSOAPACTION"); conf.put(key, action); return "";

5 5 De java functie zorgt er voor dat we action (die we als input parameter ontvangen) mappen naar THeaderSOAPACTION. Je zou hier dus ook meerdere parameters zoals TServerLocation kunnen vullen. Enige wat ons nu nog rest is de functie daadwerkelijk aanroepen. Dit kunnen we simpelweg doen door de root node van de target message van een mapping te voorzien: In de constante kunnen we nu iedere willekeurige string meegeven als SOAP Action. De java functie die we zojuist geschreven hebben zal deze waarde netjes in de correcte parameter stoppen. Resultaat We hebben nu een scenario met één Communication Channel wat meerdere operations aan kan. Tijdens runtime worden de correcte parameters gezet: