Fortgeschrittene Synchronisierung
Wenn Sie einen Inhaltstyp definieren, werden standardmäßig alle Elemente dieses Typs an alle mobilen Geräte verteilt. Diese Einstellung ist zwar einfach und für den Anfang geeignet, lässt sich aber nicht skalieren, wenn Sie zu sehr auf Inhaltselemente setzen. Nehmen wir an, Sie haben einen Inhaltstyp 'gebaude', in dem Sie alle Gebäude erfassen, die inspiziert werden. Wenn Sie 1000 solcher Elemente haben, werden alle 1000 an alle iCL Filler Apps Ihrer Inspektoren übertragen.
Mehrere tausend Elemente sind zwar kein Problem, aber wenn Sie während Ihrer Inspektionen Mängel erstellen und verfolgen, kann diese Zahl erheblich ansteigen, bis der Synchronisierungsprozess langsam wird. Abgesehen davon ist es sehr wahrscheinlich, dass nicht alle Ihre Inspektoren wirklich alle Mängel auf ihrem Gerät vorfinden müssen.
1. Aktivieren von filteredSynchronization
Normalerweise werden Inhaltselemente in der App nur benötigt, wenn sie von einer Inspektion verwendet werden (auf die eine Aufgabe verweist).
Um dieses Verhalten zu aktivieren, können Sie einfach die gefilterte Synchronisierung für bestimmte Inhaltstypen einschalten, indem Sie in der json-Definition der Inhaltstypen filteredSynchronization:true
angeben.
Einmal konfiguriert, werden Elemente des Typs Gebaude
nur dann an die Geräte Ihrer Benutzer gesendet, wenn diese eine Aufgabe (über das Feld itemsToInspect
oder 'Inspected objects') für sie haben.
{
"$type": "contentType",
"name": "gebaude",
"displayName": "Gebäude",
"canBeInspected": true,
"titleFieldName": "bezeichnung",
"icon": "fa-building",
"filteredSynchronization":true,
"fields": [...]
...
}
Der Grund, warum dies pro Inhaltstyp angegeben wird, ist, dass Sie vielleicht einen Inhaltstyp Gebäude haben, der gefiltert werden muss, weil Sie viele Gebäude in Ihrem System haben, aber es kann auch einen Inhaltstyp Gebäudekategorie geben, der nur eine sehr begrenzte Anzahl von Elementen enthält (z.B. 100) und daher keine Sync-Filter benötigt.
Denken Sie daran, dass Synchronisierungsfilter zwar die Datenmenge reduzieren, die an die Geräte der Benutzer übertragen wird, aber die Abfragekomplexität und damit die Belastung der Datenbank-Engine erheblich erhöhen. Aktivieren Sie daher die gefilterte Synchronisierung mit Vorsicht - sie ist keine Wunderwaffe!
Sie werden dann sehen, dass das Kontrollkästchen in gefilterte Synchronisierung für diesen Typ aktiviert sein wird
Während die Elemente aller nicht gefilterten Elemente immer auf alle Geräte übertragen werden, werden gefilterte Inhaltstypen nur synchronisiert, wenn sie eine der folgenden Regeln erfüllen:
1. Das Element des Inhalts ist in itemsToInspect
enthalten
Wenn es eine Aufgabe gibt, die mit einem Gerät des Benutzers synchronisiert wird und die auf ein gefiltertes Element in itemsToInspect
verweist, wird das Element synchronisiert.
Beispiel: Wenn Sie eine Aufgabe zur Inspektion eines Gebäudes erstellen und dieses Gebäude der Aufgabe als itemToInspect
hinzufügen, wird das Gebäude auch an das Gerät gesendet.
2. Das Inhaltselement wird in den Aufgabendaten verwendet
Wenn eine mit dem Gerät des Benutzers synchronisierte Aufgabe zusätzliche Daten enthält (Aufgabendaten, die zum Vorausfüllen von Checklisten verwendet werden), die sich auf ein gefiltertes Inhaltselement beziehen, wird das Element synchronisiert.
Beispiel: Wenn Sie eine Aufgabe erstellen (über die REST-Schnittstelle oder den Excel-Import), die die eindeutige ID eines Gebäudes B enthält, das in ein Checklistenfeld eingetragen werden soll, dann wird diese Identität erkannt und das Gebäude ebenfalls an das Gerät gesendet
3. Das Element wird innerhalb einer Checkliste verwendet
Wenn eine Inspektion mit dem Gerät eines Benutzers synchronisiert wird, die eine Checkliste enthält, die auf ein Element in einem Feld 'Inhaltselement' verweist, wird dieses Element ebenfalls an das Gerät gesendet.
Beispiel: Ein Gebäude A existiert auf Ihrem Gerät, weil es eine der anderen Regeln erfüllt. In der Checkliste wählen Sie das Gebäude A manuell über ein Feld 'Inhaltselement' aus. Auch wenn die ursprüngliche Regel nicht mehr erfüllt ist, bleibt das Gebäude A auf Ihrem Gerät, da es in der Checkliste verwendet wird.
4. Ein übergeordnetes Mangel Element erfüllt eine der oben genannten Regeln
Ein Mangel-Element verweist auf ein Element, das eine der oben genannten Regeln erfüllt. Da Mängel immer zusammen mit ihren übergeordneten Elementen synchronisiert werden, wird auch dieses Element an das Gerät gesendet.
Beispiel: Ein Gebäude A wurde vor einiger Zeit inspiziert. Bei dieser Inspektion haben Sie mehrere Mängel festgestellt, die bei Abschluss der Inspektion angelegt und A zugeordnet wurden. Jetzt inspizieren Sie dieses Gebäude erneut. Da die Mängel mit A mitgeschickt werden, können Sie alle bereits vorhandenen Mängel sehen und feststellen, ob neue aufgetreten sind und/oder ob die vorhandenen Mängel bereits behoben wurden.
Diese Funktionalität der 'Synchronisierung verwandter Elemente' funktioniert nur bei Mängeln. Wenn Sie ein Gebäude haben, dem fünf Stockwerkelemente zugeordnet sind, werden diese Stockwerke nicht automatisch synchronisiert.
Jetzt, da Sie wissen, welche Regeln sich darauf auswirken, ob ein Element synchronisiert wird, müssen wir Ihnen einige technische Hintergrundinformationen geben, die Ihnen helfen werden, die Prinzipien hinter der gefilterten Synchronisierung und deren Auswirkungen auf Ihr System vollständig zu verstehen.
Wie bei Inspektionen und Aufgaben wird anhand von Synchronisierungsregeln festgelegt, ob ein Objekt (Inspektion, Aufgabe, Element, Datei, ...) mit dem Gerät eines Benutzers synchronisiert wird oder nicht. Diese werden jede Minute im Hintergrund von dem Job namens IEvaluateSyncRulesJob.Execute
ausgewertet.
Wenn nun ein gefiltertes Element eine der oben genannten Regeln erfüllt, wird es vom Hintergrundjob IEvaluateSyncRulesJob.Execute
als zu synchronisieren markiert.
Diese Markierung ist dann 24 Stunden lang gültig.
Das bedeutet, dass jeden Tag um Mitternacht die Markierung dieser Elemente erneuert werden muss (durch den Hintergrundjob IReEvaluateInspectionSyncRulesJob.Execute
).
Das bedeutet auch, dass ein Element, das keine Synchronisierungsregel mehr erfüllt, weiterhin auf das Gerät des Benutzers übertragen wird, bis die Markierung schließlich nach 24 Stunden abläuft. Diese Strategie wurde gewählt, da sie für viele Elemente besser skalierbar ist.
Beachten Sie bitte auch, dass alle gefilterten Elemente pro Team synchronisiert werden, wenn eine Aufgabe selbst zuweisbar ist. Das heißt, wenn sich eine selbst zuweisbare Aufgabe, die 'Antony' vom Team 'Gebäudeinspektionen' zugewiesen wurde, auf ein Gebäude A bezieht, dann wird dieses Gebäude nicht nur mit dem Gerät von 'Antony' synchronisiert, sondern auch mit den Geräten aller anderen Inspektoren des Teams 'Gebäudeinspektionen'. Auch hier wurde diese Strategie gewählt, da sie das Beste aus beiden Welten bietet, was die Komplexität der Abfrage und die Menge der übertragenen Daten (Bytes) angeht.
2. Benutzerdefinierte Sync-Filter
In manchen Fällen ist der oben erwähnte Ansatz der Gefilterten Synchronisierung nicht ausreichend.
2.1 Zusammenhängende Elemente mit synced
synchronisieren
Es kann Fälle geben, in denen Sie eine Reihe von Inhaltstypen haben, die miteinander in Beziehung stehen und daher immer zusammen synchronisiert werden sollten.
Zum Beispiel könnten Sie eine Inspektion für ein Gebäude planen. Während dieser Inspektion soll der Benutzer alle Feuerlöscher des besagten Gebäudes durchgehen und überprüfen, ob sie ohne Mängel und vorhanden sind. Nun wäre es sinnvoll, einen Inhaltstyp Gebäude
zu haben, der das Gebäude repräsentiert und für das Sie eine Aufgabe erstellen möchten. Die Feuerlöscher (die durch einen separaten Inhaltstyp feuerloescher
repräsentiert werden) sollten zusammen mit dem Gebäude, zu dem sie gehören, synchronisiert werden - Sie möchten nicht alle x Feuerlöscher als inspected object zu der Aufgabe hinzufügen müssen.
Um dies zu erreichen, können Sie unsere erweiterte Sync-Filterfunktion verwenden, mit der Sie festlegen, dass Elemente vom Typ Feuerloescher
immer dann auf das Gerät eines Benutzers synchronisiert werden sollen, wenn ihr übergeordnetes Gebäude (Gebäude
) synchronisiert wird.
{
"$type": "contentType",
"name": "feuerloescher",
"displayName": "Feuerlöscher",
"canBeInspected": true,
"titleFieldName": "bezeichnung",
"filteredSynchronization":true,
"fields": [
...
,{
"$type": "contentField",
"type": "ContentItem",
"name": "buildingid",
"displayName": "Building",
"isRequired": true
}
],
"filteredSynchronization": true,
"syncRules": [
{
"$type": "syncRule",
"filter": {
"$type": "synced",
"field": "buildingid"
}
}
],
"relationships": [
{
"$type": "contentRelationship",
"name": "Building",
"displayName": "Building",
"foreignKeyField": "buildingid",
"targetContentType": {
"$type": "contentTypeRef",
"id": "1eee7b9b-66d7-4760-b75b-03cd1a085bbd",
"version": 1
}
}
]
...
}
Wenn Sie eine hierarchische Sync-Regel definieren, geht das System davon aus, dass alle Elemente, die von einem synchronisierten Element abhängen, an denselben Empfänger gesendet werden sollen. Daher müssen Sie in der Syncrule keinen Empfänger angeben. Sie können dieses Verhalten jedoch außer Kraft setzen, indem Sie einen Empfänger angeben.
Beachten Sie die Definition von syncRules
, in der wir festlegen, dass dieser Inhaltstyp synchronisiert wird, wenn das Gebäude synchronisiert wird. Das funktioniert, weil wir das Feld buildingid
in unserem Filter synced
angeben, der im Grunde besagt: Sehen Sie sich den Wert des Feldes buildingid
an - wenn ein Element mit dieser Identität synchronisiert wird, synchronisieren Sie auch dieses feuerloescher
Element.
Beachten Sie auch, dass Sie sich an die folgenden Regeln halten müssen, damit dies funktioniert:
- Sie können
syncRules
nur verwenden, wenn Ihr Inhaltstyp filteresSynchronization aktiviert hat. - Sie können die Regel
synced
nur verwenden, wenn Ihr Inhaltstyp (hier:feuerloescher
) eineBeziehung
zu einem anderen Inhaltstyp definiert - in einigen Fällen definiert die
relationship
nicht den genauen Typ des Ziels:
{
"relationships": [
{
"$type": "contentRelationship",
"name": "Building",
"displayName": "Building",
"foreignKeyField": "buildingid",
"targetContentType": {
"$type": "contentTypeRef",
"version": 1
}
}
]
...
}
In diesem Fall geht das System davon aus, dass alle Inhaltstypen mit builtInType
0 (Null), die filteredSynchronization
aktiviert haben, gültige Ziele sind.
Dies macht es sehr bequem, z.B. einen Mangelinhaltstyp zu definieren, der zu jedem Typ von Elternteil gehören kann und mit diesem synchronisiert werden soll, ohne dass alle möglichen Zieltypen aktualisiert werden müssen, wann immer ein neuer passender Inhaltstyp hinzugefügt oder ein alter entfernt wird.
In seltenen Fällen kann dies jedoch zu einem zyklischen Abhängigkeitsfehler führen. In solchen Fällen können Sie explizit alle möglichen Zieltypen mit Hilfe des Arrays targetContentTypeIds
definieren:
{
"relationships": [
{
"$type": "contentRelationship",
"name": "Building",
"displayName": "Building",
"foreignKeyField": "buildingid",
"targetContentType": {
"$type": "contentTypeRef",
"version": 1
},
"targetContentTypeIds": [
"1eee7b9b-66d7-4760-b75b-03cd1a085bbd",
"396205e4-a6d7-4713-88a7-7e55010e2967",
...
]
}]
}
Beachten Sie, dass diese Regel nicht für Inhaltstypen mit "builtInType":6
(Mängel) gilt.
- Der übergeordnete Typ einer Regel, die
synced
verwendet (in diesem Fallgebaude
), muss gefilterte Synchronisation aktiviert haben. Dies ist offensichtlich, denn wenn dies nicht der Fall wäre, würden allefeuerloescher
Elemente immer mit allen Geräten synchronisiert werden, was im Grunde dasselbe Verhalten ist, wie wenn Sie die gefilterte Synchronisation gar nicht erst verwenden. - Der übergeordnete Typ einer Regel, die
synced
verwendet, darf kein Mangel sein ("builtInType":6
) - Sie dürfen mit der Regel
synced
keine zyklischen Abhängigkeiten definieren. Wenn der TypGebaude
(aus welchem Grund auch immer) eine Beziehung zuFeuerloescher
hätte (z.B. um den Hauptlöscher eines Gebäudes zu speichern...entschuldigen Sie dieses unsinnige Beispiel) und Sie würden definieren, dass ein Gebäudesynced
sein soll, wenn derFeuerloescher
synchronisiert ist, würde dies eine zyklische Abhängigkeit schaffen (Gebaude
->Feuerloescher
->Gebaude
). Beachten Sie, dass unser System eine Fehlermeldung ausgibt, wenn Sie irgendwo in Ihrer Hierarchie der Inhaltstypen einen zyklischen Zusammenhang haben
Wie bei der gefilterten Synchronisation werden die Regeln, die Sie pro Inhaltstyp definieren, jede Minute von dem Job namens IEvaluateSyncRulesJob.Execute
ausgewertet und laufen nach 24 Stunden ab.
Die Sync-Regeln werden in der Reihenfolge der Abhängigkeiten ausgewertet. Dazu analysieren wir alle Inhaltstypen, ihre Regeln und Abhängigkeiten und werten sie in dieser Reihenfolge aus. In unserem Beispiel hängt feuerloescher
von gebaude
ab (weil es die Regel synced
verwendet). Da gebaude
von keinem anderen Typ abhängig ist, wird es zuerst ausgewertet. Feuerloescher" wird als letztes ausgewertet. Aufgrund dieser Auswertung der Abhängigkeitsreihenfolge muss das System
- alle gültigen Typen einer Beziehung kennen muss (daher die Einführung des Feldes
targetContentTypeIds
) - und der Abhängigkeitsgraph darf keinen Zyklus aufweisen.
2.2 Synchronisieren auf der Basis von Filtern und Empfängern
Ein anderer Fall ist, dass Sie anhand der Attribute eines Elements festlegen möchten, ob es synchronisiert wird und an wen es gesendet wird. Sie möchten zum Beispiel "Aufträge" an alle Außendienstmitarbeiter verteilen, solange sie nicht "abgeschlossen" und nicht "gelöscht" sind. Sie könnten sie natürlich mit Aufgaben verknüpfen, um sie zu synchronisieren, aber vielleicht möchten Ihre Mitarbeiter nicht aufgabenbasiert arbeiten.
In solchen Fällen können Sie benutzerdefinierte Synchronisierungsfilter definieren.
"filteredSynchronization": true,
"syncRules": [
{
"$type": "syncRule",
"filter": {
"$type": "filter",
"field": "order_status",
"operator": "NotIn",
"value":["completed", "cleared"]
}
}
]
2.2.1 Filterausdrücke
Um einen Filter zu erstellen, können Sie die folgenden Bausteine verwenden.
Das Filterobjekt:
Ermöglicht die Definition eines Filterausdrucks zur Reduzierung der Anzahl der Ergebnisse
Beispiel:
{
"$type": "filter",
"field": "order_status",
"operator": "NotIn",
"value":["completed", "cleared"]
}
Die folgenden Oepratoren sind verfügbar
Name | Typ | Beschreibung | SQL Übersetzung |
---|---|---|---|
Eq | beliebig | Vergleicht zwei Werte auf Gleichheit | = |
Neq | beliebig | Vergleicht zwei Werte auf Ungleichheit | <> |
Lt | beliebig | Kleiner als | < |
Lte | beliebig | Kleiner als oder gleich | <= |
Gt | beliebig | Größer als | > |
Gte | beliebig | Größer als oder gleich | >= |
Startswith | string | Wahr, wenn das Feld mit dem angegebenen Wert beginnt. | |
Endswith | string | Wahr, wenn das Feld mit dem angegebenen Wert endet | Wie '%...' |
Contains | string | True wenn das Feld den angegebenen Wert enthält | Like '%...%' |
In | array | True, wenn das Feld mit einem Element im angegebenen Array übereinstimmt | IN (...) ' |
NotIn | array | True, wenn das Feld mit keinem Element in dem angegebenen Array übereinstimmt | IN (...) ' |
IsNull | any | True, wenn das angegebene Feld null ist | is null ' |
IsNotNull | any | True, wenn das angegebene Feld nicht null ist | ist nicht null ' |
Das Gruppenobjekt
Ermöglicht es, mehrere Filterobjekte logisch zu kombinieren.
Die Logik
kann entweder AND
oder OR
sein.
Beispiel:
{
"$type": "group",
"logic": "AND",
"operators": [
{
"$type": "filter",
"field": "order_status",
"operator": "NotIn",
"value":["completed", "cleared"]
},
{
"$type": "filter",
"field": "agent_team",
"operator": "Contains",
"value": "order agents WEST"
}
]
}
2.2.2 Festlegen eines Empfängers
Wie Sie sehen, wurde im vorigen Beispiel ein konstanter Filter definiert, der alle Aufträge
synchronisiert, solange ihr Auftragsstatus
nicht gleich erledigt
oder freigegeben
ist.
Es wurde nicht definiert, für welche Benutzer die Elemente synchronisiert werden sollen. Da diese Informationen nicht von einem übergeordneten Element kopiert werden können (wie bei der Regel synced
), müssen wir irgendwie den Empfänger (receiver
) definieren.
Wir könnten die Option Empfänger
natürlich auch weglassen. In diesem Fall werden alle Elemente, die dem Filter entsprechen, für alle Benutzer synchronisiert.
Aus diesem Grund können Sie ein Attribut receiver
definieren.
"filteredSynchronization": true,
"syncRules": [
{
"$type": "syncRule",
"filter": {
"$type": "filter",
"field": "order_status",
"operator": "NotIn",
"value":["completed", "cleared"]
},
"receiver": {
"$type": "receiver",
"type":"Team", -- the default!
"filter": {
-- a typical filter expression
"$type": "filter",
"field": "title", -- the title of the team
"operator": "Eq",
"value": "order agents WEST"
}
}
}
]
Dies legt fest, dass jeder nicht vollständige Auftrag mit einem Team namens ""Order Agents WEST"" synchronisiert werden soll.
Ein Empfänger
kann zwei Typen
haben:
"Team"
gibt an, dass der Empfänger ein Team ist. Der Filterausdruck kann daher nur Attribute eines Teams verwenden, die lautenName Typ Beschreibung id
guid die eindeutige ID eines Teams isactive
boolean gibt an, ob das Team aktiv oder veraltet ist title
string der Titel des Teams "Benutzer" gibt an, dass ein bestimmter Benutzer der Empfänger ist. Der Filterausdruck kann daher nur Attribute eines Benutzers verwenden, die lauten
Name Typ Beschreibung id
number die eindeutige ID eines Benutzers externalid
string eine eindeutige externe Kennung für den Benutzer username
string der Benutzername name
string der Vorname des Benutzers surname
string der Nachname des Benutzers emailaddress
string die E-Mail Adresse des Benutzers isactive
boolean gibt an, ob der Benutzer aktiv ist oder nicht
Der Standard Typ
des Empfängers ist "Team"
Ein receiver
kann die gleichen Filterausdrücke verwenden, die hier beschrieben sind
Falls Sie ein Feld des Inhaltstyps in Ihrem Empfänger-Filterausdruck verwenden müssen, können Sie fieldref
verwenden.
Die fieldref
wird automatisch auf Felder des Inhaltstyps verweisen.
Lesen Sie mehr hier
Kombinieren von Synchronisationsregeln
Da es mehrere Teams gibt, die alle ihre eigene order
erhalten sollen, können wir das Team anhand des Feldes agent_team
bestimmen.
Das folgende Beispiel zeigt:
Synchronisieren Sie alle noch nicht abgeschlossenen Bestellungen, die den Text "order agents WEST" in ihrem Feld "agent_team" enthalten, mit dem Team "order agents WEST".
"filteredSynchronization": true,
"syncRules": [
{
"$type": "syncRule",
"filter": {
"$type": "group",
"logic": "AND",
"operators": [
{
"$type": "filter",
"field": "order_status",
"operator": "NotIn",
"value":["completed", "cleared"]
},
{
"$type": "filter",
"field": "agent_team",
"operator": "Contains",
"value": "order agents WEST"
}
]
},
"receiver": {
"$type": "receiver",
"type":"Team", -- the default!
"filter": {
-- a typical filter expression
"$type": "filter",
"field": "title",
"operator": "Eq",
"value": "order agents WEST"
}
}
}
]
In diesem Fall können Sie eine oder mehrere Synchronisationsregeln hinzufügen.
Wenn Sie nur eine Regel definieren, wird diese als Standardregel betrachtet und benötigt keinen Namen.
"filteredSynchronization": true,
"syncRules": [
{
"$type": "syncRule",
"filter": {
"$type": "filter",
"field": "order_status",
"operator": "NotIn",
"value":["completed", "cleared"]
}
}
]
Wenn Sie mehrere Synchronisierungsregeln definieren, müssen Sie diese (oder alle außer der Standardregel) benennen, damit das System weiß, welche Regel angewendet werden soll:
"filteredSynchronization": true,
"syncRules": [
{
"$type": "syncRule",
"filter": {
"$type": "filter",
"field": "order_status",
"operator": "NotIn",
"value":["completed", "cleared"]
}
},
{
"$type": "syncRule",
"name":"bycategory"
"filter": {
"$type": "filter",
"field": "order_category",
"operator": "Eq",
"value":"technical"
}
}
]
2.2.3 Verwendung von fieldref
Wie Sie im vorigen Beispiel gesehen haben, ist es möglich, für jedes Team eine eigene Synchronisierungsregel zu erstellen, aber das ist nicht gut skalierbar.
Wenn möglich, wäre es besser, wenn der Inhaltstyp ein Feld Team
enthielte, das das Team enthält, mit dem die Order
synchronisiert werden soll:
"filteredSynchronization": true,
"syncRules": [
{
"$type": "syncRule",
"filter": {
"$type": "filter",
"field": "order_status",
"operator": "NotIn",
"value":["completed", "cleared"],
"comment": "...only synchronize if the order is not yet completed"
},
"receiver": {
"$type": "receiver",
"type":"Team", -- the default!
"filter": {
"$type":"filter",
"comment":"here, the fields are the one of the team!",
"field": "title",
"operator":"Eq",
"value":{
"$type":"fieldref",
"field":"agent_team",
"comment":"fieldref is used to reference the field 'agent_team' of the content type 'order'"
}
}
}
}
]
Immer wenn Sie den Filter der Sync-Regel angeben, beziehen sich die verwendeten Feldnamen auf die Felder des Inhaltstyps selbst.
Wenn Sie jedoch den Filter des Empfängers angeben, beziehen sich die verwendeten Feldnamen auf die Felder eines
Team
- oderUser
-Objekts.Wenn Sie ein Feld des Inhaltstyps in Ihrem
receiver.filter
verwenden möchten, müssen Sie einfieldref
verwenden
Kombinieren einer hierarchischen Synchronisationsregel mit konstanten Filtern
Schließlich ist es auch möglich, synced
Regeln und normale Filterausdrücke zu kombinieren
In diesem Fall geht das System davon aus, dass alle Elemente, die von einem synchronisierten Element abhängen, an denselben Empfänger gesendet werden sollen.
Daher müssen Sie in der Syncrule keinen Empfänger
angeben.
Sie können dieses Verhalten jedoch außer Kraft setzen, indem Sie einen angeben, wie im folgenden Beispiel
"filteredSynchronization": true,
"syncRules": [
{
"$type": "syncRule",
"filter": {
"$type": "group",
"logic": "AND",
"operators": [
{
"$type": "filter",
"field": "status",
"operator": "Neq",
"value": "removed"
},
{
"$type": "synced",
"field": "buildingid"
}
]
},
"receiver": {
"$type": "receiver",
"type":"Team", -- the default!
"filter": {
"$type": "filter",
"field": "title",
"operator": "Eq",
"value": "order agents WEST"
}
}
}
]