Best practice / Architecture : Transform a dynamic table into a single complex JSON (Wix Rich Content)

How To
1

:us: Hello to the Make community,

I’m working on an advanced content generation scenario and I’m facing an architecture problem for which I’d like to have your insights.

The goal:

Generate a structured blog post with Gemini, then format it to send to the Wix API to create a draft post.

  1. The Input: Gemini output (via a JSON parse)

My AI provides me with a clean JSON array representing the blocks of my article. This is my raw material.

Example output :

json

[

{

“type”: “heading2”,

“content”: “The first reflexes”

},

{

“type”: “paragraph”,

‘content’: “This is the first paragraph of text.”

},

{

“type”: “bulleted_list”,

“content”: [

“First heading in the list.”,

“Second heading in the list.”

]

},

{

“type”: “paragraph”,

‘content’: “This is the second paragraph.”

}

]

2. The Desired Output: JSON for the Wix API (richContent)

I need to transform the above array into a complex, nested richContent object, like this one, before sending it to Wix.

Example of the expected final structure :

json

{

“nodes”: [

{

“type”: “HEADING”,

“headingData”: { “level”: 2 },

“nodes”: [{ “type”: “TEXT”, “textData”: { “text”: “The first reflexes” } }]

},

{

“type”: “PARAGRAPH”,

“nodes”: [{ “type”: “TEXT”, “textData”: { “text”: “This is the first paragraph of text.” } }]

},

{

“type”: “BULLETED_LIST”,

“nodes”: [

{ “type”: “LIST_ITEM”, “nodes”: [{ “type”: “PARAGRAPH”, “nodes”: [{ “type”: “TEXT”, “textData”: { “text”: “First item in the list.” } } }] } },

{ “type”: “LIST_ITEM”, “nodes”: [{ “type”: “PARAGRAPH”, “nodes”: [{ “type”: “TEXT”, “textData”: { “text”: “Second item in the list.” } }] }] } }

]

},

{

“type”: “PARAGRAPH”,

“nodes”: [{ “type”: “TEXT”, “textData”: { “text”: “This is the second paragraph.” } }]

}

]

}

3. The Challenge and the Current Architecture (in French)

My current scenario uses the following flow:

  1. Parse JSON: To obtain the Gemini table.

  2. Iterator: To browse each block ({type, content}).

  3. Router: To route each block to a different branch according to its type key.

  4. Branches: Each branch has a JSON - Create JSON module which creates the correct Wix node (one for HEADING, one for PARAGRAPH, etc.). For the bulleted_list branch, I use the Create JSON “Map” function to iterate over the content sub-table.

  5. Array Aggregator: To aggregate all the nodes created by the various branches.

My problem: The final action (the call to the Wix API) must be done ONLY ONCE, after the Iterator has finished processing all the blocks and the Array Aggregator has collected everything.

I tried placing the Array Aggregator at the end of a branch with the Router as “Source Module”, but the Aggregator runs every time its branch is activated, it doesn’t wait for all the iterations to finish. I’ve also tried a final filter with bundleOrderPosition and length(), but I’m encountering mapping difficulties and unexpected behavior.

**4. My Question to the Community

What is the architecture / “best practice ” on Make.com to solve this orchestration problem?

  • How can we reliably ensure that a final action is executed only once after processing all the elements of an array that pass through a router?

  • Is the approach with a Data Store and two scenarios the only really robust solution for this kind of case, or is there an easier way to do it in a single scenario that I can’t see?

Thanks in advance for your help and insights !

Bonjour à toute la communauté Make,

Je travaille sur un scénario de génération de contenu avancé et je fais face à un problème d’architecture pour lequel j’aimerais avoir vos lumières.

L’objectif :
Générer un article de blog structuré avec Gemini, puis le formater pour l’envoyer à l’API de Wix afin de créer un brouillon d’article.

1. L’Entrée : La sortie de Gemini (via un Parse JSON)

