Billbee.Net: Eine .NET-Bibliothek für E-Commerce-Integration

Der Bedarf nach besserer API-Integration

In meiner täglichen Arbeit als Freelancer für digitale Transformation stoße ich immer wieder auf das gleiche Problem: E-Commerce-Plattformen wie Billbee bieten zwar leistungsfähige APIs – doch die verfügbaren .NET-Client-Bibliotheken sind häufig veraltet, unvollständig oder folgen nicht den heutigen Entwicklungsstandards.

Billbee selbst ist eine beliebte Cloud-Lösung, die vor allem kleineren und mittleren Online-Händlern hilft, ihre Auftragsabwicklung über verschiedene Marktplätze und Shops zu zentralisieren – etwa Shopify, WooCommerce, Etsy oder Funk-House-Shops. Viele meiner Kunden nutzen Billbee, um Aufträge, Rechnungen und Versandprozesse zu automatisieren.

Allerdings zeigte sich in der Praxis:

👉 Nicht jede individuelle Anforderung lässt sich mit Bordmitteln von Billbee realisieren.

Nach mehreren Projekten, in denen ich ähnliche Anbindungen mehrfach neu schreiben musste, entstand daraus die Idee zu einer wiederverwendbaren, modularen und modernen .NET-Bibliothek: Billbee.Net.

Was macht Billbee.Net anders?

🚀 Modern und zukunftssicher

Statt mühsamer HTTP-Client-Konfiguration und manueller Serialisierung bietet Billbee.Net eine typisierte, saubere Schnittstelle, die sich nahtlos in moderne .NET-Anwendungen integrieren lässt.

var client = new BillbeeClient(config);
var orders = await client.Orders.GetAsync();

Die Bibliothek folgt modernen .NET-Konventionen und nutzt async/await durchgehend für optimale Performance.

🛡️ Resiliente Architektur

Temporäre Netzwerkfehler oder API-Limits gehören im E-Commerce-Alltag dazu. Billbee.Net nutzt integrierte Polly-Policies mit Retry- und Circuit-Breaker-Mechanismen, um API-Aufrufe automatisch zu stabilisieren.

services.AddHttpClient<IBillbeeClient, BillbeeClient>()
    .AddTransientHttpErrorPolicy(policy => 
        policy.WaitAndRetryAsync(3, retryAttempt => 
            TimeSpan.FromSeconds(Math.Pow(2, retryAttempt))))
    .AddTransientHttpErrorPolicy(policy => 
        policy.CircuitBreakerAsync(5, TimeSpan.FromSeconds(30)));

🔧 Praxiserprobte Patterns

Die Bibliothek basiert auf Mustern, die ich in zahlreichen Kundenprojekten entwickelt habe:

Endpoint-Pattern: Jeder API-Bereich (Orders, Products, Customers) ist als eigene Klasse gekapselt
Konfigurationsbasiert: Alle Einstellungen sind über appsettings.json steuerbar
Testbar: Kompatibel mit Dependency Injection und Mock-Interfaces

public interface IBillbeeClient
{
    IOrdersEndpoint Orders { get; }
    IProductsEndpoint Products { get; }
    ICustomersEndpoint Customers { get; }
}

Real-World-Anwendungsfälle

Viele meiner Kunden setzen Billbee in Kombination mit Funk-House-Shops ein. Hier zeigte sich oft, dass spezielle Anforderungen über das Standard-Feature-Set hinausgingen:

Eigene Controlling-Dashboards für Auftragseingänge und offene Rechnungen
Integration individueller Versandlösungen oder Logistik-APIs
Erweiterungen, um beim Auftragseingang automatisch zu prüfen, ob der Kunde Zahlungsrückstände hat
Automatische Synchronisation mit externen Buchhaltungssystemen

Diese Funktionen konnte ich über Billbee.Net als Erweiterung oder Middleware für Kundenprojekte realisieren – immer mit dem Ziel, die bestehende Billbee-Infrastruktur zu ergänzen, nicht zu ersetzen.

Beispiel: Automatisierte Auftragsabwicklung

Ein konkretes Beispiel aus einem aktuellen Kundenprojekt:

public class OrderProcessor
{
    private readonly IBillbeeClient _billbee;
    private readonly ILogger<OrderProcessor> _logger;

