Instead of producing unpredictable raw text, our application enforces guaranteed data schemas (title, body, and SEO keywords), real-time progress feedback via SSE streaming, and three distinct perspectives tailored to specific audiences: Friendly SaaS Marketer, Technical Blogger and 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)

Prerequisites

• Python and Node.js installed on your computer.
• An Azure OpenAI resource with a deployed model (e.g. GPT-4.1-mini or GPT-4o).
• An Azure Content Safety resource.
• Basic knowledge of FastAPI, Next.js, and TypeScript.
• Basic understanding of Server-Sent Events (SSE) and Pydantic schemas.

Step 1: Define the Pydantic Schema

The first step is defining the structure our application expects from the model. We create Pydantic models for individual variations and the overall response container:

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

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

This schema acts as a dual contract: it guarantees the shape of our backend API responses for the Next.js frontend, and it is passed directly to Azure OpenAI's Structured Outputsengine to strictly constrain the model's output JSON Schema.

Step 2: Implement Persona System Prompts

Marketing copy requires different tones depending on the channel and audience. In our app, we define three 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.“
        ),
    },
}

When a request arrives, the backend dynamically combines the selected persona system prompt with user instructions containing the brief, target audience, format (LinkedIn post, marketing email, or landing page copy), and output language.

Step 3: Guardrail Content with Azure Content Safety

Before invoking the language model, the backend validates the brief against Azure Content Safety. This detects harmful inputs across categories such as violence, hate speech, self-harm, and sexual content:

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

If harmful content is detected, the API returns a structured 400 Bad Request with specific category details. This prevents prompt injection and misuse while avoiding unnecessary token costs on blocked prompts. A local heuristic is also available as a fallback when offline.

Step 4: Real-Time SSE Streaming and Incremental Parsing

Generating three comprehensive marketing variations takes several seconds. Rather than making the user wait for the full response, we use Server-Sent Events (SSE) via FastAPI's 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“)

The streaming generator parses JSON chunks on the fly. As soon as each variation's closing bracket is reached, an SSE variationevent is emitted. This allows the Next.js frontend to render each content card immediately as it finishes, providing a fast and reactive user experience.

Step 5: Connect FastAPI and Next.js with Observability

The Next.js frontend connects directly to the FastAPI stream using standardfetch and reads chunks with a ReadableStreamDefaultReader. It renders live progress, displays persona badges, and supports instant copy, JSON view, and file export. In addition, every request captures observability data:

• Latency in milliseconds.
• Prompt, completion, and total token usage.
• Estimated execution cost based on Azure OpenAI token pricing.
• Per-client generation logs stored in SQLite and process memory.

Why Personas and Structured Outputs Matter

Without persona steering and structured outputs, LLM outputs tend to be generic, unpredictable, and difficult to parse reliably in production applications. Combining explicit persona instructions with Pydantic schemas yields predictable, high-quality results tailored to real marketing workflows.

• The frontend receives a guaranteed, type-safe data schema.
• No regex or Markdown code block stripping is required in application code.
• Personas provide consistent brand voice and clear positioning.
• Streaming eliminates perceived latency and improves engagement.

Conclusion

With Next.js, FastAPI, Azure OpenAI, and Azure Content Safety, we built an end-to-end content generation application with enterprise-grade guardrails and real-time streaming.

FastAPI Backend → Controls safety checks, persona mapping, streaming, and token logs
Azure OpenAI → Delivers structured, persona-driven generation via GPT-4.1
Azure Content Safety → Blocks harmful prompts before execution
Next.js Frontend → Delivers a responsive, multi-language UI with live SSE card rendering

This combination transforms generative AI from an unpredictable chat experiment into a dependable, production-ready content engineering pipeline.

I hope this short tutorial was helpful.

Now let’s code!

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

Instead of using a separate service for every task, we can send an image together with our instructions to the model and extract information such as a description, tags, detected objects and OCR text.

The important point is that the AI response should not simply be arbitrary text. Our application needs a defined data structure. For this purpose, we use JSON Schema with Pydantic.

Prerequisites

• Python must be installed on your computer.
• An Azure OpenAI deployment with GPT-4.1-mini must be available.
• Basic knowledge of Python and FastAPI.
• Basic knowledge of REST APIs and JSON.
• An Azure OpenAI client must be configured in the backend.

Step 1: Define the Pydantic Schema

First, we define the structure that our application expects from the AI using Pydantic:

This class defines both the contract for our application and the schema for the model's structured response. This means that we do not need to manually create the JSON Schema as a dictionary.

Step 2: Send the Image and Prompt to the Model

The image is read by the backend and then passed to the model as a Base64 Data URL.

In addition, we send a prompt describing which information should be extracted from the image. For example:

The user only sees the upload functionality. The actual instructions used for the image analysis remain in the backend.

Step 3: Use Structured Outputs

Now comes the important part. Instead of simply asking the model to return JSON, we use Structured Outputs:

With text_format=AnalysisResult, we use our Pydantic class as the schema for the response.

The model therefore receives a defined structure, and our backend can use the result directly as an AnalysisResult:

We no longer need to remove Markdown code fences or manually parse the returned text into JSON.

Step 4: Return the Result to the Frontend

Since our FastAPI endpoint also uses AnalysisResult, we can return the result directly:

The frontend then receives a predictable structure:

Why Structured Outputs?

A simple prompt such as “respond only with JSON” can work, but it is not an ideal contract between an AI model and an application.

With Structured Outputs, we explicitly define the expected structure.

This provides several benefits:

• The backend receives a predictable data structure.
• The Pydantic model can be used for both the API and the AI response.
• Less manual JSON parsing is required.
• The frontend can work directly with a defined structure.
• The prompt does not need to describe the complete JSON format.

Structured Outputs as a Contract

While building the application, I noticed that the model could sometimes return information that was not actually present in the image, such as an incorrect price or object. This is a common AI hallucination. Structured Outputs does not prevent hallucinations, but it provides a reliable contract between the AI and the application.

By defining the expected fields and types with Pydantic, the backend knows exactly what structure to expect. To reduce hallucinations, I also added explicit instructions to the prompt, such as “Do not invent prices or links. If the information cannot be reliably identified, return an empty value.”

This combination makes the application more predictable: Structured Outputs protects the structure, while clear prompting and validation help protect the data.

OCR or Multimodal AI?

For pure text recognition, Azure provides specialized OCR and Document Intelligence solutions. These are particularly useful when the main goal is to reliably extract text, layouts, tables or positions.

In our case, however, we do not only want to recognize text. We want to analyze the entire image and extract different types of information from it.

That makes a multimodal model such as GPT-4.1-mini an interesting alternative:

Image + instructions → model → structured data

This allows us to combine image understanding and structured data extraction in a single step.

Conclusion

With Azure OpenAI and GPT-4.1-mini, we can relatively easily build an application that analyzes images and converts the results directly into a structure that our software can consume.

The key point is not only the model we use, but also the contract between the AI and the application.

With Pydantic + Structured Outputs, a free-form AI response becomes a structured API response.

This allows AI to do more than just generate text. It can act as an additional processing layer between an image and our application.

I hope this short tutorial was helpful.

Now let’s code!

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

Cloud Integration allows us to make changes over the messages, like mappings, or converting from one structure to another. Cloud Integration is not only powerful for data manipulation, but also offers strong monitoring features. In addition to Debug or Trace modes like any development IDE, it also allows us to monitor the necessary information without debugging.

For each service we can set Log Level to 5 different modes.

Default log configuration is set as Info. Which allows us to see status of every process, like completed, abandoned, canceled, failed, etc. This mode doesn’t allow us to see the message body, message headers, basically what is passing through over CPI. It is important to protect data for security reasons and to reduce memory consumption.

But if the process fails, how can we find out the issue?
Trace mode is useful when the same message can be received again. Before receiving messages, this mode should be activated. In trace mode, both the message body and headers can be viewed at each step.

The process that gets an error is displayed. In this mode, it is much easier and faster to identify the step where the error occurs.

However, CI allows us to stay in trace mode for only 10 minutes, then it returns automatically to the previous mode (info, error, or none). Additionally, the message can no longer be accessed after 1 hour. During development, this mode is often used. However, in production, after the process fails, we cannot re-trigger the same process. It is also not recommended to reveal the full message in production due to security reasons.

In that case, how can we indicate which message gets an error without exposing the entire message? Here’s what SAP offers:

There are some pre-built properties for monitoring and filtering messages. This feature is very helpful for understanding specific messages’ status and filtering the messages in monitoring screen. We can customize those Properties according to needs. In this example, Application Message ID is set from Order Id, and the type of Order is set as Application Message Type. If this order gets an error, we can directly point out the order number without revealing the whole message.

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.

If those pre-build properties are not enough, or just need to add more customized properties, we can also add custom monitoring headers. These custom headers are not considered as actual headers. They are not sent to the receiver system. They are used only for monitoring purposes as internal.

We can also filter the messages according to monitoring properties and custom headers. For example, we have 7 messages in Completed status with the Message Type: Initial Order

But we have only 1 message with the order number 1000000.

By default, we cannot view the content of a message at any point during the process. However, in some cases, we may need to see the message body, especially when it’s in a failed status. To do this, we can create an attachment for monitoring purposes. Attachments can be in any text format, and they are customizable, allowing us to add information that helps identify the error. Additionally, attachments can be set up to be included only in error cases.