Mon IA me fournit un tableau JSON propre qui représente les blocs de mon article. C’est ma matière première.

Exemple de sortie :

json
[
{
“type”: “heading2”,
“content”: “Les premiers réflexes”
},
{
“type”: “paragraph”,
“content”: “Ceci est le premier paragraphe de texte.”
},
{
“type”: “bulleted_list”,
“content”: [
“Premier point de la liste.”,
“Deuxième point de la liste.”
]
},
{
“type”: “paragraph”,
“content”: “Ceci est le deuxième paragraphe.”
}
]


-----

**2. La Sortie Souhaitée : Le JSON pour l'API Wix (`richContent`)**

Je dois transformer le tableau ci-dessus en un objet `richContent` complexe et imbriqué, comme celui-ci, avant de l'envoyer à Wix.

*Exemple de la structure finale attendue :*

json
{
  "nodes": [
    {
      "type": "HEADING",
      "headingData": { "level": 2 },
      "nodes": [{ "type": "TEXT", "textData": { "text": "Les premiers réflexes" } }]
    },
    {
      "type": "PARAGRAPH",
      "nodes": [{ "type": "TEXT", "textData": { "text": "Ceci est le premier paragraphe de texte." } }]
    },
    {
      "type": "BULLETED_LIST",
      "nodes": [
        { "type": "LIST_ITEM", "nodes": [{ "type": "PARAGRAPH", "nodes": [{ "type": "TEXT", "textData": { "text": "Premier point de la liste." } }] }] },
        { "type": "LIST_ITEM", "nodes": [{ "type": "PARAGRAPH", "nodes": [{ "type": "TEXT", "textData": { "text": "Deuxième point de la liste." } }] }] }
      ]
    },
    {
      "type": "PARAGRAPH",
      "nodes": [{ "type": "TEXT", "textData": { "text": "Ceci est le deuxième paragraphe." } }]
    }
  ]
}


-----

**3. Le Défi et l'Architecture Actuelle**

Mon scénario actuel utilise le flux suivant :

1.  **Parse JSON** : Pour obtenir le tableau de Gemini.
2.  **Iterator** : Pour parcourir chaque bloc (`{type, content}`).
3.  **Router** : Pour aiguiller chaque bloc vers une branche différente en fonction de sa clé `type`.
4.  **Branches** : Chaque branche a un module **`JSON - Create JSON`** qui fabrique le "node" Wix correct (un pour `HEADING`, un pour `PARAGRAPH`, etc.). Pour la branche `bulleted_list`, j'utilise la fonction "Map" du `Create JSON` pour itérer sur le sous-tableau `content`.
5.  **Array Aggregator** : Pour rassembler tous les "nodes" créés par les différentes branches.

**Mon problème :** L'action finale (l'appel à l'API Wix) doit se faire **UNE SEULE FOIS**, après que l'Iterator a fini de traiter tous les blocs et que l'Array Aggregator a tout rassemblé.

J'ai essayé de placer l'Array Aggregator à la fin d'une branche avec le Router comme "Source Module", mais l'agrégateur s'exécute à chaque fois que sa branche est activée, il n'attend pas la fin de toutes les itérations. J'ai aussi tenté un filtre final avec `bundleOrderPosition` et `length()`, mais je rencontre des difficultés de mapping et des comportements inattendus.

-----

**4. Ma Question à la Communauté**

Quelle est l'architecture / la **"best practice"** sur Make.com pour résoudre ce problème d'orchestration ?

  * Comment s'assurer de manière fiable qu'une action finale ne s'exécute qu'une seule fois après avoir traité tous les éléments d'un tableau qui passent par un routeur ?
  * Est-ce que l'approche avec un **Data Store** et deux scénarios est la seule solution vraiment robuste pour ce genre de cas, ou y a-t-il une manière plus simple de le faire dans un seul scénario que je ne vois pas ?

Merci d'avance pour votre aide et vos lumières \!
1 Like