Migration von Legacy-Dokumentanzeige‑Lösungen zu modernen Low‑Footprint‑SDKs
← Back to Blog7 min read

Migration von Legacy-Dokumentanzeige‑Lösungen zu modernen Low‑Footprint‑SDKs

Der schnellste Weg zu einem modernen, sicheren und responsiven Dokumenten‑Viewer besteht darin, Legacy‑Komponenten durch Doconut’s Low‑Footprint‑SDK zu ersetzen. Für Web‑Portale, die Kendo UI nutzen, bietet das SDK schnelles Rendering, volle Barrierefreiheit und einen fokussierten Integrationspfad. Unternehmen, die einst eigens entwickelte Viewer auf Basis von Desktop‑Only‑Bibliotheken oder externen Konvertierungsdiensten zusammengebastelt haben, stoßen schnell an Grenzen: Wartungskosten steigen, clientseitige Abhängigkeiten werden fragil und die Barrierefreiheit bleibt auf der Strecke. Doconut beseitigt diese Hürden, indem es native PDF‑, Office‑ und CAD‑Renderings direkt aus einem .NET‑Backend bereitstellt, während das Front‑End leichtgewichtig und vollständig unter Ihrer Kontrolle bleibt.

In den nächsten Abschnitten schauen wir uns an, warum altmodische Viewer zu Haftungsfallen werden, wie Doconut’s Architektur diese Schmerzpunkte adressiert und welchen praxisnahen Migrations‑Fahrplan Sie sofort einsetzen können.

Migration von einem abhängigen Legacy‑Viewer zu einem sicheren serverseitigen Dokumenten‑Viewer
Migration von einem abhängigen Legacy‑Viewer zu einem sicheren serverseitigen Dokumenten‑Viewer

1. Legacy‑Viewer: Versteckte Kosten hinter vertrauten Oberflächen

Die meisten „Legacy“-Dokumenten‑Viewer entstanden, als Browser noch stark auf Plug‑Ins, ActiveX‑Steuerelemente oder sperrige Office‑Installationen auf dem Server setzten. Die Folgen zeigen sich auf verschiedene Weise:

ProblemReal‑welt‑Auswirkung
Client‑seitige AbhängigkeitenNutzer müssen Browser‑Plug‑Ins installieren oder aktivieren; die Unternehmens‑IT blockiert sie häufig, was den Arbeitsablauf unterbricht.
Server‑seitige Office‑AnforderungenDie Installation von Microsoft Office auf einem Web‑Server verletzt bewährte Sicherheitspraktiken und erhöht Lizenzkosten.
Begrenzte FormatunterstützungNeue CAD‑ oder Bildformate (DWG, DXF, PNG) werden nicht unterstützt, was Work‑arounds oder manuelle Konvertierungen erzwingt.
SkalierbarkeitsengpässeDas Rendering läuft auf der Client‑CPU; große PDFs oder mehrseitige Office‑Dateien führen zu Langsamkeit und Abstürzen.
BarrierefreiheitslückenTastaturnavigation, Screen‑Reader‑Unterstützung und WCAG‑Konformität sind oft nachträgliche Überlegungen, die Unternehmen Compliance‑Risiken aussetzen.
WartungsalptraumSDK‑Anbieter, die nicht mehr aktualisiert werden, werden zu Sicherheitsrisiken, und jedes Patchen erfordert eine vollständige Neu‑Bereitstellung.

Fügen Sie diese versteckten Kosten zu einem dokumentenzentrierten System hinzu – sei es ein DMS, ein CRM‑Portal oder eine E‑Learning‑Plattform – und die Rendite verschwindet schnell. Moderne Unternehmen benötigen einen Viewer, der nicht von Client‑Plug‑Ins abhängt, ohne Office auskommt und serverseitig skalierbar ist. Doconut gibt Ihnen genau das.


2. Low‑Footprint, Server‑Side Rendering: Der ideale PDF‑Viewer‑SDK für moderne Apps

Doconut’s Kernstärke liegt in seiner serverseitigen Dokumenten‑Rendering‑Engine, die Raster‑Bilder an den Browser streamt und damit jede Notwendigkeit für ein clientseitiges Plugin eliminiert. So passt die Architektur zu den oben genannten Herausforderungen:

a. Minimaler Client‑Footprint für den Browser

  • Der Viewer liefert nur HTML, CSS und ein winziges Stück JavaScript. Kein ActiveX, kein Flash, kein Silverlight — nur standardisierte Web‑Assets, die an unterstützte Browser ausgeliefert werden.
  • Da das Rendering auf dem Server erfolgt, benötigt der Client niemals .NET Desktop, Office oder einen installierten CAD‑Viewer.

