Data Factory

Mit der Data Factory beginnt in der Regel die Reise ins Fabric-Universum, denn hiermit werden klassische ETL Prozesse abgebildet und die Daten in den OneLake übertragen. Hier stehen zwei Bausteine zur Verfügung: Dataflows und Data Pipelines.

Mit Dataflows lassen sich via Low-code & No-code Konnektoren nahezu beliebig Datenquellen anbinden. Diese werden mit Power Query erstellt und können manuell oder wiederkehrend ausgeführt werden. Beispielsweise lassen sich hiermit stündlich aktuelle Werte aus einer REST API abrufen um später historische Auswertungen tätigen zu können.

Data Pipelines werden benutzt um komplexe Daten-Import-Prozesse zu orchestrieren und deren Ausführung zu planen. Diese Workflows bestehen z.B. aus Python Notebooks, Stored Procedures, Azure Functions oder anderen Dataflows und können dank automatischer Skalierung auch Datenmengen in Petabyte-Größenordnung verarbeiten. Konkret können Data Pipelines z.B. für den initialen Import großer Datenmengen verwendet werden, die vor dem Abspeichern in OneLake gefiltert und anderweitig aufbereitet werden müssen.

Wie die Namen vermuten lassen handelt es sich hierbei um angepasste bzw. integrierte Versionen von Azure Data Factory, Synapse Pipelines und Power BI Dataflows.

Synapse Data Warehouse

In der Synapse Data Warehouse Experience können Warehouses erstellt und verwaltet werden. Hierin werden strukturierte Daten mittels T-SQL gespeichert und abgerufen, wie man es z.B. von einem SQL Server gewohnt ist. Die Daten werden im Delta-Parquet-Format im OneLake gespeichert.

Synapse Data Engineering

In der Synapse Data Engineering Ansicht sind die Lakehouses zu finden. Diese unterscheiden sich von den Warehouses unter anderem dadurch, dass sie sowohl strukturierte (tabellarische) als auch semi-strukturierte (z.B. Websites) und unstrukturierte Daten (z.B. PDF Dateien) enthalten können. Lakehouse nutz im Hintergrund die Apache Spark Engine und kann dementsprechend auch in Spark Jobs verwendet werden.

In welchen Fällen Lakehouses oder Warehouses eingesetzt werden hängt dabei sowohl von den Daten als auch von den Konsumenten (Durchsatz, Spark vs T-SQL) ab.

Synapse Data Science

Synapse Data Science ermöglicht den Zugriff auf alle im OneLake gespeicherten Daten speziell für Data Scientists. Diese können hier ihre Workflows abbilden und aus den angereicherten Daten Erkenntnisse gewinnen. So können z.B. Machine Learning Experimente, Modelle und Notebooks erstellt und ausgeführt werden.

Synapse Real-Time Analytics

Mit Synapse Real-Time Analytics lassen sich mittels Eventstream real-time Events sammeln, verarbeiten und weiterleiten. Eine KQL-Datenbank kann die Daten im OneLake persistieren und so Fabric-weit zugänglich machen. Über KQL-Querysets können Queries geteilt und z.B. Power BI Reports erzeugt werden. Klassische Anwendungsfälle wären hierfür z.B. IoT- oder Sales-Daten.

Power BI

Power BI ist in der Regel das letzte Tool in der Datenverarbeitungs-Kette. Hier werden die gewonnen Erkenntnisse visualisiert und u.a. für Entscheidungsträger zugänglich gemacht. Die Daten stammen dabei natürlich aus dem OneLake und können sowohl historisch aber auch dank der KQL-Datenbank live gestreamt sein.

Data Activator

Mit dem Data Activator lassen sich Live-Daten in Eventstreams und Power BI Reports auf Muster oder Bedingungen überwachen. Die Logik wird hierbei mit dem No-Code-Tool Reflex entwickelt. Werden passende Events gefunden können Aktionen ausgelöst werden, wie das Benachrichtigen des Benutzers oder das Ausführen von Power Automate Workflows.

Industry Solutions

In Industry Solutions liefert stehen Templates für besondere Szenarien bereit. Aktuell können so mittels dieser Bausteine typische Workflows in Fabric für Nachhaltigkeit, Einzelhandel und Gesundheitswesen erstellt und anschließend den eigenen Bedürfnissen angepasst werden.

Zusammenfassung

