Suche

über alle News und Events

 

Alle News

 

Am 01. Oktober ab 12:30 Uhr treffen sich...

Weiterlesen

Die Nutzung des Postman Mock Servers ist einfach...

Weiterlesen

Ein Community-Held feiert seinen Erfolg: „WOW! Ich...

Weiterlesen

Einfach großartig! Die Stimmung war hervorragend....

Weiterlesen

Rules, Rules, RULES!! Dan Toomey, The evolution of...

Weiterlesen

Keynote von Slava Koltovich, Feature: E2E - AIS...

Weiterlesen

Inspirierende Messeerfahrungen auf der 'Zukunft...

Weiterlesen

In diesem Artikel wird beschrieben, wie ihr eure...

Weiterlesen

Messaging mit dem Service Bus ermöglicht die...

Weiterlesen

Sebastian Meyer, Microsoft & SAP...

Weiterlesen

How-to: How to Unzip Big Data auf dem Azure Fileshare – Part zwei

Nachdem wir nun an dem Punkt standen, an dem die Funktionalität gegeben ist, uns jedoch das Timeout in die Quere kam, musste eine neue Lösung erstellt werden.

Ebenen Fileshare im Data Folder:

  • Branche
    • Kunde
      • Kundenordner

Wobei es insgesamt 7 Branchen mit insgesamt mehr als 50 Partnern gab und minütlich wurden weiter Daten empfangen.

Zuerst hatten wir versucht, alles über eine Durable Function zu lösen, da hierbei am wenigsten Aufwand benötigt wird. Dieser Versuch scheiterte daran, dass der Run der Durable Function teils länger als 24h dauerte und sich die Abläufe somit überschnitten.

Also musste eine neue Architektur her und diese sah wie folgt aus:

 

Das Ziel dieser Architektur war es, den einen großen Workflow in sehr viele kleine Workflows zu teilen, um somit die Dauer eines einzelnen Workflows zu minimieren. Zusätzlich sollte der Use Case der Durable Function als Orchestrator gegeben sein.

Also teilten wir den Prozess in 3 Teile:

 

BranchOrchestration

Wir befinden uns nun auf der obersten Ebene des Fileshares, bei den Branchen:

Es wurde eine Durable Function erstellt, die lediglich die Aufgabe hatte, über alle vorhandenen Branchen zu loopen und pro Branche einen Request an die nächste Orchestration zu senden, mit der Information, welche Branche er zu bearbeiten hat.

Somit kommen wir direkt zur nächsten Azure Function.

CustomerOrchestration


Diese Orchestration startet auf der 2. Ebene (Kunden) mit der Hilfe des Key-Value Pairs, das im HTTP Trigger empfangen wurde, Beispiel:

Die Aufgabe hierbei bestand wieder lediglich darin, über die im Branch enthaltenen Kunden zu loopen und der nächsten Function mitzuteilen, welchen Kunden sie zu bearbeiten hat. 

Nun zum letzten und wichtigsten Schritt.

UnzipCustomer

Diese Function bekommt ebenfalls ihren Startpunkt mitgeteilt.

Hier wird nun das Unzipping ausgeführt (Download, Unzip, Upload).

Ergebnis

Von der anfangs einen einzigen Durable Function, die täglich mindestens 12h gelaufen ist, sind wir nun zu einer Architektur gekommen, die den kompletten Prozess in sehr viele kleine Schritte einteilt. Anstatt alles in einer Instanz zu bearbeiten, laufen nun etwa 90 Instanzen gleichzeitig, die die Aufgabe haben, lediglich einen Kunden zu unzippen.

Dauer:

1 Durable Function Instance: mind. 12 Stunden
Neue Architektur: höchstens 3 Stunden
 

Was lernen wir daraus?

Natürlich konnte bei diesem Projekt niemand wissen, dass die Kommunikation in solch einem Ausmaß umgesetzt werden muss. Denn dafür gibt es wieder andere Azure Komponenten, die für so etwas geeigneter sind.

Trotz alledem haben wir eine echt coole Lösung für das Projekt geschaffen, mit der alle Beteiligten mehr als zufrieden sind :-). 

Ein Tipp von Nico, QUIBIQ Stuttgart.

Ihre Kontaktmöglichkeiten

Sie haben eine konkrete Frage an uns


 

Bleiben Sie immer auf dem Laufenden


 

Mit meinem "Ja" erkläre ich mich mit der Verarbeitung meiner Daten zur Zusendung von Informationen einverstanden. Ich weiß, dass ich diese Erklärung jederzeit durch einfache Mitteilung widerrufen kann. Bei einem Nein an dieser Stelle erhalte ich zukünftig keine Informationen mehr.

© QUIBIQ GmbH · Impressum · Datenschutz