Most common usage cases:
– Seeing the whole body at the important points. – Like before mapping, after mapping
– In error case, the whole message body at the error point.

By default, Cloud Integration interface does not show any messages or headers to users. This is important for both security reasons and memory management.

However, in some cases, the failed message needs to be detected without using trace or debug mode, especially in a production environment. To achieve this, in info mode, necessary fields can be set as custom properties and attachments to identify which message has failed.

Cloud Integration stores logs maximum for 1 month. This 1-month period is intended for working with errors, detecting issues, and solving problems.

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

1. Learning and Preparation

Before I even started studying, I wanted to understand what to expect. The Solutions Architect – Associate exam tests a wide range of topics: architectural principles, high availability, security, cost optimization, and many services like EC2, S3, RDS, Lambda, or VPC.

I divided my preparation into three phases:

Phase 1: Refreshing the basics
I started with the free AWS Skill Builder, where there’s an official course called "Exam Prep: AWS Certified Solutions Architect – Associate". It gives you a good sense of the structure and depth of the questions. Additionally, I bought two topic-related courses on Udemy to deepen my knowledge further – they offered many practical examples and explanations that helped me a lot in understanding more complex subjects.

Phase 2: Intensive training
Then I used Udemy courses from instructors like Stéphane Maarek and Tutorials Dojo. I found the many hands-on labs particularly helpful – for example, setting up a VPC or an Auto Scaling group. These exercises helped me a lot to truly understand the concepts.

Phase 3: Exam simulations
In the last two weeks before the exam, I focused on practice exams. The questions on platforms like Whizlabs or Tutorials Dojo were often very similar to the real ones – sometimes almost identical in the way they were phrased.
I tried not only to know the correct answer but also to understand why the other answers were wrong – that’s crucial!

2. Equipment and Room Requirements

I decided to take the exam online from home – convenient, but with clear rules.

Technical requirements:

• A reliable laptop or PC
• A stable internet connection (LAN preferred)
• A working webcam and microphone

Before the exam, a Pearson VUE tool automatically checks whether your camera, sound, and network are fine.

Room preparation:
The room must be clean and quiet – no books, no notes, no other person in the room. I even had to briefly show my walls by moving the camera around. My desk was completely empty, and I placed my smartphone far away. That may seem a bit strict, but it ensures fairness.

3. Registration and Identity Check

Registration is done through the AWS Certification Portal. There, you can choose whether to take the exam online or in a test center.

After registration, you receive an email with all the steps. On the day of the exam, I simply clicked “Start Exam”. Then a chat window opened with the proctor.

The proctor checked my identity using my ID, asked me to show the entire room with the webcam, and verified that there were no unauthorized items nearby. After a few minutes, everything was ready – and the exam could begin.

4. The Exam Process

The exam lasts 130 minutes and consists of about 65 multiple-choice questions. Some questions are short and direct, others quite long and describe complex architectural scenarios.

I got into the habit of first answering all the questions I was sure about and marking the rest. In the end, I still had enough time to calmly review about 10 difficult questions.

A small tip:

Read the questions very carefully – sometimes a single word (“cost-effective”, “highly available”, or “fault tolerant”) changes the entire meaning.

After I submitted the last question, the system immediately displayed: “Your result will be available in next 5 days.”
Then, the email came: “Congratulations! You passed the exam!”
That was a great feeling!

5. Useful Resources and Tips

If you want to pass the AWS Certified Solutions Architect – Associate exam, these resources can help you:

• AWS Skill Builder: Official, free learning platform
• AWS Whitepapers: Especially “Well-Architected Framework” and “Security Best Practices”
• Udemy: Courses by Stéphane Maarek or Neal Davis
• Tutorials Dojo / Jon Bonso Practice Exams: Realistic practice questions
• AWS Free Tier: To try out services without costs

Conclusion

The path to the AWS Certified Solutions Architect – Associate was not only a technical challenge for me but also a personal journey. I learned a lot about modern cloud architecture and understood how important good design in AWS really is.

So if you’re thinking about taking this step: Do it! With patience, curiosity, and solid preparation, you can succeed. And the certification opens many doors in the IT world.

Good luck and have fun on your own AWS adventure!

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

In modern software development, speed and scalability are crucial. Companies want to deliver features quickly without worrying about maintaining infrastructure. This is where serverless computing shines.

With AWS Lambda and Amazon API Gateway, developers can build a fully functional REST API without managing servers. AWS automatically takes care of scaling, availability, and billing — you only pay for the requests that are actually processed.

In this article, we will explore how to set up a simple REST API using AWS API Gateway and AWS Lambda, with examples in Python.

What is Serverless?

