Die Verarbeitung von Connect-Dateien folgt einem spezifischen Ablauf, der an gewissen Stellen mit Benutzerinteraktion und Fehlerbehandlung umgehen kann.

1. Aufruf

Hier wird unterschieden, ob der Aufruf mit vollständigem Connect (Normal oder Type Data) erfolgt, oder aber via unstrukturiertem XML. Im zweiten Fall wird der richtige XML-Transformator gesucht und auf das XML angewendet. Sollte diese Operation scheitern, wird die Verarbeitung umgehend abgebrochen. Es wird kein ConnectorResult erstellt, beim serverseitigen Aufruf wird allerdings der HTTP-Fehlercode 500 (Server Error) zurückgegeben. Dies, weil die Verarbeitung zu diesem Zeitpunkt noch gar nicht gestartet wurde, sondern lediglich die Aufbereitung.

2. Aufbereitung

In diesem zweiten Schritt wird das Connect eingelesen und die Ablaufreihenfolge etabliert. Sollte das Einlesen scheitern, wird dies regulär über die OnError-Commands abgearbeitet. Das Connect-XML wird standardmässig keiner Schemaüberprüfung unterzogen, es sei denn, dies wurde über das Attribut Validate="true" gefordert.

3. Vorlagenwahl

Um die Vorlage zu wählen, gibt es drei verschiedene Möglichkeiten:

Die Id der Vorlage (TemplateId) wird explizit angegeben → Auswahl eindeutig, keine Benutzerinteraktion nötig
Die Vorlage wird über Tags gefiltert. Dabei gibt es zwei mögliche Konsequenzen: a) Nur eine Vorlage entspricht den Filterkriterien → Auswahl eindeutig, keine Benutzerinteraktion nötig b) Mehr als eine Vorlage entspricht den Filterkriterien → dem Benutzer wird der Vorlagenpicker angezeigt. Dies funktioniert nur bei einem Client-Aufruf, nicht auf dem Server. Wird der Vorlagenpicker angezeigt, hat der Benutzer auch die Möglichkeit, die Aktion abzubrechen, was wiederum in einem OnCancel-Ereignis endet.

4. Generierung

Die Dokumentenerstellung an sich wird als Blackbox betrachtet. In ihr werden die unterschiedlichen Dokumentfunktionen angewendet, die an der gewählten Vorlage angehängt sind und ggf. mit den Daten aus dem Connect-Aufruf angereichert.

5. Ausführung der Document-Commands

Nach der eigentlichen Dokumenterstellung können auf das Einzelergebnis Commands angewendet werden (z. B. die Umwandlung in ein PDF-Dokument). Gleichzeitig werden zu diesem Zeitpunkt die Fehler- und Abbruch-Commands auf Dokumentebene ausgeführt.

6. Ausführung der Batch-Commands

Nach Beendigung aller einzelnen Dokumenterstellungen können auf den gesamten Batch erneut Commands angewendet werden – z. B. das Merge-Command. Zu diesem Zeitpunkt werden auch Fehler- und Abbruch-Commands aus den kumulierten Ergebnissen der Document-Commands ausgeführt. Ganz am Ende wird – falls vom Connect-Aufruf so verlangt – die ConnectorResult-Datei erstellt. Im Falle eines Web-Aufrufs an den Server wird jetzt das erstellte Dokument als Stream zurückgeliefert.

ConnectResult

Das ConnectResult kann folgende Werte annehmen:

Success Es sind keine Fehler aufgetreten.
Cancel Der Benutzer hat den Prozess (oder den vorhergehenden) abgebrochen.
Error Es ist mindestens ein Fehler aufgetreten.
Unknown Der Status zu diesem Zeitpunkt unbekannt. Dies tritt auf, wenn der Template Picker gestartet wurde (welcher asynchron ausgeführt wird).

Reihenfolge/Priorisierung: Unknown, Error, Cancel, Success Das heisst, wenn ein Prozess, der für das Resultat relevant ist, Unknown zurückgibt, dann ist das Resultat auch Unknown, unabhängig davon, ob ein anderer Prozess abgebrochen wurde oder fehlschlug. Analog für Error und Cancel. Success wird nur zurückgegeben, wenn alles erfolgreich war.

Beispiel: Dokumentgenerierung: Success und: Commands Error ergibt ein Gesamtresultat von Error, obwohl die Dokumentgenerierung an sich erfolgreich war.

Das ConnectResult hat das folgende Format:

<?xml version="1.0" encoding="utf-16"?>
<OneOffixxConnectResult xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <InputFile>
    <!-- Pfad zum Input-File -->
  </InputFile>
  <Result>
    <!-- Success, Error, Cancel oder Unknown -->
  </Result>
  <Message>
    <!-- Fehlermeldung im Fehlerfall bzw. das gleiche wie im Resultat (aus Kompatibilitätsgründen) -->
  </Message>
  <!-- Im Messages-Tag werden sowohl Fehler als auch Warnungen und Informationen detailliert ausgegeben. -->
  <Messages>
    <!-- Pro Meldung existiert eine LogMessage. Attribute:
          Type: Error, Warning, Information
          Context: Beschreibt den internen Context, z.&#160;B. eine Dokumentfunktion, in welchem der Fehler aufgetreten ist.
          InternalMessage: Interne Fehlermeldung bzw. Fehlercode
          TimeOfOccurence: Zeitpunkt des Fehlers
         -->
    <LogMessage Type="Error" Context="N/A" InternalMessage="Unexpected Error" TimeOfOccurence="2019-10-04T17:18:47.9109335+02:00">
      <Message>
        <!-- Lesbare Fehlermeldung -->
      </Message>
      <Exception>
        <!-- Technische Fehlermeldung -->
      </Exception>
    </LogMessage>
  </Messages>
  <!-- Im asynchronen Fall (TemplatePicker), 0-basierter Index des Batch-Entry -->
  <EntryIndex>0</EntryIndex>
</OneOffixxConnectResult>