Im Laufe der Zeit findet man das eine oder andere heraus, was die Arbeit mit den Integration Flows in der SAP Cloud vereinfacht. Hier eine lose Sammlung:

• Manche Links braucht man immer wieder: CI home für devel, QA, prod. Message monitor. Integration Content etc. pp.
  
  Du kannst sie natürlich als Links im Browser (Chrome, Edge, Firefox etc.) halten. Einfacher und übersichtlicher finde ich es aber, eine HTML-Datei zu haben, in der ich die Links aufbewahre. Dort ist auch Platz für Kommentage. Und du hast die ganze Liste auf einmal im Überblick. Einfach diese Datei in einem Browsertab offenhalten und von dort öffnen mit rechtem Mausklick in neuem Tab.
• Wenn du eine Funktionalität an zwei Stellen in einem Integration Flow brauchst, dann gehört diese Funktionalität in einen lokalen Subprozess. Dann ist sie auch bei Änderunen immer gleich.
• Postman, immer wieder Postman. Auch dann, wenn dein Flow einen anderen Eingang hat, wie Timer, IDoc, XI, FTP. Ein Flow kann mehr als einen Eingang haben. (Wenn man weiß, wie es geht.) Alle Eingänge bekommen dann nur einen einzigen Schritt: einen Process call mit dem Namen „perform work“. Einer der Eingänge ist HTTP. Diesen rufst du mit Postman auf. Du holst dir einmal von irgendwo die richtigen Bodydaten, z.B. für IDoc. Und dann kannst du jederzeit mit Postman ganz einfach den Flow aufrufen. Das hat außerdem den Vorteil, dass Postman dir den letzten Stand des Bodys anzeigt. Meistens produziert den Flow ja irgend etwas, und das kannst du dir dann in Postman unmittelbar anzeigen lassen.
• Groovy is king. Vergiss die grafischen Message Mapper. Schreibe dir stattdessen ein Groovyskript. Dieses kannst du in Eclipse so lange offline ausführen, bis der Mapper alles macht, was er soll. Das Testen in Eclipse ist um Lichtjahre einfacher als der Mappingsimulator der CPI/Cloud Integration. Dafür brauchst du lediglich ein paar Groovydateien, um die Messageklasse zu mocken. (Details schreibe ich später noch einmal auf.) Sogar Value-Mapping kannst du in Eclipse simulieren.
  
  Ein guter Start für ein Mapping sind: Quellstruktur, gerne auch als XSD, eine Beispiel-Inputdatei. Die gewünschte Ausgabestruktur, auch gerne als XSD. (XSD kann, muss aber nicht.) Und dann lässt du ChatGPT einen ersten Entwurf machen. Das führt schon ziemlich weit.
  
  Wenn du ein Message Mapping von eine PO-System ins CPI hochgeladen hast, kannst du es von dort auch wieder herunterladen, als ZIP-Datei. Wenn du die auspackst, dann findet sich dort eine schöne XML-Datei, die das Mapping definiert. Die ist maschinenlesbar. Für uns Menschen ist sie unübersichtlich. Aber ChatGPT kann die prima analysieren. Und auch so kann GPT dir einen ersten Entwurf für das Groovyskript machen.
• Du kannst einen Timer benutzen, um einen Flow jeden Tag zu einer bestimmten Uhrzeit zu starten. Du kannst einen Timer auch benutzen, um einen Flow z.B. alle 12 Stunden starten. Dann kannst du die Stunde nicht festlegen.
  
  Wenn du den Flow aber jeden Tag um 9:00 und um 15:00 Uhr starten willst, dann brauchst du zwei Timer. Dann brauchst du zwei Integration Flows. Die können in dasselbe Diagramm. Auch hier: ein „perform work“ als Unterprozess einrichten. Die Timer rufen dann nur „perform work“ auf und fertig.