# Manuelle Entwicklungs- und Integrationsanleitung (9 Sprachen, keine KI erforderlich)

Diese Anleitung gilt für den Licentivo-Anbieter. Händler mit einem anderen Lizenzsystem können in der Administration unter „Lizenzauswahl und Anpassung“ einen benutzerdefinierten Dienst wählen, ihn nach der [benutzerdefinierten Lizenzierungs-API und dem Integrationsablauf](/de/launch-documents/external-licensing/) anbinden und weiterhin das SDK ihres eigenen Lizenzsystems verwenden.

> Die aktuellen unveröffentlichten Änderungen verwenden Kontoidentitätsaustausch; Zuständigkeiten und Migrationseinschränkungen siehe [Kaufzeitraum und Konto-SDK-Grenze](/de/launch-documents/account-purchase-boundary/). Launch berechnet den Kaufzeitraum; das Licentivo SDK führt die Autorisierung aus.

Nur das Launch-Integrationspaket der jeweiligen Sprache installieren. Das Launch-Paket enthält das offizielle SDK, den Standardadapter und die Linkkonfiguration; die offizielle Lizenzierungsadresse ist fest auf `https://www.licentivo.com` gesetzt. Das Programm meldet sich mit dem Konto an, das der Käufer im aktuellen Launch-Shop registriert hat.

## Ausgefüllten Initialisierungscode erhalten

1. In der Launch-Administration Software, Verkaufsplan und Licentivo-Lizenzrichtlinie verknüpfen und in der jeweiligen Umgebung veröffentlichen.
2. **Anwendungsintegration → Integrationsprüfung und Code** öffnen und Software, Sprache sowie Test-/Produktionsumgebung wählen.
3. Auf „Produktinformationen lesen und Integrationscode erzeugen“ klicken. Launch liest automatisch die aktuelle öffentliche Site-Adresse, bestehende Produktzuordnung und öffentliche Signaturschlüssel.
4. Die Verbindungsfunktion der Seite in das eigene Projekt kopieren und Oberfläche und Geschäftsaufrufe wie unten beschrieben manuell erstellen. Alternativ nach Prüfung der automatisch ausgefüllten Parameter das `Connect/connect` der jeweiligen Sprache selbst aufrufen.

Zwei interne Produkt-IDs müssen weder manuell eingegeben noch `launch-config.json` oder `product.json` erzeugt werden. Die Seite kann die Quellcode-Verbindungsfunktion speichern. Die private Serverdatei `config.yaml` dient nur dem Start des Launch-Dienstes und darf nicht mit Kundensoftware veröffentlicht werden.

Die Site-Adresse stammt aus der gültigen öffentlichen Adresse der aktuellen Instanz (Startkonfiguration `public_url` oder gültige öffentliche Adresse in den Website-Einstellungen der Administration). Sie kann eine Domain oder IP-Adresse mit Port sein, muss aber ein Protokoll enthalten; produktive Integration verwendet gültiges HTTPS. Die Listen-Adresse `http_addr` ist keine Kundenadresse. Nach Änderung von Site-Adresse, Produktzuordnung oder Umgebung die Verbindungsfunktion von der aktuellen Site neu beziehen; Sitzungen und Caches der alten Site dürfen nicht als Autorisierung der neuen Site verwendet werden.

Die zwei Produktkennungen sind eine vorhandene interne Zuordnung: Launch-Softwareprodukt und Licentivo-Lizenzprodukt. Die Integrationsseite füllt sie anhand der gewählten Software automatisch aus; Käufer geben nur ihr Shopkonto ein. Öffentliche Signaturschlüssel liest der Server über die konfigurierte Licentivo-Verbindung; Management-Schlüssel und Kundenlizenz-Zugangsdaten gelangen nicht in den Quellcode.

## Zweck von `Connect/connect`

`Connect/connect` bezeichnet in verschiedenen Sprachen das Erstellen eines Launch-Anwendungsclients. Go, C# und einige native Schnittstellen verwenden `Connect` mit großem Anfangsbuchstaben; Python, JavaScript, Ruby und andere Sprachen verwenden stilgemäß `connect`. Die von der Administration erzeugten `connectLaunch()`, `connect_launch()` oder `LaunchConnection.Open()` sind Projektfunktionen mit vorausgefüllten öffentlichen Parametern und rufen intern den jeweiligen Spracheinstieg auf.

Die Verbindung führt nur die Initialisierung durch: Sie validiert Shopadresse, Produktzuordnung, Umgebung und öffentliche Signaturschlüssel, erstellt den Launch-Client und konfiguriert das im Paket enthaltene offizielle Licentivo SDK. Sie prüft weder die Kundenidentität noch gibt sie kostenpflichtige Funktionen unmittelbar frei. Die vollständige Reihenfolge lautet:

