DEV Community: Gabriel Weidmann

Display and test openapi.yaml file

Gabriel Weidmann — Thu, 16 Apr 2026 09:19:27 +0000

From a partner company I got a openapi.yaml file to evaluate their api for our use cases. Mostly I know those files from working with ASP.NET Core Apis + Swagger UI, but this time it was just a standalone file.

I got the file and an api key for the sandbox.

Did not work: Use via ASP.NET Core swagger

The first thing I was trying was to use the already known swagger ui as it's the same format.

So:

Setting up a new ASP.NET Core Api project in Visual Studio
Including the latest Swashbuckle.AspNetCore nuget
Putting the openapi.yaml file in the wwwroot folder
Setting up the Program.cs

var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.UseHttpsRedirection();

// Allow to serve the unknown-by-default file type .yaml
var provider = new FileExtensionContentTypeProvider();
provider.Mappings[".yaml"] = "application/yaml";

app.UseStaticFiles(new StaticFileOptions
{
    ContentTypeProvider = provider,
});

app.UseSwaggerUI(c =>
{
    c.SwaggerEndpoint("/openapi.yaml", "Imported API");
    c.RoutePrefix = "swagger";
});

app.Run();

Accessing the api via https://localhost:7298/swagger

This worked almost, but then CORS came around :-(

Access to fetch at 'https://sandbox.***.com/api/...' from origin 'https://localhost:7298' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.

The problem seems to be the browser, so let's look for a non-browser-solution.

Did work: Import in Postman

Then I noticed that Postman got the functionality to import openapi spec files:

From here it's possible to simulate the api requests just as good (or better?) as in swagger UI.

Multi-Highlighting in PDF.js

Gabriel Weidmann — Fri, 14 Mar 2025 16:58:38 +0000

For a current project (document management), we were given a seemingly simple task:

Implement a PDF preview where I can see all full-text search results highlighted.

Searching for a single value is easy: just press Ctrl + F, search for the term, and it gets highlighted automatically.

However, highlighting multiple values is a bit trickier. After some research, we discovered that only one major PDF viewer supports this functionality out of the box: Mozilla Firefox’s PDF.js viewer.

Implementing the viewer

We integrated the viewer as follows:

<iframe id="@_pdfPreviewId" title="document" type="application/pdf" src="/web/viewer.html?file=" class="pdf-preview"></iframe>

This loads PDF.js with an empty view. We found that the required functionality is only accessible through JavaScript. Note that the ID changes dynamically with the currently previewed document to prevent the iframe from displaying the wrong content.

Whenever the displayed document changes, the previous preview immediately disappears.

/// <summary> Dynamic id coupled to the preview id to prevent race condition while loading pdfs </summary>
private string _pdfPreviewId => "pdf-preview_" + _previewedDocument.Id;

Whenever the displayed document changes the previous preview immediately disappears.

Implementing the logic

Next, we call JavaScript from our C# Blazor code, passing in the necessary parameters.

await JS.InvokeVoidAsync("documentPreview.open", _pdfPreviewId, _previewedDocument.DownloadPath, valuesToHighlight);

This is the JavaScript code we used:

var documentPreview = {
    async open(iframeId, url, valuesToHighlight) {
        let iframe = document.getElementById(iframeId);

        // Wait until available
        let counter = 0;
        while (!iframe || !iframe.contentWindow || !iframe.contentWindow.PDFViewerApplication) {
            counter++;

            // Wait for a maximum of 10 seconds
            // This will happen if the PDF preview is getting replaced (by iframe id) before the file loading has started
            if (counter >= 100) {
                return;
            }

            await new Promise(resolve => setTimeout(resolve, 100));

            // Prevent a bug where there are multiple iframes with the same id getting created and replaced
            // This would lead to the iframe displaying the wrong file
            iframe = document.getElementById(iframeId);
        }

        // Open the PDF with credentials (we're using msal; without this we get 401 Unauthorized)
        try {
            await iframe.contentWindow.PDFViewerApplication.open({
                url: url,
                withCredentials: true
            });
        } catch (ex) {
            console.log("Failed to open PDF: " + ex);
        }

        // Show highlights
        if (valuesToHighlight?.length > 0) {
            console.log("valuesToHighlight: " + valuesToHighlight);

            var eventBus = iframe.contentWindow.PDFViewerApplication.pdfViewer.eventBus;

            var searchOption = {
                query: valuesToHighlight,
                caseSensitive: false,
                highlightAll: true,
                phraseSearch: true
            };

            eventBus.dispatch("find", searchOption)
        }
    }
}

The result

And there it is: beautiful multi-term highlighting in action.

One thing to keep in mind: using the search feature within the viewer will break the highlighting.

Preserve File Creation and Modification Date When Downloading in a ZIP File

Gabriel Weidmann — Wed, 12 Mar 2025 18:12:54 +0000

As part of a recent project, it was necessary to ensure that the creation date and modification date of files were preserved when downloading them from the browser. The default behavior of browsers is to set both dates to the current time upon download (some research showed that this behavior can't be easily bypassed when downloading files directly in the browser).

For example, here’s the title image: just downloaded, but definitely not just created.

A workaround was to always download the files in ZIP archives and adjust the creation and modification dates there. Unfortunately, in .NET and common libraries, only the LastModifiedAt can be set. It seems the standard only supports this value.

Fortunately, the ZIP specification does support an NTFS extra field:

   4.5.5 -NTFS Extra Field (0x000a):

      The following is the layout of the NTFS attributes 
      "extra" block. (Note: At this time the Mtime, Atime
      and Ctime values MAY be used on any WIN32 system.)  

      Note: all fields stored in Intel low-byte/high-byte order.

        Value      Size       Description
        -----      ----       -----------
(NTFS)  0x000a     2 bytes    Tag for this "extra" block type
        TSize      2 bytes    Size of the total "extra" block
        Reserved   4 bytes    Reserved for future use
        Tag1       2 bytes    NTFS attribute tag value #1
        Size1      2 bytes    Size of attribute #1, in bytes
        (var)      Size1      Attribute #1 data
         .
         .
         .
         TagN       2 bytes    NTFS attribute tag value #N
         SizeN      2 bytes    Size of attribute #N, in bytes
         (var)      SizeN      Attribute #N data

       For NTFS, values for Tag1 through TagN are as follows:
       (currently only one set of attributes is defined for NTFS)

         Tag        Size       Description
         -----      ----       -----------
         0x0001     2 bytes    Tag for attribute #1 
         Size1      2 bytes    Size of attribute #1, in bytes
         Mtime      8 bytes    File last modification time
         Atime      8 bytes    File last access time
         Ctime      8 bytes    File creation time

With this, you can provide additional values—specifically the Creation time and Last modification time you want.

The implementation isn’t completely straightforward.

You need a ZIP library that supports writing this NTFS extra field. I came across SharpZipLib. It hasn’t been updated since August 2023, but it works perfectly fine for a server-side packaging solution.
You need the code to write the field.

var zipMemoryStream = new System.IO.MemoryStream();

using var zipStream = new ZipOutputStream(zipMemoryStream)
{
    IsStreamOwner = false // Prevent from disposing the memory stream
};

var zipEntry = new ZipEntry(myFilename);

byte[] ntfsExtraData = CreateNtfsExtraField(
    creationTime: myDocument.CreatedAt,
    modifiedTime: myDocument.ChangedAt,
    lastAccessTime: myDocument.ChangedAt
);

zipEntry.ExtraData = ntfsExtraData;

zipStream.PutNextEntry(zipEntry);

await fileStream.CopyToAsync(zipStream, ct);

fileStream.Dispose();
...

private static byte[] CreateNtfsExtraField(DateTime creationTime, DateTime modifiedTime, DateTime lastAccessTime)
{
    // NTFS extra field structure:
    // [Header ID (2 bytes)][Data Size (2 bytes)][Reserved (4 bytes)][Tag (2 bytes)][Content Size (2 bytes)][Timestamps (24 bytes)]

    // Constants
    ushort headerId = 0x000A; // NTFS field
    ushort tag = 0x0001;      // Attribute Tag - "Standard information"

    // Time conversion: DateTime -> Windows FILETIME (ticks since 1601-01-01)
    long creationFileTime = creationTime.ToFileTimeUtc();
    long accessFileTime = lastAccessTime.ToFileTimeUtc();
    long modifiedFileTime = modifiedTime.ToFileTimeUtc();

    using (var ms = new MemoryStream())
    using (var writer = new BinaryWriter(ms))
    {
        // Write Header ID and Size Placeholder
        writer.Write(headerId);
        writer.Write((ushort)32); // Data Size: Reserved(4) + Tag(2) + Size(2) + 24 bytes

        writer.Write(0); // Reserved (4 bytes)

        // Attribute Tag
        writer.Write(tag);
        writer.Write((ushort)24); // Content Size (24 bytes for 3 timestamps)

        // Write the timestamps (each 8 bytes)
        writer.Write(modifiedFileTime);
        writer.Write(accessFileTime);
        writer.Write(creationFileTime);

        return ms.ToArray();
    }
}

And voilà: the metadata is preserved as desired :-)

(Note: "Last Access" changes when opening the metadata dialog; before that, it’s correct 😉)

Datei-Erstellungs- und -Bearbeitungsdatum beim Download in einer ZIP-Datei beibehalten

Gabriel Weidmann — Wed, 12 Mar 2025 17:58:18 +0000

Im Rahmen eines aktuellen Projektes war es notwendig, dass beim Download von Dateien aus dem Browser das Erstellungsdatum und Bearbeitungsdatum erhalten bleiben. Das Standardverhalten von Browsern ist nämlich, beim Download beides auf die aktuelle Zeit zu setzen (einiges an Recherche hat ergeben, dass sich dieses Verhalten beim Download im Browser nicht praktikabel umgehen lässt).

Beispielsweise hier das Titelbild: Gerade erst heruntergeladen, aber sicherlich nicht gerade erst erstellt.

Ein Workaround war, die Dateien stets in ZIP-Dateien herunterzuladen und das Erstellungs- und Bearbeitungsdatum dort anzupassen. Unglücklicherweise ist in .NET und gängigen Bibliotheken stets nur das LastModifiedAt zur Änderung verfügbar. Scheinbar unterstützt der Standard nur diesen Wert.

Glücklicherweise unterstützt die ZIP-Definition aber ein NTFS-Extra-Feld:

   4.5.5 -NTFS Extra Field (0x000a):

      The following is the layout of the NTFS attributes 
      "extra" block. (Note: At this time the Mtime, Atime
      and Ctime values MAY be used on any WIN32 system.)  

      Note: all fields stored in Intel low-byte/high-byte order.

        Value      Size       Description
        -----      ----       -----------
(NTFS)  0x000a     2 bytes    Tag for this "extra" block type
        TSize      2 bytes    Size of the total "extra" block
        Reserved   4 bytes    Reserved for future use
        Tag1       2 bytes    NTFS attribute tag value #1
        Size1      2 bytes    Size of attribute #1, in bytes
        (var)      Size1      Attribute #1 data
         .
         .
         .
         TagN       2 bytes    NTFS attribute tag value #N
         SizeN      2 bytes    Size of attribute #N, in bytes
         (var)      SizeN      Attribute #N data

       For NTFS, values for Tag1 through TagN are as follows:
       (currently only one set of attributes is defined for NTFS)

         Tag        Size       Description
         -----      ----       -----------
         0x0001     2 bytes    Tag for attribute #1 
         Size1      2 bytes    Size of attribute #1, in bytes
         Mtime      8 bytes    File last modification time
         Atime      8 bytes    File last access time
         Ctime      8 bytes    File creation time

Mit diesem lassen sich weitere Werte mitgeben; eben genau die gewünschten Creation time und Last modification time.

Die Umsetzung ist nicht ganz straightforward.

braucht es eine ZIP-Bibliothek die das Schreiben dieses NTFS extra Feldes unterstützt. Hier bin ich auf SharpZipLib gestoßen. Wird zwar seit August 2023 nicht mehr aktualisiert, aber für eine serverseitige Pack-Logik passt es wunderbar.
braucht es den Code, um das Feld zu schreiben:

var zipMemoryStream = new System.IO.MemoryStream();

using var zipStream = new ZipOutputStream(zipMemoryStream)
{
    IsStreamOwner = false // Prevent from disposing the memory stream
};

var zipEntry = new ZipEntry(myFilename);

byte[] ntfsExtraData = CreateNtfsExtraField(
    creationTime: myDocument.CreatedAt,
    modifiedTime: myDocument.ChangedAt,
    lastAccessTime: myDocument.ChangedAt
);

zipEntry.ExtraData = ntfsExtraData;

zipStream.PutNextEntry(zipEntry);

await fileStream.CopyToAsync(zipStream, ct);

fileStream.Dispose();
...

private static byte[] CreateNtfsExtraField(DateTime creationTime, DateTime modifiedTime, DateTime lastAccessTime)
{
    // NTFS extra field structure:
    // [Header ID (2 bytes)][Data Size (2 bytes)][Reserved (4 bytes)][Tag (2 bytes)][Content Size (2 bytes)][Timestamps (24 bytes)]

    // Constants
    ushort headerId = 0x000A; // NTFS field
    ushort tag = 0x0001;      // Attribute Tag - "Standard information"

    // Time conversion: DateTime -> Windows FILETIME (ticks since 1601-01-01)
    long creationFileTime = creationTime.ToFileTimeUtc();
    long accessFileTime = lastAccessTime.ToFileTimeUtc();
    long modifiedFileTime = modifiedTime.ToFileTimeUtc();

    using (var ms = new MemoryStream())
    using (var writer = new BinaryWriter(ms))
    {
        // Write Header ID and Size Placeholder
        writer.Write(headerId);
        writer.Write((ushort)32); // Data Size: Reserved(4) + Tag(2) + Size(2) + 24 bytes

        writer.Write(0); // Reserved (4 bytes)

        // Attribute Tag
        writer.Write(tag);
        writer.Write((ushort)24); // Content Size (24 bytes for 3 timestamps)

        // Write the timestamps (each 8 bytes)
        writer.Write(modifiedFileTime);
        writer.Write(accessFileTime);
        writer.Write(creationFileTime);

        return ms.ToArray();
    }
}

Und voilà: Die Metadaten sind wie gewünscht :-)

