Hallo @Henry-EG-Interfaces,
Nachtrag: Ich benutze den GraphQL-Schritt nicht, sondern mache das alles mit dem APICall. Hoffe einfach mal, dass sich der Ansatz auch in den GraphQL-Schritt transferieren lässt.
Hatte mich in den letzten Tagen auch mit den verschachtelten Abfragen beschäftigt, aber nur in der Theorie. Im Moment habe ich immer noch eine Verschachtelung vermieden, indem ich die untergeordnete Connection sehr großzügig abrufe. Also 250 Lineitems statt nur 10 im Falle der Bestellungen. Das geht aber natürlich sehr auf die Query-Kosten bzw. die Abrufgeschwindigkeit.
Diese Paginierung für die Bestellungen, Produkt oder was man auf der oberen Ebene hat, setzt ich bei mir per Variable mit
<#assign end_cursor = getVariable('end_cursor')>
und in meinen GraphQL-Variablen habe ich sowas wie:
"variables": {"numProducts": 100, "cursor": <#if end_cursor == "">null<#else>"${end_cursor}"</#if>}
end_cursor wird im Parsing-Template vor dem Aufruf von NextURL gefüllt, falls vorhanden. Soweit bist du aber vermutlich auch schon.
Für die Verschachtelung müsste man dann eine zweite Variable haben, in die man eine Liste aller Bestellung-IDs + LineItems-Cursor packt (Set/GetVariable kann mit Listen arbeiten).
Der RequestBody enthält im Endeffekt zwei komplette Queries (einmal für den Bestellabruf und einmal für die Verarbeitung des LineItem-Cursors in eine bestimmten Bestellung), zwischen denen man per IF/ELSE hin und her schaltet.
Wenn Elemente in der Liste mit Bestellung-IDs + LineItems-Cursor vorliegen, schaltet man auf die zweite Query um und verarbeitet ein Element aus der Liste. Anschließend löscht man den Eintrag aus der Liste oder aktualisiert ihn, wenn es weitere LineItems für die Bestellung gibt.
Hoffe, das macht nicht nur in meinem Kopf Sinn 
.
Gruß
Gustav