Vorlagen per API — bis zum fertigen Dokument

Vorlagen ließen sich bisher ausschließlich in der Oberfläche verwalten — und Briefvorlagen nur dort gegen einen Datensatz generieren. Ab sofort geht beides über die öffentliche API — und nicht mehr nur für Briefvorlagen, sondern für jede Art von Vorlage, die propgen kennt.

Drei Arten, ein Weg

Anlegen, ändern, auflisten und löschen gilt für alle drei gleichermaßen — welche Platzhalter dabei zur Verfügung stehen, liefert die Feldabfrage je Oberfläche. Die Briefvorlage geht einen Schritt weiter: Aus ihr entsteht auch das fertige Dokument.

Vier Dinge, die nur bei Briefvorlagen dazukommen

• Anlegen und ändern — eine DOCX-Datei wird hochgeladen, mit Namen und Modellbezug versehen. Wird sie später ersetzt, bleibt dieselbe Vorlage bestehen, statt als zweiter Eintrag danebenzustehen.
• Herunterladen — die Original-Datei kommt unverändert zurück. Damit wird der Round-Trip möglich, den Versionierung und Sicherungen brauchen: auslesen, im Repository ablegen, bei Bedarf zurückspielen.
• Dokumente erzeugen — eine Vorlage wird gegen ein Objekt generiert, wie mit einem Klick in der Oberfläche, nur eben aus einem Skript heraus oder am Ende einer Automation. Wahlweise als DOCX oder als PDF, auf Wunsch direkt als Dokument am Objekt abgelegt.
• Rechte je Vorgang — auflisten, lesen, anlegen, ändern und löschen sind eigene Berechtigungen, wie im übrigen Schnittstellenmodell auch.

Erzeugt wird mit dem vollen Kontext

Eine Vorlage nützt nur so viel, wie beim Generieren an Daten zusammenkommt. Die Erzeugung über die Schnittstelle löst denselben Kontext auf wie die Oberfläche — nicht nur das Objekt, sondern alles, was daran hängt. Auch die Randfälle, an denen so etwas sonst scheitert: Firmenfelder, Highlights, lange Freitexte und Listen beliebiger Länge.

Wohin das Ergebnis geht, entscheidest Du beim Aufruf: als Datei zurück in die aufrufende Anwendung oder direkt als Dokument am Objekt abgelegt — dort, wo es auch landet, wenn jemand in der Oberfläche auf „Generieren" klickt. Damit lässt sich der Vorgang an das Ende einer Automation hängen: Objekt erreicht eine Phase, Dokument entsteht, liegt in der Akte.

Warum die Feldliste dazugehört

Ein Platzhalter, den es nicht gibt, führt beim Erzeugen zu keinem Fehler, sondern zu einer leeren Stelle. Wer einmal energietraeger schreibt, wo wesentlicher_energietraeger stehen müsste, merkt das nicht beim Bauen der Vorlage, sondern beim Eigentümer, der ein Exposé mit einer Lücke bekommt. Deshalb gehören beide Releases zusammen: Die abrufbaren Merge-Felder machen aus einem stillen Fehler einen prüfbaren.

Dazu prüft propgen beim Hochladen, ob die Vorlage nur zulässige Befehle verwendet — Platzhalter, Bedingungen, Schleifen und Bildhelfer sind erlaubt, freie Ausdrücke nicht. Eine Vorlage, die diese Grenze überschreitet, wird abgelehnt, statt später unvorhersehbar zu rendern.

Wofür das gebaut ist

• Ein Vorlagensatz über mehrere Instanzen — wer Feldprofile ohnehin per Objekte per API für die Datensätze, gegen die generiert wird, Formular-API ausrollt, konnte die darauf aufbauenden Word-Vorlagen bisher nur von Hand nachziehen. Formulare waren automatisierbar, die Vorlagen nicht — diese Lücke ist zu.
• Korrekturen ohne Handarbeit — eine Änderung an der Exposé-Vorlage geht bei fünf Gesellschaften einmal raus statt fünfmal, und der Stand lässt sich nachträglich prüfen, weil die Datei wieder auslesbar ist.

Verfügbarkeit

Die Endpunkte stehen ab sofort zur Verfügung, mit eigenen Rechten je API-Schlüssel. Einen Überblick über alles, was über die Schnittstelle läuft, gibt die Seite Public API.

Verwandte Releases: die abrufbaren Merge-Felder als Gegenstück, DOCX-Vorlagen für die Dokumentgestaltung, die Vorlagen in propgen als Grundlage und Formulare per API für die Felder darunter.

Mehr zu allen propgen-Funktionen findest Du im Funktionsüberblick.