Auteur: Max Nijholt – Data Engineer

Als amateur kok die graag iets lekkers maakt viel mijn oog op de analogie tussen full stack development en het maken van een goede hamburger. Beiden moeten solide worden opgebouwd om te zorgen dat deze niet uit elkaar valt. In dit blog wil ik jullie meenemen naar hoe we van een snel prototype naar een proof of concept gaan om vervolgens een volwaardig product op te bouwen.

De ‘hamburger’ die we in dit blog gebruiken is een oplossing die ik gebouwd heb om mijn collega’s te ondersteunen in hun dagelijkse werk. Hierbij hebben we de taak om in de gaten te houden of er geen kritieke fouten voorkomen op systemen en als deze wel voorkomen deze te melden in een ticket systeem. Daarnaast willen we tijdens de ontwikkeling en uitrol zo min mogelijk fouten in de gebouwde processen. Dit alles vormt de basis van deze oplossing die ik gebouwd heb om ons werk nauwkeuriger en gemakkelijker te maken.

Platform

Waar ik normaal met een geroosterde onderkant van het hamburgerbroodje begin, beginnen we nu met het platform. Het platform biedt namelijk de basis waarop we verder gaan bouwen en geeft richting voor de technieken die we kunnen gebruiken.

Voor ons prototype willen we snel kunnen ontwikkelen en testen of iets werkt. Daarom kiezen we hier voor lokaal ontwikkelen op Windows en Linux, dit vormt een stabiele basis waardoor het later makkelijker is om het op te pakken op een ander platform. Het proof of concept verbindt vervolgens de oplossingen aan elkaar in een benaderbare oplossing op een Linux omgeving. Waarbij een zekere vorm van stabiliteit verwacht wordt.

Vanzelfsprekend is een lokale machine die met een stekker uit het stopcontact of door een andere fout niet meer bereikbaar is niet geschikt voor productief gebruik. Daarom is de keuze gevallen op Amazon Web Services als platform. De services die zij bieden in combinatie met onze wensen sloot erg goed aan. Daarnaast biedt AWS met hun toolkit de mogelijkheid om meerdere platformen aan elkaar te koppelen waardoor de productie omgeving zich binnen een ander account kan bevinden dan development, test, acceptatie of quality assurance omgevingen.

Backend

Natuurlijk is een platform alleen niet voldoende om iets te draaien. Evenals dat alleen een broodje nog geen hamburger maakt. Daarom voegen we de burger toe, nu begint het geheel al wat duidelijker vorm te krijgen.

Ik heb gekozen voor Python, Docker en MongoDB als initiële backend voor het prototype. Hiermee verzorg ik een goede basis die ik door middel van source control over kan brengen in elke omgeving waarin in ontwikkel. Evenals dat we hiermee kunnen zorgen dat de test omgeving en ontwikkelomgeving genieten van dezelfde basis. Je wilt namelijk niet dat de hamburger droog wordt en gaat brokkelen. In het prototype is de doelstelling het uitproberen en testen van wat we willen. Kunnen we de connectie leggen richting bron systemen en kunnen we handmatig een controle doen op wat gebouwd is. Iets wat bij elke stap van het proces naar productief gebruik gecontroleerd moet worden.

Mijn keuze voor Python komt voort uit mijn ervaringen die ik tijdens mijn laatste studie heb opgedaan. De mogelijkheden om dit makkelijk lokaal te draaien en te testen en om de grote hoeveelheid aan modules die beschikbaar zijn maken het makkelijk om snel te ontwikkelen.

Door het gebruik van MongoDB kies ik ervoor om niet relationeel om te gaan met de data in de database. Ik wil namelijk documenten opslaan die verschillen van inhoud en deze verreiken op basis van complexe berekeningen over de bestandsinhoud waarbij de bestanden in sommige gevallen niet eens bestaan.

