Modul in diesem Artikel: iFlow Docs
Technisches Designdokument für SAP CPI direkt aus dem iFlow erzeugen
Was ein technisches Designdokument für SAP CPI enthalten sollte, eine Gliederung zum Übernehmen und wie Sie es aus dem iFlow als Word, PDF oder HTML oder in Ihre eigene Vorlage erzeugen.

Jedes Projekt in SAP Cloud Integration (SAP CPI) verlangt ein technisches Designdokument, und die meisten werden zweimal geschrieben: einmal vor dem Bau, nach der Spezifikation, und noch einmal bei der Übergabe, nach dem iFlow, weil sich der iFlow geändert hat. Das zweite ist größtenteils eine Abschrift dessen, was der iFlow ohnehin sagt.
Dieser Artikel listet auf, was ein technisches Designdokument für einen iFlow enthalten sollte, und zeigt, wie Sie es aus dem iFlow selbst erzeugen, als Word, PDF oder HTML oder in der Word-Vorlage Ihres Unternehmens.
Wofür das Dokument da ist
Ein technisches Designdokument erklärt jemandem, der den iFlow nicht gebaut hat, wie er funktioniert: welche Systeme er verbindet, was er unterwegs mit einer Nachricht macht, wie er fehlschlägt und was der Betrieb braucht, um ihn zu betreiben. Gelesen wird es in Reviews, bei der Übergabe und Monate später, wenn die Schnittstelle ausfällt.
Was hineingehört
- Schnittstellenübersicht: Name, ID, Package, Zweck, Sender und Receiver mit ihren Adaptern und Adressen.
- Ablauf: ein Diagramm und für jeden Prozess eine kurze Beschreibung dessen, was mit der Nachricht passiert.
- Routing: jeder Router, seine Routen und ihre Bedingungen sowie die Standardroute.
- Mappings und Skripte: was jedes davon tut, in ein oder zwei Sätzen.
- Header und Properties: was der iFlow setzt und liest.
- Fehlerbehandlung: die Exception Subprocesses und was sie tun.
- Sicherheit: die Namen der Anmeldedaten und Schlüssel, die er nutzt (nie die Geheimnisse selbst).
- Externalisierte Parameter sowie die Data Stores, JMS-Queues und ProcessDirect-Verbindungen, die er nutzt.
- Betrieb: wo er überwacht wird, was bei einem Fehler zu tun ist und wen man kontaktiert.
Warum handgeschriebene Dokumente veralten
Jeder Punkt dieser Liste steht bereits im iFlow. Ihn von Hand aufzuschreiben heißt, Adressen, Bedingungen und Parameternamen abzuschreiben, und jede Änderung am iFlow macht die Abschrift ein Stück falscher. Ein aus dem iFlow erzeugtes Dokument stimmt an dem Tag, an dem es entsteht, und es nach einer Änderung neu zu erzeugen, dauert eine Minute.
Aus dem iFlow erzeugen
- Öffnen Sie den iFlow im Designer, klicken Sie auf „Kitegra-Werkzeuge“ und wählen Sie „Diesen iFlow dokumentieren“. Das iFlow-Dokument öffnet sich in einem neuen Tab.
- Prüfen Sie die gelesenen Fakten: Teilnehmer und Adapter, Prozesse und ihre Schritte, Routen, Mappings und Skripte, Header und Properties, Parameter, Namen von Security Material, Stores und Verbindungen sowie die Fehlerbehandlung.
- Wählen Sie eine Vorlage: Technisches Design, Kurzzusammenfassung oder Betriebsübergabe.
- Füllen Sie Projekt und Autor aus; beides wird für das nächste Dokument behalten.
- Laden Sie es als Word, PDF oder HTML herunter.
Das Diagramm wird aus dem iFlow gezeichnet, und jeder Prozess erhält eine Beschreibung wie „Empfängt Nachrichten von … über …“ und „Bei einem Fehler: …“. Ohne Designer wählen Sie stattdessen „iFlow hochladen (ZIP oder .iflw)“; eine hochgeladene Datei zählt nicht zu den iFlows Ihres Tarifs. Die Beschriftungen des PDF sind auf Englisch.
Die Word-Vorlage Ihres Unternehmens verwenden
Hat Ihr Projekt eine Vorlage, wählen Sie „Eigene Word-Vorlage“. Schreiben Sie Platzhalter in eine .docx-Datei, wo die Fakten stehen sollen, und wählen Sie dann „Ausfüllen und herunterladen“:
Interface: {{iflowName}} ({{iflowId}})
Package: {{package}}
Project: {{project}} Author: {{author}} Date: {{date}}
Purpose
{{description}}
Senders: {{senders}} Receivers: {{receivers}}
Adapters: {{adapters}}
How it works
{{narrative}}
Routing: {{routes}}
Scripts: {{scripts}}
Error handling: {{errorHandling}}Die Seite listet jeden Platzhalter, den sie füllt, darunter {{iflowName}}, {{package}}, {{narrative}}, {{routes}}, {{parameters}}, {{securityMaterial}} und {{errorHandling}}. Message Mappings bekommen eine eigene Tabelle: siehe Dokumentation von Message Mappings in Excel.
Wie der Kitegra hilft
Dokumente sind der Bereich iFlow Docs des Kitegra. Das Dokument wird in Ihrem Browser erstellt; Skripte und Mappings werden nie an Kitegra gesendet. Bevor Sie einen iFlow dokumentieren, findet die Review-Checkliste, was Sie lieber nicht festhalten möchten.
Helper, Message Monitor, iFlow Inspector und iFlow Docs zählen jeweils die iFlows, für die Sie sie nutzen: 5 je Modul ohne Kitegra-Konto, 50 im Tarif Free, 100 mit Starter und 300 mit Pro; Business hat kein Limit. Die Toolbox und die Extras für den Arbeitsbereich sind kostenlos. Tarife vergleichen.
Probieren Sie ihn im nächsten iFlow aus
Lesen Sie, was der Kitegra rund um den Designer der SAP Integration Suite ergänzt, oder sehen Sie ihn neben den anderen Chrome-Erweiterungen von Kitegra.
Häufige Fragen
Was sollte ein technisches Designdokument für SAP CPI enthalten?
Eine Schnittstellenübersicht, den Ablauf mit Diagramm, Routing, Mappings und Skripte, Header und Properties, Fehlerbehandlung, Namen für die Sicherheit, Parameter, Stores und Verbindungen sowie Hinweise für den Betrieb.
Kann ich das Dokument aus dem iFlow erzeugen?
Ja. Wählen Sie im Menü „Kitegra-Werkzeuge“ den Eintrag „Diesen iFlow dokumentieren“, wählen Sie eine Vorlage und laden Sie es als Word, PDF oder HTML herunter.
Kann ich die Word-Vorlage meines Unternehmens verwenden?
Ja. Schreiben Sie die aufgelisteten Platzhalter, etwa {{iflowName}} oder {{narrative}}, in eine .docx-Datei und wählen Sie „Ausfüllen und herunterladen“.
Muss der Designer geöffnet sein?
Nein. Sie können stattdessen eine iFlow-ZIP- oder .iflw-Datei hochladen, und eine hochgeladene Datei zählt nicht zu den iFlows Ihres Tarifs.
Enthält das Dokument Passwörter?
Nein. Es listet nur die Namen von Anmeldedaten und Schlüsseln auf, nie Geheimnisse.
Wird mein iFlow an Kitegra gesendet?
Nein. Das Dokument wird in Ihrem Browser erstellt; Skripte und Mappings werden nie gesendet.