(Hinweis: "Letzter Zugriff" ändert sich beim Öffnen des Metadaten-Dialogs; vorher passt es ;) )

Hallo RabbitMQ - 2. Routing

Gabriel Weidmann — Tue, 20 Dec 2022 08:22:29 +0000

Im nächsten Schritt geht es jetzt darum ein Gesamtkonzept für das aktuelle System zu finden. Dieses umfasst folgende Komponenten (abstrahiert):

Die UI-Applikation, über welche die Benutzer Daten anzeigen, erstellen, ändern und löschen können.
Eine Dokumenten-API, über welche Dokumente angelegt, gelöscht und bearbeitet werden können. Außerdem kann jedes Dokument 1-n Versionen enthalten
Ein Renderservice, der zu jeder Dokumentversion eine Vorschau rendert
Ein Backupservice, der die erste Version jedes Dokumentes nochmal extra wegspeichert
Ein Synchronisationsservice, der jede Dokumentänderung mit einem externen System synchronisiert

Aktuell unterteilen sich die Event-Producer und Consumer in folgende Gruppen:

Um diese Struktur umzusetzen, bietet RabbitMQ einige weitere Möglichkeiten an, um unsere Queues aus dem ersten Teil flexibler zu machen:

Routing

https://www.rabbitmq.com/tutorials/tutorial-four-dotnet.html

