Anstatt unvorhersehbaren Rohtext zu erzeugen, erzwingt unsere Anwendung garantierte Datenschemata (title, body und seoKeywords), Echtzeit-Fortschritts-Feedback via SSE-Streaming und drei unterschiedliche Perspektiven, die auf bestimmte Zielgruppen zugeschnitten sind: Friendly SaaS Marketer, Technical Blogger und Skeptical CFO.

Next.js (TypeScript) → FastAPI → Azure Content Safety (Guardrails)
                                      ↓
                               Azure OpenAI (GPT-4.1 / Structured Outputs)
                                      ↓
                               Server-Sent Events (SSE-Stream)
                                      ↓
                               3 Persona-Variationen (Title, Body, SEO Keywords)

Voraussetzungen

• Python und Node.js müssen auf Ihrem Computer installiert sein.
• Eine Azure-OpenAI-Ressource mit einem bereitgestellten Modell (z. B. GPT-4.1-mini oder GPT-4o).
• Eine Azure-Content-Safety-Ressource.
• Grundkenntnisse in FastAPI, Next.js und TypeScript.
• Grundlegendes Verständnis von Server-Sent Events (SSE) und Pydantic-Schemas.

Schritt 1: Pydantic-Schema definieren

Zunächst definieren wir die Struktur, die unsere Anwendung vom Modell erwartet. Dazu erstellen wir Pydantic-Modelle für die einzelnen Variationen und den übergeordneten Antwort-Container:

class Variation(BaseModel):
    id: int
    title: str
    body: str
    seoKeywords: list[str] = Field(default_factory=list)

class ResultSchema(BaseModel):
    variations: list[Variation]

Dieses Schema fungiert als doppelter Vertrag: Es garantiert die Struktur unserer Backend-API-Antworten für das Next.js-Frontend und wird direkt an die Structured-Outputs-Engine von Azure OpenAI übergeben um das JSON-Schema des Modells strikt einzuschränken.

Schritt 2: Persona-System-Prompts implementieren

Marketingtexte erfordern je nach Kanal und Zielgruppe unterschiedliche Tonalitäten. In unserer Anwendung definieren wir drei System-Prompts:

PERSONAS = {
    „friendly“: {
        „name“: „Friendly SaaS Marketer“,
        „system“: (
            „You are a friendly SaaS marketer. „
            „Write in a warm, benefit-led, conversational tone. „
            „Prefer short sentences and a clear call to action.“
        ),
    },
    „technical“: {
        „name“: „Technical Blogger“,
        „system“: (
            „You are a technical blogger. „
            „Write in a precise, credible, educational tone. „
            „Include concrete details, trade-offs, and one practical tip.“
        ),
    },
    „cfo“: {
        „name“: „Skeptical CFO“,
        „system“: (
            „You are a skeptical CFO. „
            „Write in a direct, evidence-driven, ROI-focused tone. „
            „Quantify impact where possible and flag risks explicitly.“
        ),
    },
}

Sobald eine Anfrage eingeht, kombiniert das Backend den ausgewählten Persona-System-Prompt dynamisch mit den Benutzeranweisungen, die das Briefing, die Zielgruppe, das Format (LinkedIn-Post, Marketing-E-Mail oder Landingpage-Text) und die Ausgabesprache enthalten.

Schritt 3: Content-Moderation mit Azure Content Safety

Bevor das Sprachmodell aufgerufen wird, validiert das Backend das Briefing mit Azure Content Safety. Dadurch werden schädliche Eingaben in Kategorien wie Gewalt, Hassrede, Selbstverletzung und sexuelle Inhalte erkannt:

response = content_safety_client.analyze_text(
    AnalyzeTextOptions(text=req.brief)
)
is_safe = all(item.severity < 2 for item in response.categories_analysis)

Werden schädliche Inhalte erkannt, gibt die API ein strukturiertes 400 Bad Request mit detaillierten Kategorieangaben zurück. Dies verhindert Prompt-Injections und Missbrauch und spart gleichzeitig Token-Kosten bei blockierten Prompts. Als Fallback steht zudem eine lokale Heuristik bereit.

Schritt 4: Echtzeit-SSE-Streaming und inkrementelles Parsing

Die Generierung von drei vollständigen Marketing-Variationen dauert einige Sekunden. Anstatt den Benutzer auf die gesamte Antwort warten zu lassen, nutzen wir Server-Sent Events (SSE) über die StreamingResponse von FastAPI:

@app.post(„/generate/stream“)
def generate_stream(req: GenerateRequest):
    def events():
        yield _sse_event(„safety“, {„safe“: True})
        yield _sse_event(„start“, {„request_id“: request_id})
        with client.responses.stream(
            model=DEPLOYMENT,
            instructions=system,
            input=user_prompt,
            text_format=ResultSchema,
        ) as stream:
            for event in stream:
                if event.type == „response.output_text.delta“:
                    yield _sse_event(„delta“, {„text“: event.delta})
                    # Inkrementell abgeschlossene JSON-Variation-Objekte extrahieren
                    for v in _complete_variations_from_json(accumulated_text):
                        yield _sse_event(„variation“, {„variation“: v.dict()})
    return StreamingResponse(events(), media_type=“text/event-stream“)

Der Streaming-Generator parst die JSON-Chunks in Echtzeit. Sobald die schließende Klammer einer Variation erreicht ist, wird ein variation-SSE-Event gesendet. Dadurch kann das Next.js-Frontend jede Content-Karte sofort rendern, sobald sie fertiggestellt ist, was eine schnelle und reaktionsfreudige Benutzeroberfläche ermöglicht.

Schritt 5: FastAPI und Next.js mit Observability verbinden

Das Next.js-Frontend verbindet sich direkt über Standard-fetch mit dem FastAPI-Stream und liest die Datenblöcke mit einem ReadableStreamDefaultReader. Es rendert den Live-Fortschritt, zeigt Persona-Badges an und unterstützt sofortiges Kopieren, eine JSON-Ansicht und den Datei-Export. Zusätzlich erfasst jede Anfrage umfassende Observability-Daten:

• Latenz in Millisekunden.
• Prompt-, Completion- und Gesamt-Token-Verbrauch.
• Geschätzte Ausführungskosten basierend auf den Azure-OpenAI-Token-Preisen.
• Pro-Client-Generierungsprotokolle, die in SQLite und im Arbeitsspeicher gespeichert werden.

Warum Personas und Structured Outputs wichtig sind

Ohne Persona-Steuerung und Structured Outputs neigen KI-Antworten dazu, generisch, unvorhersehbar und in Produktionsanwendungen schwer zu parsen zu sein. Die Kombination aus expliziten Persona-Anweisungen und Pydantic-Schemas liefert vorhersehbare, hochwertige Ergebnisse, die direkt auf reale Marketing-Workflows zugeschnitten sind.

• Das Frontend erhält ein garantiertes, typsicheres Datenschema.
• Im Anwendungscode ist kein Entfernen von Markdown-Codeblöcken oder Regex-Parsing nötig.
• Personas sorgen für eine konsistente Markenstimme und klare Positionierung.
• Streaming eliminiert die wahrgenommene Wartezeit und verbessert die Benutzererfahrung.

Fazit

Mit Next.js, FastAPI, Azure OpenAI und Azure Content Safety haben wir eine End-to-End-Content-Generierungsanwendung mit unternehmensweiten Guardrails und Echtzeit-Streaming entwickelt.

FastAPI-Backend      → Steuert Sicherheitsprüfungen, Persona-Mapping, Streaming und Token-Logs
Azure OpenAI         → Liefert strukturierte, Persona-gesteuerte Generierung über GPT-4.1
Azure Content Safety → Blockiert schädliche Prompts vor der Ausführung
Next.js-Frontend     → Bietet eine reaktive, mehrsprachige UI mit Live-SSE-Karten-Rendering

Diese Kombination verwandelt generative KI von einem unvorhersehbaren Chat-Experiment in eine verlässliche, produktionsreife Content-Engineering-Pipeline.

Ich hoffe, dieses kurze Tutorial war hilfreich.

Now let’s code!

The post Strukturierte Multi-Persona-Content-Generierung mit Azure OpenAI und SSE-Streaming appeared first on Rhein-Ruhr-Informatik.

Anstatt für jede Aufgabe einen separaten Service zu verwenden, können wir ein Bild zusammen mit unseren Anweisungen an das Modell senden und beispielsweise eine Beschreibung, Tags, erkannte Objekte und OCR-Text extrahieren.

Der wichtige Punkt dabei ist: Die Antwort der KI soll nicht einfach ein beliebiger Text sein. Unsere Anwendung benötigt eine definierte Datenstruktur. Dafür verwenden wir JSON Schema mit Pydantic.