b. Umfassende Formatabdeckung

Doconut unterstützt nativ 33+ Formate aus den Bereichen Office, PDF, CAD, E‑Mail und Bild – darunter DOC/DOCX, XLS/XLSX, PPT/PPTX, DWG, DXF, PNG, JPG und mehr. Das eliminiert die „Dateityp‑Lücke“, die Entwickler sonst zu einem Flickenteppich aus Drittanbieter‑Konvertern zwingt.

c. Eingebaute Annotation, Suche und kontrollierter Druck

  • Annotation‑Plugin – Highlights, Kommentare oder Freihand‑Zeichnungen direkt im Viewer hinzufügen.
  • Search‑Plugin – Sofortige Textsuche im gesamten Dokument, mit OCR für gescannte Bilder.
  • Controlled Printing – Druckrichtlinien über die Viewer‑UI durchsetzen und unautorisierte Kopien verhindern.

d. Server‑Side‑Conversion für Office‑freie Workflows

Das Converter‑Plugin wandelt Word-, Excel‑, PowerPoint‑ und CAD‑Dateien serverseitig in PDF, PNG oder HTML um. Keine Microsoft‑Office‑Installation, kein externer SaaS‑Dienst und keine Daten verlassen je Ihre Firewall.

e. Barrierefreiheit von Haus aus

Doconut folgt WCAG 2.2 AA‑Richtlinien out‑of‑the‑box — Tastaturnavigation, ARIA‑Labels und screen‑reader‑freundliches Markup sind fest in das HTML des Viewers integriert. Die Erfüllung unternehmensinterner Barrierefreiheits‑Policies wird damit zu einem Schalter‑Klick statt zu einer Eigenentwicklung.

f. Nahtlose Integration in moderne .NET‑Stacks

Egal, ob Sie ASP.NET Core, .NET 6 oder eine Micro‑Service‑Architektur nutzen, Doconut lässt sich mit einem einzigen Middleware‑Aufruf in die Request‑Pipeline einbinden. Der Viewer kann problemlos mit Kendo UI‑Komponenten oder einem unterstützten Web‑Frontend kombiniert werden.


3. Migrations‑Blueprint: Von Legacy zu Doconut

Im Folgenden finden Sie einen pragmatischen, schrittweisen Migrationsplan, den Sie in einer bestehenden .NET‑Web‑Applikation umsetzen können. Ziel ist es, den alten Viewer durch Doconut zu ersetzen und dabei die öffentliche API für nachgelagerte Verbraucher stabil zu halten.

Schritt 1: Umgebung vorbereiten

  1. Das Doconut‑NuGet‑Paket zum Projekt hinzufügen.
  2. Sicherstellen, dass der Server .NET 6 (oder höher) ausführt; Doconut’s Optimierer für Abhängigkeiten entfaltet sein volles Potenzial mit der neuesten Runtime.

Schritt 2: Doconut‑Middleware registrieren

Die Doconut‑Middleware früh in der ASP.NET‑Request‑Pipeline einfügen, sodass Anfragen für gerenderte Dokumenten‑Bilder abgefangen und von Doconut’s Engine verarbeitet werden.

Schritt 3: Lizenz laden

Beim Anwendungsstart die Doconut‑Lizenzdatei (oder XML‑Dokument) einmalig laden. Falls Sie plugin‑spezifische Lizenzen besitzen (z. B. für das Annotation‑Plugin), diese über die entsprechende Doconut‑API einbinden.

Schritt 4: Alte Rendering‑Aufrufe ersetzen

Stellen Sie fest, wo Legacy‑Code eine Dokumentenseite in ein Bitmap oder Byte‑Array rendert. Ersetzen Sie diese Aufrufe durch Doconut’s Dokument‑Öffnen‑Flow, der ein Token zurückgibt, das das geöffnete Dokument repräsentiert. Mit diesem Token können Sie Seiten‑Bilder oder Thumbnails über Doconut’s Bild‑Servicing‑Endpoints anfordern.

Schritt 5: Annotationen und Suche aktivieren

Bestehende „Kommentar hinzufügen“‑ oder „Suche“‑Funktionalitäten auf Doconut's Annotation‑ bzw. Search‑Plugins abbilden. Beide Plugins stellen einfache serverseitige Methoden bereit, die JSON‑Payloads zurückliefern, die Ihr Front‑End konsumieren kann.

Schritt 6: Front‑End‑Integration aktualisieren

Da Doconut gerenderte Bilder streamt, benötigt das Front‑End lediglich ein <img>‑Tag pro Seite oder einen Canvas‑basierten Viewer. Für Kendo UI binden Sie die Bild‑URLs an ein Kendo‑Carousel für flüssiges Blättern.