Für das Routing bietet RabbitMQ diverse Möglichkeiten an, um unsere Queues zu befüllen.

Direct exchange

Aus Teil 1 kennen wir ja bereits die Bindings mit dem RoutingKey. Direct exchange bedeutet also:

Finde alle Queues mit dem gleichen Key wie die Nachricht und schreibe sie dort hinein.

Es dürfen natürlich auch mehrere Queues mit demselben BindingKey vorhanden sein:

Topic Exchange

Topic Exchange ist ähnlich zum Direct exchange, bietet aber die Möglichkeit mehrere Kriterien zu verwenden.

Ein Topic ist ein Textwert der 1 oder mehrere durch . getrennte Wörter, sowie ggf. Platzhalter enthält. Ohne Platzhalter verhält sich Topic Exchange exakt wie Direct Exchange.

Es gibt nur zwei Platzhalter:

* (Stern) steht für genau 1 beliebiges Wort
# (Raute) steht für 0 bis n Wörter

Wir könnten also z.B. die Konvention einführen, dass Binding Keys folgendes Format haben müssen:

<Kontext>.<Aktion>.

Es wäre in unserem Fall also möglich z.B. die Topic version.created, sowie document.* zu verwenden.

Alle Änderungen an einem Dokument gelangen immer an die UI, damit diese sich ggf. aktualisieren kann
Alle neuen Versionen gehen an die Render-Queue, damit eine neue Vorschau gerendert wird