Das nachfolgende Schaubild zeigt noch einmal, wie die Dienste grundsätzlich zueinander in Beziehung stehen. Auch wenn es viele Datenquellen und Formate gibt die auf unterschiedliche Art und Weise verarbeitet werden liegen letztendlich doch alle Information im offenen Apache Delta-Parquet im OneLake.

The post Microsoft Fabric – die Kerndienste erklärt appeared first on medienstudio.net.

Was ist Microsoft Fabric?

Microsoft Fabric ist ein Software-as-a-Service (SaaS) Angebot zur zentralen Verwaltung und Analyse aller Arten von Unternehmensdaten. Es bündelt zahlreiche etablierte und neue Dienste von Microsoft in einer Lösung, die die Sammlung, Verarbeitung und Auswertung von Daten in einer zentralen Anwendung ermöglichen. Hierbei sind die eingebundenen Dienste darauf optimiert, nahtlos zusammenzuarbeiten. Dies verringert den Bedarf an selbst programmierter Logik und erhöht die Geschwindigkeit, in der Erkenntnisse aus Daten jeder Größenordnung gewonnen werden können.

Die zentrale Rolle spielt hierbei OneLake, der zentrale Speicherort für alle Daten die in Fabric importiert oder erzeugt werden. Dieser sorgt dafür, dass alle dort gespeicherten Daten für das gesamte Unternehmen in einem einheitlichen Format zugänglich gemacht werden können.

Welche konkreten Probleme löst Microsoft Fabric?

Durch den zentralisierten Ansatz von Microsoft Fabric und dem OneLake ergeben sich zahlreiche Vorteile zu den bisherigen Individuallösungen, die sich in vielen Unternehmen über Abteilungen hinweg etabliert haben. Hier eine nicht abschließende Auflistung and Benefits:

• Eine einheitliche User Experience
  Die Benutzer können alle Funktionen innerhalb der Fabric App abrufen und müssen nicht in unterschiedliche Web Apps wechseln oder gar zusätzliche Programme installieren. Dies kann unter anderem die Einarbeitungszeit deutlich verkürzen.
• Keine Datenduplizierung
  Durch die Speicherung aller Daten im OneLake im einheitlichen Delta-Parquet Format können alle Personen und Fachbereiche im Unternehmen ohne Duplizierung auf dieselbe Datenquelle zugreifen. Dies spart Speicherplatz und somit bares Geld und erhöht die Datenkonsistenz, also die Qualität der Daten.
• Auffindbarkeit von Daten
  Durch die zentrale Speicherung der Daten können diese im Unternehmen auch einfacher auffindbar gemacht werden. Durch die integrierte Suche können Datensätze gefunden und sofort weiterverarbeitet werden, ohne dass aufwändig Zugriff auf Datenbanken oder Dokumente erfragt und manuell bearbeitet werden muss. Zudem lassen sich qualitativ hochwertige Datensätze explizit für alle sichtbar als „Empfohlen“ markieren.
• Zentrale Zugriffssteuerung
  Über den OneLake kann der Zugriff auf Daten für Benutzer zentral geregelt werden. Dies wird automatisch in den unterschiedlichen Sub-Diensten durchgesetzt und gilt auch für hiervon abgeleitete bzw. weiterverarbeitete Datensätze.
• Zentrales Monitoring
  Über den Monitoring Hub (auf Deutsch auch Überwachungshub genannt) lassen sich alle Aktivitäten in Fabric überwachen, wie z.B. die Ausführung von Datenpipelines, Dataflows, Notebooks oder Spark-Auftragsdefinitionen.
• Sicherheit und Governance
  Fabric ist als SaaS vom Microsoft umfassend geschützt. Alle Daten werden stets verschlüsselt gespeichert und übertragen. Benutzer melden sich via Microsoft Entra ID an und können so z.B. via Multifaktor-Authentifizierung oder IP-Ranges zusätzlich abgesichert werden. Des weiteren stehen Werkzeuge zur Verfügung um zahlreiche Compliance Standards zu erfüllen. Weitere Informationen
• Zentrale Abrechnung
  Durch das SaaS Modell laufen alle entstehenden Kosten an einem Punk zusammen. So können die Gesamtkosten deutlich einfacher überblickt werden als wenn jede Abteilung eigene SQL Datenbanken einer separaten Azure Subscription betreibt.

Im zweiten Teil dieser Artikelserie werfen wir einen Blick auf die unterschiedlichen Dienste, aus denen Microsoft Fabric besteht.

The post Microsoft Fabric auf den ersten Blick appeared first on medienstudio.net.