The term serverless doesn’t mean “no servers” — servers are still involved, but they are fully managed by the cloud provider. Developers focus only on writing code, while AWS handles:

– Provisioning and scaling (from zero to millions of requests)
– High availability
– Security and patching
– Billing based on actual usage

For REST APIs, the combination of API Gateway and Lambda has become a common pattern. Let’s see how they work together.

Architecture Overview

The flow looks like this:
1. A client (browser, mobile app, Postman) sends a request to an API Gateway endpoint.
2. API Gateway routes the request to a configured Lambda function.
3. The Lambda function runs your custom code (Python in our case).
4. Lambda returns a response, which API Gateway forwards back to the client.

This simple architecture is powerful because you can connect multiple Lambda functions to different API routes and methods (e.g., GET /users, POST /orders).

Step-by-Step Setup

1. Create a Lambda Function

1. Log in to the AWS Management Console.
2. Go to AWS Lambda → Create function.
3. Choose Author from scratch, give it a name (e.g., hello-world), and select Python 3.x as runtime.
4. In the code editor, paste the following function:

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. Create an API Gateway

1. Go to Amazon API Gateway → Create API.
2. Choose HTTP API (simpler) or REST API (more configurable). For this tutorial, select HTTP API.
3. Create a new API and attach it to your Lambda function (hello-world).
4. Deploy the API.

3. Test the API

Once deployed, you will get an endpoint URL such as:

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

Now test it:

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

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

Congratulations! You have just built a serverless REST API with AWS.

Why Use API Gateway + Lambda?

– Scalability: Handles traffic spikes automatically.
– Cost efficiency: Pay only when functions are executed.
– Simplicity: No server management, no patching, no scaling headaches.
– Flexibility: Connect Lambda to databases (DynamoDB, RDS), queues (SQS), or even event streams (Kinesis).

Next Steps

What we built is a minimal example. In production, you might:
– Add authentication & authorization (AWS Cognito, IAM policies, custom JWT).
– Use Infrastructure as Code (AWS SAM, CDK, or Terraform).
– Enable logging & monitoring (CloudWatch, X-Ray).
– Connect to other AWS services for full applications.

Conclusion

AWS API Gateway and AWS Lambda together make it incredibly easy to create serverless REST APIs. With just a few clicks and a small Python script, you can deploy an endpoint that scales automatically and costs only when used.

If you are building modern applications, experimenting with microservices, or simply want to avoid server management, this serverless approach is a great starting point.

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

SAP BTP allows the deployment of multiple services and applications, each with its own role collections. These services are often deployed across different subaccounts. It's possible to manage users and roles separately in each subaccount.

However, it is also possible to centralize user and role management by using a single identity service by establishing trust between the identity service and BTP subaccounts.

This post will guide you through setting up role collection mappings between BTP and Identity Authentication Service (IAS). This allows you to manage role collections for multiple subaccounts from a single identity provider.

Prerequisites

If you have an identity provider, you can configure it as a custom provider for a BTP subaccount. It can be used as the source for users and role collections.
There are some prerequisites for setting up role collection mappings:

• You must have the Subaccount Administrator role in the subaccount that will be linked (trusted) with SAP Cloud Identity Services.
• The SAP Cloud Identity Services tenant can be subscribed to in a different subaccount, but it must be part of the same global account and in the same region.

You can follow the steps in this SAP Help document to configure the trust between your subaccount and the SAP IAS tenant:

👉 You can follow the steps in this SAP Help document to configure the trust between your subaccount and the SAP IAS tenant:

NOTE: To be able to use the role collection mapping, you must log in to the application with a user that is defined in the identity provider. - Not with a BTP user.

Configurations

1. BTP Role Collections

Before creating a role collection mapping, make sure that you have the necessary role to access “Role Collections” in your subaccount.

Navigate to:

<Ihr Subaccount>          →    Security     →   Role Collections 

You can use default role collections that are defined for the standard BTP applications.

Alternatively, you can create a new custom role collection by clicking on the Create button in the top right corner.

SAP BTP Role Collections

In this example, a new custom role collection called “My_Custom_Role” is created.

• SAP Cloud Identity Services

Before starting to configure role collection mapping, we must ensure that we send necessary attributes to the application. In the SAP Cloud Identity Service, navigate to

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

Application Page on SAP Cloud Identity Services

In the assertion attributes, you must have a Groups attribute. This is what we will send to the application as a BTP role.

Assertion Attributes of an Application on SAP Cloud Identity Services

Then we should create a group for a BTP role that we will be mapping. Navigate to
                        Users & Authorizations   →  Groups

Create a new group, if you have already one, add members who will have this BTP role.

Groups and its Users on SAP Cloud Identity Services

• BTP Role Collection Mapping