Voraussetzungen

• Python muss auf Ihrem Computer installiert sein.
• Ein Azure OpenAI Deployment mit GPT-4.1-mini muss vorhanden sein.
• Grundkenntnisse in Python und FastAPI.
• Grundkenntnisse in REST APIs und JSON.
• Ein Azure OpenAI Client muss im Backend eingerichtet sein.

Schritt 1: Pydantic-Schema definieren

Zuerst definieren wir mit Pydantic die Struktur, die unsere Anwendung von der KI erwartet:

Diese Klasse definiert gleichzeitig den Vertrag für unsere Anwendung und das Schema für die strukturierte Antwort des Modells. Dadurch müssen wir das JSON Schema nicht manuell als Dictionary erstellen.

Schritt 2: Bild und Prompt an das Modell senden

Das Bild wird im Backend eingelesen und anschließend als Base64 Data URL an das Modell übergeben.

Zusätzlich senden wir einen Prompt, der beschreibt, welche Informationen aus dem Bild extrahiert werden sollen. Zum Beispiel:

Der Benutzer sieht dabei nur die Upload-Funktion. Die eigentlichen Anweisungen zur Bildanalyse bleiben im Backend.

Schritt 3: Structured Outputs verwenden

Jetzt kommt der wichtige Teil. Anstatt das Modell einfach aufzufordern, JSON zurückzugeben, verwenden wir Structured Outputs:

Mit text_format=AnalysisResult verwenden wir unsere Pydantic-Klasse als Schema für die Antwort.

Das Modell erhält dadurch eine definierte Struktur und unser Backend kann das Ergebnis direkt als AnalysisResult verwenden:

Wir müssen also nicht mehr selbst versuchen, Markdown-Codeblöcke zu entfernen oder den zurückgegebenen Text manuell in JSON umzuwandeln.

Schritt 4: Ergebnis an das Frontend zurückgeben

Da unser FastAPI-Endpunkt ebenfalls AnalysisResult verwendet, können wir das Ergebnis direkt zurückgeben:

Das Frontend erhält anschließend eine vorhersehbare Struktur:

Warum Structured Outputs?

Ein einfacher Prompt wie „Antworte nur mit JSON“ kann funktionieren, ist aber kein idealer Vertrag zwischen einer KI und einer Anwendung.

Mit Structured Outputs definieren wir die erwartete Struktur explizit.

Das bringt einige Vorteile:

• Das Backend erhält eine vorhersehbare Datenstruktur.
• Das Pydantic-Modell kann gleichzeitig für die API und das KI-Ergebnis verwendet werden.
• Man benötigt weniger manuellen JSON-Parsing-Code.
• Das Frontend kann direkt mit einer definierten Struktur arbeiten.
• Der Prompt muss nicht das komplette JSON-Format beschreiben.

Structured Outputs als Vertrag

Beim Aufbau der Anwendung ist mir aufgefallen, dass das Modell manchmal Informationen zurückgeben kann, die tatsächlich nicht im Bild vorhanden sind, zum Beispiel einen falschen Preis oder ein falsches Objekt. Das ist eine typische KI-Halluzination. Structured Outputs verhindert Halluzinationen nicht, bietet aber einen zuverlässigen Vertrag zwischen der KI und der Anwendung.

Indem wir die erwarteten Felder und Datentypen mit Pydantic definieren, weiß das Backend genau, welche Struktur es erwarten kann. Um Halluzinationen zu reduzieren, habe ich außerdem klare Anweisungen in den Prompt aufgenommen, wie zum Beispiel: „Erfinde keine Preise oder Links. Wenn die Information nicht zuverlässig erkannt werden kann, gib einen leeren Wert zurück.“

Diese Kombination macht die Anwendung vorhersehbarer: Structured Outputs schützt die Struktur, während klare Prompts und Validierung helfen, die Daten zu schützen.

OCR oder multimodale KI?

Für reine Texterkennung gibt es bei Azure spezialisierte OCR- und Document-Intelligence-Lösungen. Diese sind besonders interessant, wenn es hauptsächlich darum geht, Text, Layout, Tabellen oder Positionen zuverlässig zu extrahieren.

In unserem Fall wollen wir jedoch nicht nur Text erkennen. Wir möchten das gesamte Bild analysieren und verschiedene Informationen daraus extrahieren.

Deshalb kann ein multimodales Modell wie GPT-4.1-mini eine interessante Alternative sein:

Bild + Anweisungen → Modell → strukturierte Daten

Damit können wir Bildverständnis und strukturierte Datenextraktion in einem Schritt kombinieren.

Fazit

Mit Azure OpenAI und GPT-4.1-mini können wir relativ einfach eine Anwendung bauen, die Bilder analysiert und die Ergebnisse direkt in eine für unsere Software nutzbare Struktur umwandelt.

Der entscheidende Punkt ist dabei nicht nur das verwendete Modell, sondern auch der Vertrag zwischen KI und Anwendung.

Mit Pydantic + Structured Outputs wird aus einer freien KI-Antwort eine strukturierte API-Antwort.

So kann die KI nicht nur Text generieren, sondern als eine zusätzliche Verarbeitungsschicht zwischen einem Bild und unserer Anwendung eingesetzt werden.

Ich hoffe, dieses kurze Tutorial war hilfreich.

Now let’s code!

The post Bildanalyse mit GPT-4.1-mini und Structured Outputs appeared first on Rhein-Ruhr-Informatik.

Cloud Integration erlaubt uns die Veränderung über die Nachricht zu machen, so wie Mappings, oder die Konvertierung von einer Struktur zu der anderen. Cloud Integration ist nicht nur stark für die Manipulation der Datei, sondern auch für die Merkmale der Überwachung. Zusätzlich zu Debug- oder Trace-Modus wie in jeder Entwicklungs-IDE ermöglicht es uns auch, die notwendigen Informationen zu überwachen, ohne dass ein Debugging erforderlich ist.

Für jeden Service können wir das Log-Level auf 5 verschiedene Modi einstellen.

Die Standard-Log-Konfiguration ist auf Info eingestellt. Info ermöglicht es uns, den Status jedes Prozesses zu sehen, wie z.B. abgeschlossen, abgebrochen, fehlgeschlagen usw. In diesem Modus können wir weder die Header noch den Body sehen. Es ist wichtig, die Daten aus Sicherheitsgründen zu schützen und den Speicherverbrauch zu reduzieren.

Aber wenn der Prozess fehlschlägt, wie können wir das Problem herausfinden?
Trace-Modus ist nützlich, wenn dieselbe Request-Message empfangen werden kann. Bevor Nachrichten erhalten werden, sollte dieser Modus aktiviert werden. Im Trace können sowohl der Body als auch die Header bei jedem Schritt betrachtet werden.

Der Prozess, der einen Fehler verursacht, wird angezeigt. In diesem Modus ist es viel einfacher und schneller, den Schritt zu identifizieren, in dem der Fehler auftritt.

Allerdings erlaubt CPI uns, nur 10-Minuten im Trace zu bleiben, danach wechselt es automatisch wieder in den vorherigen Modus (Info, Error oder None). Zusätzlich ist die Nachricht nach einer Stunde nicht mehr erreichbar. Während der Entwicklung nutzen wir Trace sehr oft. In der Produktion können wir den gleichen Prozess nicht wieder triggern, wenn er einen Fehler bekommt. Aus Sicherheitsgründen ist es auch nicht empfohlen, die vollständige Nachricht in der Produktion offenzulegen.

Wie können wir in diesem Fall herausfinden, welche Nachricht einen Fehler enthält, ohne die gesamte Nachricht offenzulegen? Folgendes bietet SAP an:

Es gibt einige vorgefertigte Properties zum Überwachen und Filtern von Nachrichten. Diese Funktion ist sehr hilfreich, um den Status bestimmter Nachrichten zu verstehen und die Nachrichten im Monitoring zu filtern. Wir können diese Properties nach Bedarf anpassen. In diesem Beispiel wird die „Application Message ID“ durch die

Bestellnummer festgelegt, und der Bestelltyp wird als „Application Message Type“ bestimmt. Wenn diese Bestellung einen Fehler enthält, können wir die Bestellnummer direkt herausfinden, ohne die gesamte Nachricht offenzulegen.

Falls diese vorgefertigten Properties nicht ausreichen oder zusätzliche kundenspezifische Properties benötigt werden, können wir auch Custom-Monitoring-Header hinzufügen. Diese benutzerdefinierten Header gelten nicht als echte Header, und werden nicht an das Empfängersystem gesendet. Sie werden ausschließlich intern zu Monitoring-Zwecken verwendet.

