Het kan misschien lijken dat musea het ultieme voorbeeld zijn van fysieke gebouwen. Je moet erheen gaan om de meesterwerken tentoongesteld te zien. En natuurlijk is het een bijzondere ervaring om door een museum te wandelen en al die prachtige kunst te zien. Sommige musea hebben echter ook een digitale sectie, omdat hun collecties vaak zo groot zijn dat ze niet alles kunnen tonen. Honderdduizenden afbeeldingen worden niet tentoongesteld, maar worden bewaard in depots buiten het zicht van mensen. Digitalisering, met andere woorden het maken van een foto en het online plaatsen ervan, stelt hen in staat meer van hun collectie te laten zien en mensen van kunst te laten genieten. In sommige gevallen worden zelfs afgeleide werken gemaakt van meesterwerken. Het digitale schilderijcanvas is een van die apparaten waarmee je je favoriete kunstwerk kunt uploaden en in je eigen huis of kantoor kunt tonen. Het is een vorm van digitale verbeelding om te zien wat je kunt doen met zo’n apparaat en de digitale bronnen die musea beschikbaar stellen.
Laten we verdergaan
In het vorige deel van deze blog hebben we een API ontwikkeld waarmee we een gedigitaliseerde afbeelding uit het Rijksmuseum konden ophalen. In dit tweede deel gaan we dat uitbreiden door meerdere objecten toe te staan in de aangrenzende array en de afbeeldingen daadwerkelijk op je lokale schijf op te slaan.
De reden waarom ik deze blog schrijf, is om te laten zien dat integratie niet alleen iets is voor experts of kunstenaars, maar dat bijna iedereen het kan. Natuurlijk heb je training en enige vaardigheid nodig om te kunnen integreren, maar ik denk dat de meeste ontwikkelaars in het algemeen in staat zijn om systemen te integreren.
De opstelling
Even een samenvatting van wat je nodig hebt als je dit zelf wilt proberen:
- Een versie van de Micro Integrator (Ik gebruik versie 4.2.0)
- Integration Studio om de artefacten te ontwikkelen die we gaan implementeren (ik gebruik versie 8.2)
- Een API-sleutel van het Rijksmuseum om hun API te kunnen gebruiken
- Een Meural als je de volledige flow wilt hebben. Zo niet, dan kun je de afbeelding lokaal opslaan.
Itereren
Als je naar de opstelling kijkt die we proberen te creëren, zie je dat er een array van waarden wordt doorgegeven aan de API. Voor elk van deze waarden in de array willen we informatie over het schilderij ophalen. Binnen de Micro Integrator zijn er twee mediators die dit doel dienen. De eerste is de ForEachmediator en de tweede is de Iterate-mediator waarmee je een herhalend element in een gegevensstroom kunt nemen en logica voor elk element kunt uitvoeren.
In ons geval, omdat we een andere API willen aanroepen op basis van de waarde die we uit de array krijgen, moeten we de iterate-mediator gebruiken. De ForEach-mediator is niet geschikt omdat we toegang willen krijgen tot een (externe) systeem.
Bij het bekijken van de syntax van de Iterate-mediator zijn er verschillende parameters die je kunt instellen, afhankelijk van het gebruiksscenario dat je hebt. De mediator gaat vaak gepaard met de A ggregate-mediator, waarmee we eerst iets kunnen opsplitsen en vervolgens de resultaten kunnen samenvoegen, maar je kunt ook het bericht negeren. In ons geval hebben we dat niet nodig, omdat we niet zozeer geïnteresseerd zijn in het combineren van de antwoorden, maar meer in het uitvoeren van onze oproep op basis van de waarde die is samengevoegd in de URL. Er zijn natuurlijk ook andere manieren om dit te doen. We kunnen bijvoorbeeld de waarden die we uit een array krijgen opslaan in de berichtenwachtrij en de berichten sequentieel verwerken.
Opslaan op een lokale schijf
We hebben al gezien dat we een URL terugkrijgen die ons de downloadlocatie van een kunstwerk geeft. Wat we nu willen doen, is daadwerkelijk de afbeelding ophalen en deze vervolgens naar een lokale schijf schrijven. Dit is ook een onderdeel van integratie. Om dit te laten werken, moeten we de mogelijkheid toevoegen om naar een lokaal apparaat te schrijven, en dat doen we in de vorm van de WSO2 File-connector.
Connectors zijn uitbreidingen voor de Micro Integrator waarmee het toegang kan krijgen tot cloudgebaseerde services of in ons geval, met de file connector, ons lokale bestandssysteem. In plaats van alles zelf uit te zoeken, kunnen deze vooraf gebouwde zipbestanden aan de Micro Integrator worden toegevoegd en ze vergroten aanzienlijk de mogelijkheden van de Micro Integrator.
Bijna 200 connectors
De connectors zijn online te vinden op deze URL en ik heb op dit moment 193 connectors geteld. Niet allemaal zijn ze actueel, moet ik toevoegen, maar het bespaart je veel tijd omdat je niet hoeft uit te zoeken hoe je verbinding kunt maken met een specifiek systeem of service. De manier waarop je deze connectors gebruikt, is dat je kijkt of de versie die je gebruikt wordt ondersteund, en zelfs als er niet wordt vermeld dat de versie wordt ondersteund, kun je het altijd proberen. De connectors zelf zijn zipbestanden die je gemakkelijk kunt openen en de configuratie kunt bekijken. In de meeste gevallen zal het een reguliere synapse-configuratie zijn (dezelfde taal die we hier gebruiken voor berichtenbemiddeling), maar het kan ook zijn dat er een Java-jar-bestand in de connector zit. In het geval van de file connector, waarbij we toegang moeten krijgen tot het laag-niveau bestandssysteem, is dit inderdaad het geval.
Als je meer wilt weten over connectors en wat je ermee kunt doen, kun je een van de blogs bekijken die ik in de loop der jaren over dit onderwerp heb geschreven..
De connector wordt meestal gedownload naar je integratieontwikkelomgeving, zoals Integration Studio, en naar het product waarin je de integratie zult uitvoeren. In Integration Studio wordt het toegevoegd aan het systeem om het gebruik van de connector mogelijk te maken, net zoals je je bemiddelingen bouwt via drag-and-drop op hoog niveau. Details kunnen worden geconfigureerd in de Properties weergave of de Sourceweergave.
Bij implementatie is het ook belangrijk dat we de connector toevoegen aan de artefacten die we willen implementeren, omdat er een afhankelijkheid is die moet worden voldaan om de artefacten te kunnen uitvoeren.
Connectors kunnen op een zeer eenvoudige manier worden toegevoegd met behulp van een integratieproject waarin je eenvoudig het selectievakje voor connectors aanvinkt. Dit hebben we al gedaan in de vorige blogpost.
Maar er is nog iets anders dat we ook moeten doen. En het heeft te maken met het feit dat wanneer een bericht door de Micro Integrator wordt ontvangen, deze standaard probeert het bericht te analyseren om te kunnen bemiddelen over de inhoud. Het mechanisme maakt gebruik van transporten zoals HTTP en HTTPS, evenals builders en formatters die het binnenkomende bericht transformeren in het interne axiom-model. Bij verzending van het bericht wordt het opgebouwd volgens het door jou gedefinieerde berichttype. Bij het downloaden van een digitale afbeelding is er geen behoefte om het bericht te analyseren; het moet eenvoudigweg worden verpakt in een SOAP-envelope zonder dat de Micro Integrator probeert het bericht te openen. Om dit mogelijk te maken, heeft de Micro Integrator een doorstuurmechanisme dat het bericht niet probeert te openen, maar het bericht accepteert, verpakt en doorstuurt of iets anders doet.
Om dit te configureren, gaan we een wijziging aanbrengen in het deployment.toml-bestand, waarin alle configuraties van het product worden beheerd. Dit bestand bevindt zich in de [MI-HOME]/conf map van het product.
[[custom_message_builders]]
class = "org.wso2.carbon.relay.BinaryRelayBuilder"
content_type = "image/jpeg"
[[custom_message_formatters]]
class = "org.wso2.carbon.relay.ExpandingMessageFormatter"
content_type = "image/jpeg"Nu wordt een bericht met het contenttype image/jpeg verwerkt volgens die twee Java-klassen voor de builder en de formatter. Nadat je deze wijziging hebt doorgevoerd, moet je de Micro Integrator opnieuw starten, omdat het deployment.toml-bestand alleen bij het opstarten wordt gelezen.
Laten we eens kijken naar de API uit deel één en laten we daar de nieuwe onderdelen in plaatsen. De grote verandering is natuurlijk de Iterate-mediator die door de JSON-array zal lopen die we naar de API gaan sturen, en de code die het daadwerkelijke bestand naar onze lokale schijf zal schrijven.
Ik ga niet elk deel van deze configuratie uitleggen, omdat dat te veel ruimte zou innemen en de blog te lang zou worden. Ik heb een Bitbucket-repository gemaakt waar je de resources/artefacten kunt downloaden.
Tinkering
Je zult instellingen vinden die je moet configureren bij het starten van het bouwen van dit soort bemiddelingen.
Bijvoorbeeld, als je werkt met de JSON-array en de waarde wilt ophalen, heb ik gemerkt dat het noodzakelijk was om de “attachPath” in te stellen, zodat de individuele waarden binnen de array worden voorafgegaan door een keypair. Als je dit zou doen met een XML-bericht, is dit niet nodig. Een ander punt is dat we momenteel een klein aantal objecten gebruiken dat we willen verwerken. Als je met grotere aantallen gaat werken, moet je mogelijk de geheugeninstellingen wijzigen, omdat wanneer het begint met verwerken, het een aantal threads oppikt en de berichten in het geheugen laadt. Hiervoor moest ik het geheugen instellen op 4096 megabytes, vier keer de normale instelling voor het maximale geheugen dat de Micro Integrator zal gebruiken. Deze instelling wordt eigenlijk gedaan in het opstartscript in plaats van in de deployment.toml. Maar destijds kon ik meer dan 60 objecten verwerken in één payload.
Hieronder heb ik een JSON-array payload gemaakt: {“object”: [“SK-C-5”, “SK-C-4”]}, die ik doorgeef aan de API.
Er worden twee bestanden aangemaakt in de toegewezen directory. Zoals je kunt zien, zijn het volledige jpg-bestanden.
Overdracht van kunst voltooid! Dat is genoeg voor deze blog. In de volgende blog, genaamd Deel 3, gaan we de laatste stap zetten en dat is het uploaden naar onze Meural..