Für diese Demo bauen wir eine simple, personalisierte Startseite, die aktuelle Schlagzeilen eines WordPress-Blogs und ein paar weitere Links anzeigt. Sicherlich nicht das spannendste Projekt, aber ausreichend, um ein paar interessante Dinge zu zeigen.

Folgendes wollen wir erreichen:

• Die mustache-Templates anlegen
• Die Template-Dateien in der Azure Function laden und vorbereiten
• Die Daten aus der WordPress REST API abrufen
• Das HTML rendern und in Azure Storage hochladen

Die Mustache Templates

Um zu zeigen, wie man die Template-Dateien aufteilen kann, habe ich jeweils eine Datei für den Index, den Header und den Footer angelegt. Mit den entsprechenden Tags {{> header.mustache}} und {{> footer.mustache}} lassen sich die entsprechenden HTML-Teile in der Index-Datei einbinden.

Die News zeigen wir als einfache Liste mit einem Link zum Originalartikel an. Das Ganze sieht dann so aus:

Diese drei Dateien legen wir in einem eigenen „templates“-Verzeichnis im Azure Blob Storage ab. Auf diese Weise können wir die Templates unabhängig vom Backend-Code anpassen. Außerdem ermöglicht uns dies, die Dateien in der Function via Bindings direkt zu laden.

Die Azure Function

Wie oben erwähnt nutzen wir JavaScript für die Logik der Function. Diese habe ich mit Visual Studio Code erstellt und ein paar npm Packages hinzugefügt, die wir benötigen:

• request – für den Download der News
• mu2 – eine Node.js Mustache engine
• azure-storage – das SDK um die fertigen HTML Dateien in den Azure Blob Storage hochzuladen

Fangen wir damit an, die News-Artikel in der mynews Variable zu speichern:

Nachdem wir hier in den Optionen json auf true gesetzt haben, wird der heruntergeladene JSON-String direkt als JavaScript-Objekt (bzw. in diesem Fall als Array) geparsed zurückgegeben.

Anschließend rufen wir die prepareTemplates() Methode auf, welche die Header- und Footer-Dateien zur weiteren Verwendung mit mustache vorbereitet. Die Dateien können wir  direkt über das context.bindings Object aufrufen. Ein Blick in die functions.json Datei verrät, wie die Azure Function konfiguriert wurde.

Nachdem dies erledigt ist kann die Webseite selbst nun gebaut werden. Hierzu übergeben wir unsere Daten der mu.render() Methode und speichern den Stream-Output in der pageFile Variable. Hier erhalten wir den resultierenden HTML-Code als String.

Nach Beendigung des Streams müssen wir die Datei noch in Azure hochladen. Prinzipiell wäre es möglich, dies über die Azure Function Output Bindings zu lösen. Allerdings haben wir hier keinerlei Kontrolle über den Content Type der Datei, was in manchen Browsern zu Problemen führt.

Zunächst legen wir aber noch das benötigte $web Verzeichnis an und speichern dort dann unsere HTML-Datei als neuen Blob. Hier lässt sich dann auch der richtige Content Type ‚text/html‘ mit übergeben.

Und das wars. Der gesamte Code kann auf Github gefunden werden. Hier findet ihr das finale, wunderbar gestylte Ergebnis.

The post Building static websites with Azure Functions, mustache & Azure Storage appeared first on medienstudio.net.

Der große Vorteil hierbei ist, dass man sich nicht mehr um die typischen Webhosting-Fragen kümmern muss. Wie viele Kerne oder RAM brauche ich? Wie viele Instanzen? Und an welchen Standorten? Das alles kann man auch einfach Azure automatisch managen lassen.  Serverless all the way!

Nachdem ich also das Preview-Feature aktiviert und meine statische Website im $web Verzeichnis meines Storage Accounts abgelegt habe, hat die Seite auch direkt in Microsoft Edge funktioniert. In Chrome wurde jedoch statt die Seite anzuzeigen nur ein nicht weiter definiertes File heruntergeladen. Ein Blick mit dem Azure Storage Explorer in das Verzeichnis verriet, dass meine Dateien als application/octet-stream gespeichert wurden.

Richtig wäre in diesem Fall allerdings text/html. Das zu ändern geht am einfachsten erneut über den Azure Storage Explorer:

Rechtsklick auf die Datei => Properties… Hier kann das Content Type Feld dann entsprechend angepasst werden.