Zusätzlich können wir die Nachrichten anhand von Monitoring-Properties und Custom-Headern filtern. Zum Beispiel haben wir 7 Nachrichten im Status „Completed“ mit dem Message Type „Initial Order“.

Allerdings haben wir nur eine Nachricht mit der Nummer 1000000 erhalten.

Normalerweise ist es nicht möglich, den Inhalt einer Nachricht während oder nach dem Prozess einzusehen. In einigen Fällen müssen wir jedoch den Nachrichteninhalt sehen, insbesondere wenn sich die Nachricht im Fehlerstatus befindet. Dafür können wir ein Attachment zu Monitoring-Zwecken erstellen. Attachments können in jedem Textformat vorliegen und sind konfigurierbar. Sie helfen uns bei der Identifizierung von Fehlern. Außerdem können Attachments so eingerichtet werden, dass sie nur im Fehlerfall angelegt werden.

Typische Szenarien sind:
– Einsicht in den gesamten Nachrichteninhalt an wichtigen Stellen, z. B. vor dem Mapping und nach dem Mapping.
– Im Fehlerfall ist der komplette Nachrichteninhalt an der Fehlerstelle.

Standardmäßig zeigt die Cloud Integration-Schnittstelle keine Nachrichten oder Header für die Benutzer an. Dies ist sowohl aus Sicherheitsgründen als auch für das Speichermanagement wichtig.

In einigen Fällen muss jedoch eine fehlgeschlagene Nachricht ohne Trace- oder Debug-Modus erkannt werden, insbesondere in der Produktionsumgebung. Um dies zu ermöglichen, können im Info-Modus die notwendigen Felder als Custom-Properties und Attachments festgelegt werden. Damit können wir identifizieren, welche Nachricht fehlgeschlagen ist.

Cloud Integration speichert Logs maximal für 1 Monat. Dieser Zeitraum dient dazu, Fehler zu bearbeiten und Probleme zu lösen.

The post Monitoring in SAP Cloud Integration appeared first on Rhein-Ruhr-Informatik.

1. Lernen und Vorbereitung

Bevor ich überhaupt mit dem Lernen angefangen habe, wollte ich verstehen, was mich erwartet. Die Prüfung zum Solutions Architect – Associate prüft ein breites Spektrum an Themen: Architekturprinzipien, Hochverfügbarkeit, Sicherheit, Kostenoptimierung und viele Services wie EC2, S3, RDS, Lambda oder VPC.

Ich habe meine Vorbereitung in drei Phasen eingeteilt:

Phase 1: Grundlagen auffrischen
Ich startete mit dem kostenlosen AWS Skill Builder, wo es einen offiziellen Kurs namens „Exam Prep: AWS Certified Solutions Architect – Associate“ gibt. Dort bekommt man ein gutes Gefühl für den Aufbau und die Tiefe der Fragen. Zusätzlich habe ich zwei thematisch passende Kurse auf Udemy gekauft, um mein Wissen weiter zu vertiefen – sie boten viele praktische Beispiele und Erklärungen, die mir beim Verständnis komplexerer Themen sehr geholfen haben.

Phase 2: Intensivtraining
Anschließend nutzte ich Udemy-Kurse von Dozenten wie Stéphane Maarek und Tutorials Dojo. Besonders hilfreich fand ich die vielen praxisnahen Labs – zum Beispiel das Aufsetzen einer VPC oder einer Auto-Scaling-Gruppe. Diese Übungen halfen mir enorm, die Konzepte wirklich zu verstehen.

Phase 3: Prüfungssimulationen
In den letzten zwei Wochen vor dem Examen konzentrierte ich mich auf Übungsprüfungen. Die Fragen auf Plattformen wie Whizlabs oder Tutorials Dojo waren oft sehr ähnlich wie die echten – manchmal fast identisch in der Art, wie sie gestellt werden.
Ich versuchte, nicht nur die richtige Antwort zu kennen, sondern auch zu verstehen, warum die anderen Antworten falsch waren – das ist entscheidend!

2. Anforderungen an Ausrüstung und Raum

Ich entschied mich, die Prüfung online von zu Hause aus abzulegen – bequem, aber mit klaren Regeln.

Technische Anforderungen:

• Ein zuverlässiger Laptop oder PC
• Eine stabile Internetverbindung (LAN bevorzugt)
• Eine funktionierende Webcam und ein Mikrofon

Vor der Prüfung prüft ein Tool von Pearson VUE automatisch, ob Kamera, Ton und Netzwerk in Ordnung sind.

Raumvorbereitung:
Der Raum muss sauber und ruhig sein – keine Bücher, keine Notizen, keine zweite Person im Zimmer. Ich musste sogar meine Wände kurz zeigen, indem ich die Kamera herumschwenkte. Mein Schreibtisch war komplett leer, und ich legte mein Smartphone weit weg. Das mag etwas streng wirken, aber es sorgt für Fairness.

3. Registrierung und Identitätsprüfung

Die Registrierung läuft über das AWS Certification Portal. Man kann dort wählen, ob man die Prüfung online oder in einem Testzentrum ablegen möchte.

Nach der Anmeldung erhält man eine E-Mail mit allen Schritten. Am Tag der Prüfung klickte ich einfach auf „Start Exam“. Danach öffnete sich ein Chatfenster mit dem Prüfer (Proctor).

Der Prüfer kontrollierte meine Identität per Ausweis, ließ mich mit der Webcam den ganzen Raum zeigen und prüfte, dass keine unerlaubten Gegenstände in der Nähe sind. Nach ein paar Minuten war alles bereit – und die Prüfung konnte beginnen.

4. Der Prüfungsablauf

Die Prüfung dauert 130 Minuten und besteht aus etwa 65 Multiple-Choice-Fragen. Manche Fragen sind kurz und direkt, andere ziemlich lang und beschreiben komplexe Architekturszenarien.

Ich habe mir angewöhnt, zunächst alle Fragen zu beantworten, bei denen ich mir sicher war, und die restlichen zu markieren. Am Ende blieb mir noch genug Zeit, um etwa 10 schwierige Fragen in Ruhe zu überdenken.

Ein kleiner Tipp:

Lies die Fragen wirklich aufmerksam – manchmal ändert ein einziges Wort („cost-effective“, „highly available“ oder „fault tolerant“) die gesamte Bedeutung.

Nachdem ich die letzte Frage abgegeben hatte, zeigte das System sofort: „Your result will be available in 5 Tages.“
Dann kam die E-Mail: „Congratulations! You passed the exam!“
Das war ein großartiges Gefühl!

5. Nützliche Ressourcen und Tipps

Wenn du den AWS Certified Solutions Architect – Associate bestehen möchtest, helfen dir folgende Ressourcen:

• AWS Skill Builder: Offizielle, kostenlose Lernplattform
• AWS Whitepapers: Besonders „Well-Architected Framework“ und „Security Best Practices“
• Udemy: Kurse von Stéphane Maarek oder Neal Davis
• Tutorials Dojo / Jon Bonso Practice Exams: Realistische Übungsfragen
• AWS Free Tier: Zum Ausprobieren von Services ohne Kosten

Fazit

Der Weg zum AWS Certified Solutions Architect – Associate war für mich nicht nur eine technische Herausforderung, sondern auch eine persönliche Reise. Ich habe viel über moderne Cloud-Architektur gelernt und verstanden, wie wichtig gutes Design in AWS ist.

Wenn du also überlegst, diesen Schritt zu gehen: Mach es!Mit Geduld, Neugier und einer guten Vorbereitung kannst du es schaffen. Und das Zertifikat öffnet dir viele Türen in der IT-Welt.

Viel Erfolg und viel Spaß auf deinem eigenen AWS-Abenteuer!

The post Mein Weg zum AWS Certified Solutions Architect – Associate appeared first on Rhein-Ruhr-Informatik.

In der modernen Softwareentwicklung sind Geschwindigkeit und Skalierbarkeit entscheidend. Unternehmen wollen Funktionen schnell bereitstellen, ohne sich um die Wartung von Infrastruktur zu kümmern. Genau hier glänzt Serverless Computing.

Mit AWS Lambda und Amazon API Gateway können Entwickler ein voll funktionsfähiges REST API erstellen, ohne Server zu betreiben. AWS kümmert sich automatisch um Skalierung, Verfügbarkeit und Abrechnung – man zahlt nur für tatsächlich verarbeitete Anfragen.

In diesem Artikel zeigen wir, wie man mit AWS API Gateway und AWS Lambda ein einfaches REST API aufsetzt, mit Beispielen in Python.

