archive
archive!
archive!
2.5.6
.free
.Die contagt API führt ein langerwartetes Feature ein. Statistiken und einige Logs wurden auf Mongo 8.0
portiert und sollen so eine bessere Wartbarkeit, schnellere Zugriffszeiten zukunftssichere Speicherung ermöglichen.
Es existiert bereits eine weite Roadmap für den einsatz von dokumentenbasiertem Speicher in einige anderen Anwendungsfeldern und wir freuen uns diese jetzt angehen zu können.
Generell war es bisher für die Wartung von On-Premise installationen möglich, Datenbank und Datenmigrationen für jedes Update breitzustellen und so auf die Bedürfnisse von neuen Funktionen einzugehen.
Mit dieser Version werden auch Update Recipes für universelle Transformationsarbeiten im Rahmen eines Updates eingeführt.
Mithilfe dieser wird es auch in Zukunft möglich sein die contagt API von der Version auf den neusten Stand zu patchen, ohne zwischenversionen installieren zu müssen und dabei an allen Stellen kompatibel zu bleiben.
Als erster Anwendungsfall wird die Speicherqualität aller Galerie Thumbnails erhöht um den gestiegenden Anforderungen durch Endgeräte Rechnung zu tragen.
Mit dem Update zur Version 1.62.0 wird ein komplett neuer RPC Response Cache eingeführt. Dieser erlaubt es redundante Anfragen von Clients direkt aus einem In-Memory Cache zu beantworten und so die Latzenzen beim Refresh von Web Anwendungen oder dem Download von gecachten Guide Sets erheblich zu beschleunigen und gleichzeitig die Server Load an der API zu reduzieren.
Falls ein API Client dringend ein sehr aktuelles, ungecachtes Datenset benötigen sollte, ist es möglich dies über den API Paramter nocache: true
anzufragen. Weitere Details in der Dokumentation
Zu jedem einzelnen RPC gibt es darüber hinaus einen Eintrag zu seinen caching Eigenschaften in der RPC-Referenz
Um die Datenpflege in vielen Zielsprachen zu vereinfachen können ab sofort über die contagt API automatische Übersetzungen in alle für den Guide konfigurierten Zielsprachen angefordert werden.
Über den Content Editor steht eine UI Komponente zur verfügung, die alle nicht manuell eingetragenen Werte automatisch mit KI-Übersetzungen ergänzt.
Limitierungen: Falls struktuierte Daten wie Markdown, XML, HTML oder ähnliche Markups hinterlegt wurde, kann es vorkommen, dass das Markup durch die Translation-API zu einer ungültigen Syntax verändert wird. Wir bemühen uns den Service immer "schlauer" zu gestalten, dennoch kann es Vorkommen, dass die KI Token und Inhalte nicht korrekt voneinander unterscheidet. Daher ist hier Kontrolle wichtig!
Seit einigen Versionen erlaubt PHP unterschiedliche Bereiche mit Attributen (ähnlich den Java Annotations) mit Metadaten anzureichern. Hier wurde ein System geschaffen mit dem Speicher als sensitiv markiert werden kann, sodass nicht z.B. durch unachtsame Implementierungen oder Fehler Passwörter in Logs oder (teil)öffentliche Exports geleakt werden können.
Bisher konnten bereits viele Attribute einzelner georeferenzierter Datenpunkt (POIs) durchsucht werden, dazu gehörten u.A. die Standard-Attribute wie der Anzeigename oder die Beschreibung, aber auch Inhalte in standardisierten Formatierungen wie z.B. Telefonnummern, Öffnungszeigen uvm.
Neu in 1.62.0
ist, dass nun auch Ziele über die Namen ihrer verknüpften Kategorien gesucht werden können,
natürlich auch jeweils in der angefragten Ausgabesprache.
Limitierungen: Ist für die Kategorie Ausgang z.B. die französische Übersetzung Sortie definiert, so liefert eine Suchanfrage mit der Zielsprache en_EN (standard Englisch) für den Suchbegriff Sortie !keinen! Treffer, aber für die Anfragesprache fr_FR (standard Französisch) schon.
Zugegeben, unbebedacht; Bisher wurden Postleitzahlen von Guides als Zahlenwerte gespeichert.
Dies konfligiert ganz klar mit den Anforderungen an Postleitzahlen. Schon in Ostdeutschland beginnen diverse Postleitzahlen mit einer 0
was in den natürlichen Zahlen ℕ
nicht erlaubt ist.
Noch problematischer wird das Ganze in Ländern wie England, in denen Postleitzahlen auch Buchstaben enhalten.
Daher wurde der hinterlegte Datentype auf eine Zeichekette von bis zu 16
Zeichen geändert.
Um die Aktivierung von Useraccounts schneller und ressourcenschonender zu gestalten wurde das Standardisierte Longpolling Interface, wie in div. anderen Funktionen implementiert.
Wie immer wurden viele kleinere Probleme behoben, Code optimiert und Funktionen hinzugefügt. API Interfaces bleiben dabei innerhalb ihrer API Level Version wie immer Rückwärtskompatibel.
Starting in Version 1.57.0 the contagt API extends its support for two factor authentication.
Before this update, only email second factor was supported, now you can also register an App such as 2FAS or Google Authenticator to secure your admin account on our platform.
See How to setup twofactor in our documentation.
Starting in Version 1.57.0 the contagt API extends its support for two factor authentication.
Before this update, only email second factor was supported, now you can also register an App such as 2FAS or Google Authenticator to secure your admin account on our platform.
See How to setup twofactor in our documentation.
Zu vielen RPCs wurde die Dokumentation verbessert und ausfürlicher gestaltet.
Mit Version 1.55.0 wird PHP 8.3 die neue Grundlage für die contagt API. Mit diesem Update können viele neue Funktionen von PHP für die Weiterentwicklung der Plattform verwendet werden, es gibt aber auch Sicherheits- und Geschwindigkeitsvorteile.
Die contagt API kann nun deutlich mehr Daten auf den einzelnen Instanzen Cachen und die Caches zwischen den Instanzen teilen. Damit können API Requests noch schneller bearbeitet werden.
Die contagt API integriert für Suchen und Routings jetzt mehr native OSM-Konforme Features um das Indoor- und Outdoorerlebnis noch nahtloser zu verbinden.
The new API Version allows a, iterative, request chaining mode.
While in the current versions of our API it was already possible to chain requests you can now use iterative and wildcard accessors.
There can not be more then one parameter wildcard per request,
configurations like
$GetBuildingInfo.0.allTags.*.importantTags.*.tag_id
will be invalid and lead to empty results.
Therefore there are multiple Modes and Options. One can either execute a subrequest for all responses of earlier staged requests
↪ Request
{
"0": {
"building_id": 19
},
"1": {
"building_id": 19
},
"2": {
"tag": "$GetBuildingInfo.*.roottag"
}
}
↩ Response
{
"GetBuildingInfo": [
{
< ... >
}
],
"GetBuildingInfo": [
{
< ... >
}
],
"LoadTag": [
{
< ... >
}
],
"LoadTag": [
{
< ... >
}
]
}
and/or apply the wildcard operator to array data on the response of a function like
$<MethodenName>.<Idx> or <*>.<ParameterName>.<Idx> or <*>.<SubparameterName>
.
Here is an example for iterating an array response where three different contagt-IDs loaded from a request result in three resonses for LoadTag
.
↪ Request
{
"0": {
"building_id": 19
},
"1": {
"tag": "$GetBuildingInfo.0.allTags.*.tag_id"
}
}
↩ Response
{
"GetBuildingInfo": [
{
< ... >
allTags: [
{
tag_id: "..."
},
{
tag_id: "..."
},
{
tag_id: "..."
}
]
}
],
"LoadTag": [
{
< ... >
}
],
"LoadTag": [
{
< ... >
}
],
"LoadTag": [
{
< ... >
}
]
}
Wildcard request chaining is only functional in strict
mode and can lead to undefined behavior sending it on non-strict api calls.
You should be very careful with the wildcard feature, since it gets very easy to generate an excessive amount of api load with a single request, especially when using function and parameter wildcards.
In Version 1.47.0 it is mainly about caching.
With this update we introduce the dynamic multi route caching feature which will allow all apps to drastically improve the speed of calculating predefined multiroutes.
This cache does not only improve the reoccuring calculations of entire multiroutes, but also will share equal subroute-caches between multiroutes to reduce the overall expense on cache maintenance.
The Delta-Cache for Exporter Data has been upgraded and is re-enabled within this version. It allows all nativly caching apps to only download the delta-changeset of the the guide data since the last update and will therefore spare some of your prescious traffic volume. At the same time the caching strategies will still be applied to all non-changed data to provide the output to the apps at maximum speed.
An Hotfix Update has been released, fixing the issue that Webapp loads were not part of the Guide-Access statistics. This is now changed and also affects past entries. All Statistics should now be correct again.
A new Update is available, with the following new features.