    public async Task ProcessNewOrdersAsync()
    {
        var orders = await _billbee.Orders.GetAsync(new OrderFilter 
        { 
            State = OrderState.Confirmed,
            MinOrderDate = DateTime.Today 
        });

        foreach (var order in orders)
        {
            // Custom business logic
            await ValidateInventoryAsync(order);
            await CreateShippingLabelAsync(order);
            await NotifyCustomerAsync(order);
            
            _logger.LogInformation("Order {OrderId} processed successfully", 
                order.Id);
        }
    }
}

Performance und Monitoring

Was bei produktiven E-Commerce-Systemen entscheidend ist: Observability. Die Bibliothek bietet umfassendes Logging:

{
  "timestamp": "2024-04-28T10:15:30Z",
  "level": "Information",
  "message": "Billbee API call completed",
  "endpoint": "/api/v1/orders",
  "duration": 245,
  "statusCode": 200,
  "retryCount": 0
}

Jeder API-Call wird strukturiert geloggt, inklusive Timing-Informationen und Retry-Versuchen.

Lessons Learned: Von monolithisch zu modular

Die Entwicklung von Billbee.Net spiegelt einen Wandel in meiner Arbeitsweise wider:

Früher: Jedes Projekt hatte seine eigene HTTP-Implementierung, oft Copy-Paste aus alten Lösungen.

Heute: Eine zentrale, getestete Bibliothek, die modular aufgebaut ist, CI-getestet wird und in unterschiedlichen Projekttypen eingesetzt werden kann.

Das spart Zeit – und vor allem: Fehler und Wartungsaufwand. Bugfixes und Verbesserungen kommen allen Projekten zugute.

Integration in verschiedene Projekttypen

Billbee.Net lässt sich flexibel einsetzen:

Console-Apps: Für ETL-Prozesse und Datenmigrationen
ASP.NET Web APIs: Für Webhooks und REST-Schnittstellen
Worker Services: Für Hintergrundjobs mit Quartz.NET

Durch die klare Struktur ist es möglich, eigene Endpunkte zu erweitern oder eigene Modelle zu ergänzen – ideal für maßgeschneiderte Kundenlösungen.

Technische Highlights

Circuit-Breaker-Pattern

services.AddHttpClient<IBillbeeClient, BillbeeClient>()
    .AddTransientHttpErrorPolicy(policy => 
        policy.CircuitBreakerAsync(
            handledEventsAllowedBeforeBreaking: 5,
            durationOfBreak: TimeSpan.FromSeconds(30),
            onBreak: (result, timespan) => 
            {
                logger.LogWarning("Circuit breaker opened for {Duration}s", 
                    timespan.TotalSeconds);
            }
        ));

Erweiterbares Endpoint-System

public class CustomEndpoint : EndpointBase
{
    public CustomEndpoint(HttpClient httpClient, ILogger logger) 
        : base(httpClient, logger) { }

    public async Task<CustomData> GetCustomDataAsync()
    {
        return await GetAsync<CustomData>("/api/v1/custom");
    }
}

Zukunftspläne

Für die kommenden Versionen plane ich:

Health-Check-Integration für ASP.NET Core
OpenTelemetry-Support für Distributed Tracing
Caching-Layer für performantere Order-Abfragen
Erweiterte Webhook-Unterstützung

Warum das sinnvoll ist

Als Freelancer könnte man fragen: Warum die Zeit investieren, statt jedes Mal neu zu implementieren?

Die Antwort liegt in der Skalierbarkeit der eigenen Arbeit. Mit Billbee.Net kann ich:

✅ Schneller neue Kundenprojekte umsetzen
✅ Höhere Codequalität durch Wiederverwendung gewährleisten
✅ Meinen Kunden nachhaltigere Lösungen anbieten

Die Bibliothek ist auf GitHub verfügbar und als NuGet-Package installierbar.

Installation

dotnet add package Billbee.Net

Oder via NuGet Package Manager:

Install-Package Billbee.Net

Konfiguration

{
  "Billbee": {
    "ApiUrl": "https://api.billbee.io/api/v1",
    "ApiKey": "your-api-key",
    "Username": "your-username",
    "Password": "your-password"
  }
}

Ressourcen:

Insights