Was bedeutet Serverless?

Serverless bedeutet nicht, dass keine Server existieren – sie sind nach wie vor vorhanden, werden aber vollständig vom Cloud-Anbieter verwaltet. Entwickler konzentrieren sich nur auf den Code, während AWS folgende Aufgaben übernimmt:

– Bereitstellung und Skalierung (von null bis zu Millionen von Anfragen)
– Hohe Verfügbarkeit
– Sicherheit und Patching
– Abrechnung basierend auf tatsächlicher Nutzung

Für REST APIs hat sich die Kombination aus API Gateway und Lambda als Standardmuster etabliert. Sehen wir uns an, wie das Zusammenspiel funktioniert.

Architekturübersicht

Der Ablauf sieht so aus:
1. Ein Client (Browser, Mobile App, Postman) sendet eine Anfrage an einen API Gateway Endpoint.
2. API Gateway leitet die Anfrage an eine konfigurierte Lambda-Funktion weiter.
3. Die Lambda-Funktion führt den individuellen Code aus (in unserem Fall Python).
4. Lambda gibt eine Antwort zurück, die API Gateway an den Client weiterleitet.

Diese einfache Architektur ist sehr leistungsfähig, da man verschiedene Lambda-Funktionen mit unterschiedlichen API-Routen und Methoden verbinden kann (z. B. GET /users, POST /orders).

Schritt-für-Schritt Anleitung

1. Erstellen einer Lambda-Funktion

1. Melde dich in der AWS Management Console an.
2. Gehe zu AWS Lambda → Funktion erstellen.
3. Wähle Author from scratch, gib einen Namen an (z. B. hello-world) und wähle Python 3.x als Laufzeit.
4. Füge folgenden Code in den Editor ein:

import json

def lambda_handler(event, context):
    name = event.get("queryStringParameters", {}).get("name", "World")
    return {
        "statusCode": 200,
        "headers": {"Content-Type": "application/json"},
        "body": json.dumps({"message": f"Hello, {name}!"})
    }

2. Erstellen eines API Gateways

1. Gehe zu Amazon API Gateway → API erstellen.
2. Wähle HTTP API (einfacher) oder REST API (mehr Konfigurationsmöglichkeiten). Für dieses Beispiel nehmen wir HTTP API.
3. Erstelle ein neues API und verknüpfe es mit deiner Lambda-Funktion (hello-world).
4. Stelle das API bereit (Deploy).

3. Testen des APIs

Nach der Bereitstellung erhältst du eine Endpoint-URL, z. B.:

https://abc123.execute-api.us-east-1.amazonaws.com/default/hello-world

Nun kannst du testen:

curl "https://abc123.execute-api.us-east-1.amazonaws.com/default/hello-world?name=Alice"

Antwort:
{ "message": "Hello, Alice!" }

Glückwunsch! Du hast gerade ein serverloses REST API mit AWS gebaut.

Warum API Gateway + Lambda?

– Skalierbarkeit: Automatische Verarbeitung von Lastspitzen.
– Kosteneffizienz: Man zahlt nur, wenn Funktionen tatsächlich ausgeführt werden.
– Einfachheit: Keine Serververwaltung, keine Updates, keine Skalierungsprobleme.
– Flexibilität: Lambda kann mit Datenbanken (DynamoDB, RDS), Queues (SQS) oder Event-Streams (Kinesis) verbunden werden.

Nächste Schritte

Unser Beispiel ist minimal. In einer Produktionsumgebung könnte man:
– Authentifizierung & Autorisierung hinzufügen (AWS Cognito, IAM Policies, eigene JWTs).
– Infrastructure as Code nutzen (AWS SAM, CDK oder Terraform).
– Logging & Monitoring aktivieren (CloudWatch, X-Ray).
– Lambda mit weiteren AWS-Services kombinieren, um komplexe Anwendungen zu bauen.

Fazit

AWS API Gateway und AWS Lambda ermöglichen es, sehr einfach serverlose REST APIs zu entwickeln. Mit nur wenigen Klicks und einem kleinen Python-Skript lässt sich ein Endpoint bereitstellen, der automatisch skaliert und nur bei Nutzung Kosten verursacht.

Ob du moderne Anwendungen entwickelst, mit Microservices experimentierst oder einfach Servermanagement vermeiden willst – dieser serverlose Ansatz ist ein hervorragender Startpunkt.

The post Aufbau eines serverlosen REST-APIs mit AWS API Gateway und Lambda appeared first on Rhein-Ruhr-Informatik.

SAP BTP ermöglicht die Bereitstellung verschiedener Services und Anwendungen, die jeweils eigene Role Collection enthalten. Diese Services werden häufig in unterschiedlichen Subaccounts betrieben. Zwar ist es möglich, Benutzer und Rollen separat in jedem Subaccount zu verwalten, jedoch gibt es auch eine zentralisierte Alternative.

Durch den Aufbau einer Vertrauensbeziehung zwischen dem Identity Service und den BTP-Subaccounts kann die Benutzer- und Rollenverwaltung über einen einzigen Identity Provider erfolgen.

In diesem Beitrag zeige ich Ihnen, wie man Role Collection Mapping zwischen BTP und dem Identity Authentication Service (IAS) einrichtet. Dadurch kann man die Rollenzuweisung für mehrere Subaccounts zentral über einen Identity Provider steuern.

Voraussetzungen

Wenn Sie über einen Identity Provider verfügen, können Sie diesen als benutzerdefinierten Provider für ein BTP-Subaccount konfigurieren. Er kann dann als Quelle für Benutzer und Role Collection verwendet werden.
Für die Einrichtung von Role Collection Mapping gelten folgende Voraussetzungen:

• Sie müssen im betreffenden Subaccount, der mit den SAP Cloud Identity Services verknüpft (vertrauend) wird, die Rolle Subaccount Administrator besitzen.
• Der SAP Cloud Identity Services-Mandant kann in einem anderen Subaccount abonniert sein, muss jedoch zum gleichen Global Account gehören und sich in derselben Region befinden.

Die Schritte zur Konfiguration der Vertrauensbeziehung (Trust Configuration) zwischen Ihrem Subaccount und dem SAP IAS-Mandanten finden Sie in folgendem SAP-Hilfedokument:

👉 SAML-Vertrauensbeziehung zwischen SAP-BTP-Unterkonto und IAS konfigurieren | SAP Help Portal

Hinweis: Um die Role Collection Mapping nutzen zu können, müssen Sie sich mit einem Benutzer anmelden, der im Identity Provider definiert ist – nicht mit einem BTP-Benutzer.

Konfigurationen

1. BTP Role Collections

Bevor ein Role Collection Mapping erstellt wird, stellen Sie sicher, dass Sie über alle benötigten Rollen verfügen, um auf die „Role Collections“ in Ihrem Subaccount zugreifen zu können.

Navigiere zu:

<Ihr Subaccount>          →    Security     →   Role Collections 

Sie können die Standard Role Collection verwenden, die für BTP-Anwendungen vordefiniert sind.

Alternativ können Sie eine neue benutzerdefinierte Role Collection erstellen, indem Sie oben rechts auf die Schaltfläche Create klicken.

SAP BTP Role Collections

In diesem Beispiel wird eine neue benutzerdefinierte Role Collection mit dem Namen „My_Custom_Role“ erstellt.

• SAP Cloud Identity Services

Bevor Sie mit der Konfiguration der Role Collection Mapping beginnen, müssen Sie sicherstellen, dass Sie benötigte Attribute an die Anwendung senden. Navigieren Sie in SAP Cloud Identity Service zu:

 Application & Resources   →  <Ihr Anwendung>  →  Single Sign-On  →  Assertion Attributes

Anwendungsseite in den SAP Cloud Identity Services

Unter den Assertion-Attributen muss ein „Groups“-Attribut vorhanden sein. Dieses Attribut wird an die Anwendung als BTP Role übermittelt.

Assertion Attributes einer Anwendung in den SAP Cloud Identity Services

Anschließend sollten Sie eine Gruppe für die BTP Role erstellen, die Sie zuordnen möchten. Navigieren Sie zu:
                        Users & Authorizations   →  Groups

Erstellen Sie eine neue Gruppe, wenn es bereits eine Gruppe existiert, fügen Sie die Benutzer hinzu, die diese Rolle erhalten sollen.

Gruppen und Benutzer in den SAP Cloud Identity Services

• BTP Role Collection Mapping

Jetzt sind wir bereit, das Role Collection Mapping durchzuführen. Navigieren Sie in Ihrem SAP BTP Subaccount zu
                        <Ihr Subaccount>   →   Security   →   Trust Configuration,