Now we are ready to make role collection mapping. Go to your BTP subaccount and navigate to
                        <Ihr Subaccount>   →   Security   →   Trust Configuration,

and click on the custom identity provider that you have established in the beginning.

SAP BTP Trust Configurations

Click on the New Role Collection Mapping and choose your BTP role collection (1). You can also choose your BTP custom role collection.

For “Attribute”, you should write what you defined in IAS as a Groups attribute (2). In this case, we can leave it as “Groups”.

In the “Value” section, you should write your IAS group’s name which corresponds to your BTP role collection (3).

Then save it.

SAP BTP Role Collection Mapping

You can see your mapping from Role Collections.

SAP BTP Role Collections Mapped with IAS Groups

Conclusion:

• You can manage this role collection on SAP Identity Authentication Service with managing the corresponding group’s members.
• In the BTP subaccount, you cannot see the user's role assigned by IAS. These roles are assigned to users when they are authorized to your application via SAP IAS.

Note:

Please be aware that your IAS user must be created in your SAP BTP subaccount as well. You can check more about to create user on BTP from here:

👉 Managing SAP BTP Users

Hope this blog will help you to manage your BTP roles from your identity provider!

Feyza Sahin

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

But how exactly does AI impact our day-to-day work?

As a frontend developer, I started using AI tools to enhance my productivity. And as I integrated them into my workflow, I found myself asking a few important questions:
Is AI a threat to our jobs? Or is it an enabler of innovation? Will it eventually eliminate software developers altogether? What’s coming next?

Let’s break it down.

💡 How AI Boosts Software Developer Productivity
AI tools have significantly accelerated many parts of my development process. Here are some key ways they’ve helped:

• 🔤 Code Suggestions & Autocompletion
  Tools like Windsurf (or GitHub Copilot) predict what you’re likely to write next, saving time on syntax and boilerplate.
• 🧱 Component Generation
  Need a responsive navbar, modal, or form? AI can generate reusable UI components from simple prompts—often following best practices.
• 🐞 Debugging & Testing
  AI can detect bugs, suggest fixes, and even write unit tests, helping catch issues early in the cycle.
• 🎨 Design-to-Code Conversion
  Some tools can convert designs from platforms like Figma into clean HTML, CSS, and JavaScript—reducing manual translation time.
• 📚 Documentation & Refactoring
  Writing docs and cleaning up code is no longer a chore. AI can help produce readable documentation and suggest clearer code structures.

By automating the repetitive and mundane, AI frees up time to focus on logic, architecture, and creative problem-solving.

But how to properly use AI and get the best out of it?

🧠 Use AI as a Helper, Not a Replacement
When I first started using AI in my workflow, I gave it a complex task and expected it to deliver it from scratch. The result? Disappointing. The output was full of broken, unstructured code.

Over time, I realized the trick is to let AI assist you—not lead you. Think of AI as a junior developer or a copilot. You’re still the one steering the ship.

Here’s what works:

• Define the structure.
  You lay out the architecture. Let AI fill in the blanks—utility functions, helper methods, or minor features.
• Review and refine.
  Always double-check what AI generates. It might miss context, introduce bugs, or follow the wrong conventions.
• Stay in control.
  Don’t delegate critical parts to AI. You're the lead developer—AI is your assistant, not your replacement.

🧾 The Art of Writing Prompts
One of the most underrated skills when using AI as a developer is the art of crafting good prompts. The quality of your input directly shapes the quality of the output. A vague or overly simple prompt will likely produce vague or incorrect code. But a detailed, structured prompt can generate surprisingly accurate results.

The clearer and more contextual your instructions, the better the response.

Tips for writing great prompts:

• Specify language, framework, and desired output (e.g., “React functional component with Tailwind CSS”).
• Add examples or constraints.
• Break down big tasks into smaller, focused parts.

🎯 Good Prompt = Good Output
It’s easy to blame the AI when code doesn’t work—but often, the issue starts with the prompt itself. Treat prompt writing like writing clear requirements for a feature. The more context you give, the more relevant the output will be.

Here’s a quick example:

• Weak prompt:
  "Make me a form."
• Strong prompt:
  "Create a responsive contact form using React, with input validation for email and phone number, and styled using Tailwind CSS."

The second one gives the AI a proper direction, and that makes all the difference.

✅ Key Advantages of Using AI in Your Dev Workflow
Beyond speed, AI brings a number of practical benefits to modern development:

• 💼 Increased Efficiency
  Routine tasks like writing tests, setting up config files, or converting formats become faster and less error-prone.
• 📈 Faster Prototyping
  AI helps bring ideas to life quickly, allowing you to validate designs and features without heavy lifting.