Wichtig:

Der Binding Key muss trotzdem genau gematched werden, sonst gibt es keinen Treffer. document oder document.created.today wären somit von obigen Filtern nicht erkannt.
# als Filter matched alles

Umsetzungsmöglichkeit

Fügen wir jetzt die Teile mit den neuen Möglichkeiten zusammen, könnte sich folgendes Bild ergeben.

Topics

document
- created
- restored
- deleted
- metadata_changed
- version.created
preview
- created
- failed

Beispielprojekt

Ich habe mal versucht das beispielhaft mit dem minimalen Setup umzusetzen. Das vollständige Projekt findet man hier: https://github.com/weidmanngabriel/rabbitmq_topics_poc

Man kann jetzt einfach auf der Kommandozeile eingeben welches Event die Dokument-API abschicken soll. Die Events verhalten sich dann so wie im obigen Bild definiert.

Mit diesem Wissen kommen wir schonmal ein ganzes Stück weiter. Im nächsten Teil können wir uns dann Details wie Sende- und Empfangsbestätigung, Callbacks, etc. ansehen.

Hallo RabbitMQ - 1. Die Basics

Gabriel Weidmann — Fri, 16 Dec 2022 16:11:17 +0000

Aktuell wage ich mich für ein Firmenprojekt RabbitMQ heran. Einfach gesagt ist RabbitMQ eine Serveranwendung über die Nachrichten zwischen verschiedenen Sendern und Empfängern ausgetauscht werden können. In diesem Post möchte ich meine kleine Reise vom absoluten Neuling bis ich das Ganze verstanden habe etwas dokumentieren.

