Tijdens de WSO2 trainingen vertel ik mijn studenten dat er vaak nog een andere manier is om dingen voor elkaar te krijgen. In een serie blogs ga ik steeds twee alternatieven in het aanbod van de WSO2 Enterprise Integrator vergelijken.
Deze twee alternatieven bereiken functioneel hetzelfde doel. Het verschil zit voornamelijk in de techniek en soms komt dat neer op voorkeur of implementatiestijl. Het zou kunnen dat een van beide methodes ronduit beter is. Er kunnen situaties zijn waarin de ene manier veel sneller werkt, maar ook het kan ook voorkomen dat een manier wel goed of makkelijk werkt, maar het gebruik ervan absoluut niet aan te raden is.
In deze blog zet ik het gebruik van Data Services naast het gebruik van de DBReport en DBLookup mediators om te zien wat het beste werkt voor het invoegen van gegevens in een tabel.
Verschillen tussen de Data Service en de DBReport en DBLookup mediators
Voor de vergelijking van deze beide functies kunnen we beginnen met een eenvoudige setup waarin we een database met inhoud creëren. We hebben twee mediators, namelijk de DBReport en de DBLookup mediator, waarmee we een verbinding met de database kunnen leggen. Het alternatief is het gebruik van de service die Data Services heet, waarmee ik een speciale service bedoel die gedefinieerd wordt in ofwel de management UI van de Enterprise Integrator of de Integration Studio.
Data Services kan als dienst gegenereerd worden op basis van een bestaande gegevensbron of vanuit het niets manueel gedefinieerd worden. Als je de Wizard in de Management UI gebruikt, dan kun je een aantal operaties automatisch aanmaken om daarmee toegang tot gegevens in de gegevensbron te krijgen. De service wordt gegenereerd met verschillende operaties voor de tabellen. Als de tabel een primaire key heeft, dan zal er een eindpunt met een aantal operaties gegenereerd worden. Stel je hebt een database met 10 tabellen, dan worden er bij het genereren van de Data Service één of meerdere zogenoemde Data Services files aangemaakt. Daarmee kun je gegevens in die tabellen invoeren, uitlezen, bijwerken en verwijderen.
Dus, zoals één van mijn vrienden soms zegt: “Wie het werk voor me doet, is m’n vriend”. In dit geval is dat de generation wizard, omdat het proces daardoor sneller wordt en het je een makkelijk begin geeft dat je kunt aanpassen of bijschaven.
Als je dus gegevens wilt invoegen, dan kun je net zo goed deze service genereren en daarna alles finetunen. Als het echter slechts om 1 registratie gaat die je aan de database wilt toevoegen, uitlezen of wilt veranderen, dan kun je natuurlijk ook DB report en de DB lookup mediators gebruiken. De DB lookup mediator is, zoals de naam suggereert, een eenvoudige manier om gegevens uit een database uit te lezen. De look up mediator haalt een waarde, of bijvoorbeeld een som, op uit de database. Als je bijvoorbeeld een update, toevoeging of andere bewerking uit wilt voeren, zul je de DBreport mediator moeten gebruiken.
Het gebruik van de Data Services
Ik creëer een data service die registraties in een MySQL database tabel invoegt. Vergeet niet de MySQL JDBC connector toe te voegen aan de [EI-HOME]/lib map.
Ik ga de data services niet genereren. Had ik dat wel gedaan, dan zou ik zoiets gekregen hebben:
Ik ga de Create Functionality gebruiken om de data services op te zetten en doe dat vanuit de Management Console. Laten we eerst de ‘Create’ optie kiezen.
Voer een naam in en klik op ‘Next’.
Dan voegen we een gegevensbron toe door op ‘Add New Datasource’ te klikken.
Vul de gegevens in zoals op de afbeelding te zien is en klik op ‘Test Connection’.
Ik heb een aantal standaard inloggegevens gebruikt om verbinding te maken met mijn testdatabase, dus pas ze aan voor jouw situatie. Klik op ‘Save’ en dan op ‘Next’.
Klik nu op ‘Add New Query’.
Vul de gegevens in het SQL-veld in zoals op de afbeelding te zien is en klik dan op de ‘Generate Input Mappings’ knop eronder.
Navigeer naar ‘Save’ onderaan in het scherm. Klik op ‘Next’ om naar de laatste stap te gaan.
Hier klikken we op ‘Add New Operation’.
Vul opnieuw de gegevens in zoals je in het screenshot kunt zien.
Klik op ‘Save’ en dan in het volgende scherm op ‘Finish’.
Door de lijst met Services te openen kun je zien dat de data service toegevoegd is (kijk daarvoor in het linkermenu in de management console) en klik op ‘Try this service’.
Na het invullen van de testgegevens kun je door op ‘Send’ te klikken de database controleren om te zien of de registratie ingevoegd is.
Hoewel dit een eenvoudige en snel te regelen set-up is, zijn er toch een flink aantal kleine stappen nodig. Laten we daarom ook naar de alternatieve manier kijken waarbij we de mediators gebruiken.
Het gebruik van de DBReport mediator
Als we hetzelfde resultaat willen bereiken met de DBReport mediator, dan schakel ik over op WSO2 Integration Studio IDE en maak ik daar een nieuwe proxy of API aan. Daar kun je de mediator eenvoudig naar de inSequence van de proxy of API slepen en configureren.
Met een DBReport mediator ziet de broncode er zo uit:
<dbreport>
<connection>
<pool>
<driver>com.mysql.jdbc.Driver</driver>
<url>jdbc:mysql://localhost:3306/active</url>
<user>root</user>
<password>root</password>
</pool>
</connection>
<statement>
<sql><![CDATA[insert into records (DATE) values (?)]]></sql>
<parameter expression="get-property('DATE')" type="CHAR"/>
</statement>
</dbreport>In dit voorbeeld heb ik de gegevens van de database direct in de broncode gedefinieerd, maar ik had ook een databron in de configuratie van de Enterprise Integrator kunnen definiëren en daaraan kunnen refereren in de DBReport mediator. Voor nu is het ‘inline’ gebruik van de gegevens net wat makkelijker.
Zoals je kunt zien is het minder werk dan met Data Services. Maar de vraag is: wat is er beter?
Wat is beter: Mediators of Data Services?
Is er een duidelijke winnaar? Laten we eerst kijken naar het beperkte perspectief van dit voorbeeld. Een data service kan relatief eenvoudig hergebruikt worden, omdat het een service is met een eindpunt dat overal vandaan aangeroepen kan worden. Er kan zelfs met één simpele stap een API van gemaakt worden. Het nadeel is dat het een extra artefact is in de deployment, naast de proxy of andere artefacten die we ontwikkelen. In dit geval hebben we maar één SQL-statement gedefinieerd, maar we zouden er veel meer in een Data Service kunnen zetten, zoals we zagen in het plaatje met de gegenereerde code. We kunnen er ook andere dingen mee doen, zoals het valideren van waardes die opgeslagen zullen worden of het transformeren van de structuur voordat het teruggestuurd wordt naar de client.
Het alternatief is één of twee mediators. De DBReport mediator schrijft naar een tabel. De DBLookup mediator haalt een waarde uit een specifiek veld in een bepaalde een rij om die in een set resultaten te zetten. Meerdere rijen teruggeven kan deze mediator niet, daar heb je een data service voor nodig.
Aan de andere kant betekent het aanroepen van Data Service dat we inSequence verlaten en er na het aanroepen van de dienst naartoe terugkeren, wat meer tijd kost dan alleen het uitvoeren van een mediator. Je zult extra logica moeten implementeren om verschillende mogelijke fouten af te handelen, terwijl we met de mediators puur op de faultSequence kunnen berusten om mogelijke errors te verwerken.
Eén aspect dat in dit voorbeeld niet duidelijk naar voren komt is dat Data Services ook andere bronnen kan updaten zoals CSV-bestanden, Excel-bestanden of zelfs een custom datasource.
Een data service is duidelijk een flexibelere oplossing, maar kost meer werk om op te zetten. Is er een duidelijke winnaar? Ik zou zeggen, als je alleen wat gegevens in een tabel in wilt voegen, dan werkt de DBReport mediator prima. Hetzelfde geldt voor de DBLookup mediator. Als je slechts één veld hoeft uit te lezen uit een database, gebruik dan gewoon de DBLookup mediator. Voor alle complexere gevallen, of als je gegevens voor klanten beschikbaar moet maken die uit meerdere integraties komen, dan is de keuze voor Data Services al snel gemaakt, omdat een data service superieure flexibiliteit en bredere toepassingsmogelijkheden biedt.
