Tutorial: Ersten Servicefall lokal durchspielen
Tutorial · Stand: 2026-09-22
Status: Aus Code und Setup hergeleitet, noch nicht end-to-end durchgespielt. Wer es durchläuft: Stolpersteine bitte hier nachtragen.
In diesem Tutorial setzt du den Service lokal auf, lieferst Händler-KPIs an, stellst eine Bewertungsanfrage und siehst das Ergebnis — einmal der komplette Weg von der KPI bis zur Prüfungsintensität.
Vorausgesetzt: Docker, ein lokal erreichbares RabbitMQ (z. B. aus dem
dd-kraken-Setup) und das externe Docker-Netz dd-kraken-network
(docker network create dd-kraken-network, falls es fehlt).
1. Service starten
cp api/.env.example api/.env
# In api/.env mindestens setzen:
# RABBIT_MQ_HOST/PORT/USER/PASSWORD → dein lokales RabbitMQ
# RABBIT_MQ_SSL=false
# FRONTEND_BASIC_AUTH_USER/PASSWORD → frei wählen (für /suppliers)
docker compose up -d
docker compose exec dd-supplier-cluster-php composer install
docker compose exec dd-supplier-cluster-php php artisan key:generate
docker compose exec dd-supplier-cluster-php php artisan migrate
Die Migrationen seeden die Standard-Regeln automatisch mit. Prüfen:
docker compose exec dd-supplier-cluster-php php artisan kpi:rule:list
Du solltest 7 Regeln sehen (4× supplier, 3× service).
2. Queue-Worker starten
Der Worker konsumiert kpi-message und evaluation-request:
docker compose exec dd-supplier-cluster-php php artisan queue:work rabbitmq
Terminal offen lassen.
3. Händler-KPIs anliefern
In einem zweiten Terminal per Tinker eine kpi-message publizieren — so wie
es später das Portal tut:
docker compose exec dd-supplier-cluster-php php artisan tinker
app(DeutscheDienstrad\DdRabbitMq\Services\RabbitMqService::class)->push(
'kpi-message', 'kpi-message', [
'supplierId' => 9001,
'supplierName' => 'Tutorial-Händler GmbH',
'periodStart' => '2026-08-01',
'periodEnd' => '2026-08-31',
'schemaVersion' => 1,
'kpis' => [
['key' => 'cost_rate', 'value' => 4.0],
['key' => 'submission_rate_service_dealer', 'value' => 150.0],
['key' => 'submission_rate_delivering_dealer', 'value' => 120.0],
['key' => 'correction_rate', 'value' => 0.5],
],
],
);
Alle vier Werte liegen unter den Kritisch-Grenzen → der Händler ist
unauffällig. Kontrolle im Browser: http://localhost:9006/suppliers
(Basic-Auth aus Schritt 1) — der Händler erscheint mit grünen Bändern.
4. Bewertungsanfrage stellen
Jetzt ein Servicefall mit erhöhten Verschleißkosten (180,50 € liegt über der Kritisch-Grenze von 150 €, aber unter der Riskant-Grenze von 250 €):
app(DeutscheDienstrad\DdRabbitMq\Services\RabbitMqService::class)->push(
'evaluation-request', 'evaluation-request', [
'supplierId' => 9001,
'caseId' => 1,
'caseType' => 'technical_service',
'kpis' => [
['key' => 'wear_cost', 'value' => 180.50],
['key' => 'service_cost_rate', 'value' => 6.0],
['key' => 'ordinary_wear_violated', 'value' => 1], // 1 = eingehalten
],
],
);
5. Ergebnis ansehen
Im Worker-Log (bzw. api/storage/logs/laravel.log) erscheint
Pushing evaluation result … mit dem Payload. Erwartung:
haendlerCluster: "inconspicuous"— alle Händler-KPIs im grünen BereichservicefallCluster: "critical"— genau ein KPI (wear_cost) kritischauditIntensityPercent: 50— Matrix-Zelle Servicefall Kritisch × Händler Unauffällig
Das publizierte Ergebnis liegt auf der Queue evaluation-result (im
RabbitMQ-Management-UI einsehbar).
6. Experimentieren
Ideen zum Weiterspielen:
wear_costauf260setzen → Servicefall Riskant → 100 %.- Im
kpi-messagediecorrection_rateauf3.5undcost_rateauf8.0setzen (neue Periode2026-09-01–2026-09-30verwenden!) → zwei kritische Händler-KPIs → Händler Riskant. - Eine KPI aus dem
evaluation-requestweglassen →status: "incomplete". - Auf
/supplierseinen Override setzen und beobachten, dass sich dasevaluation-resultnicht ändert — das ist das aktuelle Bug-Verhalten (CU-123wka4jt6a), gewollt ist das Gegenteil (siehe Händler-Status übersteuern).