```text
Connect/connect → Login or Restore → RunFeature → Logout / Close
                                       └──────────→ ReleaseDevice (explicit device unlink only)
```

Während der Anwendungslaufzeit sollte dasselbe Clientobjekt beibehalten werden, damit das SDK Heartbeats und Floating-Plätze ordnungsgemäß verarbeitet. Normales Schließen behält die Gerätebindung; ausdrücklicher Kunden-Logout und der Kompatibilitätseinstieg ReleaseDevice rufen denselben Logout-Ablauf des offiziellen SDK auf.

## Installation und Initialisierungseinstiege

Die öffentlichen Installationsprüfungen von 0.1.6 für neun Sprachen sind vollständig bestanden (9/9); alle Installationsmethoden der folgenden Tabelle wurden geprüft. [GitHub Release](https://github.com/spf86/licentivo-launch-sdk/releases/tag/v0.1.6) bietet ebenfalls native Pakete und Offline-Dateien; Verwendung siehe [Installationsanleitung für heruntergeladene Pakete](/de/launch-documents/integration-packages/#install-a-downloaded-distribution).

| Sprache | Nur Launch installieren | Von der Seite bereitgestellte Verbindungsfunktion | API für direkte Initialisierung im Paket |
| --- | --- | --- | --- |
| Go | `go get github.com/spf86/licentivo-launch-sdk/pkg/launchclient@v0.1.6` | `connectLaunch()` | `launchclient.Connect` |
| Python 3.10+ | `python -m pip install licentivo-launch==0.1.6` | `connect_launch()` | `Application.connect` |
| C# / .NET 8+ | `dotnet add package Licentivo.Launch --version 0.1.6` | `LaunchConnection.Open()` | `Application.Connect` |
| Java 17+ | Maven/Gradle: `com.licentivo.launch:launch-client:0.1.6` | `LaunchConnection.open()` | `Launch.connect` |
| Node.js 20.3+ | `npm install @licentivo/launch@0.1.6` | `connectLaunch()` | `Application.connect` |
| Rust 1.85+ | `cargo add licentivo-launch@=0.1.6` | `connect_launch()` | `Application::connect` |
| Ruby 3.1+ | `gem install licentivo-launch --version 0.1.6` | `connect_launch` | `Application.connect` |
| C11 | Natives Paket aus [GitHub Release](https://github.com/spf86/licentivo-launch-sdk/releases/tag/v0.1.6) herunterladen und mit CMake importieren | `connect_launch()` | `launch_application_connect` |
| C++17 | Dasselbe native Launch-Paket verwenden | `connectLaunch()` | `Application::Connect` |

Öffentlicher Quellcode und README-Dateien aller Sprachen stehen im [Launch SDK-Repository](https://github.com/spf86/licentivo-launch-sdk), native Pakete und Offline-Dateien im [v0.1.6 Release](https://github.com/spf86/licentivo-launch-sdk/releases/tag/v0.1.6), öffentliche Installationsergebnisse unter [Registry-Verifikation für neun Sprachen](https://github.com/spf86/licentivo-launch-sdk/blob/main/docs/registry-verification.json). Die README jedes Pakets enthält Installationsbefehle und API. Das JavaScript-Paket enthält TypeScript-Deklarationen. Gewöhnliche Sprachabhängigkeiten werden vom Paketmanager aufgelöst, etwa cryptography für Python, BouncyCastle für C# und base64 für Ruby; ein offizielles SDK-Paket muss nicht installiert werden.

Der öffentliche Go-Modulname ist `github.com/spf86/licentivo-launch-sdk`, der Importpfad `github.com/spf86/licentivo-launch-sdk/pkg/launchclient`; die Anwendung benötigt kein lokales replace. Das native Windows-Paket verwendet amd64 GNU/MinGW, außerdem gibt es ein natives Linux-amd64-Paket. Ruby-Plattformpakete und Windows-Distributionen von Rust/native enthalten curl; Quellbuilds anderer Plattformen benötigen gewöhnliche C11-, curl/OpenSSL-Entwicklungsabhängigkeiten. Hinweise zu Plattform-Toolchains stehen in den Paket-README-Dateien.

## Anmeldung und geschützte Operationen

Die folgenden Ausschnitte verwenden die im vorherigen Schritt kopierte Verbindungsfunktion. `email` und `password` stammen aus der eigenen Anmeldeoberfläche; das Passwort darf nicht in Quellcode oder Konfiguration geschrieben werden. `export` muss durch einen in der Planrichtlinie tatsächlich vorhandenen Funktionsnamen ersetzt werden.

### Go

```go
app, err := connectLaunch()
if err != nil { return err }
defer app.Close()
if _, err := app.Login(ctx, email, password); err != nil { return err }
return app.RunFeature("export", func() error {
    return exportReport()
})
```

`ctx` verwendet den Anwendungslaufzeitkontext; der Heartbeat darf nicht unmittelbar nach Ende der Anmeldeanfrage abgebrochen werden. Netzwerkoperationen gehören in einen Hintergrundthread. Zur Wiederherstellung `Restore(ctx)`, zum Konto-Logout `Logout(ctx)` und zur Gerätefreigabe `ReleaseDevice(ctx)` aufrufen.

### Python

```python
with connect_launch() as app:
    app.login(email, password)
    result = app.run_feature("export", export_report)
```

`restore()` stellt eine bestehende sichere Sitzung wieder her; ohne Sitzung die Anmeldeoberfläche anzeigen. `logout()` bereinigt das Konto; `release_device()` gibt das Gerät ausdrücklich frei. Synchrone Netzwerkoperationen dürfen die Desktop-Ereignisschleife nicht blockieren.

### C# / .NET

```csharp
await using var app = LaunchConnection.Open();
await app.Login(email, password);
await app.RunFeature("export", async () => {
    await ExportReport();
});
```

`await Restore()`, `await Logout()` und `await ReleaseDevice()` verwenden. Den SDK-Lebenszyklus während der Anwendungslaufzeit erhalten und asynchrone Oberflächenabläufe verwenden.

### Java

```java
try (var app = LaunchConnection.open()) {
    app.login(email, passwordChars);
    app.runFeature("export", () -> exportReport());
}
```

Passwörter verwenden `char[]`. `restore()` gibt ohne Sitzung den Fehler `NO_SESSION` zurück; die Anmeldeoberfläche sollte angezeigt werden. Andere Fehler dürfen nicht als Autorisierung gelten. `logout()` und `releaseDevice()` sind unterschiedliche Operationen. try-with-resources übernimmt das Schließen.

### JavaScript / Node.js / TypeScript

```javascript
const app = connectLaunch();
try {
  await app.login(email, password);
  const result = await app.runFeature('export', () => exportReport());
} finally {
  await app.close();
}
```

`restore()` gibt ohne Sitzung `null` zurück; erst nach normaler Wiederherstellung darf Geschäftslogik ausgeführt werden. Der boolesche Rückgabewert von `logout()` zeigt an, ob der Remote-Logout bestätigt wurde; ein Fehler bei der Gerätefreigabe muss angezeigt werden. Der Code läuft in Node.js, im Electron-Hauptprozess oder einem vertrauenswürdigen Backend; Browser und Electron-Renderer speichern keine Autorisierungs-Zugangsdaten.

### Rust

```rust
let mut app = connect_launch()?;
app.login(&email, &password)?;
let result = app.run_feature("export", || {
    export_report()?;
    Ok(())
})?;
app.close();
```

Der Callback gibt `Result<T, Failure>` zurück. `restore()`, `logout()` und `release_device()` geben Ergebnisse zurück; Fehler müssen behandelt werden. `Drop` schließt ebenfalls die Laufzeit. Der native Standardkern wird durch build.rs kompiliert und gelinkt; das offizielle SDK muss nicht selbst gelinkt werden.

### Ruby

```ruby
app = connect_launch
begin
  app.login(email, password)
  result = app.run_feature('export') { export_report }
ensure
  app.close
end
```

`restore` stellt eine Sitzung wieder her, `logout` meldet das Konto ab, `release_device` gibt das Gerät frei. Geschützte Operationen verwenden Codeblöcke; Ausnahmen dürfen nicht in Erfolg umgewandelt werden.

### C

```c
static int export_action(void *context) {
    return export_report(context); /* Return 1 only on success. */
}

launch_application *app = connect_launch();
if (!app) return 0;
int ok = launch_application_login(app, email, password);
if (ok) ok = launch_application_run_feature(app, "export", export_action, context);
/* Check launch_application_error(app) on failure; never log credentials. */
launch_application_close(app);
return ok;
```

`launch_application_restore` hat drei Zustände: `1` wiederhergestellt, `0` keine Sitzung, `-1` Fehler. Nur ohne Sitzung normal die Anmeldung anzeigen; Ablehnung oder Ausnahme darf nicht als Erfolg gelten. Auch Rückgabewerte von `logout` und `release_device` müssen geprüft werden.

CMake importiert nur Launch:

```cmake
find_package(LicentivoLaunch CONFIG REQUIRED)
add_executable(myapp main.c)
licentivo_launch_link(myapp)
```

### C++

```cpp
auto app = connectLaunch();
app.Login(email.c_str(), password.c_str());
app.RunFeature("export", [&] { exportReport(); });
```

`Restore()`, `Logout()`, `ReleaseDevice()` folgen der C++-Ausnahmesemantik. RAII-Destruktion übernimmt das Schließen. CMake verwendet `licentivo_launch_link(myapp CXX)`; Launch behandelt SDK-Linking und Laufzeitbibliotheken des Distributionspakets automatisch.

## Lebenszyklus, sicherer Speicher und Fehler

Das Erstellen des Verbindungsobjekts initialisiert nur. Das Programm muss sich erfolgreich anmelden oder wiederherstellen und bei jeder Geschäftsoperation den Funktionsschutz-Callback verwenden. Bezahlte Bestellung, vorhandene Sitzung oder anklickbare Schaltfläche ersetzen keine SDK-Prüfung.

Standardmäßig werden Sitzungen nur im Speicher gehalten. Gemerkte Anmeldung benötigt sicheren Speicher: Go, Python, C# und natives C/C++ bieten Windows-DPAPI für den aktuellen Benutzer; Java, Node, Rust und Ruby bieten AES-GCM-Speicher mit vom Aufrufer verwaltetem Schlüssel. Plattformübergreifende Anwendungen sollten den System-Zugangsdatenstore anbinden. Schlüssel und Chiffretext dürfen nicht im selben gewöhnlichen Verzeichnis liegen.

Normales Schließen bewahrt die ausdrücklich gemerkte Sitzung und stoppt die Laufzeit. Konto-Logout ruft zuerst den einheitlichen Logout des offiziellen SDK auf und bereinigt dann den Launch-eigenen Kontodatensatz. ReleaseDevice ist ein Kompatibilitätseinstieg desselben Ablaufs; solange der Remote-Widerruf aussteht, darf keine erfolgreiche Freigabe gemeldet werden. Cache-Verzeichnis und Logout-Wiederherstellungsjournal des offiziellen SDK nicht bereinigen. Launch-Sitzungsschutz bedeutet nicht, dass alle Gerätedateien des offiziellen SDK verschlüsselt sind; Cache-Verzeichnisberechtigungen einschränken.

| Status | Programmverarbeitung |
| --- | --- |
| Konto oder Passwort fehlgeschlagen | Allgemeinen Anmeldefehler anzeigen, ohne offenzulegen, ob das Konto existiert |
| EMAIL_VERIFICATION_REQUIRED | Zur Shop-E-Mail-Verifikation anleiten |
| ENTITLEMENT_PENDING | Synchronisierung anzeigen und gemäß den begrenzten Paketwiederholungen und Retry-After warten |
| ENTITLEMENT_NOT_PURCHASED | Zum Kauf oder Kontowechsel anleiten |
| ENTITLEMENT_EXPIRED | Zur Verlängerung anleiten; Ablehnung nicht mit alten Zugangsdaten umgehen |
| ENTITLEMENT_SUSPENDED | Geschützte Funktionen stoppen und Händler kontaktieren |
| Gerätelimit erreicht | Zur Verwaltung oder ausdrücklichen Gerätefreigabe anleiten |
| Netzwerk/HTTP 5xx | Nur vom SDK verifizierte Offline-Autorisierung innerhalb ihrer Gültigkeitsdauer verwenden |

Ausdrückliche 401/403/404, falsches Konto, Abbruch oder Ratenbegrenzung dürfen nicht in einen erfolgreichen Offline-Zugriff umgewandelt werden. Erstaktivierung und Richtlinien ohne Offline-Nutzung erfordern weiterhin eine Verbindung. Ist die Serverdomain/IP nicht erreichbar, ein Verbindungsproblem anzeigen und nicht heimlich eine andere Site kontaktieren.

## Abnahme und Referenzen

Echte Anmeldung, Autorisierung des zugehörigen Kontos, geschützte Operationen, Wiederherstellung nach Neustart, gültiges Offline-Verhalten und Offline-Ablauf, Cache-Manipulation, Logout, Kontowechsel und Gerätefreigabe prüfen. Diese Anleitung erfordert keine KI. Testtools und externe Abnahmegrenzen siehe [acceptance.md](/de/launch-documents/acceptance/); lokale Pakete und Build-Anweisungen siehe [integration-packages.md](/de/launch-documents/integration-packages/).

Konfigurationsprüfung, Codeerzeugung und lokale Tests beweisen nicht automatisch erfolgreiche echte Zahlung, Lizenzausstellung oder Aktivierung auf der offiziellen Website. Externer Shop und Zahlungs-Sandbox müssen nach Konfiguration separat abgenommen werden.
