info@yenlo.com
ned
Menu
API Management 5 min

WSO2Torial – To Send or not to Send (dat is jouw keuze)

Rob Blaauboer
Rob Blaauboer
Integration Consultant & WSO2 Trainer
Blog 10 2
Blog-10-1

Send-mediatoren worden uitgebreid gebruikt in mediatiereeksen binnen de WSO2 ESB. Zonder een Send mediator zou er maar weinig gebeuren in de IN-reeks (de Send mediator stuurt het naar het opgegeven eindpunt) of de OUT-reeks (de Send mediator stuurt het terug naar de gebruiker).
Tijd om eens een kijkje te nemen naar deze mediator die we zo vaak gebruiken, maar waar we waarschijnlijk maar weinig over weten. Aan het einde van deze blog kijken we ook naar andere mediators die gerelateerd zijn aan de Send mediator, zoals de Call, Respond en Drop mediatoren.

Banner-WSO2-Community-1-5

Hoe werkt de Send mediator?

In zijn simpelste vorm verzendt het een bericht naar een bepaald eindpunt. Dit eindpunt kan vast gedefinieerd worden in de code (hardcoded), een vooraf opgegeven eindpunt zijn (benoemd of in een register) of kan afgeleid worden uit een XPATH-uitdrukking. Als er geen eindpunt opgegeven is, zal Send een bericht proberen te sturen naar de TO-header.

Als er geen eindpunt gedefinieerd is en de Send mediator in de OUT-reeks zit, zal er simpelweg naar de gebruiker verstuurd worden. Door een eindpunt te definiëren in de Send mediator in de OUT-reeks, zal dit ervoor zorgen dat er naar dat eindpunt verzonden wordt.

De syntax van de Send mediator is uiterst eenvoudig:

<send/>

Als er sprake is van een opgegeven eindpunt in de Send-syntax, dan ziet dat er zo uit:

<send>
   (endpointref | endpoint)+
</send>

We zullen straks bekijken welke parameters er mogelijk zijn. Hoewel de syntax zo overduidelijk lijkt, kan er toch meer dan je waarschijnlijk zult verwachten.

Het eindpunt in de Send mediator kan een van de volgende dingen zijn:

  • Leeg (zoals beschreven in de vorige paragraaf)
  • Gedefinieerd in de code (hardcoded in de Send mediator)
  • Gekozen uit een register of een ander benoemd eindpunt
  • XPath-Statement

Volgens de documentatie is het ook mogelijk om een bericht naar meerdere eindpunten te versturen.

Een voorbeeld van een Send mediator waarbij het eindpunt in de code is gedefinieerd ziet er zo uit:

<send>
    <endpoint>
    <address uri="http://localhost:9764/services/ADeployedService"/>
    </endpoint>
</send> 

En dit is een voorbeeld van een gedefinieerd eindpunt in een benoemde OUT-reeks:

<send receive="ProvideDataSeq">
       <endpoint key="PersonDataEpr"/>
</send>

Als je aan de slag wilt met meerdere eindpunten, zul je ze moeten definiëren in een lijst met ontvangers (recipientlist). Voor meer achtergrond staat er een Enterpise Integration Pattern (EIP) sample in de documentatie. Een recipientlist zou er als volgt uit kunnen zien:

<inSequence>
      <log/>
      <send>
        <endpoint name="1469526965038">
          <recipientlist>
            <endpoint>
              <address trace="disable"
                       uri="http://localhost:9764/services/echo"/>
            </endpoint>
            <endpoint>
              <address trace="disable"
                       uri="http://localhost:9765/services/echo"/>
            </endpoint>
          </recipientlist>
        </endpoint>
      </send>
</inSequence>

Er is nog een andere mogelijkheid om het type van de ontvangende Reeks (Sequence type) voor de Send te definiëren. Hiermee bedoelen we de OUT-reeks. Als er geen ontvangend eindpunt aangegeven is, zal het standaard eindpunt in de proxy of API, of een static (benoemde reeks) of zelfs een dynamisch eindpunt genomen worden. In het laatste geval zal een XPath- Statement vermeld moeten worden.

De laatste parameter om voor verzending te specificeren gaat over het feit of het bericht gebouwd is in het geheugen. Als er een logica is die plaats moet vinden nadat het bericht verstuurd is, zal deze parameter op “Yes” gezet moeten worden. Zo niet, dan kan deze op “No” blijven staan, wat de prestatie zal verbeteren.