Sehr hilfreich fand ich dabei dieses Tutorial: https://www.cloudamqp.com/blog/part1-rabbitmq-for-beginners-what-is-rabbitmq.html

Warum RabbitMQ?

Man sollte Code einfach schreiben und Programme einfach denken, denn kompliziert werden sie von alleine. Das habe ich - wie wohl jeder andere auch - in meiner Arbeit schon oft erlebt. Da auch in meinen aktuellen Projekten der Bedarf nach neuen Features hoch ist und immer mehr Teilsysteme dazukommen, haben wir uns im Team überlegt wie wir das gerne in Zukunft besser handhaben wollen. Dabei ist eine tolle Gesamtstruktur für die Projekte herausgekommen.

Herzstück der neuen Struktur sind einerseits eine schmale API für die Kernfunktionen des Produkts, andererseits eine einheitliche Kommunikation zwischen den Systemen über einen MessageBus.

Wir haben überlegt und evaluiert welcher MessageBus für uns in Frage kommt und RabbitMQ hat sich angeboten, da wir die Flexibilität in den Kommunikationswegen schätzen (In-Memory, TCP, Http) und vor allem da es ein etablierter Industriestandard ist und es so sehr viele Anleitungen, Tutorials und Problemlösungen zu allen gängigen Aufgabenstellungen und Problemen gibt.

Grundsätzlich erhoffen wir uns, dass unsere Infrastruktur weiter wachsen kann, ohne dass die Komplexität allzu stark zunimmt, indem wir Teilbereiche entkoppeln, Domainwissen und -daten an zentralen Stellen anbieten und die einzelnen Bausteine überschaubar halten.

Coole Features von RabbitMQ

