Konfigurowanie zadań

W tym dokumencie zakładamy, że wiesz, jak tworzyć i używać zadań. Zawiera konkretne przykłady konfigurowania zadań związanych z przesyłką na te sposoby:

  • Ustaw docelowy przedział czasu dla zadania związanego z przesyłką: 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 przesyłką znajdziesz w artykule Tworzenie zadań związanych z przesyłką. Gdy aktualizujesz dodatkowe informacje o istniejących zadaniach, musisz też podać odpowiedni identyfikator zadania, a także pola, które aktualizujesz.

Ustawianie docelowego przedziału czasu

Docelowe okno czasowe to TimeWindow, w którym zadanie powinno zostać ukończone. Jeśli na przykład podajesz odbiorcom przedział czasu dostawy, możesz użyć przedziału czasu docelowego zadania, aby go zarejestrować i wygenerować alerty, lub użyć go do analizy skuteczności wcześniejszych przejazdów.

Docelowe okno czasowe składa się z godziny rozpoczęcia i zakończenia i można je ustawić dla dowolnego typu zadania. Docelowe okno czasowe nie wpływa na działanie routingu.

Poniższe przykłady pokazują, jak ustawić przedział czasu za pomocą biblioteki gRPC w języku Java lub jak wysłać żądanie HTTP REST do UpdateTask. To pole możesz też ustawić 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ą 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

<id> to unikalny identyfikator zadania. Nagłówek żądania musi zawierać pole Authorization z wartością Bearer <token>, gdzie <token> jest wydawany przez serwer zgodnie z wytycznymi opisanymi w artykułach Role kont 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 widoczność działań związanych z zadaniami, które można następnie wyświetlać zarówno klientom otrzymującym przesyłkę, jak i operatorom floty śledzącym przesyłki. Obejmuje to takie informacje jak liczba przystanków przed wysłaniem klientowi powiadomienia o stanie dostawy przesyłki. Możesz dostosować te informacje dla każdego zadania, aby lepiej pasowały do Twojego modelu biznesowego.

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

  • Widoczność znacznika lokalizacji
  • widoczność danych o aktywnych zadaniach pojazdu, 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 widoczne na mapie, niezależnie od stanu dostawy.

Reguły widoczności danych zadania

W tej sekcji opisano domyślne reguły widoczności, które mają zastosowanie do danych zadań. Możesz dostosowywać tylko aktywne zadania pojazdu, co oznacza, że niestandardowe reguły widoczności można stosować tylko do zadań odbioru i wysiadania.

Nie można dostosować tych zadań:

  • Zaplanowane zatrzymania
  • Zadania związane z niedostępnością
  • Zadania dotyczące nieaktywnych pojazdów

Reguły widoczności zadań związanych z 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 ma przerwę lub pojazd jest tankowany na trasie do śledzonej przesyłki. Szacowany czas przyjazdu i szacowany czas ukończenia zadania są nadal dostępne. Tej reguły nie można dostosować.

Widoczność aktywnych zadań pojazdu

Obiekt TaskTrackingInfo udostępnia szereg elementów danych, które możesz wyświetlać 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 zakończeniu lub anulowaniu zadania.

Konfigurację widoczności możesz dostosować dla każdego zadania, ustawiając TaskTrackingViewConfig podczas tworzenia lub aktualizowania zadania we Fleet Engine. Spowoduje to utworzenie reguł, które umożliwią dostęp do poszczególnych elementów danych.

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

Pola zadań pojazdu dotyczące reguł widoczności
  • Linie łamane trasy
  • Szacowany czas dotarcia na miejsce
  • Szacowany czas ukończenia zadania
  • Pozostała odległość do zadania
  • Liczba pozostałych przystanków
  • Lokalizacja pojazdu

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

Opcje widoczności
  • Liczba pozostałych przystanków
  • Czas do szacowanego przybycia na miejsce
  • Pozostały dystans do przejechania
  • Zawsze widoczne
  • Nigdy niewidoczne

Linie łamane trasy i reguły 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 pojazd nie jest widoczny, widoczna jest polilinia trasy, lokalizację pojazdu można nadal określić na podstawie końca widocznej polilinii. Dlatego widoczność linii łamanej trasy musi być tak samo lub bardziej restrykcyjna niż widoczność pojazdu.

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

Łamane trasy i lokalizacja pojazdu mają takie same opcje widoczności.

W tym scenariuszu zarówno linia łamana, jak i lokalizacja pojazdu mają 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 regułami, wartość widoczności linii łamanych trasy musi być mniejsza lub równa wartości ustawionej dla widoczności pojazdu. W tym przykładzie próg pozostałych przystanków dla linii łamanej jest ustawiony na 3, czyli mniej niż wartość 5 określona dla pojazdu. Oznacza to, że gdy śledzona podróż osiągnie odległość 5 przystanków od lokalizacji zadania, pojazd się pojawi, ale trasa tego pojazdu nie będzie widoczna, dopóki podróż nie osiągnie odległości 3 przystanków.

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

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

Jeśli linie łamane 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ść linii łamanej podlega regułom widoczności pojazdu:

  • Zawsze widoczna: linia łamana trasy musi używać opcji widoczności zawsze widoczna, gdy lokalizacja pojazdu również korzysta z opcji zawsze widoczna.
  • Nigdy niewidoczna: linia łamana trasy musi używać opcji widoczności Nigdy niewidoczna, gdy lokalizacja pojazdu używa opcji widoczności Nigdy niewidoczna.

Oto 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 wynosi co najmniej 3 ORAZ pozostała odległość do przejechania wynosi co najmniej 3000 metrów.

Przykład dostosowywania widoczności zadania

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

  • Wyświetlaj linie łamane trasy, jeśli pojazd znajduje się w odległości nie większej niż 3 przystanki.
  • Pokaż szacowany czas dotarcia na miejsce, jeśli pozostała odległość do przejechania jest mniejsza niż 5000 metrów.
  • Nigdy nie pokazuj liczby pozostałych przystanków.
  • Wszystkie pozostałe pola zachowują domyślną widoczność, czyli są wyświetlane, gdy pojazd znajduje się w odległości 5 przystanków od zadania.

Zobacz TaskTrackingViewConfig dla gRPC lub REST.

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 elementu ś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?