Konfigurowanie zadań

Zakładamy, że wiesz, jak tworzyć i używać zadań. Zawiera ona konkretne przykłady konfigurowania zadań związanych z dostawą na te sposoby:

  • Ustaw docelowy przedział czasu dla zadania dostawy: ustaw przedział czasu, w którym zadanie ma zostać wykonane.

  • Dostosowywanie widoczności zadań: dostosuj widoczność działań związanych z zadaniami, aby wyświetlać je klientom lub operatorom floty.

Szczegółowe informacje o polach zadań związanych z wysyłką znajdziesz w artykule Tworzenie zadań związanych z wysyłką. Gdy aktualizujesz dodatkowe informacje o istniejących zadaniach, musisz podać odpowiedni identyfikator zadania oraz pola, które aktualizujesz.

Ustaw docelowy przedział czasu

Docelowy przedział czasu to TimeWindow, w którym zadanie powinno zostać wykonane. Jeśli na przykład informujesz odbiorców o przewidywanym czasie dostawy, możesz użyć docelowego przedziału czasu zadania, aby zarejestrować ten przedział i generować alerty, lub możesz użyć go do analizowania wyników poprzednich przejazdów.

Docelowe okno czasowe składa się z godziny rozpoczęcia i godziny zakończenia i może być ustawione dla dowolnego typu zadania. Docelowe okno czasowe nie ma wpływu na routing.

W przykładach poniżej pokazujemy, jak ustawić przedział czasu za pomocą biblioteki Java gRPC lub jak wysłać żądanie HTTP REST do UpdateTask. Możesz też ustawić to pole podczas tworzenia zadania.

gRPC

  static final String PROJECT_ID = "my-delivery-co-gcp-project";
  static final String TASK_ID = "task-8241890";

  DeliveryServiceBlockingStub deliveryService =
    DeliveryServiceGrpc.newBlockingStub(channel);

  // Task settings
  String taskName = "providers/" + PROJECT_ID + "/tasks/" + TASK_ID;
  Task task = Task.newBuilder()
    .setName(taskName)
    .setTargetTimeWindow(
      TimeWindow.newBuilder()
        .setStartTime(Timestamp.newBuilder().setSeconds(1680123600))
        .setEndTime(Timestamp.newBuilder().setSeconds(1680130800)))
    .build();

  // Task request
  UpdateTaskRequest updateTaskRequest =
    UpdateTaskRequest.newBuilder()  // No need for the header
        .setTask(task)
        .setUpdateMask(FieldMask.newBuilder().addPaths("targetTimeWindow"))
        .build();

  try {
    Task updatedTask = deliveryService.updateTask(updateTaskRequest);
  } catch (StatusRuntimeException e) {
    Status s = e.getStatus();
    switch (s.getCode()) {
       case NOT_FOUND:
         break;
       case PERMISSION_DENIED:
         break;
    }
    return;
  }

REST

Aby ustawić przedział czasu zadania za pomocą protokołu HTTP, wywołaj PATCH i użyj updateMask, aby zaktualizować parametr targetTimeWindow:

PATCH https://fleetengine.googleapis.com/v1/providers/<project_id>/tasks/<id>?updateMask=targetTimeWindow

W tym przypadku <id> to unikalny identyfikator zadania. Nagłówek żądania musi zawierać pole Authorization o wartości Bearer <token>, gdzie <token> jest tokenem wydanym przez serwer zgodnie z wytycznymi opisanymi w sekcjach Role konta usługi i Tokeny internetowe JSON.

# Set JWT, PROJECT_ID, and TASK_ID in the local environment
  curl -X PATCH "https://fleetengine.googleapis.com/v1/providers/${PROJECT_ID}/tasks/${TASK_ID}?updateMask=targetTimeWindow" \
    -H "Content-type: application/json" \
    -H "Authorization: Bearer ${JWT}" \
    --data-binary @- << EOM
  {
    "targetTimeWindow": {
      "startTime": "2023-03-29T21:00:00Z",
      "endTime": "2023-03-29T23:00:00Z"
    }
  }
  EOM

Dostosowywanie widoczności zadań

Domyślnie Fleet Engine zapewnia wgląd w aktywności związane z zadaniami, które można następnie wyświetlać zarówno klientom otrzymującym przesyłkę, jak i operatorom flot śledzącym przesyłki. Obejmuje to informacje takie jak liczba przystanków przed wysłaniem klientowi powiadomienia o stanie dostawy przesyłki. Możesz dostosowywać te informacje do poszczególnych zadań, aby lepiej dopasować je do swojego modelu biznesowego.