Für meine Zwecke war dies allerdings nicht ausreichend, da meine Seite täglich via  Azure Node SDK neu hochgeladen wird. Die von mir dabei benutzte Methode createBlockBlobFromText (docs) akzeptiert zusätzlich noch diverse Optionen, über die auch der Content Type richtig gesetzt werden kann:

const options = { contentSettings: { contentType: 'text/html' } }

In letzter Zeit hat sich im SDK die Struktur dieses Options-Objekts geändert, sodass es noch zahlreiche veraltete Beispiele zu finden gibt. Leider wirft ein falsches Options-Objekt keinen Fehler sondern wird einfach ignoriert.

Übrigens finde ich, dass Azure Storage durchaus den Content Type automatisch richtig anhand der Dateiendung setzten könnte…

The post Richtiger Content Type bei statischen Websites in Azure Storage appeared first on medienstudio.net.

Die Bilder werden in einer Liste als quadratische Kacheln angezeigt, indem die Foto-URL als background image mit background-size: cover geladen wird. Allerdings können diese Fotos dank neuster Smartphonekameras schnell über 3MB groß werden, was zu enormen Performanceproblemen geführt hat. Vor allem die Navigation innerhalb des Angular Material Tab Controls dauerte auf schwächerer Hardware schnell mehrere Sekunden.

Die Fotos im normalen img-Tag hingegen konnten trotz ihrer Größe problemlos angezeigt werden – allerdings auch nur, wenn man auf object-fit: cover; verzichtet. Offensichtlich ist hier die Neuberechnung der Bildgröße das Problem.

Das Resultat ist jetzt eine Liste mit Bildern im Original-Seitenverhältnis. Nicht ganz so schön, aber dafür läuft’s butterweich.

The post CSS Background-Url Performance Probleme (TIL) appeared first on medienstudio.net.

Lösung des Problems war, die Verschlüsselung des WLANs in den Router-Einstellungen von WPA-PSK/WPA2-PSK auf WPA2-PSK umzustellen. Nach einem Neustart des Routers konnte die Verbindung auf Anhieb hergestellt werden.

The post Fehlercode 7:3:0:0:1 – Amazon Echo & Unitymedia WLAN Probelme beheben appeared first on medienstudio.net.

Nachdem das Projekt in letzter Zeit vermehrt Pull Requests erhält, habe ich mich entschieden, den Build & Publish Prozess zu automatisieren, um nicht immer manuell die neuste Version des NuGet-Packages hochladen zu müssen. Hierfür nutze ich die kostenlosen Visual Studio Team Services.

Der grobe Plan hierfür sieht wie folgt aus:

• Code von GitHub holen
• .dll mit Visual Studio builden
• NuGet Package erstellen
• Package auf nuget.org veröffentlichen

Continuous Integration ist in meinem Fall nicht notwendig, da ich die volle Kontrolle darüber behalten möchte, wann Packages gebaut und veröffentlich werden. Auch die Versionierung wird manuell gepflegt. Wie man die Version automatisch bei jedem Build erhöhen kann, zeigt dieser Blogpost von Ben Chartrand.

Step 0: Projekt für NuGet konfigurieren

Bevor man beginnt den Build-Prozess in VSTS zu erstellen, wird zunächst das Projekt in Visual Studio 2017 geöffnet. In den Projekteigenschaften (Project properties) muss in der Package-Sektion die Option Generate NuGet package on build aktiviert werden. In den restlichen Feldern werden die Informationen zum NuGet-Package eingetragen. Aus diesen Feldern wird beim Build die NuGet-Spezifikation erstellt. Anschließend nicht vergessen, den Code einzuchecken.

Step 1: Build Definition erstellen

Als Basis eignet sich hier das normale Visual Studio Template. Einige der Steps kann man direkt wieder entfernen (siehe nächstes Foto).

Step 2: Code holen

Der Code kann nahezu jeder beliebigen Source Control (VSTS, GitHub oder jedes andere Git-Repository) geladen werden. In meinem Fall kommt der Code via GitHub, allerdings funktioniert der GitHub-Connector noch nicht mit Organisations-Repos, weshalb ich den Umweg über eine generische Git-Anbindung gehen musste.

Step 3: Setup NuGet restore

Damit die NuGet-Packages problemlos geladen werden, muss die NuGet Version 4.0.0 im Schritt NuGet restore gewählt werden.

Step 4: Build solution

