API Management

Het is voor leveranciers van producten bijna onmogelijk om voor ieder platform mobiele applicaties te maken. Natuurlijk kun je dan als leverancier zorgen voor een goede responsieve mobiele website. Het nadeel van deze manier is dat je de capaciteiten en mogelijkheden van een mobiel device niet volledig uit nut.

Daarom zijn er ook leveranciers die hun backoffice via API’s beschikbaar stellen aan de wereld. Meestal wil je dat niet zonder pardon doen en wil je er als leverancier wellicht geld aan verdienen. Dus je wil een Developer portal maken met verschillende groepen, help pagina’s, voorbeeldcode, monitoring, issue lijst, FAQ, maar ook malafide gebruikers/applicaties blacklisten. Kortom het vergt meer dan even het beschikbaar stellen van een paar webservicesje.

Enige tijd geleden had ik ook zo’n droom. Ik wilde voor de SDN een evaluatie app maken. Bezoekers van een SDN event kunnen dan mobiel een evaluatie formulier invullen. Deze evaluatie data wordt in een data store op Azure bewaard. Uiteraard wil ik niet mijn tokens/connectionstrings/passwords etc in mijn mobiele apps opslaan. En aangezien ik niet voor elk device zelf een applicatie kan schrijven, deze gegevens delen met wildvreemde developers.

Screenshot (1)

Dus bedacht ik dat ik een aantal Webapi services beschikbaar moest stellen. Maar zoals hierboven genoemd, had ik behoefte aan eer developers portal om mijn services uit te leggen en wat ze opleveren. Dat is veel werk voor zo’n API als dit. Dit is mijn landingspagina nu; http://sdnevalapp.azurewebsites.net/.

1-7-2015 4-34-32 PM

Gelukkig is daar een oplossing voor op het Azure platform. De API management service (documentatie site).

1-7-2015 4-40-33 PM

1-5-2015 9-53-21 AM

