Skip to main content

MFR (Mobile Field Report)

Anbindung an Mobile Field Report (OData v4 + REST). Auth ist HTTP Basic, Daten kommen via OData mit expand-Statements.

Im Gegensatz zu Grenke und Weclapp gibt es bei MFR klassische apiResource-Controller für 15+ Entities, die jeweils CRUD + Sync-Logik kapseln.

Stack

Inhalt

Konfiguration

MFR_BASE_URL="https://portal.mobilefieldreport.com/odata/"
MFR_API_USERNAME="..."
MFR_API_PASSWORD="..."

Routen

GET    /api/v1/mfr/show                                          # MfrController::index
GET /api/v1/mfr/show/{entity?}/{attribute?}/{value?} # MfrController::show
GET /api/v1/mfr/sync/{entity?} # MfrController::sync (Common-DB ← MFR)
GET /api/v1/mfr/setup/{stage?} # MfrController::setup
GET /api/v1/mfr/post/{stage?}/{type?}/{entity?} # MfrController::post

# apiResource (index, show, store, update, destroy)
companies → CompanyController
contacts → ContactController
products → ProductController
documents → DocumentController
timeEvents → TimeEventController
stepListTemplates → StepListTemplateController
itemTypes → ItemTypeController
itemUnits → ItemUnitController
users → UserController
costCenters → CostCenterController
tags → TagController
qualifications → QualificationController
serviceObjects → ServiceObjectController
serviceRequests → ServiceRequestController
items → ItemController

Bidirektionaler Schreib-Pfad

Jeder Mfr-Controller schreibt sowohl in die Common-DB als auch (optional) zurück nach MFR. Steuerung über das Boolean-Flag $toMfr:

public function store(Request $request, bool $toMfr = true) { ... }
public function update(Request $request, Companies $company, bool $toMfr = true) { ... }
public function destroy(Companies $company, bool $toMfr = true) { ... }
  • $toMfr = true (Default): erst MFR via GuzzleClient, dann lokale Common-DB updaten
  • $toMfr = false: nur lokale DB — z.B. wenn ein Webhook von Weclapp ankommt und MFR der eigentliche Empfänger ist (siehe WebHookCallController::create)

Daten-Modelle

app/Models/Common/Mfr/ enthält die lokalen Spiegel-Modelle (gegen die Common-DB), z.B.:

  • CompaniesId, Version, Name, BillingAddress, Contacts, Tags, ServiceObjects, …
  • Contacts, CostCenters, Documents, ItemTypes, Items, Products, Qualifications, ServiceObjects, ServiceRequests, …

Jedes Modell hat in Mfr\Helper::getExpand() einen vorkonfigurierten OData-Expand-String:

'Companies'        => 'Contacts,Tags,ServiceObjects,MainContact',
'ServiceRequests' => 'Qualifications,ServiceObjects,Customer,Reports,Items,Appointments/Contacts,Steps,Comments,StockMovements,Tags',
'ServiceObjects' => 'Contacts,Company,Product,Tags',

So zieht ein Sync immer den vollen Datensatz inkl. Kindrelationen.