- Fleet Events Reference Solution (landing page)
- Getting started - Dataflow (set up Fleet Events with the Dataflow processor)
- Getting started - Cloud Functions (set up Fleet Events with the Cloud Functions processor)
- ODRD Overview (describes components of the Cloud Functions processor)
- ODRD handlers (describes each handler supported by ODRD solution)
- Transactions (describes Firestore transactions)
- LMFS Overview (describes components of the Cloud Functions processor)
- LMFS handlers (describes each handler supported by LMFS solution)
- Transactions (describes Firestore transactions)
- ODRD Overview (describes components of the Cloud Functions processor)
This git repo is structured as follows.
- cloud-functions/: reference functions source code for Cloud Functions
- beam/: reference functions source code for Dataflow
- terraform/: deployment automation with terraform
- modules/: folder holding multiple terraform modules
- fleet_events:
README.md
: README for the modulemain.tf
: main code for the modulevariables.tf
: defines input parameters of the moduleoutputs.tf
: defines outputs of the module*.tf
:examples/
: one or more example use of the modulewith_existing_project/
:README.md
: readme for the examplemain.tf
: main terraform code showing use of the module*.tf
terraform.tfvars.sample
: sample config file
with_new_project/
…
- fleet-events-function
…
- fleetengine-logging-config
…
- fleet_events:
- modules/: folder holding multiple terraform modules
tools
: utilitiespython
*.py
: utilities to validate the deployment
- diagrams/: diagrams used in articles
*.md
: additional documents
The Fleet Events Reference Solution is an open source solution that enables Mobility customers and partners to generate key events on top of Fleet Engine and Google Cloud Platform components. The reference solution supports customers using the Last Mile Fleet Solution and On Demand Rides and Delivery.
With the Fleet Events Reference Solution, customers can generate the following events with little or no custom code:
- ETA change of task/trip arrival
- Relative ETA change of task/trip arrival
- Time remaining to task/trip arrival
- Distance remaining to task/trip arrival
- Task/TripOutcome status change
Each component of the reference solution can be customized to suit your business needs.
To get started - we support different Processing engines to compute events and provide a set of tools to automatically provision building blocks. To set up “Fleet Events” within your GCP Project, choose a Processor and follow the guides below. For those who are new to Fleet Events, we recommend starting with Cloud Functions:
Diagram : Fleet Events overview and logical building blocks
The reference solution contains the following components:
- Event Source: Where the original event stream comes from. Both “Last Mile Fleet Solution” or “On Demand Rides and Deliveries Solution” have integration with Cloud Logging that helps to turn Fleet Engine RPC call logs into event streams available to developers. This will be the core source to consume.
- Processing: Raw RPC call logs will be converted into state change events within this block that computes over a stream of log events. To detect such change, this component requires a state store so that new events can be compared with previous ones to detect change. Events might not always include all the information of interest. In such cases, this block might make look up calls to backends as needed.
- State store: Some processing frameworks provide intermediate data persistent on its own. But if not, in order to store state on your own, since these should be unique to a vehicle and event type, a K-V type data persistence service will be a good fit.
- Sink (Custom Events): Detected state change should be made available to any application or service that can benefit from it. Therefore it will be a natural choice to publish this custom event to an event delivery system for downstream consumption.
- Downstream service: Code that consumes the generated events and takes actions unique to your use case.
Google maintains this article. The following contributors originally wrote it.
Principal authors:
- Ethel Bao | Software Engineer, Google Maps Platform
- Mohanad Almiski | Software Engineer, Google Maps Platform
- Naoya Moritani | Solutions Engineer, Google Maps Platform