und klicken Sie auf den benutzerdefinierten Identity Provider, den Sie zu Beginn eingerichtet haben.

SAP BTP Trust Configurations

Klicken Sie auf New Role Collection Mapping und wählen Sie Ihre gewünschte BTP Role Collection aus (1). Dabei kann es sich sowohl um eine Standard- als auch um eine benutzerdefinierte Role Collection handeln.

Für das Feld „Attribute“ geben Sie bitte den Namen des Attributs an, das Sie im Identity Authentication Service (IAS) als Gruppenattribut definiert haben (2). In der Regel bleibt dies auf „Groups“ gesetzt.

Im Feld „Value“ geben Sie den Namen der IAS-Gruppe an, die der ausgewählten BTP Role Collection zugeordnet werden soll (3).

Speichern Sie anschließend die Konfiguration.

SAP BTP Role Collection Mapping

Die erstellten Mappings können Sie unter Role Collections einsehen.

SAP BTP Role Collections mit IAS-Gruppen verknüpft

Fazit:

• Sie können die zugewiesenen Rollen zentral im SAP Identity Authentication Service (IAS) verwalten, indem Sie die Mitglieder der entsprechenden IAS-Gruppe pflegen.
• Im BTP Subaccount sind die durch IAS zugewiesenen Benutzerrollen nicht direkt sichtbar. Diese Rollen werden dynamisch zugewiesen, sobald sich ein Benutzer über den IAS bei Ihrer Anwendung authentifiziert.

Hinweis:

Der Benutzer im IAS muss ebenfalls im entsprechenden SAP BTP Subaccount vorhanden sein. Weitere Informationen zur Benutzeranlage in BTP finden Sie unter folgendem Link:

👉 Arbeiten mit Benutzern | SAP Help Portal

Wir hoffen, dass Ihnen dieser Beitrag dabei hilft, Ihre BTP Role Collections effizient über Ihren Identity Provider zu verwalten!

Feyza Sahin

The post Verwaltung von BTP Role Collections über den SAP Cloud Identity Service appeared first on Rhein-Ruhr-Informatik.

Aber wie genau beeinflusst KI unsere tägliche Arbeit?

Als Frontend-Entwickler habe ich begonnen, KI-Tools zu nutzen, um meine Produktivität zu steigern. Mit der Zeit stellte ich mir dabei einige wichtige Fragen:
Ist KI eine Bedrohung für unsere Jobs – oder ein Motor für Innovation? Wird sie uns Entwickler irgendwann vollständig ersetzen? Und was kommt als Nächstes?

Schauen wir es uns genauer an.

💡 Wie KI die Produktivität von Softwareentwicklern steigert
KI-Tools haben viele Aspekte meines Entwicklungsprozesses deutlich beschleunigt. Hier sind einige der wichtigsten Vorteile:

• 🔤 Code-Vorschläge & Autovervollständigung
  Tools wie Windsurf oder GitHub Copilot sagen vorher, was du als Nächstes schreiben willst – und sparen so Zeit bei Syntax und Boilerplate-Code.
• 🧱 Komponentenerstellung
  Du brauchst eine responsive Navigationsleiste, ein Modal oder ein Formular? KI kann wiederverwendbare UI-Komponenten aus einfachen Anweisungen generieren – oft sogar nach Best Practices.
• 🐞 Debugging & Testing
  KI erkennt Fehler, schlägt Lösungen vor und kann sogar Unit-Tests schreiben – und hilft so, Probleme frühzeitig zu erkennen.
• 🎨 Design-to-Code-Umwandlung
  Manche Tools können Designs aus Figma direkt in sauberes HTML, CSS und JavaScript umwandeln – das reduziert den manuellen Aufwand erheblich.
• 📚 Dokumentation & Refactoring
  Dokumentation schreiben und Code aufräumen ist kein lästiger Task mehr. KI kann lesbare Dokumente erstellen und klarere Code-Strukturen vorschlagen.

Durch die Automatisierung repetitiver Aufgaben schafft KI mehr Raum für Logik, Architektur und kreatives Problemlösen.

Doch wie nutzt man KI richtig, um das Beste aus ihr herauszuholen?

🧠 Nutze KI als Helfer, nicht als Ersatz
Als ich KI-Tools zum ersten Mal einsetzte, übertrug ich ihnen direkt komplexe Aufgaben – in der Hoffnung, dass sie alles eigenständig lösen. Das Ergebnis? Enttäuschend. Der Output war voller Fehler und unstrukturierter Code.

Mit der Zeit habe ich verstanden: Der Trick ist, KI als Assistenten zu nutzen – nicht als Anführer. Denk an KI wie an einen Junior-Entwickler oder Co-Piloten. Du bist immer noch der Kapitän.

Was gut funktioniert:

• Struktur vorgeben.
  Du definierst die Architektur – die KI füllt die Lücken: Utility-Funktionen, Hilfsmethoden oder kleinere Features.
• Ergebnisse überprüfen und nachbessern.
  Kontrolliere immer, was die KI liefert. Sie kann den Kontext übersehen, Bugs einführen oder falschen Konventionen folgen.
• Die Kontrolle behalten.
  Überlasse kritische Teile niemals der KI. Du bist der leitende Entwickler – die KI ist dein Werkzeug, kein Ersatz.

🧾 Die Kunst, gute Prompts zu schreiben
Eine der am meisten unterschätzten Fähigkeiten im Umgang mit KI als Entwickler ist das Schreiben guter Prompts. Die Qualität deiner Eingabe bestimmt direkt die Qualität der Ausgabe. Ein vager oder zu einfacher Prompt führt oft zu unbrauchbarem Code. Ein detaillierter, strukturierter Prompt hingegen liefert erstaunlich präzise Ergebnisse.

Je klarer und kontextreicher deine Anweisung, desto besser das Ergebnis.

Tipps für gute Prompts:

• Gib Sprache, Framework und gewünschtes Ergebnis an (z. B. „React-Funktionskomponente mit Tailwind CSS“).
• Füge Beispiele oder Einschränkungen hinzu.
• Zerlege große Aufgaben in kleinere, fokussierte Teile.

🎯 Guter Prompt = Gutes Ergebnis
Wenn der Code nicht funktioniert, ist oft nicht die KI schuld – sondern der Prompt. Behandle Prompt-Schreiben wie das Schreiben klarer Anforderungen an ein Feature. Je mehr Kontext du gibst, desto besser passt das Ergebnis.

Ein schnelles Beispiel:

• Schlechter Prompt:
  „Mach mir ein Formular.“
• Guter Prompt:
  „Erstelle ein responsives Kontaktformular in React mit Validierung für E-Mail und Telefonnummer, gestaltet mit Tailwind CSS.“

Der zweite Prompt gibt der KI eine klare Richtung – und das macht den Unterschied.

✅ Vorteile der KI im Entwicklungs-Workflow
Neben Geschwindigkeit bringt KI viele praktische Vorteile für moderne Entwickler:

• 💼 Mehr Effizienz
  Routinetätigkeiten wie Tests schreiben, Konfigurationsdateien anlegen oder Formate konvertieren werden schneller und fehlerfreier.
• 📈 Schnelleres Prototyping
  KI hilft dabei, Ideen schnell umzusetzen – ideal zur Validierung von Designs und Funktionen.
• 💡 Wissen auf Abruf
  KI funktioniert oft wie eine intelligente Suchmaschine: Erklärungen, Code-Snippets oder Best Practices in Sekundenschnelle.
• 🧠 Bessere Codequalität (bei richtiger Nutzung)
  Mit der richtigen Anleitung kann KI sauberen Code nach Standards liefern und Anti-Patterns früh erkennen.
• 🌐 Flexibilität im Tech-Stack
  Auch bei unbekannten Bibliotheken oder Sprachen gibt KI kontextabhängige Hilfestellung.
• ⏱ Zeitersparnis
  Kleinigkeiten wie Regex-Muster, Datenformatierungen oder kleinere Bugfixes lassen sich blitzschnell lösen.

Wenn man KI klug einsetzt, wird sie vom Spielzeug zum praktischen Beschleuniger des Arbeitsalltags.

Aber mit all diesen Möglichkeiten kommen natürlich auch Bedenken …

🤖 Wird KI Softwareentwickler ersetzen?
Kurze Antwort: Nein – zumindest nicht in absehbarer Zeit.
KI kann gewisse Aufgaben automatisieren, aber sie fehlt es (noch) an tiefem Verständnis und Problemlösungskompetenz, wie sie menschliche Entwickler mitbringen.