Gedurende de ontwikkeling heb ik nog een extra wens erbij gekregen voor de oplossing namelijk een mooie afbeelding van de oplossing die geüpload wordt. Helaas was hiervoor geen geschikte module voor beschikbaar in Python maar wel in Node.js. Zo heb ik dit ook nog toegevoegd in het prototype. Deze heb ik kunnen integreren in Python door middel van console commando’s. Niet de mooiste oplossing, maar het is slechts een prototype.

Wanneer dit initiële prototype klaar is kunnen we voortzetten op een POC. Deze POC bevat feitelijk dezelfde dingen echter moet deze een stuk stabieler zijn, we willen dat collega’s deze POC kunnen gebruiken om wensen te identificeren die zij hebben bij deze oplossing.

Hierbij breiden we onze scope van de backend iets verder uit naar Docker om te zorgen dat we de applicatie kunnen hosten op de lokale machine die ik in platforms beschreven heb.

Uiteindelijk voor het eindproduct moeten we alle bovenstaande vertalen naar de oplossingen die AWS hiervoor aanbiedt. Natuurlijk zijn er binnen AWS verschillende mogelijkheden voor de begrippen die ik hierboven heb genoemd. Een van de mogelijkheden is het gebruiken van de eerder gebouwde Docker container en deze hosten. Echter is uiteindelijk de keuze gevallen op serverless architectuur. Hierbij houd ik in het achterhoofd dat ik graag deze oplossing wil kunnen schalen en is het voor mij ook een goede en leuke oefening om gebruik te maken van verschillende componenten die ik eerder nog niet heb kunnen of hoeven gebruiken.

Databases

Als echte Bourgondiër houd ik natuurlijk van een lekker plak kaas op mijn burger, ook wel de database in onze applicatie. Onze database heb ik bij backend al gedefinieerd. Ik maak gebruik van NoSQL in combinatie met MongoDB voor het prototype en POC. Voor de eindoplossing op het Amazon Web Services platform vertaalt dit zich naar DynamoDB.

Nu is het redelijk kostbaar om grote files te uploaden, downloaden en permanent op te slaan in DynamoDB. Daarom heb ik uiteindelijk gekozen om dat soort opslag te doen op de Amazon Simple Storage Solution, beter bekend als Amazon S3. Hiermee behouden we retentie op oude bestanden en kan ik deze in de toekomst gebruiken voor een ander project. Misschien een lekkere burger saus voor over de burger als volgend project.

Protocollen en API’s

In de basis moet natuurlijk onze backend kunnen communiceren met het frontend. Om de smaken aan elkaar te binden hebben we op onze burger een mooi groen blaadje sla, rode ui en tomaat. Hierbij gebruiken we een scala aan verschillende termen om het mooi technisch te houden. Zo gebruiken we REST protocollen om te zorgen dat we onze API kunnen benaderen. De logica die in de backend leeft kunnen we op deze manier aanroepen wanneer we dat willen.

Sommige informatie over de fouten die gemeld moeten worden wordt gemonitord door de backend. Deze wil je ontvangen zodra het gebeurt, niet pas 5 minuten later wanneer er bijvoorbeeld een refresh gebeurt. Daarvoor gebruiken we Websockets. Websockets staan het toe om direct een connectie te maken tussen de server en de client zodat de client op de hoogte gesteld kan worden van actuele events. Hierdoor kunnen hoge prioriteit interfaces direct gemeld worden wanneer er een fout voordoet. Hierdoor kan de eerste lijn support direct deze fout in behandeling kan nemen zonder dat deze de kans krijgt om verder te escaleren.

Natuurlijk is veiligheid van groot belang, sommige informatie kan gevoelig zijn en daarom wil je zeker zijn dat men zich eerst authentiseert voordat zij iets kunnen zien. Hiervoor gebruiken we OAuth. Open Authorization is een standaard waarmee toegang verschaft kan worden aan gebruikers nadat zij zijn ingelogd. Hiermee kunnen we dus veilig inloggen en gebruik maken van de applicatie.

Frontend