Eine Queue kann von mehreren Konsumenten abgearbeitet werden, oder es können verschiedene Queues für beliebig viele Konsumenten identisch befüllt werden. Das ermöglicht z.B. ein asynchrones Abarbeiten von Renderaufträgen.
Wie bereits erwähnt kann man seine RabbitMQ sogar rein In-Memory (z.B. mit Mediator) aufsetzen
RabbitMQ ist super schnell
Durch Plugins erweiterbar (z.B. UI-Manager, Streams)

Installation mit dem Windows Installer

Hinweis: XXX steht für irgendeine Versionsnummer.

Erlang (Programmiersprache) installieren: https://www.erlang.org/downloads
a. Unbedingt als Admin installieren
b. Benötigt einen PC Neustart
RabbitMQ herunterladen und installieren: https://github.com/rabbitmq/rabbitmq-server/releases (rabbitmq-server-XXX.exe
)
a. Anleitung hier: https://www.rabbitmq.com/install-windows.html
b. Ebenfalls als Admin installieren
RabbitMQ UI aktivieren
a. RabbitMQ Command Prompt öffnen -> Ordner ist ...\RabbitMQ Server\rabbitmq_server-XXX\sbin
b. Befehl ausführen: rabbitmq-plugins enable rabbitmq_management
c. Service neu starten mit rabbitmq-service.bat stop und anschließend rabbitmq-service.bat start
d. Nach ca. 1 Minute ist die UI nun unter http://localhost:15672 erreichbar. Benutzer: guest, Passwort: guest
Remotezugriff aktivieren
a. Tab Admin in der UI öffnen
b. Einen neuen Benutzer hinzufügen. Wichtig: Tag muss administrator sein.
c.
d. Jetzt muss man noch dem Admin-Benutzer die Berechtigung zum Zugriff geben. Dazu auf den Namen klicken und einfach die voreingestellten Berechtigungen hinzufügen
e.
f. Remotezugriff mit diesem Benutzer ist jetzt möglich. Dazu Serverurl/15627 aufrufen, z.B. http://localhost:15672/

Grundkonzept

Auf TryRabbitMQ kann man sehr schön sehen wie sich RabbitMQ in den Grundzügen verhält:

Die Message

Eine Message ist ein Bytestream der irgendwie versendet wird. Das kann natürlich ein konvertierter String, oder ein Objekt im JSON-Format sein. Die Nachricht interessiert sich nicht für das Transportmittel, sondern kapselt nur ihre Informationen.

Wichtig ist, dass eine Message Metadaten wie z.B. einen Binding-Key enthalten kann, der als Routing-Information im Exchange genutzt werden kann.

Der Producer

Ein Producer ist irgendein Client der eine Nachricht an den Server übermittelt.

Die Connection

Es wird in den meisten Setups eine TCP-Verbindung zwischen Client und Server aufgebaut. Als Faustregel gilt: Jede Applikation sollte nur 1 Connection offen haben, da diese ressorcenintensiv sind.

Der Channel

Je Connection können mehrere Channels angelegt werden, über die der Client mit dem Server kommunizieren kann. Als Faustregel gilt hier, dass jeder Task seinen eigenen Task haben sollte, da diese üblicherweise nicht Multithreading-sicher implementiert sind.

Alle offenen Channel schließen sich automatisch, wenn die Connection geschlossen wird.

Der Broker

Der Broker ist der Nachrichtenserver in seiner Gesamtheit. Das kann ein richtiger Server sein, oder auch "nur" eine In-Memory Routing-Klasse.

Der Exchange

Der Exchange hat die Aufgabe die empfangenen Nachrichten den richtigen Queues zuzuordnen. Dazu hat er verschiedene Grundkonfigurationen:

Direct: Die Message wird nur an Queues weitergeleitet deren Binding-Key exakt dem der Nachricht entspricht
Fanout: Die Message wird an alle verbundenen Queues weitergeleitet, ganz unabhängig vom Binding-Key
Topic: Benutzt Wildcards, um ein Pattern-Matching durchzuführen
Headers: Spezialfall bei dem die Message-Header fürs Routing genutzt werden

Die Queue

Ein Buffer der Nachrichten zwischenspeichert. Hierbei gilt im allgemeinen FIFO. Es gibt aber auch z.B. die Möglichkeit einer Priorisierung.