De Send mediator kan gedefinieerd worden door gebruik te maken van de UI van de WSO2 ESB, de Developer Studio of als een XML-snippet die in een proxy of API gekopieerd wordt.

UI Configuratie

Blog-10-2

Het is belangrijk om te beseffen dat de Send Mediator de huidige flow (IN of OUT) zal afbreken. Het plaatsen van mediatoren na de Send mediator werkt dus niet, omdat deze nooit bereikt worden.

De Call mediator

Een Call mediator werkt vergelijkbaar met de Send mediator, maar in tegenstelling tot de send mediator wordt de flow van de proxy of API niet onderbroken. Dit geeft de mogelijkheid om een service chain te gebruiken, een aantal opeenvolgende calls waar bijvoorbeeld de resultaten van overgedragen worden van de ene call aan de andere, met in achtneming van de ingestelde eigenschappen.

De syntax van de Call mediator lijkt sterk op die van de Send Mediator:

<call [blocking="true"]>
   (endpointref | endpoint)+
</call>

In this cases multiple endpoints are supported, however only in non blocking mode.

Blog-10-4
Figuur 1 Voorbeeld van de ESB fundamentals training waar in de OUT-reeks een andere dienst aangeroepen wordt

Theoretisch zijn er meer manieren voor service chaining door gebruik te maken van IN- en OUT-flows of benoemde reeksen, of zelfs constructies waar in de OUT-flow bijvoorbeeld een proxy, een switch en nog een Send worden gebruikt, alhoewel dit suboptimale situaties creëert. (De switch bepaald in dit geval of er nog een Call gemaakt zal moeten worden.) De Call mediator is de manier om service chaining te gebruiken binnen de WSO2 ESB.

Drop Mediator

Nog een ondergeschoven mediator die gerelateerd is aan de Send mediator is de Drop mediator die precies het tegenovergesteld aan de Send mediator functioneert: het laat het bericht vallen. Als de Drop Mediator in de IN-reeks geplaatst wordt, zal het een 202 Accepted als reactie aan de gebruiker geven. Als het in de OUT-reeks geplaatst wordt, zal het geen reactie teruggeven, maar alleen het bericht laten vervallen.

De syntax van deze mediator is de gemakkelijkste in deze set: <drop/>

De Respond mediator

Een Respond mediator stuurt het bericht terug naar de gebruiker en stopt het huidige proces. Een van de manieren waarop het gebruikt wordt is in de Makefault Mediator om en SOAP-bericht terug te geven aan de gebruiker, omdat er iets mis is met het bericht (dus, als de payload incorrect is of iets dergelijks).

Ook hier is de syntax uiterst eenvoudig: <respond/>

De Loopback mediator

Een van de onbekendste mediators is de Loopback mediator. Zoals je in de onderstaande afbeelding kunt zien zet de Loopback mediator de flow om naar de Out-reeks, waarbij de variabelen op de axis2 scope gehandhaafd blijven.

De gebruikte syntax is: <loopback/>

Wanneer zou je een Loopback kunnen inzetten? In fundamentele gevallen waarbij je zou willen dat de Out-reeks de reactie naar de gebruiker vormgeeft.

Blog-10-5

In dit overzicht hebben we gekeken naar een aantal mogelijkheden om de flow binnen een proxy te beheren, zoals het verzenden naar verschillende eindpunten en het aanroepen van een benoemde OUT-reeks. Nu je weet dat je de optie hebt om de flow te veranderen, zou dat enorm handig kunnen zijn bij een van je eigen projecten.

Als je vragen hebt over deze blogpost, neem dan gerust contact met ons op via het commentaar hieronder. Bekijk ook onze WSO2 tutorials, webinars of white papers voor meer technische informatie. Ondersteuning nodig? Wij bieden WSO2 Productondersteuning, en ondersteuning voor WSO2 Development, WSO2 Operational en WSO2 Trainingsprogramma’s.

Blog-10-1-1

WSO2TORIALS helpen je om WSO2-producten te verbeteren, wijzigen of bij te werken en zijn gebaseerd op onze ervaring met de producten. WSO2TORIALS helpen je er stap voor stap doorheen met weinig vereiste voorkennis.

ned
Sluiten