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

Der Bedarf nach besserer API-Integration

In der täglichen Arbeit mit E-Commerce-Kunden taucht ein Problem immer wieder auf: Plattformen wie Billbee bieten leistungsfähige APIs – doch die verfügbaren .NET-Client-Bibliotheken sind häufig veraltet, unvollständig oder folgen nicht den heutigen Entwicklungsstandards.

Billbee 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 oder Etsy. Viele Kunden nutzen Billbee, um Aufträge, Rechnungen und Versandprozesse zu automatisieren.

Nicht jede individuelle Anforderung lässt sich dabei mit Bordmitteln von Billbee realisieren. Nach mehreren Projekten, in denen ähnliche Anbindungen mehrfach neu geschrieben werden mussten, entstand die Idee zu einer wiederverwendbaren, modularen .NET-Bibliothek: Billbee.Net.

Was Billbee.Net anders macht

Modern und typisiert

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

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

Die Bibliothek nutzt async/await durchgehend und folgt modernen .NET-Konventionen.

Resiliente Architektur mit Polly

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:

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

Praxiserprobtes Endpoint-Pattern

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

• 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 Kunden setzen Billbee in Kombination mit individuellen Shop-Systemen ein. Spezielle Anforderungen gehen dabei häufig über das Standard-Feature-Set hinaus:

• Eigene Controlling-Dashboards für Auftragseingänge und offene Rechnungen
• Integration individueller Versandlösungen oder Logistik-APIs
• Automatische Prüfung auf Zahlungsrückstände beim Auftragseingang
• Synchronisation mit externen Buchhaltungssystemen

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

Beispiel: Automatisierte Auftragsabwicklung

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)
        {
            await ValidateInventoryAsync(order);
            await CreateShippingLabelAsync(order);
            await NotifyCustomerAsync(order);
            
            _logger.LogInformation("Order {OrderId} processed successfully", 
                order.Id);
        }
    }
}

Observability

Was bei produktiven E-Commerce-Systemen entscheidend ist: Jeder API-Call wird strukturiert geloggt, inklusive Timing-Informationen und Retry-Versuchen.

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

Von monolithisch zu modular

Die Entwicklung von Billbee.Net spiegelt einen Wandel in der Arbeitsweise wider. Früher hatte jedes Projekt seine eigene HTTP-Implementierung – oft Copy-Paste aus alten Lösungen. Heute gibt es eine zentrale, getestete Bibliothek, die modular aufgebaut ist, CI-getestet wird und in unterschiedlichen Projekttypen eingesetzt werden kann.

Das spart Zeit, reduziert Fehler und macht Bugfixes für alle Projekte wirksam.

Einsatzmöglichkeiten

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:

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");
    }
}

Installation

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

dotnet add package Billbee.Net

Konfiguration über appsettings.json:

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

Die Billbee API-Dokumentation liefert die vollständige Referenz zu verfügbaren Endpunkten und Datenstrukturen.