Im Schritt Build Solution war es in diesem Fall notwendig, statt dem Platzhalter **\*.sln den Pfad zur tatsächlichen .csproj, also WordPressPCL\WordPressPCL.csproj einzutragen. Hierzu muss zunächst das Feld „unlinked“ werden.

Step 5: NuGet Publisher

Nun zum eigentlich interessanten Teil. Als finaler Schritt wird nun der NuGet Publisher Task hinzugefügt. Den NuGet Packager benötigen wir nicht, da das NuGet-Paket ja bereits von Visual Studio fertig ausgespuckt wird.

In diesem Schritt muss nun der NuGet Server Endpoint konfiguriert werden, was man über das kleine Zahnrad rechts neben dem Eingabefeld erledigen kann.
Über New Service Endpoint -> Generic wird dem Endpoint ein Name, https://nuget.org/ als die Server URL und der nuget.org Username eingetragen.

Unter nuget.org/account muss zudem ein neuer API Schlüssel erstellt werden, den man als Password/Token Key verwendet.

Nachdem diese Einstellungen gespeichert wurden, kann man den neuen Endpoint im NuGet Publisher Schritt aus dem Dropdown-Menü auswählen. Auch in diesem Schritt stellen wir die NuGet Version auf 4.0.0.

Das wars. Die .NET Standard Bibliothek sollte jetzt als NuGet Package im öffentlichen nuget.org Feed veröffentlicht werden.

The post .NET Standard Nuget Packages in VSTS builden & auf nuget.org veröffentlichen appeared first on medienstudio.net.

Wiring MCP23017-E/SP & DragonBoard 410c

Die Verkabelung von DragonBoard und Port Expander ist relativ simpel, vor allem wenn nur ein einzelner MCP23017-Chip angeschlossen werden muss:

• Verbinde SCL (12) Pin mit DragonBoard I2C0 SCL (15) Pin
• Verbinde SDA (13) Pin mit DragonBoard SDA (17) Pin
• Verbinde RESET (18) und VDD (9) mit DragonBoard 1.8V PWR (35) Pin
• Verbinde A0, A1, A2 (15, 16, 17) und VSS (10) mit Ground / GND (1, 2, 39 or 40)

Die MCP23017 Chips von Amazon sind an sich OK, die Sockel hielten allerdings nur schlecht auf meinem Breadboard, sodass ich auch keine Verbindung bekam. Bessere Sockel erkennt man an den runden Pins (wie diese z.B.), mit denen dann auch die Verbindung stabil war.

Verbindung mit Windows 10 IoT Core zu MCP23017-E/SP via I2C herstellen

Der „Windows.Devices.I2c“ Namespace nimmt einem bereits viel Arbeit bei der Herstellung einer Verbindung via I2C ab. Wie das beispielsweise aussehen kann zeigt dieses Code-Beispiel von Microsoft. Allerdings ist es meist nicht ganz so einfach.

Fast alle Tutorials die man zu Windows 10 IoT Core und I2C-Kommunikation findet beziehen sich auf ein Setup mit Raspberry Pi-Geräten. Diese versorgen den Expander-Chip mit 3.3V, das DragonBoard kann allerdings nur mit 1.8V arbeiten. An sich kein Problem, da der MCP23017 prinzipiell mit 1.8V – 5.5V funktioniert.

ABER

Es ist nicht möglich, bei 1.8V mit I2cBusSpeed.FastMode (400kHz) zu arbeiten. Stattdessen muss hier I2CBusSpeed.StandardMode (100 kHz) verwendet werden, da man sonst den Fehler „Slave address was not acknowledged.“ erhält, der alles und nichts sagt.

Wichtig ist auch, den Chip richtig zu adressieren. Das r/w-bit wird am Ende weggelassen, sodass man eine die 7-bit Adresse 0x20 erhält (sofern die Adress-Ports a0, a1 & a2 geerdet sind).

Mit MCP23017 produktiv arbeiten

Bei den Recherchen zum MCP23017-Chip bin ich auf eine sehr praktische Helper-Bibliothek für Raspberry Pi von Michael Hacker gestoßen, die ich geringfügig für das DragonBoard angepasst habe. Diese nimmt einem nochmal einiges an Arbeit zu Initialisierung des Chips ab. Außerdem kann man so statt anstatt von Hex-Adressen mit schönen Konstanten und Enums arbeiten.

Beispielsweise lässt sich damit so in wenigen Zeilen eine LED am GPB0-Port steuern:

private MCP23017 i2cPortExpanderClient = new MCP23017("I2C0");
await i2cPortExpanderClient.Init();
i2cPortExpanderClient.SetDriveMode(MCP23017.Pin.GPB0, MCP23017.PinMode.Ouput);
i2cPortExpanderClient.Write(MCP23017.Pin.GPB0, MCP23017.PinValue.High);
i2cPortExpanderClient.Write(MCP23017.Pin.GPB0, MCP23017.PinValue.Low);

The post DragonBoard GPIO-ports erweitern mit MCP23017-ESP und Windows 10 IoT Core appeared first on medienstudio.net.

Im konkreten Beispiel geht es darum, wöchentlich aus dem Windows Store die aktuellen „Red Stripe Deals“-Angebote auszulesen und die Informationen als JSON-Datei auf dem Server abzulegen, wo diese z.B. von einer App weiterverwendet werden können.

Verantwortungsbewusst Crawlen & Scrapen

Ich möchte an dieser Stelle keine große Ethik-Diskussion über das scrapen von Daten vom Zaun brechen. Dazu gibt es im Web schon mehr als genug Diskussionen und Meinungen. Allerdings möchte ich anmerken, dass man selbst nur davon profitiert, wenn man nicht rücksichtslos vorgeht. Gerade wenn mehrere, unter Umständen tausende Seiten aufgerufen werden sollen, ist es durchaus im eigenen Interesse, den Server nicht mit zu vielen gleichzeitigen Requests in die Knie zu zwingen. Zudem möchte man den Seitenbetreiber ja nicht dazu ermuntern, Gegenmaßnahmen zu ergreifen.

Aus diesem Grund verwenden wir Tools wie Async.js und die in Node.js enthaltene Library zlib, um möglichst ressourcenschonend an die Daten zu kommen.

Verwendete Tools

• Windows Azure Account
• NodeJS
• Microsoft Webmatrix

Vorbereitung

Zunächst benötigen wir eine neue Web App, unter der wir den WebJob ausführen können. Hierfür reicht erst mal auch die kostenlose F1 Free-Instanz des App Service Plans.

Projekt anlegen

Um ein neues Projekt anzulegen erstellen wir einen neuen Ordner, welcher am Ende alle benötigten Files enthalten wird und den wir dann einfach als .zip auf Azure hochladen können.

In dem noch leeren Ordner öffnen wir die cmd (im Ordner Shift + Rechtsklick -> Eingabeaufforderung hier öffnen) und beginnen damit, die benötigten Node.js-Pakete herunterzuladen.

npm install request

request ist ein HTTP request client, über den wir die benötigten Seitenaufrufe ausführen können.

npm install cheerio

cheerio ist quasi eine für Node.js abgespeckte Variante von jQuery, die es ermöglicht, Informationen mit gewohnt simplen Selektoren aus dem DOM-Baum zu extrahieren.

npm install async

async ermöglicht es uns, Warteschlangen für unseren Crawler anzulegen und so die HTTP-Anfragen zu drosseln.

Neben diesen externen Paketen benötigen wir noch zwei bereits in Node.js enthaltene Module:

Mit zlib können wir die Webseiten gzip-komprimiert aufrufen und entpacken, was uns vor allem Traffic und Zeit spart.
Mit fs greifen wir am Ende auf das Dateisystem zu und speichern unsere Daten als .json-Dokument.

In unserem Stammverzeichnis legen wir nun eine leere app.js Datei an, in der wir all diese Module laden:

var request = require('request');
var cheerio = require('cheerio');
var fs = require('fs');
var async = require('async');
var zlib = require('zlib');

Anschließend brauchen wir noch ein paar Konfigurations-Variablen sowie ein output-Array, in welches wir die erhaltenen Apps pushen.

var output = [fusion_builder_container hundred_percent="yes" overflow="visible"][fusion_builder_row][fusion_builder_column type="1_1" background_position="left top" background_color="" border_size="" border_color="" border_style="solid" spacing="yes" background_image="" background_repeat="no-repeat" padding="" margin_top="0px" margin_bottom="0px" class="" id="" animation_type="" animation_speed="0.3" animation_direction="left" hide_on_mobile="no" center_content="no" min_height="none"][];
var dealsUri = "https://www.microsoft.com/en-us/store/collections/redstripedeals/pc";
var baseUri = "http://microsoft.com";
var output = [];
var outputFilename = "redstripedeals.json";
//var outputFilename = "d:\\home\\site\\wwwroot\\redstripedeals2.json";