Schritt 7: Testen, Optimieren, Deployen

  • Performance – Zeit bis zur ersten Seite messen; Doconut’s serverseitiges Raster‑Rendering liefert typischerweise Unter‑Sekunden‑Ergebnisse für gängige PDFs.
  • Sicherheit – prüfen, dass keine Dokumentendaten über die gerenderten Bilder hinaus an den Client gelangen.
  • Barrierefreiheit – einen Screen‑Reader‑Audit durchführen; Doconut’s Markup enthält bereits die notwendigen ARIA‑Rollen.

Wenn die Test‑Suite bestanden ist, den Legacy‑Viewer‑Route durch den neuen Doconut‑Endpoint ersetzen und das Update ausrollen.


4. Barrierefreiheit und UX mit Doconut und Kendo UI stärken

Barrierefreiheit ist kein Nice‑to‑Have mehr; sie ist in vielen regulierten Branchen (Gesundheitswesen, Finanzen, öffentlicher Sektor) Pflicht. Doconut’s sofortige Konformität hilft Ihnen, diese Standards zu erfüllen, ohne eigenen Code zu schreiben.

Tastaturnavigation

Jedes interaktive Element — Seitennavigation, Zoom‑Steuerungen, Annotation‑Tools — verfügt über standardisierte tabindex‑Attribute. Nutzer können das Dokument ausschließlich mit der Tastatur durchlaufen, ein Muss für Section 508‑Konformität.

ARIA‑Labels und Screen‑Reader

Der Viewer‑HTML‑Code enthält role="document" und beschreibende aria-label‑Attribute, die Seitenzahlen und Zoom‑Stufe an assistive Technologien übermitteln. Keine zusätzlichen ARIA‑Skripte nötig.

Hochkontrast‑Modus

Doconut kann die im Viewer‑Interface eingestellten Hochkontrast‑Präferenzen übernehmen. Die UI wechselt in ein dunkles‑auf‑helles Schema und hält die Lesbarkeit für sehbehinderte Nutzer scharf.

Integration mit Kendo UI

Kendo UI’s barrierefreie Widgets (z. B. kendoButton, kendoSlider) lassen sich nahtlos über Doconut’s Bild‑Rendering legen. Das Ergebnis: ein durchgängig tastatur‑navigierbarer Viewer, der sich wie ein integraler Bestandteil Ihrer Anwendung anfühlt.


5. Zukunftssicherheit: Erweiterung des Viewers mit Plugins

Doconut’s modulare Plugin‑Architektur bedeutet, dass Sie zunächst mit Basis‑Viewing starten und später weitere Funktionen aktivieren können, wenn geschäftliche Anforderungen wachsen.

PluginKernvorteilTypischer Unternehmenseinsatz
Annotation PluginHervorheben, kommentieren, zeichnenRechtsprüfung, Konstruktionsänderungen
Search PluginVolltext‑ und OCR‑gestützte SucheGesundheits‑Datensatz‑Lookup, Finanz‑Audit
Converter PluginServer‑seitige Office → PDF/HTMLDMS‑Ingest‑Pipelines, automatisierte Berichte
Controlled PrintingDruckquoten, WasserzeichenVertrauliche Verträge, regulierte Einreichungen

Da alle Plugins serverseitig laufen, behalten Sie zentrale Kontrolle über Datenverarbeitung, Lizenzierung und Skalierung. Ein neues Plugin zu aktivieren bedeutet lediglich, dessen Lizenz zu laden und die passende API aufzurufen — keine Neu‑Kompilierung des Front‑Ends nötig.


Fazit

Die Modernisierung Ihres Dokumenten‑Viewer‑Stacks muss kein kostspieliger, riskanter Umbau sein. Durch die Einführung von Doconut’s Low‑Footprint‑, serverseitigem Rendering‑Engine erhalten Sie:

  • Breite Formatunterstützung ohne externe Konverter.
  • Eingebaute Annotation, Suche und kontrollierten Druck, die Compliance‑Anforderungen erfüllen.
  • Unternehmens‑grade Barrierefreiheit sofort einsatzbereit.
  • Reibungslose Integration in bestehende .NET‑ und Kendo UI‑Projekte.

Bereit, Legacy‑Viewer abzuschaffen und Ihren Nutzern ein schnelleres, sichereres Erlebnis zu bieten? Starten Sie noch heute Ihre Migration mit Doconut – SDK herunterladen, den Migrations‑Blueprint befolgen und den Unterschied bereits nach wenigen Minuten erleben.

#document rendering#PDF Viewer SDK#legacy migration#enterprise .NET#Doconut#Dokument‑Rendering#PDF‑Viewer‑SDK#Legacy‑Migration