• 💡 Knowledge on Demand
  AI tools often act like intelligent search engines, providing instant explanations, code snippets, or best practice suggestions.
• 🧠 Improved Code Quality (when guided)
  With the right guidance, AI-generated code can follow established standards and catch anti-patterns early.
• 🌐 Tech Stack Flexibility
  AI lets you work confidently across unfamiliar libraries or languages by offering context-aware help.
• ⏱ Time Savings
  Small tasks that typically steal your attention—like regex patterns, data formatting, or minor bug fixes—become instant wins with AI.

Used wisely, these advantages turn AI from a novelty into a practical accelerator for your daily workflow.

But with all these amazing capabilities comes natural concerns..

🤖 Will AI Replace Software Developers?
Short answer: No—at least not anytime soon.
While AI can automate certain tasks, it still lacks the deeper understanding and problem-solving skills that human developers bring to the table.

Building accessible, performant, and scalable applications isn’t just about writing code. It requires strategic thinking, creativity, and collaboration—areas where humans still have the upper hand.

Here’s why developers remain essential:

• Contextual Understanding
  AI doesn’t truly grasp business goals, user needs, or the product vision.
• Human Collaboration
  Developers communicate and collaborate with designers, PMs, stakeholders—something AI can’t fully replicate.
• Creative & Strategic Decision Making
  Choosing the right tools, optimizing UX, and making architectural decisions demand human judgment.
• Problem Solving
  Real-world software is messy. Edge cases, debugging, and planning require reasoning that AI doesn’t yet possess.

But if it lacks all of those concepts, how should we use AI in our workflow?

🧭 Conclusion
AI is changing the game for software developers—not by replacing us, but by amplifying our abilities. It removes friction, boosts efficiency, and helps us deliver faster. But true success lies in knowing when and how to use it.

The future belongs to developers who embrace these tools with a thoughtful mindset—balancing automation with human creativity, judgment, and leadership.

At the same time, AI is evolving at an incredible pace. Tools, capabilities, and best practices are changing month by month. What worked yesterday may be outdated tomorrow. That’s why developers should treat AI like any other part of the tech stack: stay curious, stay sharp, and always stay updated.

So yes, use AI. Let it assist you.
But always keep your hands on the wheel — and your eyes on the road ahead.

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

First, you need a hypervisor, then a compatible ISO file, followed by VM configuration, partitioning, Windows installation, driver setup, and so on. In short: It’s doable, but not exactly pleasant.

But what if I told you that you could launch a full Windows installation inside a Docker container—with shared storage, RDP access, and optional VLAN support? Sounds crazy? It kind of is. But it works.

The Idea Behind the Project

A developer named Kroese published a GitHub project that makes this possible. A Docker container that automatically sets up a fresh Windows installation—no manual setup required. Just start the container, wait a few minutes, and you get a fully functional Windows environment. Access it via your browser or RDP.

And the best part? You don’t even have to install Windows yourself. The container handles the entire process—from fetching the image to finalizing the setup.

How Does It Work Technically?

If you look closely at the Docker command, you’ll notice the flag passing through /dev/kvm—Linux’s kernel-based virtualization mechanism. In short: This isn’t a "true" Windows container but rather a Linux container running a KVM-based VM. So, no magic here—just clever automation built on proven technology.

The catch? Hardware virtualization must be available and enabled—otherwise, nothing will work.

The Biggest Advantage: Convenience

What makes this special isn’t technical innovation but the massive gain in convenience. The most tedious aspects of a Windows installation—partitioning, initial setup, language, and keyboard selection—are completely automated.

Yet, you still get all the benefits of a "normal" KVM-based VM: USB and SATA passthrough, adjustable CPU cores and RAM allocation, and even optional PCIe passthrough (though that’s probably better suited for dedicated VMs).

Everyday Use: RDP Instead of VNC

The container’s web interface uses VNC, which is fine for quick access—but it’s slow and doesn’t support audio. RDP is the better option here. The container forwards the RDP port by default, allowing easy remote access from macOS, Linux, or even another Windows machine.

With shared folders, you can also mount directories from the host system, making file transfers between Windows and Linux seamless. The default container allocates 2 CPU cores, 4 GB of RAM, and 64 GB of storage—all adjustable via environment variables.

Multiple Windows Versions? No Problem!

The container supports not just Windows 11 but older versions too—from XP to Server 2022. You can even use stripped-down variants like Tiny11 or Tiny10—or supply your own ISO. In one test, five Windows versions ran simultaneously: XP, Vista, 7, 10, and 11—all on an Intel N100 system drawing just 18W.

(Windows 8.1 refused to cooperate—but who misses it anyway?)

What About Licensing?