dealsUri ist die Einstiegsseite, über die wir die Links zu den Apps erhalten.
baseUri benötigen wir, um aus den relativen Links absolute URLs bauen zu können.
Über outputFilename geben wir an, wo unsere Deals am Ende gespeichert werden. Für den lokalen Test soll die Datei einfach im Stammverzeichnis abgelegt werden. In Azure wird das Script allerdings in einem temporären Verzeichnis ausgeführt, so dass hierfür ein absoluter Pfad angegeben werden sollte.

Der Crawler

Das Script soll folgendermaßen vorgehen:

1. Die Red-Stripe-Deals-Seite in gzip-Form mit den Links zu allen Apps herunterladen

   var loadDeals = function () {
       var options = { 
           url: dealsUri,
           port: 443,
           headers: {
               'User-Agent': 'Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko',
               'Accept-Language': 'en-us',
               'Content-Language': 'en-us',
   			'Accept-Encoding': 'gzip'
           },
           timeout: 0,
           encoding: null
       };
       request(options, function (err, resp, body) {
           if (err) {
               console.log("error loading page");
           } 
           if (!err) {
               if (resp.headers['content-encoding'] == 'gzip') {
                   zlib.gunzip(body, function (err, dezipped) {
                       redstripedealsParser(dezipped.toString());
                   });
               } else {
                   redstripedealsParser(body);
               }
           }
       });
   }
   

2. Die Links mit cheerio (jQuery) extrahieren und in die Warteschlange / Queue qDetails einfügen

   var redstripedealsParser = function (body, lang)
   {
       $ = cheerio.load(body);
       $('figure h4 a').each(function ()
       {
           var appUri = baseUri + $(this).attr("href");
           qDetails.push(appUri);
       });
   }

3. Die Warteschlange einzeln abfragen und die App-Details-Seiten entpackt and den Parser weitergeben.
   Hier lässt sich über den letzten Parameter von async.queue() die Anzahl der parallel laufenden Tasks anpassen (in diesem Fall 1).

   var qDetails = async.queue(function (task, callback) {
       console.log("get details: " + task);
   	var options = {
   		url: task,
   		headers: {
   			'User-Agent': 'Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko',
   			'Accept-Language': 'en-us',
   			'Content-Language': 'en-us',
   			'Accept-Encoding': 'gzip'
   		},
   		timeout: 0,
           encoding: null
   	};
   	request(options, function (err, resp, body) {
           if (err)
           {
               console.log("error: " + task);
               throw err;
           }
   		if(resp.headers['content-encoding'] == 'gzip'){
   			zlib.gunzip(body, function(err, dezipped) {
   				GetDetails(dezipped.toString(), task, callback);
   			});
   		} else {
   			GetDetails(body, task, callback);
   		}
   	}); 
   }, 1);
   

4. App-Details mit cheerio extrahieren und in das output-Array schreiben
   Am Ende nicht den callback() für die async-Queue vergessen.

   var GetDetails = function (body, task, callback) {
       console.log("parse details: " + task);
       $ = cheerio.load(body);
   
       var app = {};
       
       app["title"] = $('#page-title').text();
       app["image"] = "http:" + $('.ph-logo > img').first().attr('src').toString();
       app["description"] = $('.showmore  > p').first().text();
       app["price"] = $('.srv_price > span').first().text();
       app["ratingValue"] = $('.srv_ratingsScore.win-rating-average').first().text();
       app["ratingCount"] = $('.win-rating-total').first().text().replace(/\D/g, '');
       app["packageSize"] = $('.metadata-list-content > div').eq(2).text().replace("\r\n", "").trim();
       app["publisher"] = $('.metadata-list-content > div').eq(0).text().replace("\r\n", "").trim();
   
       output.push(app);
       callback();
   }

5. Wenn die Warteschlange leer ist, das output-Array als JSON-Dokument auf der Festplatte ablegen

   qDetails.drain = function ()
   {
   	fs.writeFile(outputFilename, JSON.stringify(output, null), function (err)
   	{
   		if (err)
   		{
   			console.log(err);
   		} else
   		{
   			console.log("JSON saved to " + outputFilename);
   		}
   	});
   }

6. Script starten

   loadDeals();

Das gesamte Script findet ihr hier nochmal als Github Gist.

Das Script lässt sich über die Kommandozeile mit folgenden Befehl ausführen:

node app.js

Script veröffentlichen und Zeitplan einrichten

Sofern das Script lokal fehlerfrei durchläuft, kommentieren wir den output-Pfad für Azure ein (und den lokalen aus) und packen den ganzen Ordner anschließend als normale .zip-Datei.