Wichtig ist zu wissen, dass jede Nachricht nur 1x aus der Queue geholt werden kann (es sei denn das Abholen läuft auf ein Timeout hinaus, dann wir Requeued). D.h. wenn mehrere Consumer auf dieselbe Queue zugreifen, wird jede Nachricht nur an genau 1 Consumer weitergereicht. Möchte man eine Nachricht an mehrere Consumer verteilen, benötigt jeder Consumer seine eigene Queue in welche die Nachricht jeweils dupliziert wird.

Der Consumer

Ein oder mehrere Consumer fordern die Daten von der Queue an. Sobald eine Nachricht erhalten wurde (Standard), bzw. bestätigt wurde, wird sie aus der Queue gelöscht. Bis dahin ist sie für andere Konsumenten unsichtbar.

Mehr ...

Das sind nur die absoluten Basics, es gibt diverse Einstellungen und Möglichkeiten. Es empfiehlt sich einerseits die Tutorials zu machen, andererseits die Dokumentation zu studieren. Hier werden viele Fragen gut erklärt.

Das RabbitMQ Management Interface

Das Interface hilft dabei zu verstehen wie die Producer, Exchanges, Queues und Consumer zusammenarbeiten ... oder auch nicht arbeiten. Es ist im allgemeinen unter http://localhost:15672/, bzw. mit dem Servernamen erreichbar.

Es ist gut zu wissen, dass man über Queues auch von hier aus Exchanges und Queues anlegen kann. Das geht auch über den Code, aber wahrscheinlich macht es am meisten Sinn alle dauerhaften Dinge hierüber einzurichten und alles weitere bei Bedarf über den Code.

Das Ganze habe ich mir noch nicht in der Tiefe angeschaut. Interessant könnten aber z.B. die User und Virtual Hosts sein. Damit sollte es möglich sein abgegrenzte Bereiche zu definieren in denen Benutzern Lese- und Schreibrechte vergeben werden können. Ist aber zum jetzigen Zeitpunkt noch nicht relevant.

Für mehr Infos empfehle ich den Folgepost (zu dem oben) von cloudamqp: https://www.cloudamqp.com/blog/part3-rabbitmq-for-beginners_the-management-interface.html

Basic Setup

1. Die Connection einrichten

var factory = new ConnectionFactory()
{
    HostName = "http://localhost:15672/",
    VirtualHost = "/",
    UserName = "guest",
    Password = "guest",
};

var connection = factory.CreateConnection();

Hinweis: Wie bereits erwähnt sollte es nur 1 Connection je Applikation geben. Sie kann also z.B. als Singleton deklariert werden, wenn man DI nutzt.

2. Den Channel öffnen

var channel = connection.CreateModel();

Hinweis: Empfehlung ist 1 Channel je Task.

3. Eine Queue deklarieren

channel.QueueDeclare(
    queue: "letterbox",
    durable: false,
    exclusive: false,
    autoDelete: false,
    arguments: null);

Hier gibt es viel zu erklären:

queue: Der Name der Queue. Wird er leergelassen, wird der Name vom Server generiert
durable: Soll die Queue auf die Platte gespiegelt werden, damit im Falle eines Serverneustarts die Daten nicht verloren sind? Bei false wird alles nur im RAM gehalten.
exclusive: Die Queue wird gelöscht, wenn die einzige Connection mit Zugriff darauf geschlossen wird
autoDelete: Die Queue wird gelöscht, sobald es keinen aktiven Konsumenten mehr gibt
arguments: Weitere Features und Plugins nutzen diese

Wie weiter oben beschrieben halte ich es durchaus für sinnvoll, wenn man dauerhafte Queues über das Admin-Interface definiert. Es ist aber sehr cool, wenn ein Service z.B. eine exklusive Queue mit einem BindingKey anlegt und alle neuen Nachrichten dann immer auch in diese Queue geschrieben werden. Wird der Service dann gestoppt, verschwindet die Queue auch sofort wieder mitsamt der Daten.

4. Eine Nachricht versenden

var message = "This is my message number " + i++;

var body = Encoding.UTF8.GetBytes(message);

channel.BasicPublish("", "letterbox", null, body);

