Method SignAsync
SignAsync(IEnumerable<DocumentInput>, SigningOptions, Action<string>, string, CancellationToken, ZedalCallContext, Action<SigningProcess>)
Die Fassade für den Standardfall (Konzept AP6): Vorgang anlegen und vorlegen,
die signing_url über presentSigningUrl an den
Aufrufer geben (der sie dem Menschen zeigt), auf den Endzustand warten und bei
Erfolg die signierten Dokumente liefern.
Task<SignOutcome> SignAsync(IEnumerable<DocumentInput> documents, SigningOptions options = null, Action<string> presentSigningUrl = null, string redirectUrl = null, CancellationToken cancellationToken = default, ZedalCallContext context = default, Action<SigningProcess> onSubmitted = null)
Parameters
documentsIEnumerable<DocumentInput>Zu signierende Dokumente (inline oder Referenz).
optionsSigningOptionsOptionale Vorgangsoptionen (Signaturgrund, …).
presentSigningUrlAction<string>Bekommt die
signing_url, sobald sie steht.redirectUrlstringOptionaler Rückweg nach Abschluss (Allowlist!).
cancellationTokenCancellationTokenBricht den Aufruf ab — Anlegen, Vorlegen und Warten; der Vorgang läuft serverseitig weiter. Der Abbruch kommt IMMER als OperationCanceledException mit diesem Token an, auch wenn er einen laufenden RPC trifft (dort meldet der gRPC-Client ihn sonst als
RpcException(Cancelled)).contextZedalCallContextDeadline-/Metadaten-Steuerung je Aufruf. Das Warten auf die menschliche Signatur läuft als Langläufer ohne Deadline; eine ausdrücklich gesetzte Zeitgrenze (WithTimeout(int)) gilt aber auch dort und beendet das Warten mit DeadlineExceeded.
onSubmittedAction<SigningProcess>Bekommt den vorgelegten Vorgang, bevor das Warten beginnt — für Aufrufer, die die Vorgangs-Id BRAUCHEN, solange gewartet wird. Wer das Warten abbricht (Strg+C an einer Kommandozeile, eigenes Zeitbudget), hat sonst nichts in der Hand: Der Vorgang läuft serverseitig weiter und wird vielleicht fertig, aber
presentSigningUrlträgt nur diesigning_url, und in der steht das Handoff-Token, nicht die Id.