Om de hamburger helemaal af te maken hebben we natuurlijk het bovenste broodje nog nodig. Knapperig van de onderkant, boven bedekt met wat maanzaad of sesamzaad. In ons geval hebben we gebruik gemaakt bij het prototype van wat HTML5, wat ingeladen wordt met wat informatie door middel van templating die dan ingevuld wordt door de backend.

Bij het overgaan op de POC heb ik gebruik gemaakt van wat meer JavaScript, JQuery, bootstrap en CSS. Dit komt heel mooi terug doordat deze technieken gebruikt worden voor gebruikersgemak. Bij prototype was het doel om te kijken of we het technisch mogelijk konden maken met de informatie voorziening, inmiddels bij de POC willen we gebruikersgemakken in gaan bouwen om te zien hoe daar op gereageerd wordt waardoor we nog aanpassingen kunnen maken. Zo geven JavaScript en JQuery de mogelijkheid tot mooie pop-ups, waarmee bijvoorbeeld een bevestiging gedaan kan worden en bepaalde grafische elementen mogelijk gemaakt worden. CSS zorgt er voor dat alles er goed uit ziet in combinatie met Bootstrap zodat er een uniform uiterlijk is.

Uiteindelijk hebben we de elementen die in CSS en Boostrap zitten opgenomen in een Mendix Applicatie die communiceert met de backend. Hierdoor kunnen we nu full-circle gaan met onze technieken en informatie. Doordat alles uiteindelijk samen komt. De Mendix applicatie communiceert via onze API met de database en backend die op het AWS Platform draait. Een perfecte prikker om de gehele hamburger bij elkaar te houden.

Bon appetit! Geniet van onze full-stack hamburger!

Development teams face challenges while converting UX designs into functioning web applications. A dedicated UX / UI designer is often needed to assign classes to containers to make them behave the way we want, so business developers don’t have to dive too deep into the .scss files. By giving developers the right tools, it is easier to create responsive layouts without having to involve a dedicated UX designer.

Our colleague Sven Spierings wrote a blog about Mendix design properties and CSS styling, and he created a downloadable module in the Mendix Marketplace.

Read the blogpost at:

https://medium.com/@sven.spierings/adding-custom-design-properties-to-speed-up-and-simplify-mendix-ui-ux-development-65c5e3dd75e5

Or download the module:

https://marketplace.mendix.com/link/component/119683

Congratulations to Sven Spierings for getting his Mendix Advanced Developer Certification!
He successfully demonstrated the knowledge, skills and experience required and can now call himself an Advanced Developer. Now go make it!

On the 13th of March, we hosted a casual knowledge sharing session around the Google Assistant API’s and a do-it-yourself Google Assistant device. Together with our colleagues we built no less than 3 fully operational Google Assistants

THE PURPOSE OF THIS SESSION

One of the main objectives was to introduce the Raspberry Pi and additional hardware like the Voice-HAT, which stands for “Hardware Attached on Top”. Also understanding the concepts of Machine Learning and Artificial Intelligence applied within ‘smart assistants’ like Google Home, Siri or Alexa was something we wanted to achieve. 

Introduction and objectives

THE INGREDIENTS, PREPARATION AND ASSEMBLY OF COMPONENTS

To be able to build a Google Assistant, we needed both hardware and software components. We did some preparations on forehand, so the participants wouldn’t have to waste too much time on downloading Linux distributions and configuring the Raspberry Pi in terms of Wi-Fi connectivity and remote access via SSH and VNC.

After a short introduction to the project, the two teams started by assembling the different components. Most components can be connected easily by using the provided connector cables and attaching the Voice-HAT to the Raspberry’s GPIO pins. However, two wires of the 8 Ohm speaker needed to be screwed onto the connector on the Voice HAT.

The casing will be made out of card board, so we had to use our folding skills to build the box to house all electronical components.

Assembly of components

But off course our own human hardware needs input and energy as well, so we had a Pizza break before continuing with the software part of the project.

Fuel for the human hardware

CONFIGURING THE SOFTWARE

