skloppig
Occasional Observer

CaaS Connect 3: Filtern von Datenquelleninhalten inklusive inhalte der referenzierten Objekte

Jump to solution

Hallo zusammen,

gibt es für CaaS einen Request, über den ich Daten inklusive deren referenzierten Objekte filtern kann?

Die Daten werden über Datenquellen bzw. ein Datenbankschema, dass Relationen enthält, gespeichert.
Das Mapping zu den referenzierten Daten erfolgt teilweise über FS_INDEX bzw. CMS_INCLUDE_OPTIONS.

Aktuell verwende ich folgenden Request, um die Daten auszulesen

<base-url>/<tenant>/<project-id>.preview.content?filter={'template.uid':'Products.products','locale.identifier':'US'}

Allerdings habe ich das Problem, dass mir für die referenzierten Inhalte nur die Referenzen angezeigt werden, nicht aber die Attribute nach denen ich filtern möchte.

Gibt es die Möglichkeit, alle Datensätze inklusive Daten der referenzierten Objekte im CaaS zu sehen und dann auch filtern?

Viele Grüße

Sabrina

 

0 Kudos
2 Solutions

Accepted Solutions

Hi Sabrina,

so in etwa könnte das aussehen, das war mal für nen kleinen Microservice der Kontaktpersonen je nach PLZ raussucht. Also auch ein Lookup, nur dass du in deinem Fall eine Verknüpfung mit derselben Collection machst (also "from": ist dann gleich der Collection wo du den PUT-Request hinschickst.

{
"aggrs": [
{
"type": "pipeline",
"uri": "get_contacts",
"stages": [
{
"_$match": {
"_id": {
"_$var": "region"
}
}
},
{
"_$lookup": {
"from": "collection_name",
"localField": "contact_id",
"foreignField": "_id",
"as": "contact_persons"
}
}
]
},
{mehr als eine Aggregation? Neues Objekt hier}
]
}

Also erst ein PUT-Request, wo der ganze Block in den body kommt, als raw, JSON-Format, an die Adresse

..collection/

Du hast bestimmt ein größeres Datenmodell als hier in meinem Minimalbeispiel, also nimm noch eine "_$project"-Stage mit rein (https://www.mongodb.com/docs/manual/reference/operator/aggregation/project/), und nimm nur die Keys mit die du wirklich brauchst. So etwas wie {"name": "formData.tt_name.value"} würd ich auch immer wärmstens empfehlen, wenn man die verschachtelte Struktur nicht mehr braucht.

Danach schickst du einen GET-Request an die Adresse

...collection/_aggrs/get_contacts?avars={"region": "DE_48149"}

Jede Variable die du mit _$var eingebaut hast, muss immer besetzt sein. Falls du mehr als eine Aggregation definieren willst, schick erst mal einen GET-Request an deine Collection direkt an /, da siehst du was als "aggrs" schon da ist. Der Key wird immer überschrieben, also kopier am besten erst den schon vorhandenen Inhalt in den body für den neuen PUT-Request und ergänz dann die nächste Definition. "type" ist immer "pipeline", die "uri" muss einzigartig sein, das ist ja die Adresse wo der GET-Request hingeht.

Viele Grüße,
Stephie

PS: Ich hoffe die Formatierung hier frisst nicht die Sonderzeichen

View solution in original post

Hallo Stephie,

vielen Dank für die Unterstützung, hat mir sehr weitergeholfen.

Gruß

Sabrina

View solution in original post

0 Kudos
4 Replies
StephieWalter
New Creator

Hallo Sabrina,

mit einem CaaS-Request alleine wirst du die Attribute nicht kriegen. Man könnte allerdings eine Aggregation auf der Datenbank zusammenbauen, die einen Lookup auf die verknüpften Objekte macht. Die CaaS-Daten liegen ja in einer MongoDB, die noch mehr kann als nur filtern.

Das geht allerdings nur, wenn du den apikey mit Schreibrechten für die Collection hast, weil eine Aggregation erst mit einem PUT-Request definiert werden muss, bevor man dann mit GET das Ergebnis abruft. Kennst du dich mit MongoDB aus? Ist nicht ganz simpel, aber damit kann man dann so ziemlich alles aus den Daten herauskitzeln was man sich vorstellen kann. Hier die Links zur Doku:

https://www.mongodb.com/docs/manual/aggregation/

https://www.mongodb.com/docs/manual/reference/operator/aggregation/lookup/

Viele Grüße,
Stephie

0 Kudos

Hallo Stephie,

das klingt relativ viel versprechend.

Leider kenne ich mich mit MongoDB nicht aus.

Könntest Du mir eventuell ein Beispiel geben, wie ein solcher Put-Request aussehen würde.

Gruß

Sabrina

0 Kudos

Hi Sabrina,

so in etwa könnte das aussehen, das war mal für nen kleinen Microservice der Kontaktpersonen je nach PLZ raussucht. Also auch ein Lookup, nur dass du in deinem Fall eine Verknüpfung mit derselben Collection machst (also "from": ist dann gleich der Collection wo du den PUT-Request hinschickst.

{
"aggrs": [
{
"type": "pipeline",
"uri": "get_contacts",
"stages": [
{
"_$match": {
"_id": {
"_$var": "region"
}
}
},
{
"_$lookup": {
"from": "collection_name",
"localField": "contact_id",
"foreignField": "_id",
"as": "contact_persons"
}
}
]
},
{mehr als eine Aggregation? Neues Objekt hier}
]
}

Also erst ein PUT-Request, wo der ganze Block in den body kommt, als raw, JSON-Format, an die Adresse

..collection/

Du hast bestimmt ein größeres Datenmodell als hier in meinem Minimalbeispiel, also nimm noch eine "_$project"-Stage mit rein (https://www.mongodb.com/docs/manual/reference/operator/aggregation/project/), und nimm nur die Keys mit die du wirklich brauchst. So etwas wie {"name": "formData.tt_name.value"} würd ich auch immer wärmstens empfehlen, wenn man die verschachtelte Struktur nicht mehr braucht.

Danach schickst du einen GET-Request an die Adresse

...collection/_aggrs/get_contacts?avars={"region": "DE_48149"}

Jede Variable die du mit _$var eingebaut hast, muss immer besetzt sein. Falls du mehr als eine Aggregation definieren willst, schick erst mal einen GET-Request an deine Collection direkt an /, da siehst du was als "aggrs" schon da ist. Der Key wird immer überschrieben, also kopier am besten erst den schon vorhandenen Inhalt in den body für den neuen PUT-Request und ergänz dann die nächste Definition. "type" ist immer "pipeline", die "uri" muss einzigartig sein, das ist ja die Adresse wo der GET-Request hingeht.

Viele Grüße,
Stephie

PS: Ich hoffe die Formatierung hier frisst nicht die Sonderzeichen

Hallo Stephie,

vielen Dank für die Unterstützung, hat mir sehr weitergeholfen.

Gruß

Sabrina

0 Kudos