Eine performante, barrierefreie und skalierbare Anwendung zu bauen, ist weit mehr als nur Code schreiben. Es geht um strategisches Denken, Kreativität und Zusammenarbeit – und hier sind Menschen nach wie vor unschlagbar.

Warum Entwickler unverzichtbar bleiben:

• Kontextverständnis
  KI versteht keine Geschäftsziele, Nutzerbedürfnisse oder Produktvisionen im eigentlichen Sinne.
• Menschliche Zusammenarbeit
  Entwickler kommunizieren mit Designern, Projektmanagern, Stakeholdern – das kann KI nicht ersetzen.
• Kreative & strategische Entscheidungen
  Die Wahl der richtigen Tools, UX-Optimierung und Architekturentscheidungen erfordern menschliches Urteilsvermögen.
• Problemlösung
  Reale Software ist chaotisch. Sonderfälle, Debugging und Planung erfordern logisches Denken – etwas, das KI (noch) nicht beherrscht.

Aber wenn KI all das (noch) nicht kann – wie soll man sie dann nutzen?

🧭 Fazit
KI verändert das Spiel für Softwareentwickler – nicht, indem sie uns ersetzt, sondern indem sie unsere Fähigkeiten verstärkt. Sie reduziert Reibung, erhöht die Effizienz und beschleunigt die Entwicklung. Der Schlüssel zum Erfolg liegt darin, zu wissen, wann und wie man sie einsetzt.

Die Zukunft gehört den Entwicklern, die diese Tools mit Bedacht einsetzen – mit einem Gleichgewicht aus Automatisierung, Kreativität, Urteilsvermögen und Führung.

Gleichzeitig entwickelt sich KI rasant weiter. Tools, Fähigkeiten und Best Practices ändern sich ständig. Was gestern funktionierte, ist morgen vielleicht schon veraltet. Deshalb sollten Entwickler KI wie jedes andere Tool im Tech-Stack behandeln: neugierig bleiben, lernen und sich kontinuierlich weiterentwickeln.

Also ja – nutze KI. Lass dich unterstützen.
Aber halte stets die Hände am Steuer – und den Blick auf die Straße vor dir gerichtet.

The post Die Rolle von KI im Leben eines Softwareentwicklers appeared first on Rhein-Ruhr-Informatik.

Zunächst benötigt man einen Hypervisor, dann eine passende ISO-Datei, muss die VM konfigurieren, Partitionen einrichten, Windows installieren, Treiber hinzufügen und so weiter. Kurzum: Es ist machbar, aber nicht unbedingt angenehm.

Doch was, wenn ich dir sage, dass du eine vollständige Windows-Installation in einem Docker-Container starten kannst – mit geteiltem Speicher, RDP-Zugang und optionalem VLAN-Support? Klingt verrückt? Ist es auch ein bisschen. Aber es funktioniert.

Die Idee hinter dem Projekt

Ein Entwickler namens Kroese hat auf GitHub ein Projekt veröffentlicht, das genau das ermöglicht. Ein Docker-Container, der automatisch eine frische Windows-Installation einrichtet – und das ganz ohne manuelles Setup. Man startet einfach den Container, wartet ein paar Minuten und bekommt eine vollständig einsatzbereite Windows-Umgebung. Zugriff erfolgt bequem über den Browser oder per RDP.

Und das Beste: Man muss Windows nicht mal selbst installieren. Der Container übernimmt den kompletten Prozess – von der Image-Beschaffung bis zur Einrichtung.

Wie funktioniert das technisch?

Wer genau hinsieht, erkennt im Docker-Command das Flag, das /dev/kvm durchreicht – also den Kernel-basierten Virtualisierungsmechanismus von Linux. Kurz gesagt: Es handelt sich hierbei nicht um einen „echten“ Windows-Container, sondern um einen Linux-Container, der eine KVM-basierte VM aufsetzt. Also doch keine Magie, sondern eine clever automatisierte Lösung auf Basis bewährter Technologie.

Die Voraussetzung: Hardware-Virtualisierung muss vorhanden und aktiviert sein – sonst läuft hier gar nichts.

Der große Vorteil: Komfort

Das Besondere ist nicht die technische Innovation, sondern der enorme Komfortgewinn. Die lästigsten Aspekte einer Windows-Installation – wie Partitionierung, Ersteinrichtung oder die Wahl von Sprache und Tastaturlayout – fallen komplett weg. Alles läuft automatisiert ab.

Man erhält trotzdem alle Vorteile einer „normalen“ VM mit KVM: USB- und SATA-Passthrough, limitierbare CPU-Kerne und RAM, und wenn man will, sogar PCIe-Passthrough – wobei letzteres für ambitionierte Setups wahrscheinlich ohnehin in „richtige“ VMs gehört.

Nutzung im Alltag: RDP statt VNC

Die Web-Oberfläche des Containers nutzt VNC, was für den Anfang genügt – aber langsam ist und keinen Ton überträgt. RDP ist hier die bessere Wahl. Der Container unterstützt standardmäßig die Weiterleitung des RDP-Ports, sodass man einfach per Remotedesktop von Mac, Linux oder Windows aus zugreifen kann.

Dank Datenfreigabe kann man auch einfach Ordner vom Host einbinden – und so Dateien zwischen Windows und Linux austauschen. Der Standard-Container bietet 2 CPU-Kerne, 4 GB RAM und 64 GB Festplattenspeicher – alles über Umgebungsvariablen anpassbar.

Multi-Windows? Kein Problem!

Der Container unterstützt neben Windows 11 auch ältere Versionen – von XP bis Server 2022. Wer will, kann sogar abgespeckte Varianten wie Tiny11 oder Tiny10 nutzen – oder eigene ISO-Dateien einbinden. In einem Test liefen fünf Windows-Versionen parallel: XP, Vista, 7, 10 und 11 – alles gleichzeitig, auf einem Intel N100-System mit gerade einmal 18W Stromverbrauch.

Nur Windows 8.1 wollte nicht – aber wer vermisst das schon?

Und die Lizenz?

Die Windows-Images stammen, je nach Version, entweder direkt von Microsoft oder aus offenen Quellen wie Bob Pony. Neue Versionen sind unaktiviert, laufen aber ohne Einschränkungen 30 Tage lang. Wer länger nutzen will, muss einen gültigen Key eintragen. Das Projekt selbst enthält laut Entwickler keine proprietären Inhalte und basiert ausschließlich auf Open-Source-Code.

Fazit: Einfach, praktisch, genial

Ob für das schnelle Testen von Windows-Software, zum Spielen mit Legacy-Systemen oder für spezielle Tools wie BIOS-Editoren – dieses Docker-Projekt bietet eine komfortable, schlanke Lösung, bei der man auf nahezu nichts verzichten muss. Natürlich ersetzt es keine hochperformante VM mit dedizierter GPU, aber das will es auch gar nicht.

Was bleibt, ist ein beeindruckendes Beispiel dafür, was heute mit etwas Kreativität und offenen Standards möglich ist – ganz ohne den altbekannten Installationsfrust.

Und wer weiß – vielleicht rettet dir Windows XP auch heute noch den Tag.

The post Windows in einem Docker-Container? Ja, wirklich! appeared first on Rhein-Ruhr-Informatik.

Warum ein Uptime-Monitor Pflicht ist

Uptime-Monitore benachrichtigen dich, sobald deine Website nicht erreichbar ist. Die meisten Lösungen fallen dabei in zwei Kategorien:

• Gehostete Dienste wie UptimeRobot, Hyperping oder OhDear, die regelmäßig deine Website überprüfen.
• Self-Hosted Open-Source-Tools wie Uptime Kuma oder OpenStatus, die du selbst betreibst.

Selbstgehostete Lösungen haben allerdings einen großen Nachteil: Wenn dein gesamter Server ausfällt, ist auch der Monitor betroffen. Daher müsstest du diesen auf einem komplett separaten Server oder Anbieter hosten – das ist aufwendig und fehleranfällig.

Die Lösung: Upptime

Hier kommt Upptime ins Spiel – eine komplett kostenlose und Open-Source-basierte Monitoring-Lösung, die du direkt mit deinem GitHub-Konto betreiben kannst. Keine externen Server, keine Kosten. Upptime nutzt drei zentrale Funktionen von GitHub:

1. GitHub Actions
2. GitHub Issues
3. GitHub Pages

1. GitHub Actions für Monitoring

GitHub Actions ermöglichen automatisierte Abläufe – z. B. Tests, Deployments oder eben das regelmäßige Prüfen, ob deine Website erreichbar ist. Upptime konfiguriert diese Prüfungen über einfache YAML-Dateien im Verzeichnis .github/workflows.
Über GitHubs eigene Zeitplanung kannst du Checks beispielsweise alle 5 Minuten automatisiert ausführen lassen.