Um einen WebJob „gemäß einem Zeitplan“ ausführen zu können, müssen wir uns jetzt im alten Azure Portal anmelden. Dort können wir nun in der zuvor angelegten Web App unter Webaufträge einen neuen WebJob hinzufügen. Hierzu wird lediglich ein Name und die .zip-Datei benötigt. Außerdem wird die Region abgefragt, in welcher der Job ausgeführt werden soll.

Im zweiten Schritt lässt sich dann planen, wann genau das Script ausgeführt werden soll. Nachdem sich in unserem Fall die Red Stripe Deals nur einmal die Woche ändern, muss der WebJob auch nicht öfters laufen.

Sobald der Job eingerichtet wurde, können wir das Script zum ersten Mal ausführen. Wenn wir alles richtig gemacht haben, sollten wir nach kurzer Wartezeit ein „Success“ unter „Ergebnis der letzten Ausführung“ sehen.

WebJob Script nachträglich anpassen

Wenn wir nachträglich noch Änderungen am WebJobs Script vornehmen wollen, ist die vermutlich einfachste Variante, dies direkt via Webmatrix auf dem Server zu tun – natürlich NIE bei produktiven Systemen! Meldet man sich im Editor mit seinem Microsoft Account an, lässt sich die Web-App samt WebJobs direkt remote öffnen und editieren.

JSON abrufen

Zu guter Letzt möchte man natürlich auch noch die erstellte JSON-Datei mit all den Deals in irgendeiner Weise (z.B. in einer mobilen App) weiterverarbeiten. Hier gibt es allerdings einen kleinen Stolperstein, vor dem man gewarnt sein sollte. Denn von Haus aus liefern Azure Web-Anwendungen kein statischen JSON-Dateien aus. Dies ist allerdings leicht behoben, indem man folgenden Code innerhalb der Web.config im Root-Verzeichnis ablegt:

<?xml version="1.0"?>
 
<configuration>
    <system.webServer>
        <staticContent>
            <mimeMap fileExtension=".json" mimeType="application/json" />
     </staticContent>
    </system.webServer>
</configuration>

via Microsoft Developer

Es mag auf den ersten Blick etwas viel Aufwand sein, letztendlich ist das Ganze allerdings gar nicht so tragisch. Fragen und Anmerkungen zur Anleitung und zum Code gern in den Kommentaren.

 [/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

The post Webseiten scrapen mit Azure WebJobs, Node.js, jQuery, Async.js & gizp appeared first on medienstudio.net.

Alle Aufrufe auf /wp-login.php, /wp-admin/ und /wp-admin/index.php lieferten nur einen Error 310: ERR_TOO_MANY_REDIRECTS Fehler zurück. Diverse versuche, dies mit diversen Hacks via wp-config.php, plugins und .htaccess zu lösen blieben anfangs vergeblich.

Nach knapp einem Tag bin ich dann hier auf die richtige Lösung gestoßen. Demnach müssen WordPress Seiten hinter Load Balancers oder Reverse Proxies aktiv die Verwendung von HTTPS in der $_SERVER[fusion_builder_container hundred_percent=“yes“ overflow=“visible“][fusion_builder_row][fusion_builder_column type=“1_1″ background_position=“left top“ background_color=““ border_size=““ border_color=““ border_style=“solid“ spacing=“yes“ background_image=““ background_repeat=“no-repeat“ padding=““ margin_top=“0px“ margin_bottom=“0px“ class=““ id=““ animation_type=““ animation_speed=“0.3″ animation_direction=“left“ hide_on_mobile=“no“ center_content=“no“ min_height=“none“][‚HTTPS‘] Variable setzen. Der bei mir funktionierende Code sieht dementsprechend wie folgt aus:

if ( isset( $_SERVER['HTTP_X_FORWARDED_PROTO'] ) 
            && 'https' == $_SERVER['HTTP_X_FORWARDED_PROTO'] ) 
{
    $_SERVER['HTTPS'] = 'on';
}

Dieser Schnipsel muss einfach in die wp-config.php (z.B. über der „/* That’s all, stop editing! Happy blogging. */“ Zeile) eingefügt werden.[/fusion_builder_column][/fusion_builder_row][/fusion_builder_container]

The post WordPress & Cloudflare Flexible SSL: ERR_TOO_MANY_REDIRECTS Fehler beheben appeared first on medienstudio.net.