W tej sekcji opisujemy reguły widoczności śledzonych obiektów na mapie. Te reguły dotyczą 2 kategorii obiektów:

  • Widoczność znacznika lokalizacji
  • Widoczność danych zadań dla aktywnych zadań dotyczących pojazdów, takich jak linie łamane i szacowany czas dotarcia na miejsce

Reguły widoczności znacznika lokalizacji

Fleet Engine wyświetla znaczniki lokalizacji miejsca dostawy przesyłki na mapie niezależnie od stanu dostawy.

Reguły widoczności danych zadań

W tej sekcji opisujemy domyślne reguły widoczności, które mają zastosowanie do danych zadań. Możesz dostosowywać tylko aktywne zadania dotyczące pojazdu, co oznacza, że tylko zadania odbioru i dostawy mogą podlegać dostosowanym regułom widoczności.

Nie można dostosowywać tych zadań:

  • Zaplanowane przystanki
  • Zadania dotyczące niedostępności
  • Zadania dotyczące nieaktywnych pojazdów

Reguły widoczności zadań dotyczących niedostępności

Domyślnie pojazd nie pojawia się na mapie, jeśli do śledzonego zadania jest przypisane co najmniej 1 zadanie niedostępności. Na przykład gdy kierowca robi przerwę lub pojazd jest tankowany na trasie do śledzonej przesyłki. Szacowany czas przyjazdu i szacowany czas ukończenia zadania są nadal dostępne. Pamiętaj, że nie możesz dostosować tej reguły.

Widoczność aktywnych zadań dotyczących pojazdów

Obiekt TaskTrackingInfo zawiera wiele elementów danych, które możesz udostępnić za pomocą biblioteki śledzenia przesyłek. Domyślnie te pola są widoczne, gdy zadanie jest przypisane do pojazdu i gdy pojazd znajduje się w odległości 5 przystanków od zadania. Widoczność kończy się po wykonaniu lub anulowaniu zadania.

Możesz dostosować konfigurację widoczności dla każdego zadania, ustawiając parametr TaskTrackingViewConfig w zadaniu podczas jego tworzenia lub aktualizowania w Fleet Engine. Spowoduje to utworzenie reguł udostępniania poszczególnych elementów danych.

W tabeli poniżej znajdziesz pola, do których możesz zastosować reguły widoczności.

Pola zadań dotyczących pojazdów w przypadku reguł widoczności
  • Linie łamane tras
  • Szacowany czas dotarcia
  • Szacowany czas ukończenia zadania
  • pozostała odległość dojazdu do zadania,
  • Pozostała liczba przystanków
  • Lokalizacja pojazdu

W tej tabeli znajdziesz opcje widoczności dostępne w przypadku pól wymienionych powyżej.

Opcje widoczności
  • Pozostała liczba przystanków
  • Czas do szacowanego czasu przyjazdu
  • Pozostała odległość do przejechania
  • Zawsze widoczne
  • Nigdy nie wyświetla się

Linie łamane trasy i zasady widoczności lokalizacji pojazdu

W przypadku śledzonej trasy widoczność linii łamanych trasy zależy od widoczności pojazdu. Jeśli na aktywnej trasie, na której nie widać pojazdu, jest widoczna linia łamana trasy, lokalizację pojazdu można nadal określić na podstawie końca widocznej linii łamanej. Dlatego widoczność linii łamanej trasy musi być tak samo lub bardziej ograniczona niż widoczność pojazdu.

Aby podać prawidłową kombinację widoczności linii łamanych trasy i lokalizacji pojazdu, postępuj zgodnie z tymi zasadami.

Linie łamane trasy i lokalizacja pojazdu mają te same opcje widoczności.

W tym scenariuszu zarówno linia łamana, jak i lokalizacja pojazdu ustawiają te same opcje, które obejmują:

  • pozostała liczba przystanków,
  • czas do szacowanego czasu dotarcia na miejsce
  • pozostały dystans do przejechania,

Aby zachować zgodność z zasadami, wartość widoczności polilinii trasy musi być mniejsza lub równa wartości ustawionej dla widoczności pojazdu. W tym przykładzie pozostały próg zatrzymania dla linii łamanej jest ustawiony na 3, czyli mniej niż wartość 5 określona dla pojazdu. Oznacza to, że gdy śledzona podróż osiągnie 5 przystanków od lokalizacji zadania, pojawi się pojazd, ale trasa tego pojazdu nie będzie widoczna, dopóki podróż nie będzie oddalona o 3 przystanki.

```js
"taskTrackingViewConfig": {
  "routePolylinePointsVisibility": {
    "remainingStopCountThreshold": 3
  },
  "vehicleLocationVisibility": {
    "remainingStopCountThreshold": 5
  },
}
```