2. Benachrichtigung über GitHub Issues

Fällt deine Website aus, erstellt Upptime automatisch ein GitHub-Issue – eine Art Zwischenfallbericht. Diese Funktion kann erweitert werden, etwa mit Benachrichtigungen via Slack, Telegram, Discord, E-Mail oder sogar SMS.
Sobald die Website wieder erreichbar ist, schließt Upptime das Issue automatisch.

3. GitHub Pages als Statusseite

Eine weitere Stärke: Upptime erstellt eine öffentliche Statusseite via GitHub Pages.
Diese zeigt in Echtzeit die Erreichbarkeit deiner Website, inklusive Ladezeiten und Verlaufsdiagrammen. Kommentare zu Incidents werden automatisch übernommen – perfekt für transparente Kommunikation mit deinen Nutzern.

Einrichtung von Upptime

Die Einrichtung ist einfach:

1. Forke das offizielle Upptime-Repository als Vorlage.
2. Erstelle ein neues öffentliches Repository auf Basis dieser Vorlage.
3. Generiere ein GitHub Access Token mit den nötigen Berechtigungen (Actions, Issues, Contents, Workflows).
4. Hinterlege dieses Token in den Repository-Settings unter Secrets als GH_PAT.
5. Konfiguriere deine .upptimerc.yml mit deinem GitHub-Namen, Repo-Namen und den zu überwachenden URLs.
6. Commits triggern automatisch die Checks und die Statusseiten werden erstellt.

Fazit

Upptime ist eine elegante Lösung für Entwickler:innen, Freelancer und Agenturen, die ein kostenloses, zuverlässiges und transparentes Monitoring wünschen – ganz ohne externe Server.

Mit Upptime erhältst du:

• Regelmäßige Checks deiner Website
• Automatische Incident-Reports
• Öffentliche Statusseiten mit Verlauf und Ladezeiten

Alles, was du brauchst, ist ein GitHub-Konto.
Du möchtest wissen, wie lange die Einrichtung dauert?
Im Video wurden Setup und Videoerstellung mit dem Open-Source-Zeittracker Solidtime erfasst – ebenfalls eine spannende GitHub-basierte Lösung.

Links zu Upptime, Dokumentationen und weiteren Tools findest du in der Beschreibung des Videos.
Und wer weiß – vielleicht ist Upptime auch genau die Lösung für dein nächstes Projekt.

🔗 https://github.com/upptime/upptime

The post Website-Überwachung mit GitHub: So richtest du kostenloses Uptime-Monitoring mit Upptime ein appeared first on Rhein-Ruhr-Informatik.

In unserer globalen Geschäftswelt ist die reibungslose Kommunikation zwischen den Geschäftspartnern eines der wichtigsten Kriterien, um den weltweiten Handel in der heutigen Form durchzuführen. Um dieses zu erreichen, wurde EDI (Electronic Data Interchange) mit dem Zweck, den elektronischen Austausch von Geschäftsdokumenten, wie beispielsweise Artikelstammdaten, Bestellungen, Lieferscheine und Rechnungen auszutauschen, eingeführt.

Als Vater des elektronischen Datenaustausches gilt Edward Guilbert der EDI bereits in den 1960er Jahren in den Lieferketten der US-Transportbranche implementierte. Um die globale Reichweite der Technologie zu verbessern schuf 1985 die UN EDIFACT EDI. Diese Dokumente werden in Form von strukturierten Daten und ohne manuelle Eingriffe ausgetauscht.

Gegenüber papierbasierten Geschäftsprozessen hat EDI den entscheidenden Vorteil, dass es eine automatisierte Verarbeitung mit sehr geringer Fehlerquote ist und die Möglichkeit bietet, EDI-Nachrichten automatisch ins ERP-System (Warenwirtschaftssystem des Unternehmens) zu erfassen.

Was ist EDIFACT?

UN/EDIFACT sind Regeln der Vereinten Nationen und umfassen eine Reihe international vereinbarter Standards, Verzeichnisse und Richtlinien für den elektronischen Austausch von strukturierten Daten zwischen weltweit unabhängigen computergestützten Informationssystemen.“

EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) bedeutet zu Deutsch, -elektronischer Datenaustausch für Verwaltung, Handel und Transport-. Dieser besteht aus einer hierarchischen Struktur, bei der die oberste Ebene als Interchange bezeichnet wird. Eine EDIFACT-Nachricht ist eine vollständige, strukturierte Datensequenz, die einen einzelnen Geschäftsvorgang darstellt, wie zum Beispiel eine Bestellung. Die UN/EDIFACT-Syntax ist in der Norm ISO 9735 festgelegt. Er umfasst über 200 verschiedene Nachrichtentypen und wird mittlerweile von mehr als 300.000 Unternehmen weltweit eingesetzt.

EANCOM ein Subset aus EDIFACT

EANCOM® (EAN + Communication) ist ein weltweit gültiger Nachrichtenstandard, mit dem international und branchenübergreifend elektronisch Geschäftsdaten ausgetauscht werden können. Er ist der global am weitesten verbreitete Standard für den elektronischen Datenaustausch EDI. Die Besonderheit von EANCOM® ist die Berücksichtigung der globalen GS1 Standards zur Identifikation wie z.B. GLN, GTIN und SSCC/NVE.

GLN – Mit der GLN werden Unternehmen und Unternehmensteile, wie zum Beispiel Standorte oder Lager, weltweit eindeutig und überschneidungsfrei identifiziert und ist 13-stellig.

GTIN – Mit der GTIN kann jeder Artikel, jedes Produkt oder jede Produktvariante weltweit überschneidungsfrei identifiziert werden.

SSCC/NVE – Der SSCC (Serial Shipping Container Code) ist eine 18-stellige Identifikationsnummer für jegliche Arten von Transporteinheiten, z.B. Paletten und Versandkartons. In Deutschland wird er auch als NVE (Nummer der Versandeinheit) bezeichnet. In der Praxis ist der SSCC wichtiger Bestandteil des GS1 Transportetiketts.

Weitere Infos dazu finden man auf der Seite der GS1 unter www.gs1-germany.de

Im EANCOM-Subset werden nur die benötigten Segmente aus dem unterliegenden UN/EDIFACT-Standard verwendet. Die Besonderheiten eines Subsets stellen die branchenspezifischen Qualifier dar. Diese erweitern den Standard um die in der Branche üblichen und benötigten Ausprägungen.

Der Standard EANCOM® wurde ursprünglich für die Bedürfnisse der Konsumgüterindustrie konzipiert. Heute ist der EDI-Standard jedoch branchenübergreifend aufgestellt. Beispiele hierfür sind das Gesundheitswesen, Logistik, Fashion, eCommerce oder Bargeldlogistik. 

EANCOM (EAN + Communication) steht für detaillierte Beschreibungen vereinfachter EDIFACT-Nachrichten, die Anwender leicht verstehen und in der Praxis einsetzen können. GS1 ist für die Weiterentwicklung des EDIFACT-Subsets EANCOM® verantwortlich.

• EANCOM beinhaltet alle GS1 Identifikationsstandards (z.B. GLN & GTIN) und hat dadurch einen sehr hohen Nutzen in der Vereinheitlichung des elektronischen Datenaustausch.
• Ermöglicht eine direkte elektronische Verarbeitung nach Erhalt der Daten, mit direktem Zugriff auf die gesendeten Informationen in kürzester Verarbeitungszeit.
• Vorteile einer internationale Unternehmenskommunikation in einheitlicher Datenstruktur.
• Durch die elektronische Übermittlung ergibt sich eine hohe Sicherheit der Datenkonsistenz gegenüber manuellen Eingaben in den ERP-Systemen und es entfallen aufwendige Kontrollprozesse zur Freigabe der Daten. 
• Spürbare Reduzierung in den Aufwänden für Verwaltung und Personal sowie Porto und Versandkosten.

Struktur einer Übertragungsdatei

Eine einfache Übertragungsdatei besteht aus einem Nutzdaten-Kopfsegment mit den Nutzdaten. Diese interpretieren vereinfacht dargestellt einen Briefumschlag mit Absender und Empfänger, sowie den inhaltlichen Text.

Diese Segmente beginnen immer mit einem “UN“ und werden Service Segmente genannt. Jedes Segment gibt wie in einer XML-Struktur, ein definierter Anfang und Ende zusammenhängender Daten an.

UNB als Anfang und UNZ als Ende (dieses ist der Umschlag)

