Porównanie OptimizeTours i BatchOptimizeTours

Interfejs Route Optimization API udostępnia 2 metody:

  • OptimizeTours to metoda synchroniczna, która w odpowiedzi na OptimizeToursRequest zwraca zoptymalizowaną trasę. Klienty muszą utrzymywać otwarte połączenie z interfejsem Route Optimization API, dopóki nie zostanie przetworzone żądanie i nie zostanie zwrócony błąd OptimizeToursResponse lub błąd.
  • BatchOptimizeTours to metoda asynchroniczna, która akceptuje identyfikatory URI dla co najmniej jednego elementu OptimizeToursRequest i odpowiednich komunikatów OptimizeToursResponse, zwracając nazwę zasobu operacji długotrwałej (LRO) (REST, gRPC), która służy do sprawdzania realizacji wsadu. OptimizeToursRequest Procesy OptimizeToursRequest są przetwarzane w tle, więc klienty utrzymują otwarte połączenia z interfejsem Route Optimization API tylko do sprawdzenia stanu {1/BatchOptimizeToursRequest lub na jego wywołanie.GetOperation BatchOptimizeTours odczytuje żądania z Google Cloud Storage i zapisuje w nich odpowiedzi.

Przykłady zastosowania

OptimizeTours sprawdza się w przypadku małych i prostych żądań oraz w przypadku zgłoszeń, których czas zajmuje do kilku minut. Utrzymywanie długotrwałych połączeń z interfejsem Route Optimization API zwiększa ryzyko przerw w działaniu usługi, zanim możliwe będzie zwrócenie rozwiązania. Więcej informacji znajdziesz w artykule Praca z limitem czasu.

BatchOptimizeTours może obsługiwać większe żądania i będzie działać dłużej, ponieważ nie wymaga długotrwałego połączenia z interfejsem Route Optimization API.

Długo trwające operacje

LRO są odczytywane z interfejsu Route Optimization API przy użyciu metody GetOperation w celu sprawdzenia stanu ukończenia wsadu. LRO zawierają właściwość done, która wskazuje, czy przetwarzanie całego wsadu zostało zakończone, oraz pole error, które informuje o błędach napotkanych podczas przetwarzania. Jeśli done ma wartość prawda, ale nie ma elementu error, wsad został ukończony. Obecność error oznacza, że przetwarzanie wsadowe nie powiodło się w przypadku części lub całości.

Typowy cykl życia żądania BatchOptimizeTours wygląda tak:

  1. Prześlij BatchOptimizeToursRequest do interfejsu Route Optimization API, który zwraca nazwę zasobu LRO.
  2. Sonduj GetOperation ze zwróconą nazwą zasobu LRO, dopóki właściwości done lub error nie pojawią się w odpowiedzi LRO.
  3. Jeśli done ma wartość prawda i nie występuje żaden błąd, odczytaj OptimizeToursResponses z identyfikatorów URI Google Cloud Storage określonych w żądaniu BatchOptimizeTours. Jeśli występuje error, sprawdź błąd, zaktualizuj odpowiednio interfejsy OptimizeToursRequest w Google Cloud Storage i spróbuj ponownie w zależności od zaobserwowanego błędu.

Żądania OptimizeTours i BatchOptimizeTours można wysyłać na różne sposoby: z poziomu wiersza poleceń lub za pomocą biblioteki klienta.

Dalej: wysyłanie prośby