Wozu brauche ich ein Kommandozeilentool / CLI? Welche Vorteile hat das?

Für den Datenaustausch in den Formaten CSV, XLSX, JSON und XML bieten wir den Command Line Interface / Kommandozeilenclient livectl an. Er erfüllt im Wesentlichen folgende Funktionen:

  • Sicherer Login livectl meldet sich über das sichere Systemlogin Ihres Rechners an und nutzt den FIDO2-Standard. Es werden keine Kennwörter verwendet, was die Sicherheit deutlich erhöht. In Zeiten permanenter Angriffsversuche auf IT-Infrastruktur ist es notwendig, vor allem personenbezogene Daten möglichst gut zu schützen. livectl bietet hier gegenüber einem herkömmlichen Serverzugriff per Zugangsdaten einen klaren Vorteil. Anmeldung mit:

Wie bekomme ich Daten ins System - und wie wieder heraus?

inkasso.live bietet verschiedene Schnittstellen an, um Ihre Daten (Aufträge, Ergebnisse, Stammdaten, …) in das System zu importieren und auch wieder zu exportieren (Ergebnisse, Reports, Berichte, …).

Die drei wichtigsten Schnittstellen sind:

  1. Datei-Im-/Export (asynchron) Daten werden als Datei eingelesen oder geschrieben — in den Formaten CSV, XLSX, JSON und XML. CSV und XLSX sind dabei gleichwertige Container. Der einfachste und empfohlene Weg dafür ist der Kommandozeilen-Client livectl. Beispiele:

    # Neuaufträge importieren
    livectl assignments import auftraege.csv --tenant-id <mandant> --dto fsg1
    
    # Statusänderungen / Außendienstergebnis importieren
    livectl assignments import status.csv --tenant-id <mandant> --dto fsg2
    
    # Aufträge exportieren
    livectl assignments --dto fsg3 -f csv > auftraege.csv

    Der Import ist standardmäßig tolerant: gültige Zeilen werden übernommen, fehlerhafte einzeln mit Zeile und Grund gemeldet (in der App als „Ungültig" sichtbar und korrigierbar). Mehr dazu auf der Seite Command Line Interface.

Welchen Technologiestack verwendet ihr für die Cloud Versionen?

  • app.inkasso.live
    Die Test-/Beta-Version der Inkasso.live App basiert auf

    • docker compose auf amd64 Debian Linux im LXC auf einem Proxmox Server
    • Verwendet den :beta Tag.
    • CouchDB als Dokumentstore
  • demo.inkasso.live
    Die Demo der Inkasso.live App basiert auf

    • docker compose auf amd64 Debian Linux im LXC auf einem Proxmox Server
    • Verwendet den :latest Tag.
    • CouchDB als Dokumentstore
  • lab.inkasso.live
    Die Labor-Version der Inkasso.live App basiert auf

    • docker compose auf amd64 Debian Linux im LXC auf einem Proxmox Server
    • Verwendet den :lab Tag.
    • CouchDB als Dokumentstore

Welchen Technologiestack verwendet ihr für die Entwicklung?

Der Server ist in TypeScript geschrieben und läuft auf Bun. Daraus kompilieren wir ein einzelnes, eigenständiges live-Binary, das ohne externe Laufzeitumgebung startet.

Als Dokumentstore verwenden wir CouchDB. Geschäftsvorfälle werden als Dokumente abgelegt; daraus leitet der Server intern eine Leseseite (CQRS-Read-Model) ab, die wir als schnellen Cache für Abfragen nutzen. So bleibt die Schreibseite schlank und nachvollziehbar, während Listen und Auswertungen flott bleiben.

Viele Ideen über die Bedienung auf der Kommandozeile haben wir aus unserer langjährigen Erfahrung im Cloud Umfeld bezogen: die Arbeit mit Docker, Kubernetes und ähnlichen Tools zeigt, wie man auch bei komplexen technischen Werkzeugen eine für den Administrator angenehme CLI schaffen kann. Von diesen Tools haben wir auch die Ideen für das Rechte- und Rollenkonzept übernommen. Das macht sich positiv im Betrieb bemerkbar: Administratoren, die diese Cloud Werkzeuge gewohnt sind, kommen ohne großen Lernaufwand mit unseren Applikationen klar. Inkasso.live fügt sich nahtlos in eine Cloud-Native Infrastruktur ein.

Welches base Image nutzt ihr für die Cloud Version?

Das Server-Image basiert auf debian:bookworm-slim, ergänzt um ca-certificates. Es enthält im Wesentlichen nur das live-Binary und die CA-Zertifikate, die für ausgehende TLS-Verbindungen nötig sind. Wir veröffentlichen es für amd64 und arm64.

Mit diesem schlanken Debian-Slim-Image halten wir die Angriffsfläche bewusst klein: keine zusätzlichen Dienste, Paketmanager-Altlasten oder Werkzeuge, die im Betrieb nicht gebraucht werden — nur das, was der Server zur Laufzeit tatsächlich benötigt.