UNH als Anfang und UNT als Ende (dieses ist der gesamte Brief)

Zusätzlich UNS innerhalb des UNH-UNT das als Abschnitts-Kontrollsegment dient. Je nach Nachrichtenart folgen dann Segmente zur Kontrolle oder nicht.

Innerhalb des UNH-UNT gibt es dann eine Aufteilung, die je nach Nachrichtenart aus drei Teilen besteht.

• Einem Kopfteil der sich auf die gesamte Nachricht bezieht.

• Positionsteil, wo sich die angegebenen Daten immer nur auf diese eine Position beziehen.

• Einem Summenteil, wo es nur Segmente zu Summen und Kontrollwerte gibt wie z.B. Anzahl der Bestellposition oder Rechnungsgesamtbetrag usw.

Zusätzlich gibt es noch die Möglichkeit einen erweiterten Zeichensatz anzuwenden, den auch die meisten Handelspartner anwenden und diesen dadurch kenntlich machen, indem Sie ein UNA der eigentlichen Nachricht voranstellen. Dieses zeigt explizit den Gebrauch der Standard-Trennzeichen innerhalb der Nachricht an.

Nutzdatensegmente

Für die Nutzdatensegmente gibt es eine Vielzahl von Bezeichnern die eine grobe Information und Qualifier, die eine genaue Angabe über die Bedeutung bzw. Zugehörigkeit der übermittelten Daten festlegen. Dazu gibt es noch Code Werte, die eine Nachrichtenfunktion beschreiben.

Zwei Segment Beispiele zur Verdeutlichung:

DTM+137:20250502:102‘
DTM		= Bezeichner für das Segment – Datum/Uhrzeit/Zeitspanne-
+		= Trennzeichen
137		= Qualifier der festlegt, dass es sich um das Dokumentendatum handelt
:		= Trennzeichen
20250502	= Datum, wann der Beleg erstellt wurde
: 		= Trennzeichen
102		= Code der festlegt, wie das Format des Datums anzugeben ist.
‚		= Segmentende Kennzeichen

BGM+220+2334583161+9'
BGM		= Bezeichner für das Segment – Beginn der Nachricht-
+		= Trennzeichen
220		= Qualifier der festlegt, dass es sich um eine Bestellung handelt
+		= Trennzeichen
2334583161	= Auftragsnummer der Bestellung oder Bestellnummer
+		= Trennzeichen
9		= Code für Original
‚		= Segmentende Kennzeichen

Beispiel einer einfachen EANCOM ORDERS (Bestellung) mit zwei Positionen

UNA:+.? '	  
UNB+UNOC:3+4888885550836:14+9898999999999:14+250424:1312+16984+++++EANCOM'
UNH+001+ORDERS:D:96A:UN:EAN008'		Referenznummer der ORDERS lautet 001 und Versionsangaben
BGM+220+4700483161+9'			Die Bestellnummer lautet 4700483161
DTM+137:20250424:102'			Das Belegdatum ist der 24.04.2025
DTM+2:20250429:102'				Der Liefertermin soll der 29.04.2025 sein
NAD+BY+4888885550836::9'			Die eindeutige GLN des Bestellers
NAD+SU+9898999999999::9'			Die eindeutige GLN des Lieferanten
NAD+DP+4888885551234::9'			Die eindeutige GLN des Warenempfängers (z.B. ein Lager)
NAD+IV+4888885550001::9'			Die eindeutige GLN an dem die Rechnung zu Auszustellen ist
CUX+2:EUR:9'					Währungsangabe
LIN+1++9898942116455:EN'			Erste Position mit der eindeutigen Artikel GTIN 9898942116455
PIA+1+77315-705:SA'				Interne Artikelnummer des Lieferanten 77315-705
IMD+F++:::BLUSE/BLOUSES'			Artikelbeschreibung
QTY+21:36:PCE'					Menge der Bestellten Artikel ist 36
PAC++1'					Packstück/Verpackung
LIN+2++9898912548068:EN'			Zweite Position mit der eindeutigen Artikel GTIN 9898912548068
PIA+1+77315-732:SA'				Interne Artikelnummer des Lieferanten 77315-732
IMD+F++:::HOSE/PANTS'			Artikelbeschreibung
QTY+21:60:PCE'					Menge der Bestellten Artikel ist 60
PAC++1'					Packstück/Verpackung
UNS+S'						Abschnitts Kontrollsegment
UNT+21+001'					Nachrichtenende, es gibt 21 Segmente inkl. UNH-UNT  
UNZ+1+16984'					Ende, es befindet sich eine Nachricht im Umschlag 16984 

Datenübermittlung

Für die Übermittlung von EDI-Daten gibt es vielfältige Möglichkeiten. Am häufigsten werden AS2 (Applicability Statement 2, ist ein HTTP-basiertes Protokoll), oder X.400 ( BusinessMail, ein Message Transfer System der Deutschen Telekom) verwendet. Auch gesicherte Verbindungen über z.B. SFTP, SCP, OFTP usw., werden in bilateraler Absprache eingesetzt.

EDI intern oder extern?

Ein Unternehmen kann eine EDI-Abteilung aufbauen, die zusammen mit der eigenen IT aus den internen Systemen Schnittstellen definiert und jeweils ein zugehöriges Mapping erarbeitet, die dann im Datenausgang EDI Nachrichten erzeugt und über die bilateral abgesprochene Verbindung zum Partner versendet. Die von den Partnern versendeten EDI-Nachrichten ans Unternehmen werden in Umkehr durch Mappings in die systemeigenen Schnittstellen konvertiert, um automatisch eingelesen und verarbeitet werden zu können. Da sich Unternehmen ständig an den Markt anpassen müssen oder interne Betriebsabläufe oder Systeme ändern, gibt es auch in der EDI-Verarbeitung meistens kleinere oder größere Projekte, die zu Anpassungen an diesen Schnittstellen führen. Wie viele Mitarbeiter benötigt werden, um eine interne Abteilung aufzubauen, die den Kundenkontakt, Support und IT-Leistungen koordiniert, ist einer der entscheidenden Faktoren, ob diese Lösung in Betracht kommt.

Eine externe Lösung, die viele Unternehmen wählen hat den Vorteil, dass keine Infrastruktur im Unternehmen selbst aufgebaut werden muss. Der EDI-Dienstleister übernimmt alle Aufgaben, die für den elektronischen Datenaustausch mit den Partnern nötig sind. Durch Analysen werden die systemeigenen Schnittstellen des Unternehmens vom EDI-Dienstleister ohne Veränderung aufgenommen. Er verfügt in der Regel über eigene Konverter Systeme, wo die aufgenommenen Schnittstellendaten in abgesprochene EDI-Formate konvertiert werden, um diese an die zugehörigen Partner zu versenden. Der Empfang von Daten, die der Partner versendet hat, wird entsprechend umgekehrt verarbeitet und die passend konvertierten Daten an die Schnittstelle übergeben. Er übernimmt die elektronische Kommunikation zum Unternehmen und den Partnern sowie den AMS-Support.

Fazit:

Die hier dargestellte, kurze Erläuterung von EDI, EDIFACT und EANCOM ist ein sehr kleiner Teil des gesamten Spektrums dieser Thematik und gibt nur einen kurzen Einblick in die Welt des elektronischen Datenaustausches. Es zeigt aber die Möglichkeit auf, einen einfachen und sicheren Datenaustausch zwischen Kunde und Lieferant herzustellen, so dass diese Unternehmen die verschickten Daten ohne manuelle Bearbeitung weiterverarbeiten können. Die Einsatzmöglichkeit von EDI ist sehr vielfältig, effizient und kann Unternehmen große Kosteneinsparungen in der Datenverarbeitung erbringen. Eine umfassende Beratung von EDI-Spezialisten mit anschließender Analyse der internen Unternehmensabläufe, aktueller Datenverarbeitung und bestehenden Systemen sind für die Einführung mehr als empfehlenswert. Es gibt viele Faktoren die bei der Einführung von EDI entscheidend sind, wie z.B., mit wie vielen Partnern soll der Datenaustausch erfolgen, welche Nachrichtenarten möchte man einführen, welche Anzahl an Nachrichten werden pro Tag oder Monat ausgetauscht, wie viele Schnittstellen werden benötigt und noch viele andere.  Aus der Analyse können dann auch die möglichen Schlüsse für eine interne oder externe Lösung ausgearbeitet werden, um die optimale Effizienz auszuschöpfen.

The post EDI, EDIFACT und EANCOM Kurzeinführung appeared first on Rhein-Ruhr-Informatik.