pit - Mobile Server Release Notes

Revision 363

vollständiger Support für Webservice-Kommunikation über SSL.
Klasse ist jetzt per Flag isView als pit-View markierbar -> Anlegen, Bearbeiten, Löschen von Datensätzen in pit - Mobile wird ignoriert.
Datum + Uhrzeit wird in Timelog geschrieben
Synchronisationsfehler behoben wenn Klasse zwischen zwei Synchronisationen aus contract.json verschwunden ist.
PHP Fehler behoben wenn leeres Datenobjekt übergeben wird.
PHP Sessions werden nun vollständig bereinigt.

Revision 359

Der ConfigChecker ist ein neues Tool für den pit - Mobile Server, das die aktuelle Server-Konfiguration ausgibt. Er ist aufrufbar über die angehangene Url /core/tools/configchecker.
Lightweight-Attribute werden nun im Rahmen der Synchronisation unterstützt.
Falls bei der Verwendung des Datameter-Tools die Eigenschaft contract nicht definiert ist, wird nun eine PHP-Warnung ausgegeben.

Revision 353

Möglichkeit per requestFileName eine einzulesende Datei mit anzugeben; Ablage unter temp, Bsp: http://localhost/mobile/mangelmanagement/2018/?requestFileName=test.txt
Pfad-Attribut wird auch gesetzt wenn Datei nicht in pit - FM abgelegt wurde
Unterstützung neuer Prozessattribute für zukünftige Client-Versionen
besseres Error-Handling bei ungültigen IDs

Revision 351

Datenabfrageoptimierung von Listen an pit-IS

Bisher resultierten aus der Abfrage von Daten einer Klasse SQL-Statements in welchen die einzelnen, auf dem Gerät bereits vorhandenen, IDs per OR miteinander verknüpft wurden. Vor allem bei großen Datenmengen führte dies zu einer unnötig komplexen Anfrage.

Mit dieser Version des Server-Cores wurden die an den Webservice übermittelten Parameter überarbeitet, sodass stattdessen ein ID IN (…) resultiert. Dies führt zu (teilweise deutlich) spürbaren Verbesserungen der Synchronisationsgeschwindigkeit.

Nutzung des Synchronisationscache über pit – FM

In der Vergangenheit ist es immer wieder zu Problemen mit Duplikaten nach fehlerhaften Synchronisationen gekommen. Ursache hierfür war das Speichern der Zuordnung zwischen mobiler ID und erzeugter pit ID erst nach dem Commit in einer Textdatei. Ist allerdings während der Ausführung des Commits ein Timeout (oder anderer Fehler) aufgetreten, so konnte das entsprechend notwendige Speichern der Zuordnungen im Synchronisationscache nicht stattfinden.

Im Rahmen der Prüfung dieser Thematik wurden verschiedenste Lösungsansätze diskutiert. Das Ergebnis dieser Diskussionen war, dass das Speichern der o.g. Mappings direkt im pit - FM stattfinden muss. Dies ist optional durch folgende Schritte möglich:

Erweiterung des Metamodells
Setzen der Einstellung legacySyncCache = false unterhalb von [Sync] in der settings.ini des mobilen Projekts

Funktionsausführung an einzelnen Klassen vor der Datenabfrage

Bisher war es nur möglich, zu Beginn oder Ende einer Synchronisation eine Klassenformel in pit - FM auszulösen (fireStartEvent, fireStopEvent). Allerdings kann es unter Umständen möglich sein, dass sich aus der ersten Phase der Datensynchronisation (Datensätze anlegen/modifizieren) die Notwendigkeit ergibt, erneut einen Automatismus auszulösen. Im Gegensatz zu Start- und Stop-Event kann dies nun klassenweise ausgelöst werden. Hierfür sind folgende Voraussetzungen zu erfüllen:

Die Methode muss folgendem Template entsprechen und im Service-Mode aktiv sein:

///
/// Parameter:
/// int $iEvent - numerischer Wert für ein durch die Synchronisation ausgelöstes Event
/// string $sClassname - aktuell in der Synchronisation befindliche Klasse
///
/// Mögliche Werte für $iEvent:
///     0 = StartSync; bisher fireStartEvent in settings.ini; $sClassname ist nicht gesetzt
///     1 = BeforeGetData; $sClassname ist gesetzt; alle Änderungen sind bereits in der DB gespeichert. Ab jetzt werden nur noch Daten auf das Gerät synchronisiert
///     2 = StopSync; bisher fireStopEvent in settings.ini; $sClassname ist nicht gesetzt
/// </SUMMARY>
safe function void ExecuteMobileSyncEvent(int $iEvent, string $sClassname)
{
      ...
}

Innerhalb des Prozesses muss an der entsprechenden Klasse die Eigenschaft events mit folgendem Inhalt definiert werden:
```
{
    "BeforeGetData": true
}
```

Alternatives Auslösen von Start- & Stop-Event

Für eine perspektivische Zentralisierung aber auch Standardisierung der Funktionalitäten ist es künftig möglich, alternativ zu den in der settings.ini bekannten Einstellungen fireStartEvent und fireStopEvent innerhalb des Vertrags zu definieren, ob entsprechende Aktionen ausgeführt werden sollen. Diese durchlaufen dann, wie an anderer Stelle bereits definiert, die Funktion ExecuteMobileSyncEvent mit den Event-Werten 0 (Start) bzw. 2 (Stop). An dieser Stelle wird jedoch kein Klassenname übergeben. Zur Nutzung dieser Funktionalität muss neben der entsprechenden Klassenformel die neue Eigenschaft events innerhalb des Vertrags folgendermaßen definiert werden:

{
    "StartSync": true,
    "StopSync": true
}

Table of Contents