The Windows images come either directly from Microsoft (for newer versions) or from open sources like Bob Pony. Fresh installations are unactivated but run without restrictions for 30 days. For longer use, you’ll need a valid license key. According to the developer, the project itself contains no proprietary code and relies entirely on open-source components.

Verdict: Simple, Practical, Brilliant

Whether you need to quickly test Windows software, tinker with legacy systems, or run specialized tools like BIOS editors—this Docker project offers a sleek, hassle-free solution without major compromises. Of course, it’s no replacement for a high-performance VM with a dedicated GPU, but that’s not the goal.

What remains is an impressive example of what’s possible today with a bit of creativity and open standards—no installation headaches required.

And who knows? Maybe Windows XP will save your day yet again.

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

Why an Uptime Monitor Is Essential

Uptime monitors notify you as soon as your website becomes unreachable. Most solutions fall into two categories:

• Hosted services like UptimeRobot, Hyperping, or OhDear, which regularly check your website.
• Self-hosted open-source tools like Uptime Kuma or OpenStatus, which you run yourself. wie Uptime Kuma oder OpenStatus, die du selbst betreibst.

However, self-hosted solutions have a major drawback: if your entire server goes down, the monitor does too. This means you would need to host it on a completely separate server or provider – which is complex and error-prone.

The Solution: Upptime

This is where Upptime comes in – a completely free and open-source monitoring solution that you can run directly using your GitHub account. No external servers, no costs. Upptime leverages three core GitHub features:

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

1. GitHub Actions for Monitoring

GitHub Actions enable automated workflows – e.g., tests, deployments, or regularly checking if your website is reachable. Upptime configures these checks using simple YAML files in the .github/workflows.
Using GitHub's built-in scheduling, you can have checks run automatically every 5 minutes, for example.

2. Notifications via GitHub Issues

If your website goes down, Upptime automatically creates a GitHub-Issue – a kind of incident report. This feature can be extended with notifications via Slack, Telegram, Discord, email, or even SMS.
Once your website is back online, Upptime automatically closes the issue.

3. GitHub Pages as a Status Page

Another strength: Upptime generates a public status page via GitHub Pages.
This displays your website’s availability in real-time, including load times and history charts. Comments on incidents are automatically included – perfect for transparent communication with your users.

Setting Up Upptime

Setup is simple:

1. Fork the official Upptime-Repository as a template.
2. Create a new public repository based on that template.
3. Generate a GitHub access token with the required permissions (Actions, Issues, Contents, Workflows).
4. Add this token in the repository settings under Secrets as GH_PAT.
5. Configure your .upptimerc.yml with your GitHub username, repo name, and the URLs to monitor.
6. Commits automatically trigger checks, and status pages are generated.

Conclusion

Upptime is an elegant solution for developers, freelancers, and agencies who want a free, reliable, and transparent monitoring system – without external servers.

With Upptime, you get:

• Regular checks of your website
• Automatic incident reports
• Public status pages with history and load times

All you need is a GitHub account.
Curious how long setup takes?
The video recorded the setup and editing process using the open-source time tracker Solidtime – another interesting GitHub-based tool.

You’ll find links to Upptime, documentation, and other tools in the video description.
And who knows – maybe Upptime is the perfect solution for your next project.

🔗 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 our global business world, smooth communication between business partners is one of the most important criteria for conducting worldwide trade in its current form. To achieve this, EDI (Electronic Data Interchange) was introduced with the goal of electronically exchanging business documents such as product master data, orders, delivery notes, and invoices.

Edward Guilbert is considered the father of electronic data exchange, having implemented EDI in the supply chains of the U.S. transportation industry as early as the 1960s. To enhance the global reach of the technology, UN/EDIFACT EDI was created by the United Nations in 1985. These documents are exchanged as structured data without manual intervention.

Compared to paper-based processes, EDI has the key advantage of automated processing with a very low error rate and the ability to automatically import EDI messages into the company’s ERP system (Enterprise Resource Planning).

What is EDIFACT?

UN/EDIFACT stands for United Nations rules for Electronic Data Interchange for Administration, Commerce, and Transport. It includes internationally agreed standards, directories, and guidelines for the electronic exchange of structured data between independent computerized information systems worldwide.

EDIFACT (Electronic Data Interchange for Administration, Commerce and Transport) consists of a hierarchical structure, with the top level referred to as an interchange. An EDIFACT message is a complete, structured sequence of data representing a single business transaction, such as an order. The UN/EDIFACT syntax is defined in the ISO 9735 standard. It includes more than 200 different message types and is now used by over 300,000 companies worldwide.

EANCOM – A Subset of EDIFACT

EANCOM® (EAN + Communication) is a globally valid message standard that allows for the electronic exchange of business data across industries and countries. It is the most widely used global standard for EDI. A special feature of EANCOM® is its use of global GS1 identification standards, such as:

GLN – uniquely identifies companies or company units such as locations or warehouses.

GTIN – uniquely identifies articles, products, or variants worldwide.

SSCC/NVE – an 18-digit number for transport units like pallets or shipping cartons. In Germany, it's also known as NVE (shipment unit number).

More information can be found on the GS1 Germany website: www.gs1-germany.de

In the EANCOM subset, only the required segments from the underlying UN/EDIFACT standard are used. The particular features of a subset are the industry-specific qualifiers. These extend the standard with the common and necessary specifications used in the respective industry.

The EANCOM® standard was originally designed to meet the needs of the consumer goods industry. Today, however, the EDI standard is cross-industry. Examples include healthcare, logistics, fashion, eCommerce, or cash logistics. 

EANCOM (EAN + Communication) stands for detailed descriptions of simplified EDIFACT messages that users can easily understand and implement in practice. GS1 is responsible for the ongoing development of the EDIFACT subset EANCOM®.

• EANCOM includes all GS1 identification standards (e.g., GLN & GTIN), making it highly valuable for standardizing electronic data exchange.
• It enables direct electronic processing upon receipt of the data, with immediate access to the transmitted information in the shortest processing time.
• Advantages of international corporate communication using a standardized data structure.
• The electronic transmission ensures high data consistency compared to manual entries in ERP systems and eliminates the need for extensive control processes to approve the data. 
• Noticeable reduction in administrative and personnel effort as well as postage and shipping costs.

Structure of a Transmission File

A simple transmission file consists of a payload header segment and the payload data. These can be roughly interpreted as an envelope with sender and recipient, along with the actual content.

These segments always begin with “UN” and are called service segments. Each segment, similar to an XML structure, defines a start and end for logically grouped data.

UNB as the start and UNZ as the end (this is the envelope)

UNH as the start and UNT as the end (this is the full message)

Additionally, UNS within the UNH–UNT range serves as a section control segment. Depending on the message type, there may be control segments or not.

Within UNH–UNT, the message is divided depending on the message type into three parts:

• A header section, which relates to the entire message.

• A line item section, where the data applies only to the specific item.

• A summary section, which includes segments such as total number of order lines or total invoice amount.

Additionally, there is the possibility to use an extended character set. Most trading partners do this and indicate it by placing a UNA segment in front of the actual message. This explicitly indicates the use of standard separators within the message.

Payload Segments

There are many identifiers for payload segments that provide general information, and qualifiers that define the specific meaning or association of the transmitted data. In addition, there are code values that describe the function of the message.

Two example segments for clarification:

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

Example of a Simple EANCOM ORDERS Message with Two Items

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 

Data Transmission

There are various ways to transmit EDI data. The most commonly used are: AS2 (Applicability Statement 2) – an HTTP-based protocol X.400 (BusinessMail) – a message transfer system from Deutsche Telekom Secure connections like SFTP, SCP, OFTP, etc., are also used based on bilateral agreements.

EDI Internally or Externally?

A company can build its own EDI department that, in cooperation with the internal IT department, defines interfaces from internal systems and develops corresponding mappings. These mappings generate EDI messages on output, which are then sent to partners using an agreed-upon communication method. Incoming EDI messages from partners are converted via mappings into the company’s internal format so they can be automatically read and processed. As businesses constantly adapt to market conditions or change internal processes or systems, there are often ongoing EDI projects that require updates to these interfaces. How many employees are needed to build such an internal department (handling customer contact, support, and IT services) is a key factor in deciding whether to pursue this option.

An external solution, which many companies choose, has the advantage of not requiring internal infrastructure. The EDI service provider takes over all tasks necessary for electronic data exchange with partners. Through analysis, the provider identifies the company’s internal interfaces without requiring changes. They usually have their own converter systems, which translate the captured data into the agreed EDI formats and send them to the appropriate partners. The receipt of partner data is processed in reverse, and the converted data is handed off to the internal interface. The provider handles communication between the company and its partners, as well as support services.

Conclusion:

This brief explanation of EDI, EDIFACT, and EANCOM represents only a small part of the entire topic and provides a quick overview of the world of electronic data exchange. It shows the potential for simple and secure data exchange between customers and suppliers, allowing companies to process received data without manual handling. EDI offers highly efficient and diverse use cases and can lead to significant cost savings in data processing. Comprehensive consulting by EDI specialists and a follow-up analysis of internal company workflows, current data handling, and systems is highly recommended before implementation. There are many key factors to consider when introducing EDI, such as: how many partners will exchange data, which message types will be used, the number of messages exchanged per day or month, how many interfaces are needed, etc. This analysis can also help determine whether an internal or external solution will achieve the best efficiency.

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