Der erste Wert wäre der Name des Exchange den man ansprechen will. Mit Leerstring wird der Default-Exchange verwendet.
letterbox ist der Name des Routings, bzw. in dem Fall der Queue
Der body ist ein Byte-Array oder -Stream

5. Die Nachricht empfangen

var consumer = new EventingBasicConsumer(channel);

channel.BasicConsume(
    queue: "letterbox",
    autoAck: true, // Nachricht aus der Queue löschen, sobald sie erhalten wurde
    consumer: consumer
);

consumer.Received += (model, ea) =>
{
    var body = ea.Body.ToArray();
    var message = Encoding.UTF8.GetString(body);
    Console.WriteLine($"Nachricht erhalten: {message}");
};

Praktische Anwendungsszenarien

Dokument-Rendition

Eine Anforderung ist, dass alle eingestellten Dokumente automatisch eine Vorschau gerendert bekommen. Der Aufbau mit der Queue könnte so aussehen:

An einer Stelle im System (in diesem Fall der DocumentService) wird ein neues Dokument eingestellt
Eine Nachricht mit den Dokument-Metadaten (z.B. Id, Speicherort) wird an den Broker geschickt
Der Exchange leitet die Nachricht an die Queue weiter, wenn sie den Tag rendition-task gesetzt hat.
Ein RenditionWorker kann sich den Task aus der Queue ziehen, sobald er Kapazität hat

UI-Aktualisierung

Eine weitere Anforderung ist, dass sich alle Ansichten aktualisieren müssen, in denen das Dokument zu sehen sein wird. Das könnte dann so aussehen:

Der Service benachrichtigt über document-changed
Jede Queue die den Key hinterlegt hat, bekommt die Nachricht
Die renditionQueue gibt die Nachricht nur an 1 ServiceWorker
Jede der uiNotifQueues bekommt eine eigene Nachrichtenkopie
Die Nachricht wird an den jeweiligen Consumer weitergeleitet. Auf diese Weise könnten auch 100te Consumer ihre jeweils eigene (temporäre!) Queue eröffnen

Soweit mal zu den Basics. Ich denke, dass man damit schon einiges anfangen kann. Im nächsten Teil werde ich dann mehr in die Details reinschauen.

Show local webpage in Xamarin.Forms WebView

Gabriel Weidmann — Wed, 01 Dec 2021 09:48:19 +0000

A local webpage extracted from an online webpage that runs on HTML, CSS and JavaScript.

For my current mobile app project I needed to embed the field map from an website into my field management mobile app. Here you can see how it looks at the end of the process on both platforms:

Complex layouts and functions are often a problem in Xamarin.Forms … but they are great when they finally work 😇

There were multiple problems on the way:

The webpage is running on HTML, CSS and JavaScript and executing custom code. We didn’t want to rewrite it in parallel in the web and the app, but to reuse the code.

So we shrinked down the web version to a local standalone page running in the webbrowser that can be displayed by simple opening the index.html file. For displaying it we would need to open the index file with the Xamarin.Forms WebView and make it load the other files.

The webview is not easy to understand, because it’s cross-plattform but uses the native controls on each. It was hard to get it working on Android, but I didn’t make it on iOS.

It didn’t want to load the files from the assets, so I placed them in the shared project, set them as “Embedded Resource”, copied them at runtime to a sub folder in the cache and set this as the base path. Then I would load the index.html directly.

When the files are copied to [CacheDirectory]/Resources/AckerMap I set this directory as the base for the webview to search the other files referenced.

I got it working on android, but iOS was crashing and I still don’t know why.

So I was trying something else: If the webview doesn’t want to load additional files correctly, why not put everything into a single file? After a short search I found the Inliner tool. It takes your webpage and tries to combine all of the assets in a single file.

From Github

So I made sure my webpage runs well in my local browser and then used this tool to create the single file. It’s quite easy:

Install the tool over NPM

Just specify the base html file of your webpage and the output file.

And the output tells me everything is alright :-)

At last I just needed to put the file in my project, set it as “Embedded Resource” and load it directly:

And now 🥳 it works out of the box on Android & iOS 🎉💯

Have a nice day 😉