Als je de service gemaakt hebt, dan is er een aparte portal (https://marcelmeijer.portal.azure-api.net/admin) waar je alle instellingen doet, waar je de metrics van je API ziet, de applicaties die aangemeld zijn, welke API het vaakst aangeroepen wordt etc.

1-5-2015 9-53-33 AM

Bij de settings kun je dan de webservices beschikbaar stellen. De verschillende operaties, welke http verb, welke responses er verwacht kunnen worden, welke URL, omschrijving en helpteksten.

1-5-2015 9-56-59 AM

1-5-2015 9-57-15 AM

De URL naar de bron services kan ook on-premises gehost worden. Uiteraard is het dan wel verstandig om de endpoints op deze URL te beveiligen met een Certificaten, UserName/Password combinatie of via OAuth.

Dit is de management portal voor de beheerder van de API(https://marcelmeijer.portal.azure-api.net/admin), voor de ontwikkelaars is er een aparte portal (https://marcelmeijer.portal.azure-api.net/). Deze kan tot op zekere hoogte ook gestyled en aangepast worden.

Deze Developer portal is redelijk compleet. Alle genoemde zaken zijn hier wel te vinden.

1-5-2015 9-53-44 AM

Zo is er een handig overzicht van de beschikbare API’s.

1-5-2015 9-53-59 AM

Van de beschikbare API kun je de beschikbare endpoints zien. Je ziet dan de omschrijving en de  URL om API aan te spreken. Om het endpoint te gebruiken moet je een subscription key meegeven. Het hele idee van deze portal is dan ook om gebruik te reguleren en met behulp van de subscription key is de API per applicatie/ontwikkelaar apart. Aangezien de endpoints aan de basis beveiligd zijn met Certificaten, Username/Passwords of via OAuth, heeft het geen zin om rechtstreeks naar de bron te gaan.

Op deze Developer portal kun je API methode ook uitproberen en de verschillende gedefinieerde HTTP acties uitvoeren. Je krijgt dan de trace en het resultaat te zien.

1-5-2015 9-54-38 AM

1-5-2015 9-54-56 AM

1-5-2015 9-55-30 AM

Helemaal onderaan de pagina kun je per programmeertaal voorbeeldcode krijgen. Alles om de ‘klanten’ van je API te ondersteunen en te helpen.

1-5-2015 9-55-45 AM

Zoals ik in het begin al zei, het beschikbaar stellen van een API is een maar om er een hele developer portal bij te maken is twee. Door deze Azure service kun je je richten op het echte leuke en belangrijkste van de API, de functionaliteit.

Waarom zou je het zelf doen, als je gebruik kunt maken van de expertise van andere. “You can reach further while standing on the shoulders of giants”

Azure Webjobs

Tijdens de afgelopen Microsoft Techdays 2014 deed ik een sessie over Azure Cloud Services. De opname is te vinden op Channel 9. In het begin van Azure waren Cloud services de “way to go”.

Cloud Servies is een krachtig concept, maar er kleefde ook de nodige nadelen aan. Bestaande applicaties konden niet zomaar via de Lift en Shift methode naar de Cloud gebracht worden. Meestal was dit gewoon te wijten aan de applicaties zelf. Weinig applicaties zijn of waren zuiver stateless, asynchroon in de basis en in staat als meerdere instanties naast elkaar te draaien.

In de afgelopen jaren is het Azure platform rijker geworden met verschillende diensten. In plaats van iets zelf te verzinnen of te kopieren van anderen, zijn er nu bestaande tools/producten opgepakt en in samenwerking geschikt gemaakt voor Azure (Hadoop, Docker, etc).

Maar ook is IT development een stuk volwassener geworden. Developers en architecten realiseren zich steeds vaker dat Scale up niet helpt met availability, dat services/servers stuk gaan en dat een internet applicatie de potentie van een miljoenen publiek heeft.

Standaard dogma’s als SOA architecture, Servicebussen of SOAP webservices lijken ook hun kracht te verliezen, Microservices krijgen meer draagvlak en betere tooling. Daarover ga ik zeker nog vaker bloggen.

Terug naar mijn Techdays demo. Die zag er zo uit:

blog2

De solution zag er zo uit. De code is te downloaden of op te vragen. Zoals gezegd bestond het uit een WebRole en een WorkerRole. De WebRole voor het uploaden en bekijken van de plaatjes.

webjob1

De flow van de applicatie zag er zo uit.

 Slide1 

Zoals je ziet, de WebRole moest naast het uploaden ook een bericht op een queue zetten voor de WorkerRole. Aan de WorkerRole kant moet er een mechanisme zijn om de queue leeg te lezen. Zoals ik vertelde in mijn sessie, moet je dan ook het Busy waiting oplossen. Het lezen van de queue is een transactie en dat kost geld. Een belangrijk onderdeel van architectuur op Azure is Cost Based design. Dus wil je het lezen van bijvoorbeeld een queue zo efficiënt en effectief mogelijk houden met het oog op de kosten.

Op Azure zijn tegenwoordig Webjobs beschikbaar. Met deze webjobs is het mogelijk om deze te laten triggeren na het toevoegen van een nieuwe blob op storage. Dat scheelt in mijn geval een bericht op de queue en eigen check actie van de queue. Het hele wachten en kijken of er werk (nieuwe blob op storage) is, wordt nu door het platform verzorgd en geregeld. En wat ik niet hoef te doen, dat scheelt tijd en het platform kan dat efficiënter. Dus de WorkerRole wordt vervangen door een Webjob. De WebRole heeft ook een alternatief. Moest ik voor de WebRole toch nog iets aparts leren, zoals bijvoorbeeld het lezen van de configuratie settings. Met een Azure Website kan ik de technieken gebruiken die ik altijd al gebruikte. En voor de settings zie je in mijn vorige blogpost de oplossing.

Het proces plaatje ziet er dan zo uit.

 Slide2

En de website ziet er na een kleine redesign zo uit.

blog3 

En de code van de Webjob is eigenlijk alleen dit, ongeveer 55 regels.

function1

De WorkerRole besloeg ongeveer het dubbele aantal regels code, waarvan het grootste gedeelte zaken die niets met het proces te maken hebben.

Op deze manier krijg je precies zoals ik altijd zeg tijdens presentaties. We kunnen ons richten op de functionaliteit en het echte werk, de rest wordt overgenomen en geregeld door het Azure platform.

Oke, nu wil ik eigenlijk dat de Client niet op de queue hoeft te kijken, maar op een andere manier genotificeerd wordt.

NB In deze blogpost beweer ik niet dat Cloud Services niet bruikbaar zijn. Voor het hier genoemde scenario waren de uitgebreide mogelijkheden van Cloud Services niet nodig. Kijk op deze page voor een betere vergelijking tussen de mogelijkheden.

Macro in Excel not working after update

Voor het maken van fakturen gebruik ik een Excel 2013 sheet. De sheet maakt gebruik van makro’s. Na de laatste Office updates deed de Excel sheet het niet meer. Er verschenen allerlei errors.

Na enig zoeken op internet kwam ik deze oplossing tegen. Zoek het bestand MSForms.exd, normaal gesproken staat deze in de folder C:\Users\user.name\AppData\Local\Temp\Excel8.0\ en verwijder MSForms.exd. Deze wordt dan opnieuw opgebouwd bij de volgende start van Excel 2013 en alle VBA makro’s werken weer.

Het werkte en zo ook mijn faktuur sheet.

ConnectionStrings / AppSettings Azure

Tijdens mijn poging om Azure webjobs te doorgronden kwam ik het volgende tegen.

Een Webjob wordt gedeployed bij een Azure website. Bij de Webjob hoort ook een dashboard. Na het deployen van mijn Webjob ging ik naar dit dashboard. Tot mijn verbazing zag ik dat mijn Webjob gestart was, maar dat er wel Errors en Warnings waren over een setting.

siteconstring1

Zoals de error/warning verteld, moet je de Connectionstring toevoegen aan het Connectionstring gedeelte van de Azure website. Daarna is de error/warning weg.

siteconstring2

Eerst dacht ik dat ik deze Connectionstring op twee plekken moest configureren. Een keer op de portal en een keer in de app.config van de Webjob. Dat stuitte mij tegen de borst, ik hou niet van om settings op twee plekken hetzelfde te configureren. Dat blijkt ook niet te hoeven.

In je code gebruik je:
var storageAccount =
CloudStorageAccount.Parse(
ConfigurationManager.
ConnectionStrings[
“AzureWebJobsStorage”].
ConnectionString
);

Maar de Connectionstrings of App settings geef je een waarde op de Configure tab van de Azure Website.

image

En dit werkt ook voor de App.config van een Azure Webjob.

Meer informatie: http://www.asp.net/identity/overview/features-api/best-practices-for-deploying-passwords-and-other-sensitive-data-to-aspnet-and-azure