www.rietberg.de

Bugsink: https://bugsink.cytrus.de/issues/issue/702591c8-be44-46aa-981d-4ea00d63e62a/event/last/

Typ: NEW issue

Projekt: www-rietberg-de

Bugsink Alert

ErrorException: Warning: file_get_contents(https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch?type=3&maxOccurs=-1&terms=Sozi…

Automatisch erstellt durch n8n

KI-Analyse:

Hier ist die präzise Analyse des Fehlers mit den geforderten Punkten:

1. Ursache identifizieren¶

• Kernproblem:
  Der Fehler tritt auf, weil die PHP-Funktion file_get_contents() versucht, eine externe HTTP-Anfrage an die URL https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch zu senden, aber der Zielserver antwortet mit HTTP 503 (Service Unavailable).

  • HTTP 503 bedeutet: Der Zielserver ist temporär nicht erreichbar (z. B. wegen Wartungsarbeiten, Überlastung oder einer Störung).
  • Die Anfrage wird nicht verarbeitet, sondern direkt abgelehnt.

• Technische Details:

  • Der Fehler stammt aus einer Benutzerland-Logik (nicht aus TYPO3-Core), da die Stacktrace auf /public/index.php (Zeile 21) verweist.
  • Die Middleware-Kette von TYPO3 wird zwar durchlaufen, aber der Fehler wird nicht von TYPO3 selbst verursacht, sondern von einem externen Webservice-Aufruf.
  • Der Parameter maxOccurs=-1 deutet auf eine unlimitierte Abfrage hin, was möglicherweise den Zielserver überlastet.

2. Fix beschreiben (konkret)¶

Kurzfristige Lösung (Fehlerbehandlung)¶

• Exception-Handling hinzufügen:
  Um den Fehler abzufangen, sollte der file_get_contents()-Aufruf in einen try-catch-Block eingebettet werden. Beispiel:

  try {
      $response = file_get_contents('https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch?type=3&maxOccurs=-1&terms=Sozialamt');
      if ($response === false) {
          throw new \RuntimeException('Webservice antwortet nicht (HTTP 503).');
      }
  } catch (\ErrorException $e) {
      // Loggen und Fallback-Logik (z. B. Cache nutzen oder Default-Wert zurückgeben)
      $logger = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Log\LogManager::class)->getLogger(__CLASS__);
      $logger->error('Webservice-Fehler: ' . $e->getMessage());
  
      // Optional: Cache prüfen oder leere Antwort zurückgeben
      return []; // oder aus Cache laden
  }
  

Mittelfristige Lösung (Robustheit erhöhen)¶

• Alternative HTTP-Client-Bibliothek nutzen:
  file_get_contents() ist für HTTP-Anfragen ungeeignet, da es keine Kontrolle über Timeouts, Headers oder Fehlercodes bietet. Besser:

  use GuzzleHttp\Client;
  
  $client = new Client(['timeout' => 5]);
  try {
      $response = $client->get('https://rietberg.ratsinfomanagement.net/webservice/portal/getSearch', [
          'query' => [
              'type' => 3,
              'maxOccurs' => -1,
              'terms' => 'Sozialamt'
          ]
      ]);
      $data = json_decode($response->getBody(), true);
  } catch (\GuzzleHttp\Exception\ServerException $e) {
      // 503-Fehler abfangen
      $logger->error('Webservice nicht verfügbar: ' . $e->getMessage());
      return []; // Fallback
  }
  

  • Vorteile: Timeout-Kontrolle, bessere Fehlerbehandlung, Unterstützung für Headers/Authentication.

• Parameter anpassen:

  • maxOccurs=-1 könnte den Zielserver überlasten. Besser: Einen sinnvollen Maximalwert setzen (z. B. maxOccurs=100).

Langfristige Lösung (Architektur)¶

• Caching implementieren:
  Die Antwort des Webservices sollte zwischengespeichert werden (z. B. mit TYPO3-Cache oder Redis), um bei Ausfällen des Zielservers auf den Cache zurückzugreifen.

  $cache = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance(\TYPO3\CMS\Core\Cache\CacheManager::class)->getCache('my_cache');
  $cacheIdentifier = md5('webservice_search_' . $searchTerm);
  
  if ($cache->has($cacheIdentifier)) {
      return $cache->get($cacheIdentifier);
  }
  
  // ... (HTTP-Anfrage wie oben)
  $cache->set($cacheIdentifier, $data, [], 3600); // 1 Stunde Cache
  

• Asynchrone Verarbeitung:
  Falls der Webservice häufig ausfällt, könnte die Anfrage asynchron über eine Queue (z. B. TYPO3-Scheduler) verarbeitet werden.

3. Betroffene TYPO3 Extension nennen¶

• Keine TYPO3-Core-Extension betroffen!
  Der Fehler stammt aus benutzerdefiniertem Code (vermutlich eine Custom Extension oder ein Site-Package), da:

  • Die Stacktrace auf /public/index.php verweist (kein TYPO3-Core-Pfad).
  • Der Aufruf von file_get_contents() ist kein Standard-TYPO3-Verhalten.
  • Typische TYPO3-Extensions (z. B. ext:news, ext:form) nutzen keine direkten file_get_contents()-Aufrufe für externe APIs.

• Vermutung:
  Es handelt sich um eine eigene Extension (z. B. ext:my_webservice_integration), die den Ratsinfo-Webservice anbindet.

4. Confidence (0-100%)¶

• 95% Confidence für die Ursachenanalyse und den Fix.
  • Begründung:
    • Der HTTP 503-Fehler ist klar erkennbar.
    • Die Stacktrace zeigt, dass der Fehler aus Benutzerland kommt.
    • Die vorgeschlagenen Lösungen sind Standard-Praktiken für HTTP-Anfragen in TYPO3.
  • Unsicherheit (5%):
    • Ohne Zugriff auf den konkreten Code kann nicht 100%ig ausgeschlossen werden, dass eine Drittanbieter-Extension (z. B. ext:external_import) beteiligt ist. Allerdings ist dies unwahrscheinlich, da solche Extensions normalerweise Guzzle oder cURL nutzen.

Zusammenfassung¶

Empfehlung:

1. Sofort: try-catch um den file_get_contents()-Aufruf legen.
2. Mittelfristig: Auf Guzzle umstellen und Caching implementieren.
3. Langfristig: Mit dem Betreiber des Webservices klären, warum maxOccurs=-1 zu 503 führt.