Namenskonventionen in SAP CPI: Ein Regelpaket, das Ihr Team durchsetzen kann

Die meisten Teams in SAP Cloud Integration (SAP CPI) haben Namenskonventionen. Weniger haben Konventionen, denen jeder iFlow folgt, denn die Regeln stehen auf einer Wiki-Seite, und niemand prüft den Namen eines Content Modifier vor einem Transport.

Dieser Artikel schlägt eine Ausgangskonvention für Schritte, Kanäle, Properties und Adressen vor und zeigt, wie Sie sie als Regeln schreiben, die ein Werkzeug prüfen kann, und wie ein Team sie teilt und durchsetzt.

Warum Namen in SAP CPI wichtig sind

Den Namen eines Schritts sehen Sie, wenn etwas kaputtgeht. Der Monitor meldet den fehlgeschlagenen Schritt mit seinem Namen, eine Suche nach „dem Schritt, der die Bestell-ID setzt“ findet ihn nur, wenn der Name das sagt, und ein Designdokument oder eine Übergabe liest sich wie die Beschriftungen des Diagramms. „Content Modifier 3“ sagt nichts; CM_SetOrderHeaders sagt, was der Schritt tut.

Einheitliche Namen machen außerdem zwei iFlows vergleichbar: Wer die Konvention kennt, kann jeden iFlow des Teams auf einen Blick lesen.

Eine Ausgangskonvention

Ein Präfix für die Art des Schritts, dann seine Aufgabe in PascalCase – das reicht für die meisten Teams. Dies ist das Paket, das der Kitegra mitbringt; es ist ein Ausgangspunkt zum Anpassen, kein SAP-Standard:

Die Konvention als Regeln schreiben

Eine Konvention, die ein Werkzeug prüfen kann, ist eine Liste von Regeln, eine je Art von Element. Literaler Text muss genau passen; <Placeholder> steht für beliebigen Text; <PascalCase>, <camelCase>, <UPPER>, <lower> und <Number> stehen für Text dieser Form. Es gilt die erste Regel jeder Art, und jede Regel hat einen Schweregrad: Fehler, Warnung oder Info.

Im Kitegra sind die Regeln ein JSON-Regelpaket. Ein Auszug:

{
  "rules": [
    {
      "id": "content-modifier",
      "target": "content-modifier",
      "pattern": "CM_<Action>",
      "example": "CM_SetOrderHeaders",
      "notes": "Content Modifier: CM_ and what it sets.",
      "severity": "warning",
      "enabled": true
    },
    {
      "id": "mapping",
      "target": "mapping",
      "pattern": "MM_<Source>_to_<Target>",
      "example": "MM_Order_to_SalesOrder",
      "notes": "Message Mapping: source and target message.",
      "severity": "info",
      "enabled": true
    },
    {
      "id": "property",
      "target": "property",
      "pattern": "<camelCase>",
      "example": "orderId",
      "notes": "Exchange property names in camelCase.",
      "severity": "info",
      "enabled": true
    }
  ]
}

Sich im Team einigen

1. Öffnen Sie die Optionsseite der Erweiterung und suchen Sie Namensregeln. Dort steht zu Beginn das Standardpaket.
2. Ändern Sie Muster, Schweregrad oder Hinweise einer Regel, schalten Sie eine Regel über „Regel an“ ab, oder wählen Sie „Regel hinzufügen“ und legen Sie unter Prüft fest, was sie prüft.
3. Wählen Sie „JSON exportieren“ und legen Sie die Datei dort ab, wo das Team seine Standards aufbewahrt, neben den Transportrichtlinien.
4. Jede Kollegin und jeder Kollege wählt „JSON importieren“ mit dieser Datei. Wer mit Kitegra angemeldet ist, hat das Paket dann auf jedem Computer.

Die Synchronisierung hält das Paket einer Person auf all ihren Computern gleich; die gemeinsame JSON-Datei sorgt dafür, dass das ganze Team dieselben Regeln hat.

Einen iFlow gegen die Regeln prüfen

Öffnen Sie den iFlow, klicken Sie auf „Kitegra-Werkzeuge“ und wählen Sie Inspektor (oder drücken Sie Alt+Shift+K). Die Registerkarte Benennung listet jeden Namen, der von den Regeln abweicht, und ihre Anzahl steht auf der Schaltfläche: der tatsächliche Name, was Erwartet wurde, ein Beispiel und, wo der Inhalt des Schritts es zulässt, ein Vorschlag, der aus der Aufgabe des Schritts gebildet wird. Ein Klick auf einen Befund wählt den Schritt im Diagramm aus.

Im Bearbeitungsmodus tippt Umbenennen den vorgeschlagenen Namen in das Feld Name des Schritts. Gespeichert wird dabei nie: Das Panel meldet „Umbenannt. Speichern Sie den iFlow, um es zu behalten.“, und Sie entscheiden.

Dieselben Befunde erscheinen im iFlow-Bericht neben den Designprüfungen, wie die Checkliste für das iFlow-Review zeigt, und gute Namen sorgen dafür, dass sich ein erzeugtes Designdokument gut liest.

Wie der Kitegra hilft

Die Benennung gehört zum iFlow Inspector im Kitegra. Die Prüfung liest das Modell des iFlows in Ihrem Browser; Ihr Regelpaket wird mit Ihrem Kitegra-Konto synchronisiert, wenn Sie angemeldet sind, und der Inhalt des iFlows wird nie gesendet.

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