Linie łamane trasy i lokalizacja pojazdu określają różne opcje widoczności.

Jeśli polilinie trasy i lokalizacja pojazdu mają różne opcje widoczności, lokalizacja pojazdu jest widoczna tylko wtedy, gdy spełnione są obie opcje widoczności. Widoczność polilinii zależy od reguł widoczności pojazdu:

  • Zawsze widoczna: linia łamana trasy musi używać opcji widoczności zawsze widoczna, jeśli lokalizacja pojazdu również udostępnia tę samą opcję widoczności zawsze widoczna.
  • Nigdy nie jest widoczna: linia łamana trasy musi używać opcji widoczności nigdy nie jest widoczna, gdy lokalizacja pojazdu używa opcji widoczności nigdy nie jest widoczna.

Przykład:

  "taskTrackingViewConfig": {
    "routePolylinePointsVisibility": {
      "remainingStopCountThreshold": 3
    },
    "vehicleLocationVisibility": {
      "remainingDrivingDistanceMetersThreshold": 3000
    },
  }

W tym przykładzie lokalizacja pojazdu jest widoczna tylko wtedy, gdy liczba pozostałych przystanków jest co najmniej równa 3 I pozostała odległość do przejechania wynosi co najmniej 3000 metrów.

Przykład dostosowywania widoczności zadań

Poniższe przykłady pokazują, jak ustawić zadanie z tymi regułami widoczności:

  • Wyświetlaj linie trasy, jeśli pojazd znajduje się w odległości 3 przystanków.
  • Wyświetl szacowany czas przyjazdu, jeśli pozostała odległość do przejechania jest mniejsza niż 5000 metrów.
  • Nigdy nie wyświetlaj liczby pozostałych przystanków.
  • Pozostałe pola zachowują domyślną widoczność, czyli są wyświetlane, gdy pojazd znajduje się w odległości 5 przystanków od miejsca wykonania zadania.

Więcej informacji o gRPC i REST znajdziesz w TaskTrackingViewConfig.

gRPC

static final String PROJECT_ID = "my-delivery-co-gcp-project";
static final String TASK_ID = "task-8241890";

DeliveryServiceBlockingStub deliveryService =
  DeliveryServiceGrpc.newBlockingStub(channel);

// Task settings
String taskName = "providers/" + PROJECT_ID + "/tasks/" + TASK_ID;
Task task = Task.newBuilder()
  .setName(taskName)
  .setTaskTrackingViewConfig(
    TaskTrackingViewConfig.newBuilder()
      .setRoutePolylinePointsVisibility(
        VisibilityOption.newBuilder().setRemainingStopCountThreshold(3))
      .setEstimatedArrivalTimeVisibility(
        VisibilityOption.newBuilder().remainingDrivingDistanceMetersThreshold(5000))
      .setRemainingStopCountVisibility(
        VisibilityOption.newBuilder().setNever(true)))
  .build();

// Task request
UpdateTaskRequest updateTaskRequest =
  UpdateTaskRequest.newBuilder()  // No need for the header
      .setTask(task)
      .setUpdateMask(FieldMask.newBuilder().addPaths("taskTrackingViewConfig"))
      .build();

try {
  Task updatedTask = deliveryService.updateTask(updateTaskRequest);
} catch (StatusRuntimeException e) {
  Status s = e.getStatus();
  switch (s.getCode()) {
      case NOT_FOUND:
        break;
      case PERMISSION_DENIED:
        break;
  }
  return;
}

REST

Aby ustawić okno konfiguracji widoku śledzenia zadań za pomocą protokołu HTTP, wywołaj PATCH i użyj updateMask, aby zaktualizować parametr taskTrackingViewConfig:

PATCH https://fleetengine.googleapis.com/v1/providers/<project_id>/tasks/<id>?updateMask=taskTrackingViewConfig

Na przykład:

# Set JWT, PROJECT_ID, and TASK_ID in the local environment
curl -X PATCH "https://fleetengine.googleapis.com/v1/providers/${PROJECT_ID}/tasks/${TASK_ID}?updateMask=taskTrackingViewConfig" \
  -H "Content-type: application/json" \
  -H "Authorization: Bearer ${JWT}" \
  --data-binary @- << EOM
{
  "taskTrackingViewConfig": {
    "routePolylinePointsVisibility": {
      "remainingStopCountThreshold": 3
    },
    "estimatedArrivalTimeVisibility": {
      "remainingDrivingDistanceMetersThreshold": 5000
    },
    "remainingStopCountVisibility": {
      "never": true
    }
  }
}
EOM

Co dalej?