So, the hardware part is now done and we continue by inserting the Micro-SD card with the Raspbian Linux operating system distribution. This Micro-SD card was prepared and pre-configured to automatically connect with our QforIT Wi-Fi network. Also the VNC-service and SSH-service were enabled, so external access to both the graphical interface as the command line is possible. To be able to connect easily, we configured static IP-addresses on the Raspberry Pi’s. 

When the operating system has been booted up, we perform some checks to determine if all hardware has been assembled correctly. To do so, we run a prepared Python script check_audio.py. This script will try to play a test sound over the Voice-HAT and connected speaker. Also the user is asked to record a test message which will then be replayed by the device, so both the microphones and the speaker are tested.

GOOGLE CLOUD PLATFORM: GOOGLE ASSISTANT SDK

The real magic happens within the Google Cloud Platform. Voice Recognition will be done by sending audio fragments to Google’s servers via the Google Assistant API’s. First we log in to the Google Cloud Platform dashboard, to create a new project.

The project we create will be named ‘Voice Kit’, the next step is to enable the Google Assistant API.

The Google Assistant client on our Raspberry Pi needs to connect to this API, but to do so, it will need to authenticate with the proper credentials. The Google Cloud Platform dashboard allows us to create a credentials-file for downloading to the client.

After downloading the Json credentials file to the home directory on the Raspberry Pi, we need to reboot the system. The startup procedure of the Raspberry Pi has been configured so it will automatically start all necessary Voice Kit services and the credentials file will be loaded. After the system has been rebooted, we have a working Google Assistant!

Interacting with the Assistant is easy, just press the arcade button on top and start talking, or just say ‘Hey Google’ and ask questions like: 
– ‘What is the weather forecast?’ 
– ‘Can you sing me a song?’ 
– ‘What is the latest news’ 

Hey Google, Let’s talk!
The end-result in its full glory
We also like to thank Dennis van Gerwen from InnoTractor
for the demonstration of their amazing IoT CUBE. 

With the ease of Arduino and beauty of Narrow Band. The CUBE is a multi-sensor development device with NB-IOT and CAT-M1 connectivity. By being fully Arduino compatible, making Internet of Things use cases has never been so easy! Innotractor uses The CUBE to create fast and reliable end to end Proof of Concepts.

#TopTeam

Martin Jaspers – 04-06-2018

Our integration package, QforIT Error Alerting for SAP Cloud Platform Integration, has been available for some time in the SAP App Center, https://www.sapappcenter.com/apps/13577#!overview but is now also available as a downloadable package on the discover page in SAP Cloud Platform Integration.

We developed this integration package to automatically monitor your tenant via OData API requests and to have SAP Cloud Platform Integration send email alerts in case of errors/issues (using priorities according to the ITIL priority matrix). You can customize the parameters, priorities, timeframes etc, based on your own requirements.

Please read the rest of the blog here on SAP Community Network:
https://blogs.sap.com/2018/06/04/qforit-error-alerting-for-sap-cloud-platform-integration-revised/

Rik Dingemans – 15-05-2018

On the 25th of April Q for IT and SAP hosted the SAP CodeJam about IoT Foundation and SAP Cloud Platform Integration. Several speakers from Q for IT and SAP covered interesting topics about integration and the Internet of Things. A very exciting and fully-packed CodeJam with lots of enthusiasts from all-over the community was the result.

Please read the rest of the blog here on SAP Community Network:
https://blogs.sap.com/2018/05/15/sap-codejam-sap-cloud-platform-iot-integration/

Martin Jaspers – 17-07-2017

Two weeks ago we joined twenty SAP customers and –partners in the design council workshop for SAP cloud platform integration and API Design. This is an event organized by SAP in which they show future developments, ask for feedback on these developments and listen to customer- and partner experiences with the existing functionality.

Please read the rest of the blog here on SAP Community Network:
https://blogs.sap.com/2017/07/17/design-council-workshop-for-sap-cloud-platform-integration-and-api-design/