Fleet Monitoring Status Updates

Why Agapi tells the Fleet Monitoring Platform about trip handover and what this integration does not do.

The Symfony integration with the Fleet Monitoring Platform (FMP) has one narrow purpose: tell the external platform when a boat is checked in or checked out.

This helps another operational system understand whether the boat has moved into or out of member use. It is not a general telemetry service inside this repository.

When a status is sent

Only two saved booking states trigger the integration:

Agapi booking state	Value sent to FMP	Business meaning
`checked in`	`Checkin`	The member trip started and custody was handed over.
`checked out`	`Checkout`	The member trip ended and the boat was returned.

Other states such as booked, blocked, payment pending, cancelled, or expired are not sent by this service.

sequenceDiagram
    actor Operator
    participant Booking as Agapi booking
    participant DB as PostgreSQL
    participant FMP as Fleet Monitoring Platform

    Operator->>Booking: Change to checked in or checked out
    Booking->>DB: Save the new state
    DB-->>Booking: Saved
    Booking->>FMP: Boat ID and Checkin/Checkout
    FMP-->>Booking: HTTP result

The local booking is saved before the FMP request is made. Therefore, an FMP failure does not mean the booking stayed in its old state.

What is sent

The outbound JSON contains only:

vehicle_id — the Agapi resource/boat ID from the booking;
status — Checkin or Checkout.

The request uses the configured FMP URL and basic authentication. A response with HTTP 201 Created is logged as success; another response is logged as a failure with its code and body.

Enabled and disabled behavior

The integration runs only when FMP_ENABLE is enabled. When it is disabled, the booking state still changes but no FMP request is sent.

When enabled, URL, username, password, and date-format settings must be present. Missing configuration raises an error after the booking status has already been saved. Support staff must therefore check Agapi and FMP separately.

Safe recovery

If a member is shown as checked in/out in Agapi but FMP did not receive it:

confirm the booking ID, boat ID, final state, and change time;
inspect the FMP log result and configuration for the correct environment;
confirm whether FMP already received the request despite a client-side error;
use an approved resend or reconciliation procedure for the missing status;
do not toggle the booking through false states merely to trigger another call.

Changing a real booking state for transport recovery can create incorrect member history and unrelated messages.

What this integration does not provide

The inspected Symfony service does not receive live GPS, engine, battery, fuel, or geofence events. It has no sensor inventory, incoming webhook, alert engine, or durable retry queue.

Other parts of the wider platform may display measured boat values, but they must not be attributed to this two-state outbound service without following their actual source.

Technical reference

BookingRepository::setStatus() saves the state and calls FleetMonitoringPlatformService::sendData() only for the two FMP states. Configuration names are FMP_ENABLE, FMP_URL, FMP_USERNAME, FMP_PASSWORD, and APP_DATE_FORMAT; values must never be copied into documentation.