ERP Austria Tools Hilfe und Dokumentation zu den von uns als Ergänzung der BüroWARE/ERP Suite angebotenen Tools (BW Starter, OnlinePay, Import2BW, BW Scheduler, ...) BWMagic Kurzanleitung für Anwender Bei der Inventurdifferenzliste sind u.U. Artikel doppelt dargestellt Bis zur Version 5.04.0014 werden Buchungen bei der Differenzprüfung u.U. doppelt dargestellt, wenn die Inventureröffnung über die Statistikdatenbank erstellt wurde. In diesem Fall wurde bis zur V3.04.0013 die Lagereinheit nicht in die Buchungen übernommen und somit können Buchungen doppelt dargestellt werden. Logische Erklärung: 10 "Liter" <> 10 "" Beheben Sie dieses Problem über ein LiveUpdate auf V3.04.014. Vorhandene Buchungen bei einer laufenden Inventur werden nicht automatisch geändert. Hierfür können Sie folgendes SQL-Script innerhalb von BWMagic ausführen, um die aktuellen Daten zu ergänzen. Benötigte Abfrage:  UPDATE [BWInventur]   SET ME =(SELECT TOP 1 ME_Text FROM BWArtikelstamm WHERE BWArtikelstamm.Artikelnummer = BWInventur.Artikelnummer AND SerieCharge = '') WHERE Tabellenblatt = 'S_RSTK30.DAT' AND Status = 0 AND (ME IS NULL OR ME = '') Kurzanleitung Inventureröffung Mit Eröffnen und Bewerten startet die Inventur mit folgendem Dialog: Die meisten dieser Einstellungen sollten vorab vom Administrator in den BWMagic-Einstellungen bereits korrekt vorgenommen sein und nur noch das Inventurdatum, das von und bis Lager und die Artikel-/Inventurbewertung könnten speziell abgeändert werden. Mit dem Button - links oben - werden die Daten aus der ERP-Suite eingelesen. Die Hinweismeldung  weist darauf hin, dass die Eröffnung und das Einlesen der Artikellagerdaten erfolgreich durchgeführt wurde. Istbestände erfassen Je nachdem, wie die Zählmengen aufgenommen werden - direkt in BWMagic, oder über eine externe Zählliste (zB. MS Excel) - kann auf zwei Arten der nächste Schritt erfolgen Erfassung per Barcode-Scan: Werden die Artikel über Barcode (EAN, etc) oder manuell über die Artikelnummer direkt in BWMagic erfasst, öffnet man mit dem Button Erfassen und Einscannen die folgende Funktion. Als erstes MUSS im Feld Lager: das Lager gewählt werden, in dem die aktuelle Zählung erfolgt. Im Feld Artikelnummer oder Seriennummer kann der gezählte Artikel erfasst (manuell, oder per Handscanner)  werden und im Feld Menge wird die gezählte Menge eingetragen. Mit dem Button links neben dem Feld Artikelnummer oder Seriennummer kann die Artikelauswahlliste für eine manuelle Suche geöffnet werden. Nach Bestätigung der Menge, wird dieser Artikel sofort in der Tabelle unterhalb dargestellt. Über das Menü Allgemein stehen folgende Funktionen zur Verfügung: Um die aktuelle Zählung abzuschließen und die Zähllisten zu überprüfen, oder weiter zu verarbeiten, muss diese abgeschlossen werden. Das erfolgt mit dem Button Zählliste Abschließen. Hinweis: Es können mehrere offene (laufende) Zählungen parallel erfolgen. Je nach Berechtigung kann jeweils nur die eigene Zählliste, oder über die Option Zähllisten aller Mitarbeiter Abschließen und Übernehmen, abgeschlossen werden. Jedenfalls muss in dieser Maske der Name des Zählers und des Erfassers protokolliert werden, bevor die Listen abgeschlossen werden können. Bestätigt wird die Übernahme der Zählung mit folgendem Hinweis: Erfassung mit externen Zähllisten Sollen (zusätzlich) druckbare Zähllisten erstellt werden, erfolgt dies über den Button Zähllisten Erstellen Ob es bereits offene Zähllisten gibt, sieht man noch bevor man den Button betätigt im linken unteren grün dargestellten Bereich: Auch in der über den Button Zähllisten Erstellen gestartetes Modul, werden rechts im grünen Bereich bereits erstellte Zähllisten dargestellt. Mit den Parametereingaben kann die neue Zählliste eingegrenzt werden. Mit dem Button wird diese Liste zu einer ausdruckbaren Excel/CSV-Liste. Dabei öffnet sich eine Eingabemaske, wo ein vorgegebener Listenname erfasst/geändert  wird. Über den Button gelangt man direkt zur so erstellten MS-Excel-Datei. Nach externer Erfassung der Zählmengen können diese Zähllisten mit dem Button wieder in BWMagic zurück importiert werden. Zunächst wählt man über den Button Zählliste Auswählen aus dem Verzeichnis die mit den Zählmengen ergänzte Datei aus.   Die Liste mit den erfassten Zählmengen (Spalte “IST”) wird sofort geladen. Sollte sich diese Liste nicht auf der ersten/einzigen Karteikarte des Arbeitsblatts befinden, kann das gewünschte Arbeitsblatt über die Arbeitsblatt Auswahl gewählt werden. Ist die Liste überprüft und korrekt wird die Zählung mit dem Button für die Weiterverarbeitung eingelesen. Zähllisten prüfen Im Menü Prüfen/Verbuchen befinden sich die beiden Werkzeuge (Module) Korrigieren und Bearbeiten und Prüfen und Kontrollieren Korrigieren und Bearbeiten Mit diesem Modul lassen sich erfasste Zählmengen entweder direkt in BWMagic, oder über eine externe Liste (MS-Excel) bearbeiten. Über die Listenparameter und das Suchfeld (1) kann die Liste unterhalb beeinflusst werden. In der Spalte IST (2) können die Zählmengen verändert werden. Sollen die Änderungen in einer externen Liste erfolgen, welche dann wieder in BWMagic importiert werden, dann kann die zu ändernde Liste mit dem Button (3) Datenexport Excel exportiert werden. Der Import der geänderten Mengen erfolgt über Erfassung mit externer Liste . Prüfen und Kontrollieren Über die Listenparameter (roter Rahmen) lässt sich die Liste der zu prüfenden Artikel rasch eingrenzen. Die so erhaltene Prüfliste kann über den Button gedruckt, oder als MS Excel exportiert werden. Abschließen Der Abschluss erfolgt über drei Stufen: Aktuelle Zählung Schließen Verbuchung freigeben und Verbuchen und Abschließen Aktuelle Zählung Schließen Beim Ausführen dieser Funktion erfolgt eine weitere Sicherheitsabfrage: Mit Ja sind alle aktuellen Zähllisten abgeschlossen und stehen für den nächsten Schritt bereit. Verbuchung freigeben Über den Button wird der zweite Schritt des Abschlusses vollzogen. Wurde die Zählung, also Schritt eins, nicht ausgeführt, erfolgt folgender Hinweis und die Inventur kann nicht weiterverarbeitet werden. Verbuchen und Abschließen Das abschließende Modul wird mit dem Button gestartet. Dabei öffnet sich folgende Oberfläche. Wie bereits einleitend beschrieben, sollten diese Einstellungen vom Administrator voreingestellt sein. Eine Option ist aber besonders wichtig! Aktivieren sie “BüroWARE Datenimport aktivieren” NUR dann, wenn sie 100% sicher sind, dass alle Inventurbuchungen aus BWMagic in BüroWARE (ERP-Suite) sofort übertragen und gebucht werden sollen! - Damit wird der letzte Prozess der Inventurbuchungen aus BWMagic angestoßen. Wie kann ich eine individuelle SQL-Abfrage bei der Inventureröffnung durchführen? Um eine individuelle SQL-Abfrage bei der Inventureröffnung durchführen zu können, legen Sie im Programmordner von BWMagic im Unterordner SQL die Datei Inventureröffnung.IndividuelleAbfrage01.sql an. Diese Abfrage wird direkt nach der SOLL/IST-Übernahme-Abfrage durchgeführt. Beispiel: Aktualisiert alle Datensätze, wo das Feld [Ist] leer ist oder 0 enthält. UPDATE [dbo].[BWInventur] SET [Ist] = [Soll] WHERE [Artikelnummer] LIKE 'K%' AND (Ist IS NULL OR Ist = 0) Aktualisiert nur Datensätze, welche aus der Statistikdatei gekommen sind. Somit werden manuell eingespielte Zähllisten nicht berührt. UPDATE [dbo].[BWInventur] SET [Ist] = [Soll] WHERE [Artikelnummer] LIKE 'K%' AND [Tabellenblatt]='S_RSTK30.DAT' Diese Abfrage übernimmt in allen Buchungen, wo die Artikelnummer mit "K" beginnt den Soll-Stand in das Feld Ist. WARNUNG Es wird hier keine Sicherung oder Ähnliches angelegt! Mit diesen Abfragen ändern Sie direkt und unwiderruflich die Daten in der SQL-Datenbank von BWMagic. Überlegen Sie gut, ob eventuell Einschränkungen auf die Artikelstatistik oder ähnliches erforderlich ist, um nicht ihre Zählungen zu überschreiben. Datanorm 4 BüroWARE Welche Funktionen sind innerhalb der Schnittstelle vorhanden? Dieses Dokument beschreibt alle unterstützten Funktionsnamen ( PFunction ) der Methode GetFunktionValue sowie deren Verhalten auf den Parameter Value und gegebenenfalls IgnoreField . 1. Allgemeines Verhalten Value wird direkt verändert (ByRef). IgnoreField wird nur von der Funktion SELEKT[...] gesetzt. Ist Value = Nothing , wird die Funktion sofort beendet. 2. Standardfunktionen (ohne Parameter) Funktion Beschreibung Besonderheiten/Format UCASE Wandelt den Inhalt von Value in Großbuchstaben um. LCASE Wandelt den Inhalt von Value in Kleinbuchstaben um. TRIM Entfernt führende und nachfolgende Leerzeichen. STRIM Entfernt führende/nachfolgende Leerzeichen und fügt immer ein führendes Leerzeichen hinzu. Ergebnis: " " & Trim(Value) LIEFERANTENID Fügt die Lieferanten-ID aus der XML-Konfiguration vor den Wert an. Quelle: Import / CONFIG / LieferantenID PREFIXID Identisch zu LIEFERANTENID . SUFFIXID Fügt die Lieferanten-ID aus der XML-Konfiguration nach dem Wert an. DATUM Setzt Value auf das aktuelle Datum. Format: Abhängig von Config.GetDate_0_10 ZEIT Setzt Value auf die aktuelle Uhrzeit. Format: Abhängig von Config.GetTime_0_5 TIMESTAMP Setzt Value auf einen Zeitstempel. Format: Abhängig von Config.GetTimeStamp_0_19 REMOVESPACE Ersetzt mehrfach aufeinanderfolgende Leerzeichen durch genau ein Leerzeichen. MATCHCODE Erzeugt einen normierten Matchcode. Regeln: 3. Parameterfunktionen SELEKT[…] Beschreibung: Führt einen Vergleich aus und setzt abhängig davon IgnoreField . Wenn der Vergleich nicht zutrifft → IgnoreField = True . Value selbst wird nicht verändert . Varianten: Direkter Vergleich Syntax: SELEKT[ABC] Vergleicht Value mit ABC . Vergleich mit Substring Syntax: SELEKT[ABC;Start] oder SELEKT[ABC;Start;Länge] Vergleicht einen Teilstring von Value . Vergleich mit Feldreferenz Syntax: SELEKT[$FELD$WERT] Holt den Wert aus einem anderen Feld. Vergleich über CompareValue . 4. Funktion PREFIX(text) Beschreibung: Fügt einen Prefix vor Value ein. Besonderheit: PREFIX( ) erzwingt ein führendes Leerzeichen.SUFFIX(text) 5. Funktion SUFFIX(text) Beschreibung: Fügt einen Suffix hinter Value ein. Besonderheit: SUFFIX( ) erzwingt ein nachgestelltes Leerzeichen.GETDATA(Datei;Delimiter;Suchspalte;Rückgabespalte;[Funktionen]) 6. Funktion FINDDATAINFILE(...) Beschreibung: Sucht in einer externen Datei anhand von Value und ersetzt Value durch den gefundenen Rückgabewert. Interne Funktion: FindDataInFile(...) Parameter: Dateiname Trennzeichen / Tab / Default Suchspalte (Integer) Rückgabespalte (Integer) Optionale Zusatzfunktionen (derzeit nicht implementiert) 7. Hinweise Fehlerhafte Parameter führen teilweise zu MsgBox . Mehrere Funktionen in einer Definition werden nicht verkettet , sondern einzeln ausgewertet. Die Funktion ist stark konfigurations- und kontextabhängig (XML, CompareValue, externe Dateien). *Stand: Analyse aus Quellcode GetFunktionValue Welche Kalkulationen empfehlen wir bei der Verwendung von Datanorm? Diese Kalkulationen stellen lediglich ein Beispiel dar und sind als Anregung zu verstehen, jedoch nicht 1:1 übernehmbar in jede Konfiguration! Artikelstamm: Positionskalkulationen: Welche Variablen sind in der Schnittstlele möglich oder vorhanden? Dieses Dokument enthält eine vollständige Auflistung aller in Datanorm4BW verwendeten Platzhalter/Funktionskennungen, die mit $ beginnen und enden. Die Platzhalter werden zur feldbasierten Wertauflösung je Satzart (A‑, B‑, R‑, Z‑Satz usw.) verwendet. ________________________________________ 1. A‑Satz (Artikelstammsatz) $Artikelnummer.A-Satz$ $ArtikelnummerOriginal.A-Satz$ $Verarbeitungskennzeichen.A-Satz$ $Kurztext1.A-Satz$ $Kurztext2.A-Satz$ $Preis.A-Satz$ $EK.A-Satz$ $VK.A-Satz$ $Preiseinheit.A-Satz$ $Preiskennzeichen.A-Satz$ $Rabattgruppe.A-Satz$ $RabattgruppeID.A-Satz$ $Mengeneinheit.A-Satz$ $Hauptwarengruppe.A-Satz$ $Warengruppe.A-Satz$ $Langtextschlüssel.A-Satz$ $Langtextnummer.A-Satz$ $Matchcode.A-Satz$ $AlternativartikelnummerKürzel.A-Satz$ $Alternativartikelnummer.A-Satz$ $HerstellernummerKürzel.A-Satz$ $Herstellernummer.A-Satz$ $Herstellertype.A-Satz$ $EAN.A-Satz$ $Anbindungsnummer.A-Satz$ $Mindestverpackungsmenge.A-Satz$ $Verpackungsmenge.A-Satz$ $Katalogseite.A-Satz$ $Textkennzeichen.A-Satz$ $Kostenart.A-Satz$ $Lagermerker.A-Satz$ $Referenznummernersteller.A-Satz$ $Referenznummer.A-Satz$ $Mehrwertssteuer.A-Satz$ ________________________________________ 2. B‑Satz (Änderungs‑/Ergänzungssatz) $Artikelnummer.B-Satz$ $Verarbeitungskennzeichen.B-Satz$ $Alternativartikelnummer.B-Satz$ $Matchcode.B-Satz$ $Katalogseite.B-Satz$ $KupferGewichtsmerker.B-Satz$ $KupferKennzahl.B-Satz$ $KupferGewicht.B-Satz$ $EAN.B-Satz$ $Anbindungsnummer.B-Satz$ $Warengruppe.B-Satz$ $Kostenart.B-Satz$ $Verpackungsmenge.B-Satz$ $Referenznummernersteller.B-Satz$ $Referenznummer.B-Satz$ ________________________________________ 3. G‑Satz (Grafikanbindung) $Satzartkennzeichen.G-Satz$ $Verarbeitungskennzeichen.G-Satz$ $Schlüsselnummer.G-Satz$ $Zeilennummer.G-Satz$ $Anbindeart.G-Satz$ $Dateiname.G-Satz$ $Dateinamenzusatz.G-Satz$ $Kurzbeschreibung.G-Satz$ ________________________________________ 4. S‑Satz (Warengruppen) $Hauptwarengruppe.S-Satz$ $Verarbeitungskennzeichen.S-Satz$ $Warengruppe.S-Satz$ $Bezeichnung.S-Satz$ $BezeichnungHauptwarengruppe.S-Satz$ ________________________________________ 5. R‑Satz (Rabattgruppen) $Verarbeitungskennzeichen.R-Satz$ $Rabattgruppe.R-Satz$ $RabattgruppeID.R-Satz$ $Rabattgruppenbezeichnung.R-Satz$ $Bezeichnung.R-Satz$ $Rabattkennzeichen.R-Satz$ $Rabatt.R-Satz$ $Rabattsatz.R-Satz$ $Multiplikator.R-Satz$ $Teuerungszuschlag.R-Satz$ ________________________________________ 6. P‑Satz (Preisänderungen) $Artikelnummer.P-Satz$ $Preiskennzeichen.P-Satz$ $Preis.P-Satz$ $Rabattkennzeichen1.P-Satz$ $Rabatt1.P-Satz$ $Rabattkennzeichen2.P-Satz$ $Rabatt2.P-Satz$ $Rabattkennzeichen3.P-Satz$ $Rabatt3.P-Satz$ $Preiseinheit.P-Satz$ $RabattGesamt%.P-Satz$ $EK.P-Satz$ $VK.P-Satz$ $RabattgruppeID.P-Satz$ ________________________________________ 7. Z‑Satz (Zu‑/Abschläge, Staffelpreise) $Verarbeitungskennzeichen.Z-Satz$ $Artikelnummer.Z-Satz$ $Zeilennummer.Z-Satz$ $Bearbeitungsmerker.Z-Satz$ $Textzeile.Z-Satz$ $Anzeigezeile.Z-Satz$ $Zuschlagsart.Z-Satz$ $Vorzeichen.Z-Satz$ $Preiskennzeichen.Z-Satz$ $Preiseinheit.Z-Satz$ $Preis.Z-Satz$ $Sortiermerker.Z-Satz$ $Basismerker.Z-Satz$ $VONBasis.Z-Satz$ $BISBasis.Z-Satz$ $Rohstoff.Z-Satz$ $Rohstoffmerker.Z-Satz$ $VONTagespreis.Z-Satz$ $BISTagespreis.Z-Satz$ $Bezugspreisbasis.Z-Satz$ $BezugspreisUmrechnungsfaktor.Z-Satz$ $Gewicht.Z-Satz$ $GewichtUmrechnungsfaktor.Z-Satz$ ________________________________________ 8. T‑ / D‑Satz (Lang‑ und Dimensionstexte) $Artikelnummer.T-Satz$ $Langtextnummer.T-Satz$ $Artikelnummer.D-Satz$ ________________________________________ 9. Sonderfelder (satzunabhängig) $Lieferantennummer$ $Langtext$ $Lager$ $Kontenzuordnung$ $LieferantenID$ $Verarbeitungsart$ ________________________________________ Hinweis: Die tatsächliche Wertauflösung erfolgt kontextabhängig über die jeweilige Satzverarbeitungsfunktion (GetASatz, GetRSatz, GetZSatz, …) sowie optionale Funktionsketten (z. B. UCASE, PREFIX(), SELEKT[]). Nicht jedes Feld ist aus technischen Gründen in allen Definitionen möglich. Wie ist die Datanorm Schnittstellendefinition aufgebaut und wie kann sie angepasst werden? Der Block < ART > steuert den Datenimport der Hauptsätze A und B. Header: Hier geben Sie den Header für den Datenimport an. Sie könnten hier natürlich jedes in der BüroWARE verfügbare Satzkennzeichen verwenden. Entnehmen Sie die Satzkennzeichen und Header werte der BüroWARE Satzbeschreibung, die Sie am SoftENGINE FTP finden, oder verwenden Import 2 BüroWARE, um die Felder schnell zu suchen. < ART >  'Artikelstamm / Hauptsatz A und B               ' Über die Verarbeitungsart können die Datensätze gesteuert werden: NEUANLAGE/LÖSCHEN       Hier wird die Artikelnummer des A-Satzes in der Datanormdatei an das BüroWARE-Feld aa übergeben.                                                Die Datanorm-Bezeichnung ist 2x 40 Zeichen lang, da in der BüroWARE der Artikeltext nur 60 Zeichen hat, wird u.u. der Text der 2. Zeile abgeschnitten, da die Feldlänge u.u. überschritten wird. Über die Funktion TRIM werden Leerzeichen im Feld $Kurztext.A-Satz$ links und rechts entfernt.       Da die BüroWARE-Variable ad zweimal angegeben wird (Kurztext1 und 2), werden die beiden Felder verkettet. Zusätzlich werden Leerzeichen entfernt und ein einzelnes Leerzeichen vor dem Kurztext2 angefügt.       Hier wird der Wert "3" fix dem BüroWARE Feld EK-Verwaltung.            Über die Funktion SELEKT wird dieses Feld nur importiert, wenn das Feld EK.A-Satz auch einen Wert >0 hat.                                     Das Feld $ RabattgruppeID.A-Satz $ verkettet die LIEFERANTENID (angegeben im Bereich CONFIG ) mit der eigentlichen Rabattgruppe, da die Rabattgruppen bei verschiedenen Herstellern die gleiche Nummer haben könnte und so überschrieben werden würden.             Die Lieferantennummer, die im bereich CONFIG angegeben wird, kann in jedem Bereich zugewiesen werden.             'Hier wird das aktuelle Tagesdatum und die aktuelle Uhrzeit in die Individualfelder 01 und 02 Importiert.                                           'Diese Zeile sollte nicht entfernt werden, da diese intern verwendet wird.       Der Preisänderungssatz ist wie der Hauptsatz zu verwenden, mit der Eigenheit, dass hier "nur Ändern" fix eingetragen wurde. Der Preisänderungssatz muss immer NACH den Hauptdatensätzen importiert werden (A-Satz+B-Satz)     < PREISÄNDERUNG >                                                                                         Der Langtext wird in die Datei S_RVTX21.DTK direkt geschrieben. Der Index ist hier @LT,00 wobei 00 für die Sprache steht (00 deutsch, 01...)                                   Der Index wird über das Feld aa übergeben. Somit ist auch hier eine Individualisierung möglich.                 Der Dimensionstext kann optional auch zusätzlich noch in ein eigenes Langtextfeld übertragen werden, wenn z. B. für Angebote auch der Dimensionstext ohne Langtextbeschreibung verwendet werden soll. Der Langtext enthält den Dimensionstext aber in jedem Fall!                     Die Filterfunktion kann momentan nur den Bereich Hauptwarengruppe filtern. Um mehrere Warengruppen zu selektieren, fügen Sie so viele Zeilen mit den Gruppen ein, die Sie benötigen.   < ASATZFILTER >       < !-- add key="$Hauptwarengruppe.A-Satz$" value="M4E" funktion="" / -- >     'Um Einstellungen auszunehmen, können Sie über die hier sehenden Zeichen eine Zeile kommentieren:                                 Hier geben Sie Sonderfelder an, die dann in der Zuweisung angegeben werden können. Es können ur vordefinierte Felder verwendet werden.     < CONFIG > Gibt die Adressnummer des Hauptlieferanten an.               Die Kontenzuordnung für die Artikelgenaue Zuweisung zu einem Kontenmodell.       Die LIEFERANTENID  wird verwendet, um z. B. bei den Rabattgruppen ein "Prefix" für den Lieferanten anzugeben. Beispiel: ID: "STD" Rabattgruppe: "200" Über das Feld $ RabattgruppenID.A-Satz$ wird nun die ID mit der Rabattgruppe verkettet: " STD200 "           Die Rabattgruppen werden in den von Softengine vorgesehenen Leistungsstamm eingelesen. Wie Sie den Leistungsstamm verwenden, erfragen Sie bitte beim SoftENGINE Support. Tipp: Es müssen in der Formel Fakturierung für den Leistungsstamm die Kalkulationen erweitert werden, um die benötigten Kalkulationen zu verwenden, die Sie verwenden möchten.     < RABATTGRUPPEN >                                                     Der Warengruppenstamm, hier gilt dasselbe wie in den oben genannten Bereichen.     < WGR >                                         EDI 2 BüroWARE Dokumentnamensfilter C002 - 1000 Der Dokumentnamensfilter kann Platzhalter enthalten. Beispiele für den Filter:  Feldinhalt in EDI-Nachricht Wert im Filter Dokument wird verarbeitet. ABCDE ABCDE Ja 81234567890 81234567890 Ja ABCDE *CDE* Ja ABCDE *CD? Ja ABCDE F *CD? Nein ABCDE1 *CDE# Ja ABCDE X *CDE# Nein ABCDEF [A-F] Ja ABCDE G [A-F] Nein aM3b a[L-P]#[!c-e] Ja aM3 e a[L-P]#[!c-e] Nein aM a b a[L-P]#[!c-e] Nein Bestellung *stell* Ja SSL-Zertifikat erstellen für SFTP SSH Übertragung Schritt-für-Schritt: SSH-Key mit PuTTYgen erstellen 🔧 1. PuTTYgen starten • Geh zu deinem Startmenü → PuTTYgen • (Falls nicht installiert: Download hier) 🛠️ 2. Key-Typ und Größe auswählen • Type: RSA oder ED25519

 (ED25519 ist moderner, aber RSA ist universeller – wenn du unsicher bist, nimm RSA 4096) • Bits: 4096 (für RSA) 🖱️ 3. Key generieren • Klicke auf „Generate" • Bewege die Maus im Feld, um den Schlüssel zu erzeugen 📝 4. Kommentar setzen • Im Feld „Key comment“ kannst du z. B. italcos-prod@firma.com eintragen 💾 5. Schlüssel speichern • Klicke auf: ◦ Save private key → z. B. id_rsa.ppk ◦ Save public key → z. B. id_rsa.pub Wichtig: Umwandlung in OpenSSH-FormatPublic Key: (Wird am SFTP-Server hinterlegt) Private Key in OpenSSH umwandeln: 
 (wird für den Client verwendet. z. B. Filezilla, EDI4BW) INFO: 
 Der private-Key wird immer im FTP-Client eingetragen und darf NICHT weitergegeben werden.
 Der Public Key wird im SFTP-Server eingetragen und beim entsprechenden User hinterlegt. Wie kann ich den Datenabgleich starten oder über den Scheduler einrichten? Um den Datenabgleich zu starten, ist im Programmpfad von EDI4BW die Datei run.ini zu erstellen. Der Inhalt der Datei wird dabei nicht berücksichtigt und ist nicht relevant. Um den Datenabgleich über den ERP-Starter einzurichten, gehen sie folgendermaßen vor: Erstellen Sie im ERP-Starter über einen Rechtsklick (1) in der Übersichtstabelle der Aufgaben eine neue Aufgabe: "Webshop Connect Datenabgleich" (2) Bearbeiten Sie anschließend die gerade erstellte Aufgabe mit einem Rechtsklick auf den Eintrag und passen Sie den Pfad, wo die Datei run.ini abgelegt werden soll, auf den Programmpfad von EDI4BueroWARE an. Die Datei Run.ini kann auch z. B. aus einem Workflow erstellt werden, um einen gezielten Datenabgleich anzustoßen. ERP Austria Client Wir kann ich den ERP-Austria Client über den DNS-Server konfigurieren? Sie können mit Stand 0.04 folgende Einstellungen über den DNS-Server konfigurieren. Technisch verbindet sich der Client mit der Service-API von ERP-Suite Connect und damit erfolgt dann auch der Datenaustausch. Innerhalb der ERP-Suite muss das Datenaustausch-Workflow den entsprechenden User ansprechen. Die Userzuweisung erfolgt daher innerhalb der ERP-Suite und nicht in der Service-API. Wenn der Client sich mit max.mustermann registriert, dann muss auch im Workflow der ERP-Suite das Öffnen einer Datei an den User max.mustermann gesendet werden. Der User kann in den Clienteinstellungen geändert werden, wenn dieser nicht verwendet werden soll. ERPSuiteServer = Server auf dem die API läuft Port = Port auf dem die Service-API eingerichtet wurde. nossl = Verbindung zur Service-API nicht verschlüsseln (sollte nicht oder nur zum Testen verwendet werden!) Legen Sie dazu in ihrem DNS-Server einen TXT-Eintrag in der Domäne in der sich die Clients befinden mit folgenden Einstellungen an: ERPSuiteServer={Server}:{Port}:{nossl} Mit SSL-Verschlüsselung: (erfordert ein gültiges SSL-Zertifikat auf dem ERP-Suite Connect Dienst) ERPSuiteServer=BWServer.kundenname.local:8443:nossl Datenübertragung ohne SSL: ERPSuiteServer=BWServer.kundenname.local:8443 Bei diesem Dienst werden keine Zugangsdaten oder Ähnliches übertragen. Allerdings empfehlen wir ausdrücklich die Verwendung der SSL-Verschlüsselung. meinedomäne.local bitte durch ihre Domäne/Domänennamen ersetzen! Rechtsklick in den freien Bereich und auf "Weitere neue Einträge" klicken. ERP Austria E-Mail Export und Archivierung Wie verwende ich das Tool BüroWARE MailArchiv und Emailbereinigung? Das Tool kann alle oder einen Teil der E-Mails aus der ERP-Suite (Classic und Vectoring) auslesen und in lesbare E-Mail (EML) -Dateien, welche z. B. mit Inoxision, Outlook oder Mailstore und anderen Mailprogrammen oder Archivierungssystemen verarbeitet werden können, exportieren. Diese Maildateien werden für Mailstore z. B. mit relevanten Daten angereichert, damit diese über den Mailstore-Proxy verarbeitet werden können. Des Weiteren können optional alle E-Mails, welche in der Adressakte zugewiesen wurden, exportiert werden, um somit ein zentrales Archiv zu ermöglichen, ohne private E-Mails. Hierbei wird die Adressakte ausgelesen und alle E-Mails in dem selektierten Zeitraum werden dann exportiert. Eine Sonderform ist der Export in E-Mails (EML-Dateierstellung mit Ordnerstruktur), wobei die ERP-Ordnerstruktur beibehalten wird. Info: Das betrifft nicht die Ordnerstruktur, welche im Officeplaner angelegt wurde, sondern den direkten BWMAIL/EMAILS Ordner mit Unterordnern. Verarbeitungsart Mit der Verarbeitungsart legen Sie die Art des Exportes fest. Eine Sonderform ist die BüroWARE permanent Archivierung, welche E-Mails, die durch die Permanentarchivierung der ERP-Suite laufend exportiert werden, verarbeitet und in EML-Dateien umwandelt. BüroWARE-Pfad Legen Sie hier den ERP-Suite-Pfad fest. Dieser kann lokal oder auch ein UNC-Pfad sein. BüroWARE Archivpfad Dieser Pfad wird für die Permanentarchivierung verwendet. Geben Sie hier den Pfad, welcher in der ERP-Suite für die Permanentarchivierung angegeben wurde, an. Archiv-Ausgabepfad Der Zielpfad für die konvertierten Dateien. (kann auch ein UNC-Pfad sein) Globale Selektion: Hier wird die globale Selektion durchgeführt, welche auf das Empfangsdatum selektiert. Zusätzlich kann über die Option „immer von 1. Jänner berechnen“ die Detailselektion beeinflusst werden. Über die Detailselektion werden die E-Mails weiter eingeschränkt und es kann z. B. eingestellt werden, dass nur E-Mails, die älter als 3 Jahre sind, archiviert werden. Diese Funktion ist vorrangig für die Löschfunktion wichtig, sofern diese verwendet wird, betrifft aber auch die Archivierung selbst. Bei der Selektion für die Löschung kann angegeben werden, ob die E-Mail komplett gelöscht oder durch eine Archiv-Nachricht ersetzt wird. TIPP: Wir empfehlen, die E-Mail-Löschung über einen Report in der ERP-Suite durchzuführen, da dort dann auch die Notiztexte sauber bereinigt werden. Adressakte ergänzen Diese Funktion prüft die Adressakte in der ERP-Suite und stellt fehlende E-Mails im ERP-Suite-Ordner aus einer Datensicherung wieder her. Somit können E-Mails, welche unabsichtlich gelöscht wurden, selektiv wieder hergestellt werden, ohne alle E-Mails Rücksichern zu müssen. Benutzerzuweisung Hier werden alle in der ERP-Suite angelegten User ausgegeben und es ist die zu verwendete E-Mail-Adresse einzugeben. Nur wenn die E-Mail-Adresse angegeben wurde, wird dieser auch exportiert/konvertiert. Diese E-Mail-Adresse ist dann wichtig, wenn die Funktion Mailstore Proxy verwendet wird, da über diese dann die Archivzuweisung erfolgt. Die E-Mails selbst werden dabei nicht verändert und auch für die Inoxision oder Outlook-Exporte wird diese nicht verwendet, außer für die Exportselektion des Users. Es erfolgt aber keine Selektion, ob die E-Mail-Adresse übereinstimmt! Tipp: Wenn Sie keine Mailstore-Archivierung auswählen, können Sie bei den E-Mail-Adressen der Benutzer auch eine beliebige Dummy-Adresse eingeben. Wichtig: Sie können das Tool jederzeit auch ohne Lizenz im Demomodus testen. Hierbei wird jedoch die Anzahl der E-Mails limitiert. Der Reiter allgemein zeigt dann den Fortschritt der Konvertierung an. Hier können Sie auch den Debug-Modus aktivieren, um im Ausgabefenster die gerade konvertierte Mail zu sehen. Info: Ignorierte E-Mails werden i.d.r. nicht ausgegeben, da dieses auch einen Zeitfaktor darstellt. Unbeaufsichtigter Modus Um das Tool unbeaufsichtigt für die Permanentarchivierung zu starten, gibt es folgende Parameter: Beispiel: MailStore BWMailArchive.exe /BWARCHIV /SILENT Der Download kann über unseren FTP-Server oder über unsere Homepage erfolgen. Die Zugangsdaten für unseren FTP-Server erhalten Sie über unseren Support unter support@erpaustria.com https://ftp.erpaustria.com https://www.erpaustria.com/downloads/ Wenn das Tool installiert wurde, liegt im erstellten Pfad das Programm "MailStore BWMailArchive.exe" Eine automatische Desktopverknüpfung ist aktuell (Stand 1.10.2025) nicht vorgesehen. MailArchiv und E-Mail-Bereinigung: Welche E-Mails werden verarbeitet? Das Tool liest E-Mails aus der ERP-Suite (Classic und Vectoring) und exportiert sie bei Bedarf als EML-Dateien. Optional bereinigt es die Originale in der ERP-Suite. Export und Bereinigung haben unterschiedliche Auswahlregeln. Eine exportierte E-Mail wird nicht automatisch gelöscht. Verarbeitungsarten Verarbeitungsart Ergebnis Auswahl Mailstore Proxy EML-Datei und Zuordnungsdaten für den MailStore-Proxy Normale Auswahl; optional nur nicht private E-Mails aus der Adressakte. Inoxision Mailarchive / Inoxision Enterprise Suite EML-Dateien Normale Auswahl. EML-Dateierstellung EML-Dateien im Ausgabeordner Normale Auswahl. EML-Dateierstellung mit Ordnerstruktur EML-Dateien mit der ERP-Mailordnerstruktur Normale Auswahl; die Officeplaner-Struktur wird nicht übernommen. Keine Archivierung (nur Löschen) Kein EML-Export Normale Auswahl; Löschung nur bei aktivierter E-Mail-Löschung und passenden Löschkriterien. Keine Archivierung (nur Ersetzen) Kein EML-Export Normale Auswahl; Ersetzung oder Löschung nur bei aktivierter E-Mail-Löschung und passenden Löschkriterien. BüroWARE Permanentarchivierung EML-Dateien aus ZIP-Dateien des ERP-Permanentarchivs Eigener Ablauf ohne die normalen Benutzer-, Monatsordner- und Maildatumsfilter. Wichtig: Der Name einer Verarbeitungsart ohne Archivierung löst allein keine Löschung oder Ersetzung aus. Maßgeblich sind zusätzlich „E-Mail-Löschung aktiv“, die Löschgrenzen und die eingestellte Löschart. So erfolgt die normale Auswahl Die folgenden Schritte gelten für alle Verarbeitungsarten außer „BüroWARE Permanentarchivierung“: Benutzer: Es werden nur Benutzer mit einer gültig eingetragenen E-Mail-Adresse in der Benutzerzuweisung berücksichtigt. Es kann „Alle“ oder ein einzelner Benutzer gewählt werden. Die Adresse dient bei Mailstore Proxy zur Archivzuordnung; sie filtert nicht nach Absender oder Empfänger. Ordner und Datei: Das Tool untersucht E-Mail-Dateien im ERP-Mailordner des Benutzers. Der übergeordnete Monatsordner muss als Jahr_Monat erkennbar sein. Für die Vorauswahl wird das Monatsende mit „Archivierung ab/bis“ verglichen. Liegt es außerhalb, wird der ganze Ordner übersprungen. Fehlende Dateien werden ebenfalls nicht verarbeitet. Maildatum: Zuerst gilt das Nachrichtendatum. Fehlt es, folgen Anzeigedatum und Empfangsdatum. Ist kein verwendbares Datum vorhanden, wird das Erstellungsdatum der Datei genommen. Das wirksame Datum kann daher vom erwarteten Empfangsdatum abweichen. Zeitraum: Eine Mail muss am oder nach dem Startdatum liegen. Am Starttag zählt zusätzlich die eingestellte Uhrzeit. Das Bis-Datum ist für einzelne Mails ausgeschlossen : Eine Mail an diesem Tag wird nicht exportiert. Adressakte bei Mailstore Proxy: Wenn eine E-Mail-Adresse für die Adressakte eingetragen ist, werden ausschließlich dort zugeordnete, nicht als privat markierte Mails verarbeitet. Bei den anderen Verarbeitungsarten gilt dieser Filter nicht. Bereits ersetzte Mails: Eine vorhandene Archiv-Nachricht wird nicht erneut exportiert. Liegt ihr Datum vor der Grenze für die endgültige Löschung, wird sie entfernt; sonst bleibt sie bestehen. Achtung bei Monatsgrenzen: Liegt „Archivierung bis“ mitten im Monat, kann dessen Ordner bereits in der Vorauswahl ausscheiden, weil das Monatsende später liegt. Um einen Monat vollständig zu verarbeiten, muss das Bis-Datum nach dessen letztem Tag liegen. Bei „bis 01.06.2024“ können etwa Mails aus Mai berücksichtigt werden; Mails vom 01.06.2024 selbst nicht. Wann wird gelöscht oder ersetzt? Die Bereinigung erfolgt zusätzlich nach der normalen Auswahl und nur mit aktivierter „E-Mail-Löschung“. Für eine einzelne Mail müssen alle folgenden Bedingungen erfüllt sein: Ihr wirksames Datum liegt am oder vor „Löschung bis Datum“. Es liegt vor der berechneten Grenze „älter als … Jahre“. Eine Mail genau an der Grenze bleibt erhalten. Wenn eine Mindestgröße über 0 KB eingetragen ist, muss die Quelldatei größer als dieser Wert sein. Bei 0 KB gibt es keinen Größenfilter. Die Altersgrenze entsteht durch Rückrechnung der eingestellten Jahre vom aktuellen Datum. Mit „immer von 1. Jänner berechnen“ beginnt die Rechnung stattdessen am 1. Januar des aktuellen Jahres. Die Oberfläche zeigt das berechnete Datum an. Diese Altersangabe begrenzt die Bereinigung, nicht den EML-Export. Bei „Email Löschen“ wird die Quelldatei entfernt. Bei „Email ersetzen durch Archiv-Nachricht“ wird der Inhalt zunächst durch einen kurzen Hinweis ersetzt. Liegt das Maildatum vor der Grenze für die endgültige Löschung, wird die Datei stattdessen vollständig entfernt. Ganze Monatsordner: Bei aktivierter E-Mail-Löschung prüft das Tool bereits vor der Einzelverarbeitung, ob komplette Monatsordner entfernt werden können. Das betrifft Monate vor dem Monat der Grenze für die endgültige Löschung. Diese Ordner werden im selben Lauf nicht mehr einzeln exportiert. Eine automatische Löschgrenze in Monaten kann die Grenze vom aktuellen Datum ableiten; bei 0 Monaten gilt der manuell eingestellte Wert. Prüfen Sie diese Grenze vor dem Start sorgfältig. BüroWARE Permanentarchivierung Diese Verarbeitungsart liest ZIP-Dateien direkt im angegebenen BüroWARE-Archivordner; Unterordner werden nicht durchsucht. Der Inhalt wird als EML-Datei im Archiv-Ausgabepfad abgelegt. Nach der Konvertierung entfernt das Tool die ZIP-Datei, die gleichnamige Steuerdatei und die temporär entpackte Datei. Benutzerzuweisung, Maildatum, Adressakte und die Alters- und Größenfilter des normalen Exports bestimmen hier nicht, welche ZIP-Dateien verarbeitet werden. Warum fehlt eine E-Mail? Beobachtung Prüfen Sie Alle Mails eines Benutzers fehlen Ist er ausgewählt, mit gültiger E-Mail-Adresse eingetragen und sein ERP-Mailordner vorhanden? Alle Mails eines Monats fehlen Liegt das Monatsende innerhalb der Archivierungsgrenzen? Hat der Ordner das Format Jahr_Monat? Wurde er durch die Löschung entfernt? Einzelne Mail fehlt Welches Datum wurde tatsächlich verwendet? Liegt es am oder nach dem Start und vor dem Bis-Datum? Nur bei Mailstore Proxy fehlen Mails Ist die Adressaktenoption aktiv? Ist die Mail dort zugeordnet und nicht privat? Statt der Originalmail steht ein Hinweis Die Mail wurde ersetzt und wird nicht nochmals exportiert. EML vorhanden, Originalmail ebenfalls Die Löschung ist nicht aktiv oder eine weitere Datums- oder Größenbedingung ist nicht erfüllt. Bei Permanentarchivierung fehlen Mails Liegen die ZIP-Dateien direkt im angegebenen Archivordner? Für die Fehlersuche können Sie den Debug-Modus aktivieren und die Logdatei öffnen. Prüfen Sie einen Exportzeitraum zunächst bei deaktivierter E-Mail-Löschung. Adressakte ergänzen „Adressakte ergänzen“ ist ein eigener Vorgang: Das Tool prüft die ERP-Adressakte und kann fehlende E-Mail-Dateien aus einer angegebenen BWMail-Datensicherung wiederherstellen. Dazu müssen der ERP-Pfad und ein erreichbarer Datensicherungspfad angegeben sein. ' ERP Austria Monitoring Client Vectoring Migrationsanalyse (bw.vectoring.format.log) In der MonitoringClientGlobal.ini muss ggf. der ERP-Suite Pfad eingetragen werden, sofern dieses bisher nicht erfolgt ist. [ERP Suite] ERP Basispfad=D:\Daten\BWWIN2016 (hier wird der ERP-Suit Programmpfad eingetragen) Um die Analyse zu starten, ist Folgendes einzugeben: MonitoringClient.exe /INI= Vectoring.ini (oder ein anderer beliebiger INI-Name) Die INI-Datei wird automatisch erstellt und anschließend ist, der Sensor zu korrigieren: [Config] Sensor=Init #SensorType=KEINER #SensorType=DATEIANZAHL #SensorType=LOGFILES #SensorType=SUCHEERSETZEEML #SensorType=DIENST #SensorType=FORTIGATE #SensorType=FORTINET #SensorType=FGT #SensorType=FORTISWITCH #SensorType=BWPROTLÖSCHANALYSE #SensorType=DTAEXTRACT_UEBER_N SensorType=BWVECTORINGFORMATLOG #SensorType=DUPLIKATFINDER Hier reicht es, wenn die # vor SensorType für den gewünschten Sensor entfernt wird. [CONFIG] SensorType=BWVECTORINGFORMATLOG Sensor=INIT ..... Anschließend den MonitoringClient noch einmal mit denselben Parametern starten, dann werden die fehlenden INI-Einträge automatisch erstellt und sehen dann so aus. [CONFIG] SensorType=BWVECTORINGFORMATLOG [Vectoring Migrationsanalyse] Archiviere Classic Files, wenn diese auch im vectoring Format vorhanden sind=False Migriere vorhandene IDBs in das Vectoring-Format=False Öffne nach der Analyse die erstellte Excel-Analysedatei=True Beendet die GUI automatisch, nach der Analyse=True Logfiles analysieren und im Excelformat ausgeben=True Die erweiterten Einstellungen ggf. korrigieren und wie vorhin den Sensor starten, um die Auswertung durchzuführen. Das Ergebnis sieht dann so ähnlich aus: TIPP: Um nur die Logdatei zu leeren und zu archivieren, ohne viele Ressourcen zu verbrauchen, sind folgende Parameter einzustellen: [Vectoring Migrationsanalyse] Archiviere Classic Files, wenn diese auch im vectoring Format vorhanden sind=False Migriere vorhandene IDBs in das Vectoring-Format=False Öffne nach der Analyse die erstellte Excel-Analysedatei=False Beendet die GUI automatisch, nach der Analyse=True Logfiles analysieren und im Excelformat ausgeben=False Wie kann ich Classic oder Vectoring Datendateien konvertieren? Mit dem Monitoring Client können die meisten Classic-Tabellen in das Vectoringformat und Vectoringtabellen in das Classicformat konvertiert werden. Aktuell können *.DAT und *.SEDB Tabellen konvertiert werden. Dazu ist entweder die Satzlänge der Zieltabelle erforderlich oder ein entsprechender Vorlagepfad mit den entsprechenden Dateien für das Zielformat. Mit dem Monitoring Client können Sie eine einzelne Datei konvertieren oder den gesamten Quellpfad. Die Ausgabe erfolgt dabei in einem zu definierenden Ausgabepfad. Voraussetzung: MonitoringClient ab V1.67 Microsoft .NET 4.8 oder höher In diesem Beispiel wird der komplette Quellpfad konvertiert und als Vorlagepfad dient der Beispielmandant. Die Ausgabe erfolgt am Bildschirm mit folgender Anzeige: Beispiel von INI-Dateien für die Konvertierung: In diesem Beispiel wird nur die S03DBK_R00.SEDB (Vectoring) in das Classicformat konvertiert. Wenn der Quelldateiname leer ist, dann wird automatisch alles, was im Quellpfad liegt, in die entsprechende Zieldatei umgewandelt. Vectoring --> Classic und Classic --> Vectoring Es gibt folgende Parameter für MonitoringClient.exe: /INI=INI-Datei (Konvertierungsvorgabe - ZWINGENDER PARAMETER) /F= Quelldatei (Datei die konvertiert weden soll) /V= Vorlagedatei (für die Ermittlung des Zieldateinamens + Ermittlung der Satzlänge der Zieldatei) /L= Satzlänge des Zielformates (optional) MonitoringClient.exe /INI= SEDBConvert.ini Konvertiert aufgrund der INI-Einstellungen. Alle Vorgaben werden aus der INI verwendet. MonitoringClient.exe /INI= SEDBConvert.ini / F= S05DBK32.DAT Konvertiert die Classic-Datei S05DBK32.DAT in S05DBK_R00.SEDB Die Satzlänge wird aus der Vorlage im Vorlageordner gesucht und automatisch ermittelt. MonitoringClient.exe /INI= SEDBConvert.ini /F= S05DBK32.DAT /V= S05DBK_R00.SEDB Konvertiert die Classic-Datei S05DBK32.DAT in S05DBK_R00.SEDB mit Vorgabe des Ausgabedateinamens. Die Satzlänge wird aus der Vorlage automatisch ermittelt. MonitoringClient.exe /INI= SEDBConvert.ini / F= S05DBK_R00.SEDB /V= S05DBK32.DAT Konvertiert die Vectoring-Datei S05DBK_R00.SEDB in S05DBK32.DAT mit Vorgabe des Ausgabedateinamens. Die Satzlänge wird aus der Vorlage automatisch ermittelt. MonitoringClient.exe /INI=SEDBConvert.ini /F=S05DBK_R00.SEDB /L=5118 Konvertiert die Vectoring-Datei S05DBK_R00.SEDB in S05DBK32.DAT mit Vorgabe des Ausgabedateinamens. Die Länge des Satzes ist fix auf 5118 Bytes festgelegt. Die Parameter /F, /V und /L übersteuern die Einstellungen/Vorgaben, welche in der INI-Datei gemacht wurden. WICHTIG: Es werden aktuell nicht alle Dateien unterstützt und dieses ist auch nicht das Ziel von diesem Tool. Nicht unterstützt werden alle Datenfiles mit Dateierweiterungen, wie z.B. Artikelstamm, Adressstamm, Belege, Belegpositionen oder Dateien mit speziellen Satzlängen, welche nicht auf einer Datensatzlänge, sondern auf Basis von Bytepositionen basieren. Das betrifft z. B. den Firmenstamm o. Ä. Wie kann ich den MonitoringClient aktualisieren (LiveUpdate) Um das Live-Update für den Monitoring Client zu starten, müssen Sie den folgenden Batch im Programmpfad des Clients starten: Wie starte und konfiguriere ich den Monitoring Client? In der MonitoringClientGlobal.ini muss ggf. der ERP-Suite-Pfad eingetragen werden, sofern dieses bisher nicht erfolgt ist. [ERP Suite] ERP Basispfad=D:\Daten\BWWIN2016 (hier wird der ERP-Suite-Programmpfad eingetragen) Um die Analyse/Konvertierung o.ä. zu starten, ist Folgendes einzugeben: MonitoringClient.exe /INI= INI-Dateiname (ein beliebiger INI-Name ohne Leerzeichen) Die INI-Datei wird automatisch erstellt und anschließend ist, der Sensor zu korrigieren: [Config] Sensor=Init #SensorType=KEINER #SensorType=DATEIANZAHL #SensorType=LOGFILES #SensorType=SUCHEERSETZEEML #SensorType=DIENST #SensorType=FORTIGATE #SensorType=FORTINET #SensorType=FGT #SensorType=FORTISWITCH #SensorType=BWPROTLÖSCHANALYSE #SensorType=DTAEXTRACT_UEBER_N SensorType=BWVECTORINGFORMATLOG #SensorType=DUPLIKATFINDER #SensorType=SEDBConvert Hier reicht es, wenn die # vor SensorType für den gewünschten Sensor entfernt wird. [CONFIG] SensorType=BWVECTORINGFORMATLOG Sensor=INIT ..... Anschließend den MonitoringClient noch einmal mit denselben Parametern starten, dann werden die fehlenden INI-Einträge automatisch erstellt und sehen dann (abhängig vom Sensor) so aus. [CONFIG] SensorType=BWVECTORINGFORMATLOG [Vectoring Migrationsanalyse] Archiviere Classic Files, wenn diese auch im vectoring Format vorhanden sind=False Migriere vorhandene IDBs in das Vectoring-Format=False Öffne nach der Analyse die erstellte Excel-Analysedatei=True Beendet die GUI automatisch, nach der Analyse=True Logfiles analysieren und im Excelformat ausgeben=True Die erweiterten Einstellungen ggf. korrigieren und wie vorhin den Sensor starten, um die Auswertung oder die Analyse durchzuführen. ERP Austria Scheduler / FlowManager Der ERP Austria FlowMananger kann Aufgaben und Workflows ausführen und koordinieren Allgemeiner Überblick über den Scheduler Überblick Der BWScheduler führt wiederkehrende oder gezielt ausgelöste Aufgaben automatisch aus. Typische Einsatzbereiche sind: Starten von ERP-Suite-Aufgaben, Programmen und Skripten Aufrufen vorbereiteter Wartungs- und Systemfunktionen Starten, Stoppen oder Neustarten von Windows-Diensten Überwachen von Dateien und Ordnern Auslösen einer Aufgabe über eine SchedulerXX.RUN -Datei Auslösen einer Aufgabe auf einem verbundenen BWScheduler über die REST-API Jede Aufgabe besitzt eine eindeutige Scheduler-ID. Die Bezeichnung dient der Übersicht und darf bei mehreren Aufgaben gleich sein. Für gezielte Aufrufe ist immer die Scheduler-ID maßgeblich. Zeitsteuerung des BWSchedulers Die globale Einstellung Zeitsteuerung legt fest, in welcher Betriebsart geplante Aufgaben ausgeführt werden dürfen. Einstellung Bedeutung Dienst Die Zeitsteuerung ist nur im Windows-Dienst aktiv. Applikation Die Zeitsteuerung ist nur in der manuell gestarteten Anwendung aktiv. Immer aktiv Die Zeitsteuerung darf sowohl im Dienst als auch in der Anwendung aktiv sein. Optional kann die Zeitsteuerung auf einen bestimmten Windows-Benutzer eingeschränkt werden. Die Schaltfläche zum manuellen Starten der Zeitsteuerung kann eine unpassende Betriebsart oder Benutzerbeschränkung nicht übersteuern. Wichtig: Ist die Einstellung Zeitsteuerung nicht korrekt gesetzt, bleiben geplante Aufgaben in der betreffenden Instanz inaktiv. Aufgabenarten Aufgabenart Verwendung ERP-Suite Aufgabe Führt eine dafür vorgesehene Aufgabe in der ERP-Suite aus. Modaler Programmaufruf Startet ein Programm und wartet auf dessen Abschluss. Programmstart (nicht modal) Startet ein Programm, ohne andere nicht zusammengehörige Aufgaben bis zu dessen Ende zu blockieren. Skriptaufruf (modal) Führt ein Skript aus und berücksichtigt dabei die modale Steuerung. Funktionsaufruf Führt eine im BWScheduler bereitgestellte Funktion aus, beispielsweise eine NoLock- oder Dienstfunktion. Bei modalen Aufgaben kann zusätzlich eine Modale Gruppe eingestellt werden. Aufgaben derselben Farbgruppe werden nacheinander ausgeführt. Aufgaben verschiedener Farbgruppen dürfen parallel laufen. keine (Global) sperrt sich mit allen modalen Gruppen. Weitere Einzelheiten enthält die Kundendokumentation Modale Gruppen im BWScheduler . Wichtige Einstellungen einer Aufgabe Einstellung Bedeutung Aktiv Nur aktivierte Aufgaben werden automatisch ausgeführt. Bezeichnung Frei wählbarer Name zur leichteren Erkennung. Aufgabenart Legt fest, wie die Aufgabe ausgeführt wird. Prozesspriorität Legt bei unterstützten Programmaufrufen die Windows-Prozesspriorität fest. Modale Gruppe Steuert die gleichzeitige Ausführung modaler Aufgaben. Ausführungsintervall Bestimmt den Kalendertag beziehungsweise die Wiederholung. Ausführungsbedingung Zusätzliche Bedingung, die vor dem Start erfüllt sein muss. Ausführungsdatum Tag oder Datum für datumsabhängige Ausführungen. Wochentag Erlaubte Wochentage. Ohne Wochentage erfolgt keine normale zeitgesteuerte Ausführung. Ausführungszeit Uhrzeit für eine einmalige Ausführung bei Intervall 0 . Zeit von / Zeit bis Zeitraum, innerhalb dessen die Aufgabe gestartet werden darf. Intervall Wiederholung in Minuten; 0 bedeutet Ausführung zur festen Uhrzeit. App Programm, Skript oder bereitgestellte Scheduler-Funktion. AppParameter / AppParameter2 Übergabewerte für die gewählte Aufgabe oder Funktion. Maximale Prozesslaufzeit Überwachung der zulässigen Laufzeit in Minuten. Rückgabecode Variable Optionale Auswahl einer der zehn fest vorgegebenen Variablen, in der das Ergebnis der Aufgabe gespeichert wird. Rückgabecode übernehmen Legt bei nicht-modalen Programmen fest, ob bereits der erfolgreiche Start oder erst das Prozessende ausgewertet wird. Variable nach Ausführung auf -1 setzen Verbraucht die für die Ausführungsbedingung verwendete Variable nach der Ausführung, damit dasselbe Ergebnis nicht nochmals verarbeitet wird. REST-API Ausführung Legt fest, ob und mit welcher Berechtigung die Aufgabe über REST ausgelöst werden darf. Je nach Aufgabenart können weitere Einstellungen sichtbar oder erforderlich sein, beispielsweise Dienstname, Netzlaufwerk, Benachrichtigung oder Dateifilter. Zeitgesteuerte Ausführung Ausführung zu einer festen Uhrzeit Für eine einmalige Ausführung pro passendem Tag wird Intervall auf 0 gesetzt. Die Ausführungszeit muss innerhalb von Zeit von und Zeit bis liegen. Beispiel: Einstellung Wert Ausführungsintervall Täglich Wochentag MO, DI, MI, DO, FR Ausführungszeit 05:31 Zeit von 05:30 Zeit bis 06:00 Intervall 0 Die Aufgabe wird an den gewählten Wochentagen einmal um 05:31 Uhr ausgeführt. Plausibilitätsprüfung: Bei einem Zeitfenster innerhalb desselben Tages muss Zeit bis später als Zeit von sein. Eine Ausführungszeit außerhalb des Fensters ist nicht zulässig. Wiederkehrende Ausführung Ist Intervall größer als 0 , erfolgt die Wiederholung in Minuten. Der nächste Lauf richtet sich nach der letzten Ausführungszeit und muss weiterhin in einem erlaubten Zeitfenster und an einem erlaubten Wochentag liegen. Beispiel: Bei Intervall = 15 wird die Aufgabe frühestens 15 Minuten nach dem letzten Start erneut berücksichtigt. Kalenderintervalle Der BWScheduler unterstützt unter anderem: Täglich bestimmter Tag oder bestimmtes Datum Monatsanfang und Monatsende Quartalsanfang und Quartalsende Halbjahresanfang und Halbjahresende Jahresanfang und Jahresende Zusätzlich müssen der eingestellte Wochentag, das Zeitfenster und eine mögliche Ausführungsbedingung passen. Ausführungsbedingungen Standardmäßig gilt keine Einschränkung . Je nach Aufgabe kann als zusätzliche Bedingung beispielsweise verlangt werden, dass der ERP-Suite-Mailserver aktiv ist. Eine Aufgabe startet nur, wenn alle für sie geltenden Voraussetzungen erfüllt sind: Die Aufgabe ist aktiviert. Die Zeitsteuerung ist für die aktuelle Instanz erlaubt und aktiv. Kalendertag und Wochentag passen. Die Aufgabe befindet sich im erlaubten Zeitfenster. Feste Uhrzeit oder Minutenintervall sind fällig. Die Ausführungsbedingung ist erfüllt. Es besteht keine Sperre durch NoLock, Wartungsmodus oder eine unpassende modale Gruppe. Rückgabecodes und abhängige Aufgaben Eine Aufgabe kann ihr Ergebnis in einer benannten Scheduler-Variable bereitstellen. Eine andere Aufgabe kann diese Variable anschließend als Ausführungsbedingung verwenden. Verfügbare Rückgabecode-Variablen Der Scheduler stellt zehn fest vorgegebene Variablen bereit: Variable 1 Variable 2 Variable 3 Variable 4 Variable 5 Variable 6 Variable 7 Variable 8 Variable 9 Variable 10 Die Namen können nicht geändert werden. Dadurch bezeichnet beispielsweise Variable 3 bei der Aufgabe, die den Rückgabecode schreibt, und bei der davon abhängigen Aufgabe immer denselben Inhalt. Neue Ausführungsbedingungen Unter Ausführungsbedingung stehen folgende Arten zur Verfügung: Auswahl Verhalten keine Einschränkung Es wird keine zusätzliche Selektion geprüft. Die übrigen Zeit-, Status- und Schutzbedingungen gelten weiterhin. ERP-Suite Mailserver aktiv Die Aufgabe startet nur, wenn der ERP-Suite-Mailserver aktiv ist. Nur wenn Rückgabecode-Variable 'Variable 1' den Wert 0 oder 200 enthält Die Aufgabe startet nur, wenn Variable 1 erfolgreich ist. Nur wenn Rückgabecode-Variable 'Variable 2' den Wert 0 oder 200 enthält Die Aufgabe startet nur, wenn Variable 2 erfolgreich ist. Nur wenn Rückgabecode-Variable 'Variable 3' den Wert 0 oder 200 enthält Die Aufgabe startet nur, wenn Variable 3 erfolgreich ist. Nur wenn Rückgabecode-Variable 'Variable 4' den Wert 0 oder 200 enthält Die Aufgabe startet nur, wenn Variable 4 erfolgreich ist. Nur wenn Rückgabecode-Variable 'Variable 5' den Wert 0 oder 200 enthält Die Aufgabe startet nur, wenn Variable 5 erfolgreich ist. Nur wenn Rückgabecode-Variable 'Variable 6' den Wert 0 oder 200 enthält Die Aufgabe startet nur, wenn Variable 6 erfolgreich ist. Nur wenn Rückgabecode-Variable 'Variable 7' den Wert 0 oder 200 enthält Die Aufgabe startet nur, wenn Variable 7 erfolgreich ist. Nur wenn Rückgabecode-Variable 'Variable 8' den Wert 0 oder 200 enthält Die Aufgabe startet nur, wenn Variable 8 erfolgreich ist. Nur wenn Rückgabecode-Variable 'Variable 9' den Wert 0 oder 200 enthält Die Aufgabe startet nur, wenn Variable 9 erfolgreich ist. Nur wenn Rückgabecode-Variable 'Variable 10' den Wert 0 oder 200 enthält Die Aufgabe startet nur, wenn Variable 10 erfolgreich ist. Die Variablenselektion ist eine zusätzliche Bedingung. Eine Aufgabe muss weiterhin aktiviert und zeitlich fällig sein und darf nicht durch Wartungsmodus, NoLock oder eine modale Gruppe gesperrt sein. Ergebnisvariable einer Aufgabe zuordnen Unter Rückgabecode Variable stehen Keine Rückgabecode-Variable sowie Variable 1 bis Variable 10 zur Auswahl. Wählen Sie die Variable aus, in der diese Aufgabe ihr Ergebnis bereitstellen soll. Soll die Aufgabe keinen Rückgabewert bereitstellen, wählen Sie Keine Rückgabecode-Variable . Beim Start der Aufgabe wird die Variable auf -1 gesetzt. Nach erfolgreichem Abschluss wird der Rückgabecode gespeichert. Wert Bedeutung -1 Aufgabe wurde noch nicht beendet oder Ergebnis steht noch aus. 0 Erfolgreich beziehungsweise Selektion erfüllt. 200 Erfolgreich beziehungsweise Selektion erfüllt. jeder andere Wert Fehler beziehungsweise Selektion nicht erfüllt. Interne Scheduler-Funktionen, die keinen eigenen Exitcode liefern, setzen bei fehlerfreier Ausführung den Wert 0 . Kann ein Programm nicht gestartet oder überwacht werden oder tritt eine Zeitüberschreitung auf, speichert der Scheduler einen eigenen negativen Fehlercode. Interner Fehlercode Bedeutung -1001 Programm konnte nicht gestartet werden. -1002 Maximale Laufzeit überschritten; Prozess wurde beendet. -1003 Maximale Laufzeit überschritten; Prozess läuft laut Einstellung weiter. -1004 Prozessüberwachung nicht möglich. -1005 Fehler während der Aufgabenausführung. Folgeaufgabe auswählen Bei anderen Aufgaben erscheint die Variable unter Ausführungsbedingung in folgender Form: Nur wenn Rückgabecode-Variable 'Variable 1' den Wert 0 oder 200 enthält Die Folgeaufgabe darf nur starten, wenn Variable 1 den Wert 0 oder 200 enthält. Bei -1 sowie bei jedem Fehlercode bleibt die Bedingung unerfüllt. Ergebnis nach der Ausführung verbrauchen Aktivieren Sie bei der Folgeaufgabe die Einstellung Variable nach Ausführung auf -1 setzen , wenn dasselbe Ergebnis nur einmal verarbeitet werden darf. Nach der Ausführung der Folgeaufgabe setzt der Scheduler die in der Ausführungsbedingung ausgewählte Variable wieder auf -1 . Bei einem nicht-modalen Programm erfolgt dies nach dessen erfolgreichem Start, während die Prozessüberwachung im Hintergrund weiterläuft. Dadurch ist die Bedingung anschließend nicht mehr erfüllt und die Aufgabe kann wegen desselben Rückgabewerts nicht nochmals starten. Wird der Aufgabenstart verhindert, bleibt die Variable unverändert. Diese Einstellung wirkt ausschließlich bei einer Ausführungsbedingung mit einer Rückgabecode-Variable. Vollständiges Beispiel Aufgabe A führt einen Datenimport aus. Aufgabe B soll danach genau einmal eine Weiterverarbeitung starten. Aufgabe Einstellung Auswahl Aufgabe A Rückgabecode Variable Variable 1 Aufgabe B Ausführungsbedingung Nur wenn Rückgabecode-Variable 'Variable 1' den Wert 0 oder 200 enthält Aufgabe B Variable nach Ausführung auf -1 setzen aktiviert Ablauf: Beim Start von Aufgabe A wird Variable 1 auf -1 gesetzt. Solange Variable 1 den Wert -1 enthält, darf Aufgabe B nicht starten. Aufgabe A beendet sich mit 0 oder 200 . Damit ist die zusätzliche Ausführungsbedingung von Aufgabe B erfüllt. Sobald auch alle übrigen Bedingungen von Aufgabe B erfüllt sind, wird Aufgabe B ausgeführt. Nach der Ausführung setzt Aufgabe B Variable 1 wieder auf -1 . Aufgabe B kann aufgrund dieses Ergebnisses nicht nochmals gestartet werden. Erst ein neuer erfolgreicher Lauf von Aufgabe A gibt sie wieder frei. Nicht-modale Programme Für Programmstart (nicht modal) stehen unter Rückgabecode übernehmen zwei Möglichkeiten zur Verfügung: Einstellung Verhalten Nach Programmstart Nach einem erfolgreichen Start wird die Variable sofort auf 0 gesetzt. Dies ist die Standardvorgabe. Nach Prozessende Die Variable bleibt während der Laufzeit auf -1 und erhält erst nach dem tatsächlichen Prozessende dessen Exitcode. Unabhängig von dieser Auswahl überwacht der Scheduler den gestarteten nicht-modalen Prozess im Hintergrund: Andere Scheduler-Aufgaben dürfen weiterhin ausgeführt werden. Dieselbe Aufgabe kann nicht nochmals gestartet werden, solange ihr Prozess noch läuft. Die maximale Prozesslaufzeit und die Einstellung Prozess bei Zeitüberschreitung nicht Abbrechen gelten auch für nicht-modale Programme. Wird der Prozess wegen Zeitüberschreitung beendet, wird die Ergebnisvariable auf einen Fehlerwert gesetzt. Darf der Prozess nach einer Zeitüberschreitung weiterlaufen, bleibt dieselbe Aufgabe bis zu seinem tatsächlichen Ende für einen erneuten Start gesperrt. Empfehlung: Verwenden Sie pro Variable möglichst nur eine schreibende Aufgabe. Mehrere gleichzeitig laufende Aufgaben mit demselben Variablennamen würden sich gegenseitig überschreiben. Haupt- und Unteraufgaben Unter einer Hauptaufgabe können Unteraufgaben angelegt werden. Wird die Hauptaufgabe gestartet, werden ihre aktivierten Unteraufgaben entsprechend der eingestellten Reihenfolge verarbeitet. Für gezielte Aufrufe über SchedulerXX.RUN oder die REST-API sollte eine Hauptaufgabe verwendet werden. Eine Unteraufgabe ist für einen direkten externen Start nicht vorgesehen. Möglichkeiten zum Starten einer Aufgabe Automatische Zeitsteuerung Der BWScheduler prüft regelmäßig, welche Aufgaben fällig sind. Eine Aufgabe wird nur einmal gleichzeitig zur Ausführung eingeplant; ein noch laufender Prüfvorgang wird nicht parallel ein zweites Mal gestartet. Manuelle Ausführung Eine Aufgabe kann in der Bedienoberfläche gezielt gestartet werden. Ausführungsbedingungen, modale Gruppen und aktive Schutzsperren sind weiterhin zu beachten. SchedulerXX.RUN -Datei Im eingestellten Überwachungsordner kann eine Datei nach folgendem Schema angelegt werden: Scheduler22.RUN Damit wird die Hauptaufgabe mit der Scheduler-ID 22 angefordert. Die Dateierkennung reagiert auch dann, wenn eine Datei zunächst unter einem anderen Namen erstellt und anschließend in Scheduler22.RUN umbenannt wird. Mehrere Dateiereignisse für dieselbe Datei führen nicht zu einer mehrfachen parallelen Ausführung derselben Anforderung. Eine RUN-Datei hebt eine NoLock- oder Wartungssperre nicht auf. Während einer solchen Sperre gelten ausschließlich die weiter unten beschriebenen Ausnahmen. Dateiüberwachung Eine Aufgabe kann auf das Erstellen oder Ändern passender Dateien in einem überwachten Ordner reagieren. Die Überwachungsaufgabe verweist auf die auszuführende Zielaufgabe. Zielaufgabe und Überwachungsaufgabe dürfen nicht identisch sein. REST-API Ab Programmversion 5.31 können BWScheduler-Installationen Aufgaben verschlüsselt untereinander auslösen. Die Zielaufgabe muss dafür über REST-API Ausführung ausdrücklich freigegeben sein. Einzelheiten enthält die Kundendokumentation BWScheduler über REST-API verbinden . Verhalten bei NoLock.ini und Wartungsmodus Zweck der Sperre Eine gefundene NoLock.ini , eine NoLock_admin_only.ini oder ein aktiver ERP-Suite-Wartungsmodus hält die normale Programmausführung des BWSchedulers an. Dadurch sollen während Wartungsarbeiten keine normalen ERP-, Programm-, Skript-, Datei- oder Importaufgaben neu gestartet werden. Der BWScheduler berücksichtigt die NoLock-Dateien in den dafür vorgesehenen ERP-Suite- und Mandantenpfaden. Der Wartungsstatus wird regelmäßig neu geprüft. Sobald keine Sperre mehr besteht, kann die normale Zeitsteuerung fortgesetzt werden. Welche Aufgaben trotz Sperre ausgeführt werden dürfen Während einer gefundenen NoLock-Datei oder eines aktiven Wartungsmodus sind ausschließlich folgende Funktionsaufrufe freigegeben: Kundenfunktion Unterstützte Funktionsnamen Verhalten während der Sperre NoLock.INI löschen $DELETENOLOCKINI , $DELETENOLOCK , $DELETENOLOCK.INI Darf ausgeführt werden und entfernt die vorgesehenen NoLock-Dateien. Alle NoLock.INI löschen $DELETEALLNOLOCKINI Darf ausgeführt werden und entfernt die NoLock-Dateien aus allen berücksichtigten Pfaden. Benutzer beziehungsweise ERP-Suite-Sitzungen abmelden $AUSLOGGEN , $LOGOFF , $LOGOFFMDE , $BWLOGOFF Darf ausgeführt werden, damit eine Wartung oder Abmeldung abgeschlossen werden kann. Alle anderen Aufgaben bleiben gesperrt. Das betrifft insbesondere: ERP-Suite-Aufgaben modale und nicht-modale Programmaufrufe Skripte normale Datei- und Importfunktionen Start, Stopp und Neustart von Diensten das Erstellen einer NoLock-Datei mit $CREATENOLOCKINI Prozessstart- und Prozessbeendigungsfunktionen, sofern sie nicht zu den oben ausdrücklich freigegebenen Abmeldefunktionen gehören über RUN-Datei, Dateiüberwachung oder REST-API angeforderte normale Aufgaben Wichtig: „Darf trotz Sperre ausgeführt werden“ bedeutet nicht „wird sofort und bedingungslos ausgeführt“. Bei einem normalen Zeitplan muss die Aufgabe aktiviert sein; außerdem müssen Wochentag, Zeitfenster, Ausführungszeit beziehungsweise Intervall und Ausführungsbedingung passen. Für einen gezielten Aufruf gelten dessen eigene Freigabe- und Aktivierungseinstellungen. Ein gezielter Aufruf kann die zeitliche Fälligkeit ersetzen, aber nicht die NoLock-Freigabeliste erweitern. Zusammenfassung Systemzustand Normale Aufgaben NoLock löschen / Abmelden Keine Sperre gemäß Aufgabenplanung erlaubt gemäß Aufgabenplanung erlaubt NoLock.ini gefunden gesperrt erlaubt, wenn die betreffende Aufgabe fällig oder gezielt angefordert ist NoLock_admin_only.ini gefunden gesperrt erlaubt, wenn die betreffende Aufgabe fällig oder gezielt angefordert ist Wartungsmodus aktiv gesperrt erlaubt, wenn die betreffende Aufgabe fällig oder gezielt angefordert ist Zeitsteuerung manuell pausiert gesperrt die ausdrücklich freigegebenen Entsperr-/Abmeldefunktionen bleiben grundsätzlich möglich Empfohlener Ablauf eines Wartungsfensters Legen Sie eine Aufgabe zum Erstellen der NoLock-Datei an. Planen Sie anschließend die benötigten Wartungs- oder Beendigungsaufgaben in einer sinnvollen Reihenfolge. Beachten Sie, dass nach Aktivierung der Sperre normale Aufgaben nicht mehr neu gestartet werden. Verwenden Sie zum Abschluss eine ausdrücklich freigegebene Aufgabe zum Löschen der NoLock-Dateien. Prüfen Sie nach dem Wartungsfenster die Statusanzeige und das Protokoll. Hinweis: Eine Aufgabe, die nach dem Erstellen der NoLock-Datei noch als normale separate Scheduler-Aufgabe starten soll, wird durch die Sperre verhindert. Solche Abläufe müssen als zusammengehöriger Wartungsablauf vorbereitet oder vor Eintritt der Sperre gestartet werden. Anzeige und Statuskontrolle Die Aufgabenliste zeigt unter anderem: Aktivstatus Bezeichnung und Scheduler-ID letzte und nächste Ausführung aktuellen Laufstatus die kompakte Spalte Gruppe mit dem Namen und der Farbe einer ausgewählten Farbgruppe Bei keine (Global) und bei nicht-modalen Aufgaben bleibt die Zelle in der Spalte Gruppe leer. Die globale Sperrwirkung der Einstellung keine bleibt davon unberührt. Bei unerwartetem Verhalten sollte zusätzlich das BWScheduler-Protokoll geprüft werden. Dort werden beispielsweise folgende Zustände festgehalten: Zeitsteuerung aktiv oder nicht aktiv Aufgabe fällig oder nicht fällig nicht erfüllte Ausführungsbedingung erkannte NoLock-Datei oder Wartungsmodus Warten auf eine modale Gruppe Start und Ende einer Aufgabe fehlende Programme, Pfade oder Berechtigungen Änderung einer Rückgabecode-Variable geändertes Ergebnis einer Variablenselektion verhinderter Doppelstart eines noch laufenden nicht-modalen Programms Benachrichtigungen und Laufzeitüberwachung Je nach Konfiguration kann der BWScheduler über Aufgabenstart, Aufgabenende, Fehler, NoLock-Erkennung oder ungewöhnlich lange Laufzeiten informieren. Für lang laufende oder geschäftskritische Aufgaben empfiehlt sich: eine realistische maximale Prozesslaufzeit ein Warnungszeitpunkt vor oder bei Überschreitung aktivierte Benachrichtigungen die Kennzeichnung als kritischer Prozess, sofern zutreffend Ein automatischer Abbruch sollte nur verwendet werden, wenn das betreffende Programm gefahrlos beendet werden kann. Checkliste für eine neue Aufgabe Eindeutige Bezeichnung und richtige Aufgabenart wählen. Programm beziehungsweise Funktion und Parameter prüfen. Aufgabe aktivieren. Gewünschte Wochentage festlegen. Feste Uhrzeit oder Minutenintervall einstellen. Prüfen, ob die Ausführungszeit innerhalb von Zeit von und Zeit bis liegt. Bei modalen Aufgaben die passende Gruppe wählen. Benötigte Zugriffsrechte des Scheduler-Kontos prüfen. REST-Freigabe nur bei tatsächlichem Bedarf aktivieren. Aufgabe zunächst kontrolliert testen und anschließend das Protokoll prüfen. Fehlerbehebung Eine geplante Aufgabe startet nicht Prüfen Sie in dieser Reihenfolge: Ist die Aufgabe aktiviert? Ist die Zeitsteuerung in dieser Instanz aktiv? Passt die globale Betriebsart Dienst , Applikation oder Immer aktiv ? Ist der aktuelle Windows-Benutzer zugelassen? Ist der heutige Wochentag ausgewählt? Liegt die aktuelle Zeit im erlaubten Zeitfenster? Ist die feste Uhrzeit beziehungsweise das Intervall bereits fällig? Ist die Ausführungsbedingung erfüllt? Wurde eine NoLock.ini oder NoLock_admin_only.ini gefunden? Ist der ERP-Suite-Wartungsmodus aktiv? Wartet die Aufgabe auf eine belegte modale Gruppe? Sind Programm, Pfad, Dienstname und Parameter korrekt? Aufgaben verschiedener Farben warten trotzdem Prüfen Sie, ob eine laufende modale Aufgabe die Gruppe keine (Global) verwendet. Eine globale modale Aufgabe sperrt alle Farbgruppen. Zwei unterschiedliche Farbgruppen dürfen nur dann parallel laufen, wenn keine globale modale Aufgabe aktiv ist. Eine Aufgabe wurde beim Programmstart unerwartet ausgeführt Prüfen Sie besonders: ob Zeit von und Zeit bis ein gültiges Zeitfenster bilden, ob die Ausführungszeit innerhalb dieses Fensters liegt, ob ein Intervall größer als 0 eingestellt ist, ob noch eine SchedulerXX.RUN -Datei oder ein anderer externer Auftrag vorhanden war, ob die Aufgabe als Unteraufgabe einer gerade gestarteten Hauptaufgabe ausgeführt wurde. Weiterführende Kundendokumentationen Modale Gruppen im BWScheduler Funktionsaufrufe im BWScheduler BWScheduler über REST-API verbinden Benutzer abmelden und Blacklist Über den Scheduler/FlowManager können über die Aufgabenart "Alle Remotedesktop-Benutzer abmelden" alle User automatisiert vom Server abgemeldet werden. So kann zB. vermieden werden, dass die Sessions immer nur getrennt und so mit der Zeit vermeidbare Probleme generiert werden. Blacklist Im Programmverzeichnis gibt es die Datei rds-logoff-blacklist.txt , in der die Bediener eingetragen werden, die nicht abgemeldet werden sollen: BWScheduler über REST-API steuern Überblick Über die REST-API können mehrere BWScheduler-Installationen verschlüsselt miteinander verbunden werden. Eine Installation übernimmt die Rolle des Servers, die übrigen Installationen arbeiten als Clients. Eine Installation kann immer nur eine Rolle besitzen: Server: Nimmt Verbindungen an und kann Aufträge für Clients bereitstellen. Client: Verbindet sich mit dem Server, sendet Aufträge an den Server und fragt Aufträge für sich selbst ab. Damit können Aufgaben in beide Richtungen ausgelöst werden: Client startet eine Aufgabe auf dem Server. Server startet eine Aufgabe auf einem oder mehreren Clients. Es werden keine SchedulerXX.RUN -Dateien benötigt. Voraussetzungen Auf allen beteiligten Systemen muss BWScheduler mindestens in Programmversion 5.31 installiert sein. Alle beteiligten BWScheduler müssen über das Netzwerk erreichbar sein. Auf dem Server muss der eingestellte TCP-Port freigegeben sein. Standard ist Port 9443 . Die Uhren der beteiligten Windows-Systeme sollten korrekt eingestellt sein. Die auszuführende Zielaufgabe muss auf der Gegenstelle vorhanden und aktiviert sein. Die Zielaufgabe muss über die Einstellung REST-API Ausführung ausdrücklich freigegeben sein. Zielaufgaben müssen Hauptaufgaben sein. Unteraufgaben können nicht direkt über die REST-API gestartet werden. Das Konto des BWSchedulers benötigt weiterhin alle Rechte, die von der Zielaufgabe benötigt werden. Verschlüsselung und Zertifikate Der gesamte Datenverkehr wird über TLS 1.2 verschlüsselt. Internes Zertifikat Wenn unter SSL-PFX Zertifikat keine Datei angegeben wird, erstellt und verwendet der Server automatisch ein internes Zertifikat. Dieses Zertifikat dient ausschließlich zur Verschlüsselung der Verbindung zwischen den BWSchedulern. Für die Standardverbindung zwischen BWScheduler-Installationen muss daher kein Zertifikat bereitgestellt werden. Eigenes PFX-Zertifikat Optional kann auf dem Server ein eigenes PFX-Zertifikat hinterlegt werden: SSL-PFX Zertifikat: vollständiger Pfad zur PFX-Datei SSL-PFX Zertifikat Kennwort: Kennwort der PFX-Datei Das PFX-Zertifikat muss einen privaten Schlüssel enthalten. Der im Zertifikat verwendete Name sollte zur eingestellten Serveradresse passen. Bei einem von einer vertrauenswürdigen Zertifizierungsstelle ausgestellten Zertifikat ist auf den Clients keine Ausnahme erforderlich. Ungültige Zertifikate erlauben Die Einstellung Erlaube ungültige SSL-Zertifikate betrifft die Prüfung auf der Clientseite. Deaktiviert: Zertifikat und Servername müssen gültig sein. Das automatisch verwendete interne BWScheduler-Zertifikat wird ebenfalls akzeptiert. Aktiviert: Zertifikatsfehler werden ignoriert. Sicherheitshinweis: Aktivieren Sie diese Option nur in einem kontrollierten und vertrauenswürdigen Netzwerk. Authentifizierung Unter Authentifizierungsart stehen drei Möglichkeiten zur Verfügung: Einstellung Bedeutung Keine Für Aufgaben mit der Freigabe „Gemäß globaler Authentifizierung“ wird kein Schlüssel verlangt. API-Key Auf Server und Clients muss derselbe kundenspezifische API-Key eingestellt sein. Nur eigene Produkte Freigegebene PHX-Produkte weisen sich automatisch mit ihrer Produktkennung und ihrem internen Produktschlüssel aus. Eine Kundeneingabe ist nicht erforderlich. Die empfohlene Einstellung für eine Verbindung zwischen BWSchedulern ist Nur eigene Produkte . Der kundenspezifische API-Key wird nur bei der Authentifizierungsart API-Key benötigt. Er sollte ausreichend lang und zufällig sein und darf nicht an unberechtigte Personen weitergegeben werden. Server einrichten Öffnen Sie die Einstellungen und wechseln Sie zum Bereich REST-API . Einstellung Wert Aktiv aktiviert Betriebsart Server IP-Adresse des REST-Servers kann auf dem Server leer bleiben Port 9443 oder ein eigener freier Port SSL-PFX Zertifikat optional SSL-PFX Zertifikat Kennwort nur bei Verwendung einer PFX-Datei Erlaube ungültige SSL-Zertifikate auf dem Server ohne Bedeutung Authentifizierungsart empfohlen: Nur eigene Produkte API-Key nur bei Authentifizierungsart API-Key Speichern Sie die Einstellungen und starten Sie den BWScheduler neu beziehungsweise laden Sie die Einstellungen neu. Der Server nimmt verschlüsselte Verbindungen auf allen lokalen Netzwerkadressen über den eingestellten Port an. Stellen Sie sicher, dass die Windows-Firewall eingehende Verbindungen für diesen Port erlaubt. Client einrichten Öffnen Sie auf jedem Client den Bereich REST-API . Einstellung Wert Aktiv aktiviert Betriebsart Client IP-Adresse des REST-Servers IP-Adresse oder DNS-Name des Servers Port derselbe Port wie auf dem Server SSL-PFX Zertifikat normalerweise leer SSL-PFX Zertifikat Kennwort normalerweise leer Erlaube ungültige SSL-Zertifikate nur bei Bedarf aktivieren Authentifizierungsart dieselbe Einstellung wie am Server API-Key bei Authentifizierungsart API-Key derselbe Wert wie am Server Beispiele für die Serveradresse: 192.168.1.20 scheduler.firma.local https://scheduler.firma.local Der Client baut ausschließlich eine ausgehende Verbindung zum Server auf. Auf dem Client muss deshalb kein eingehender REST-Port geöffnet werden. Als Clientname wird automatisch der Windows-Rechnername verwendet. Dieser Name wird benötigt, wenn der Server einen Auftrag nur an einen bestimmten Client senden soll. Aufgabe auf der Gegenstelle ausführen Erstellen Sie über Neu die Aufgabe: REST-API Aufgabe auf Gegenstelle ausführen Die Aufgabe wird mit folgenden Werten vorbereitet: Einstellung Wert Aufgabenart Funktionsaufruf App $RESTAPI-EXECUTE AppParameter Execute=22 AppParameter2 leer Intervall 0 Passen Sie die Aufgabennummer, Ausführungszeit, Wochentage und das erlaubte Zeitfenster an den gewünschten Ablauf an. Client startet eine Aufgabe auf dem Server Auf dem Client wird eine Aufgabe mit folgendem AppParameter angelegt: Execute=22 Wird diese Aufgabe auf dem Client ausgeführt, sendet er den Auftrag verschlüsselt an den Server. Der Server plant dort die aktivierte Hauptaufgabe mit der Scheduler-ID 22 ein. Die Zielaufgabe auf dem Server muss vorhanden, aktiviert, als Hauptaufgabe eingerichtet und über REST-API Ausführung freigegeben sein. REST-Freigabe der Zielaufgabe Jede Zielaufgabe besitzt die Einstellung REST-API Ausführung . Standardmäßig ist eine Aufgabe nicht über REST erreichbar. Einstellung Verhalten Nicht über REST ausführbar REST-Aufrufe werden immer abgelehnt. Dies ist der Standardwert. Gemäß globaler Authentifizierung Es gilt die im Bereich REST-API eingestellte Authentifizierungsart. Nur durch BWScheduler Die Aufgabe darf ausschließlich von einem automatisch erkannten BWScheduler ausgelöst werden. Ohne Authentifizierung Die Aufgabe darf ohne Schlüssel ausgelöst werden. Diese Einstellung nur gezielt verwenden. Die Freigabe wird auf der Seite eingestellt, auf der die Zielaufgabe tatsächlich ausgeführt wird. Für eine reine Sendeaufgabe mit $RESTAPI-EXECUTE ist keine eingehende REST-Freigabe erforderlich. Zusammenspiel der Einstellungen REST-API Ausführung der Zielaufgabe Globale Einstellung Ergebnis Nicht über REST ausführbar beliebig Die Aufgabe wird immer abgelehnt. Gemäß globaler Authentifizierung Keine Die Aufgabe kann ohne Schlüssel gestartet werden. Gemäß globaler Authentifizierung API-Key Ein gültiger kundenspezifischer API-Key ist erforderlich. Gemäß globaler Authentifizierung Nur eigene Produkte Ein gültig erkanntes PHX-Produkt ist erforderlich. Nur durch BWScheduler beliebig Nur ein erkannter BWScheduler darf die Aufgabe starten. Ohne Authentifizierung beliebig Die Aufgabe kann ohne Schlüssel gestartet werden. Empfohlene Konfigurationen BWScheduler mit BWScheduler verbinden Auf Server und Clients: Einstellung Wert Authentifizierungsart Nur eigene Produkte API-Key leer Bei der auszuführenden Zielaufgabe: REST-API Ausführung: Nur durch BWScheduler Diese Einstellung erfordert keine manuelle Schlüsselpflege durch den Kunden. Externes System mit API-Key Auf dem REST-Server: Einstellung Wert Authentifizierungsart API-Key API-Key langer, zufälliger und geheimer Wert Bei der auszuführenden Zielaufgabe: REST-API Ausführung: Gemäß globaler Authentifizierung Das externe System muss den eingestellten API-Key bei jedem Auftrag mitsenden. Einzelne Aufgabe ohne Authentifizierung Bei der betreffenden Zielaufgabe: REST-API Ausführung: Ohne Authentifizierung Diese Freigabe gilt unabhängig von der globalen Authentifizierungsart. Verwenden Sie sie nur für gezielt ausgewählte Aufgaben und begrenzen Sie den Netzwerkzugriff zusätzlich über die Windows-Firewall. Wichtig: Verwenden Sie für sensible Wartungs-, Programmstart- oder Beendigungsaufgaben keine anonyme Freigabe. Server startet eine Aufgabe auf allen Clients Auf dem Server wird eine Aufgabe mit folgendem AppParameter angelegt: Execute=22 Der Server stellt den Auftrag allen Clients bereit, die sich seit dem Start des Servers bei ihm gemeldet haben. Jeder dieser Clients plant seine lokale Aufgabe mit der Scheduler-ID 22 ein. Die Scheduler-ID bezeichnet immer die Aufgabe auf der jeweiligen Gegenstelle. Die Aufgaben dürfen auf Server und Clients unterschiedliche Bezeichnungen oder Inhalte besitzen. Server startet eine Aufgabe auf einem bestimmten Client Soll nur ein bestimmter Client angesprochen werden, wird dessen Windows-Rechnername ergänzt: Client=PC-BUCHHALTUNG&Execute=22 Damit wird die Aufgabe 22 ausschließlich für den Client PC-BUCHHALTUNG bereitgestellt. Der Clientname muss dem Windows-Rechnernamen des Zielsystems entsprechen. Groß- und Kleinschreibung sind dabei nicht relevant. Mehrere Clients Mehrere Clients können denselben Server verwenden. Dabei gibt es zwei Möglichkeiten: Nur Execute=22 : Auftrag wird an alle beim Server bekannten Clients verteilt. Client=RECHNERNAME&Execute=22 : Auftrag wird nur für den angegebenen Client bereitgestellt. Ein Auftrag für einen bestimmten Client kann bereits bereitgestellt werden, bevor dieser wieder verbunden ist. Er wird beim nächsten erfolgreichen Abruf übernommen, solange der Server zwischenzeitlich nicht neu gestartet wurde. Direkter REST-Aufruf am Server Der Server nimmt einen Ausführungsauftrag unter folgender Adresse entgegen: https://SERVER:9443/api/scheduler/execute Ausführungsaufträge können mit POST oder direkt über die Adresszeile eines Browsers mit GET übermittelt werden. Für Programme und automatisierte Schnittstellen wird weiterhin POST empfohlen. Execute=22 wird dabei als formularcodierter Inhalt gesendet. Für einen direkten Browseraufruf stehen zwei Schreibweisen zur Verfügung: https://SERVER:9443/api/scheduler/execute=22 https://SERVER:9443/api/scheduler/execute?Execute=22 Bei erfolgreicher Annahme zeigt der Browser OK Execute=22 an. Ein erneutes Laden der Seite löst die Aufgabe erneut aus. Die Antwort darf deshalb nicht als regelmäßige Startseite oder automatische Browserprüfung verwendet werden. Bei der Authentifizierungsart API-Key wird der Schlüssel im HTTP-Header übergeben: X-PHX-API-Key: IHR_API_KEY Bei Nur eigene Produkte werden Produktkennung, Schlüsselkennung und Produktschlüssel automatisch durch das aufrufende PHX-Produkt übergeben. Eine manuelle Eingabe ist nicht vorgesehen. Ein normaler Aufruf über die Browser-Adresszeile sendet keine PHX-Authentifizierungsheader. Er funktioniert deshalb nur in einem der folgenden Fälle: Die Zielaufgabe ist unter REST-API Ausführung ausdrücklich auf Ohne Authentifizierung eingestellt. Die Zielaufgabe verwendet Gemäß globaler Authentifizierung und die globale Authentifizierungsart steht auf Keine . API-Keys werden bewusst nicht als URL-Parameter unterstützt, da URLs im Browser-Verlauf sowie in Proxy- und Serverprotokollen gespeichert werden können. Zur Verfügbarkeitsprüfung steht folgende Adresse bereit: https://SERVER:9443/api/scheduler/status Eine erfolgreiche Prüfung liefert OK zurück. Sicherheitshinweis: Ein Browseraufruf verändert den Ausführungszustand des Schedulers. Verwenden Sie diese Möglichkeit nur für ausdrücklich freigegebene Aufgaben und begrenzen Sie den Zugriff auf den REST-Port über die Windows-Firewall auf die vorgesehenen Clientsysteme beziehungsweise das interne Netzwerk. Verhalten der Zielaufgabe Ein angenommener REST-Auftrag verhält sich weitgehend wie ein Auftrag über eine SchedulerXX.RUN -Datei: Die Zielaufgabe wird beim nächsten Scheduler-Durchlauf eingeplant. Die Aufgabe muss aktiviert sein. Unteraufgaben können nicht direkt gestartet werden. Die eingestellte modale Gruppe und der Doppelstartschutz bleiben wirksam. Eine bereits laufende oder bereits eingeplante Aufgabe wird nicht nochmals parallel gestartet. Eine aktive Wartungs- oder NoLock-Sperre kann die Ausführung weiterhin zurückhalten. Die Zeitplanung der sendenden $RESTAPI-EXECUTE -Aufgabe bestimmt, wann der Auftrag übertragen wird. Die feste Ausführungszeit der Zielaufgabe wird durch den angenommenen Remote-Auftrag nicht abgewartet. Typischer Einrichtungsablauf Prüfen, ob auf allen beteiligten Systemen mindestens BWScheduler-Programmversion 5.31 installiert ist. Eine BWScheduler-Installation als Server konfigurieren. Port 9443 oder den gewählten Port in der Server-Firewall freigeben. Weitere Installationen als Clients konfigurieren. Verbindung im Protokoll kontrollieren. Auf der Gegenstelle eine ungefährliche Testaufgabe anlegen und aktivieren. Bei der Zielaufgabe die gewünschte Einstellung unter REST-API Ausführung auswählen. Auf der sendenden Seite eine $RESTAPI-EXECUTE -Aufgabe mit der entsprechenden Scheduler-ID erstellen. Auftrag zunächst manuell ausführen. Ausführung und Ergebnis auf beiden Seiten kontrollieren. Erst danach die gewünschte Zeitplanung aktivieren. Fehlerprüfung Server ist nicht erreichbar Prüfen Sie: REST-API ist auf beiden Seiten aktiviert. Server verwendet die Betriebsart Server . Client verwendet die Betriebsart Client . Serveradresse und Port stimmen überein. Windows-Firewall erlaubt den Port. Der Serverprozess läuft. Zertifikatsfehler Prüfen Sie: Stimmt der DNS-Name mit dem eigenen Zertifikat überein? Ist das Zertifikat noch gültig? Ist die Zertifikatskette auf dem Client vertrauenswürdig? Ist das PFX-Kennwort korrekt? Die Option zum Ignorieren von Zertifikatsfehlern sollte nur vorübergehend zur Eingrenzung des Problems verwendet werden. Aufgabe wird nicht ausgeführt Prüfen Sie: Ist die angegebene Scheduler-ID auf der Gegenstelle vorhanden? Ist die Zielaufgabe aktiviert? Handelt es sich um eine Hauptaufgabe? Ist die Zielaufgabe über REST-API Ausführung passend freigegeben? Stimmen Authentifizierungsart und gegebenenfalls API-Key auf beiden Seiten überein? Läuft die Aufgabe bereits oder wartet sie auf ihre modale Gruppe? Ist eine Wartungs- oder NoLock-Sperre aktiv? Ist im AppParameter tatsächlich Execute=Zahl eingetragen? Bestimmter Client erhält den Auftrag nicht Prüfen Sie: Entspricht der Wert hinter Client= exakt dem Windows-Rechnernamen? Hat sich der Client bereits erfolgreich beim Server gemeldet? Wurde der Server nach dem Bereitstellen des Auftrags neu gestartet? Funktionsaufrufe im BWScheduler Überblick Der BWScheduler stellt integrierte Funktionen bereit, die über einen Namen mit vorangestelltem $ ausgewählt werden. Damit können beispielsweise NoLock-Dateien verwaltet, Dateien überwacht, Windows-Dienste gesteuert oder Datenimporte gestartet werden. Diese Dokumentation richtet sich an Anwender und Administratoren. Vor dem Einsatz von Funktionen, die Dateien, Prozesse, Dienste oder Benutzersitzungen beenden, sollte die Aufgabe zuerst in einer Testumgebung geprüft werden. Allgemeine Einrichtung Für die nachfolgend beschriebenen Funktionen wird bei der Aufgabe grundsätzlich Folgendes eingestellt: Einstellung Empfohlener Wert Aktiv aktiviert Aufgabenart Funktionsaufruf App gewünschte $ -Funktion Wochentag gewünschte Ausführungstage Ausführungsintervall meistens Täglich Ausführungsbedingung keine Einschränkung, sofern keine besondere Prüfung benötigt wird Modale Gruppe passend zum betroffenen System oder Arbeitsablauf Einmalige tägliche Ausführung Für eine einmalige Ausführung zu einer festen Uhrzeit: Intervall: 0 Ausführungszeit: gewünschte Startzeit Zeit von: Beginn des erlaubten Zeitraums Zeit bis: Ende des erlaubten Zeitraums Beispiel: Einstellung Wert Zeit von 05:30 Ausführungszeit 05:31 Zeit bis 06:00 Intervall 0 Die Ausführungszeit muss innerhalb des erlaubten Zeitraums liegen. Für einen Zeitraum innerhalb desselben Tages muss Zeit bis später als Zeit von sein. Wiederkehrende Ausführung Für eine wiederkehrende Ausführung: Intervall: Abstand in Minuten, beispielsweise 15 Ausführungszeit: leer lassen Zeit von / Zeit bis: Zeitraum, in dem die Wiederholungen erlaubt sind AppParameter und AppParameter2 Je nach Funktion werden zusätzliche Angaben benötigt: AppParameter: meistens Dateipfad, Ordnerpfad oder eine Funktionsoption AppParameter2: zusätzliche Angabe, beispielsweise Dateialter oder Zielaufgabe Dienstname: Name eines Windows-Dienstes oder Prozesses Nicht benötigte Felder bleiben leer. Kurzreferenz Funktion Zweck AppParameter AppParameter2 Dienstname $CREATENOLOCKINI NoLock.INI erstellen leer leer leer $DELETENOLOCKINI Vom Scheduler erstellte NoLock.INI entfernen leer leer leer $DELETEALLNOLOCKINI Alle gefundenen NoLock.INI entfernen leer leer leer $AUSLOGGEN NoLock.INI vorübergehend setzen leer leer leer $BÜROWARE-BEENDEN ERP-Suite-Prozesse und zugehörige Dienste beenden optional: Prozesslistendatei leer leer $WEBWARE-BEENDEN Webware-Prozesse und zugehörige Dienste beenden optional: Prozesslistendatei leer leer $PROZESSE-BEENDEN Mehrere definierte Prozesse oder Dienste beenden optional: Prozesslistendatei leer leer $PROZESSE-STARTEN Mehrere definierte Prozesse oder Dienste starten optional: Prozesslistendatei leer leer $CREATEFILE Datei erstellen oder ersetzen vollständiger Dateipfad leer leer $DELETEFILE Einzelne Datei löschen vollständiger Dateipfad leer leer $DELETEFILES Mehrere ältere Dateien löschen Pfad mit Dateimaske Alter in Tagen leer $DATEIÜBERWACHUNG Dateiänderung überwachen und Aufgabe einplanen vollständiger Dateipfad RUN(n) leer $DTAIMPORT DTA-Dateien importieren Importordner Bediener und optional Mandant leer $NETZWERKLAUFWERK-VERBINDEN Hinterlegte Netzlaufwerke verbinden leer leer leer $STARTSERVICE Windows-Dienst starten leer leer Dienstname $STOPSERVICE Windows-Dienst stoppen leer leer Dienstname $RESTARTSERVICE Windows-Dienst neu starten leer leer Dienstname $KILLPROCESS Einzelnen Prozess sofort beenden leer leer Prozessname $RDS-LOGOFF Remotedesktop-Sitzungen abmelden Option, z. B. /all leer leer $SOFTWAREAUDIT ERP-Suite Software-Audit durchführen leer leer leer NoLock- und Wartungsfunktionen $CREATENOLOCKINI Erstellt im eingestellten ERP-Suite-Programmpfad eine NoLock.ini . Dadurch werden ERP-Suite und zugehörige Dienste in den vorgesehenen Wartungszustand versetzt. Solange die NoLock-Datei vorhanden ist, werden normale Scheduler-Aufgaben angehalten. Empfohlene Einstellungen: Einstellung Wert Aufgabenart Funktionsaufruf App $CREATENOLOCKINI AppParameter leer Intervall 0 Zeit von 05:30 Ausführungszeit 05:31 Zeit bis 06:00 Modale Gruppe keine (Global) Voraussetzungen: Der globale ERP-Suite-Pfad muss richtig eingestellt und erreichbar sein. Das Benutzerkonto des BWSchedulers benötigt Schreibrechte im ERP-Suite-Ordner. Es sollte eine passende Aufgabe zum späteren Entfernen der NoLock-Datei vorhanden sein. $DELETENOLOCKINI Entfernt NoLock-Dateien, die vom BWScheduler selbst erstellt wurden. Fremd oder manuell angelegte NoLock-Dateien bleiben zum Schutz erhalten. Empfohlene Einstellungen: Einstellung Wert Aufgabenart Funktionsaufruf App $DELETENOLOCKINI AppParameter leer Intervall 0 Zeit von 05:30 Ausführungszeit 05:32 oder gewünschter Freigabezeitpunkt Zeit bis 06:00 oder passend zum Wartungsfenster Modale Gruppe keine (Global) Wird die NoLock-Datei für längere Wartungsarbeiten benötigt, muss die Löschaufgabe entsprechend später eingeplant werden. $DELETEALLNOLOCKINI Entfernt alle vom BWScheduler gefundenen NoLock-Dateien – unabhängig davon, wodurch sie angelegt wurden. Achtung: Diese Funktion kann auch eine bewusst manuell gesetzte Wartungssperre entfernen. Sie sollte nur durch berechtigte Administratoren und nur für eindeutig definierte Wartungsabläufe verwendet werden. Empfohlene Einstellungen: Aufgabenart: Funktionsaufruf App: $DELETEALLNOLOCKINI AppParameter / AppParameter2: leer Modale Gruppe: keine (Global) Zeitpunkt: nur innerhalb eines kontrollierten Wartungsfensters $AUSLOGGEN Erstellt eine NoLock-Datei, wartet ungefähr 30 Sekunden und entfernt sie anschließend wieder. Die Funktion ist dafür vorgesehen, laufende ERP-Suite-Module zum geordneten Beenden beziehungsweise Abmelden aufzufordern. Empfohlene Einstellungen: App: $AUSLOGGEN AppParameter / AppParameter2: leer Intervall: 0 Modale Gruppe: keine (Global) Ausreichend Abstand zu nachfolgenden Aufgaben einplanen Beispiel: Ausführung um 23:00 innerhalb eines erlaubten Zeitraums von 19:30 bis 23:55. ERP-Suite- und Prozesssteuerung $BÜROWARE-BEENDEN Versetzt die ERP-Suite zunächst in den Wartungszustand, wartet ungefähr 30 Sekunden und beendet danach die vorgesehenen ERP-Suite-Prozesse und Dienste. Nach einer weiteren Kontrolle werden noch vorhandene Prozesse erneut beendet. Anschließend wird die vom Scheduler erstellte NoLock-Datei entfernt. Empfohlene Einstellungen: App: $BÜROWARE-BEENDEN AppParameter: Pfad zur vorgesehenen ERP-Suite-Prozesslistendatei oder leer für die Standardliste Intervall: 0 Modale Gruppe: keine (Global) Zeitfenster: außerhalb der normalen Arbeitszeit Achtung: Offene ERP-Suite-Sitzungen können beendet werden. Stimmen Sie die Ausführung mit den Anwendern ab und prüfen Sie die verwendete Prozessliste sorgfältig. $WEBWARE-BEENDEN Entspricht dem Ablauf von $BÜROWARE-BEENDEN , verwendet jedoch die für Webware vorgesehenen Prozesse und Dienste. Empfohlene Einstellungen: App: $WEBWARE-BEENDEN AppParameter: Pfad zur Webware-Prozesslistendatei oder leer für die Standardliste Intervall: 0 Modale Gruppe: keine (Global) Zeitfenster: außerhalb der normalen Nutzung $PROZESSE-BEENDEN Beendet die Einträge einer Prozesslistendatei. Nach einer kurzen Wartezeit wird erneut geprüft und ein zweiter Beendigungsversuch durchgeführt. Empfohlene Einstellungen: App: $PROZESSE-BEENDEN AppParameter: vollständiger Pfad zur Prozesslistendatei; leer verwendet die allgemeine Standardliste Intervall: 0 Modale Gruppe: eigene Farbgruppe für den betroffenen Arbeitsablauf oder Global Achtung: Prüfen Sie jeden Eintrag der Prozessliste. Eine falsche Liste kann nicht vorgesehene Anwendungen oder Dienste beenden. $PROZESSE-STARTEN Startet die in einer Prozesslistendatei hinterlegten Prozesse und Dienste. Empfohlene Einstellungen: App: $PROZESSE-STARTEN AppParameter: vollständiger Pfad zur Prozesslistendatei; leer verwendet die allgemeine Standardliste Netzwerklaufwerk verbinden: aktivieren, wenn Programme oder Dateien über ein Laufwerk im Netzwerk erreicht werden Modale Gruppe: dieselbe Gruppe wie die zugehörige Beendigungs- oder Wartungsaufgabe Planen Sie den Start erst nach Abschluss aller Wartungs- und Sicherungsarbeiten ein. $KILLPROCESS Beendet alle laufenden Prozesse mit dem angegebenen Prozessnamen sofort. Empfohlene Einstellungen: Einstellung Wert App $KILLPROCESS Dienstname Prozessname ohne .exe , beispielsweise bwwin32 AppParameter leer Intervall 0 Modale Gruppe passend zum betroffenen System Achtung: Diese Funktion ermöglicht kein geordnetes Speichern oder Beenden. Sie sollte nur verwendet werden, wenn ein normales Beenden nicht möglich oder ausdrücklich unerwünscht ist. Windows-Dienste steuern $STARTSERVICE Startet den unter Dienstname angegebenen Windows-Dienst. Läuft der Dienst bereits, bleibt er unverändert. $STOPSERVICE Stoppt den unter Dienstname angegebenen Windows-Dienst. Ist der Dienst bereits beendet, ist keine weitere Aktion erforderlich. $RESTARTSERVICE Stoppt den angegebenen Windows-Dienst und startet ihn anschließend erneut. Der BWScheduler wartet auf das Beenden des Dienstes und versucht danach den Start. Empfohlene Einstellungen für alle drei Dienstfunktionen: Einstellung Wert Aufgabenart Funktionsaufruf App $STARTSERVICE , $STOPSERVICE oder $RESTARTSERVICE Dienstname Anzeigename oder Dienstname des gewünschten Windows-Dienstes AppParameter / AppParameter2 leer Intervall normalerweise 0 Modale Gruppe eine gemeinsame Farbe für zusammengehörige Dienste Voraussetzungen: Der angegebene Dienst muss auf demselben Windows-System vorhanden sein. Das Benutzerkonto des BWSchedulers benötigt die Berechtigung zum Steuern des Dienstes. Bei abhängigen Diensten muss eine sinnvolle Reihenfolge und ausreichend Zeitabstand eingeplant werden. Dateifunktionen $CREATEFILE Erstellt eine Datei am angegebenen Ort. Eine bereits vorhandene Datei wird ersetzt. Die Funktion eignet sich insbesondere zum Erzeugen von Steuer- oder Triggerdateien. Empfohlene Einstellungen: App: $CREATEFILE AppParameter: vollständiger Dateipfad, beispielsweise C:\ERP\Export\run.ini AppParameter2: leer Netzwerklaufwerk verbinden: aktivieren, wenn ein hinterlegtes Netzlaufwerk verwendet wird Der Zielordner muss bereits vorhanden sein und das verwendete Konto benötigt Schreibrechte. $DELETEFILE Löscht genau die unter AppParameter angegebene Datei. Empfohlene Einstellungen: App: $DELETEFILE AppParameter: vollständiger Dateipfad AppParameter2: leer Modale Gruppe: dieselbe Gruppe wie eine zugehörige Erstellungs- oder Verarbeitungsaufgabe Achtung: Kontrollieren Sie den vollständigen Pfad vor der Aktivierung. Die gelöschte Datei wird nicht in den Windows-Papierkorb verschoben. $DELETEFILES Löscht mehrere Dateien eines bestimmten Musters, sobald sie das angegebene Alter erreicht haben. Beispiel: Einstellung Wert App $DELETEFILES AppParameter C:\ERP\Log\*.log AppParameter2 30 In diesem Beispiel werden passende Protokolldateien berücksichtigt, die älter als 30 Tage sind. Hinweise: Verwenden Sie im AppParameter einen vollständigen Ordnerpfad mit Dateimaske. Prüfen Sie die Dateimaske besonders sorgfältig. Der Ordner muss erreichbar sein. Verwenden Sie möglichst ein eigenes, klar begrenztes Archiv- oder Protokollverzeichnis. Dateiüberwachung $DATEIÜBERWACHUNG Überwacht eine bestimmte Datei auf Änderungen. Wird eine Änderung erkannt, plant der BWScheduler eine andere Aufgabe zur Ausführung ein. Empfohlene Einstellungen der Überwachungsaufgabe: Einstellung Wert Aufgabenart Funktionsaufruf App $DATEIÜBERWACHUNG AppParameter vollständiger Pfad der zu überwachenden Datei AppParameter2 RUN(n) mit der Nummer der Zielaufgabe Intervall 0 Zeit von / Zeit bis Zeitraum, in dem Änderungen verarbeitet werden dürfen Beispiel: AppParameter: C:\ERP\Import\auftrag.dat AppParameter2: RUN(5) Damit wird bei einer Änderung der Datei die Aufgabe 5 eingeplant. Voraussetzungen für die Zielaufgabe: Die Zielaufgabe muss aktiviert sein. Die Zielaufgabe muss Intervall 0 verwenden. Überwachungsaufgabe und Zielaufgabe dürfen nicht dieselbe Aufgabe sein. Unter Mindestwartezeit bei Triggerausführung sollte ein ausreichender Abstand eingestellt werden, damit mehrere unmittelbar aufeinanderfolgende Dateiänderungen nicht zu wiederholten Starts führen. Bei Netzwerkpfaden muss der Pfad aus dem Ausführungskonto des BWSchedulers erreichbar sein. DTA-Datenimport $DTAIMPORT Importiert .dta -Dateien aus einem angegebenen Ordner. Erfolgreich verarbeitete Dateien werden in den Unterordner Importiert verschoben. Empfohlene Einstellungen: Einstellung Wert App $DTAIMPORT AppParameter vollständiger Pfad des DTA-Importordners AppParameter2 Bedienernummer und optional Mandant, z. B. 000 000001 Intervall z. B. 15 Minuten Ausführungszeit bei Intervallausführung leer Modale Gruppe eigene Gruppe für den jeweiligen Importbereich Alternativ können Bedienernummer, Mandantennummer und Importmodul zentral im Bereich Datenimport eingestellt werden. Zu prüfen sind: Importordner ist vorhanden und beschreibbar. ERP-Suite-Programmpfad ist korrekt. Bedienernummer und Mandantennummer sind gültig. Gewünschtes Importmodul ist ausgewählt: WAWI, FIBU oder automatische Erkennung über den Dateinamen. Bei automatischer Erkennung sollte der Dateiname eindeutig WAWI oder FIBU enthalten. Während einer aktiven NoLock-Sperre beziehungsweise Wartung wird kein DTA-Import durchgeführt. Netzlaufwerke verbinden $NETZWERKLAUFWERK-VERBINDEN Verbindet die im Bereich Netzwerk hinterlegten Netzlaufwerke. Für bis zu drei Verbindungen können eingestellt werden: Server-Pfad, beispielsweise \\Server\Freigabe Zugewiesener Laufwerksbuchstabe Benutzer Kennwort Persistente Verbindung Empfohlene Aufgabeneinstellungen: App: $NETZWERKLAUFWERK-VERBINDEN AppParameter / AppParameter2: leer Zeitpunkt: vor allen Aufgaben, die diese Laufwerke benötigen Modale Gruppe: passend zu den abhängigen Aufgaben Die Einstellung Netzwerklaufwerk verbinden innerhalb einer einzelnen Aufgabe kann zusätzlich verwendet werden, damit die hinterlegten Verbindungen unmittelbar vor dieser Aufgabe hergestellt werden. Remotedesktop-Sitzungen abmelden $RDS-LOGOFF Meldet Remotedesktop-Benutzersitzungen entsprechend der gewählten Option ab. AppParameter Wirkung leer getrennte Sitzungen abmelden /all alle vorgesehenen Remotedesktop-Sitzungen abmelden /U=benutzername den angegebenen Benutzer abmelden Beispiel: /U=m.mustermann Empfohlene Einstellungen: App: $RDS-LOGOFF Intervall: 0 Modale Gruppe: keine (Global) Zeitfenster: außerhalb der normalen Arbeitszeit Achtung: Nicht gespeicherte Benutzerdaten können verloren gehen. Informieren Sie betroffene Benutzer vor einer automatischen Abmeldung. Bestimmte administrative Benutzer können über die Datei rds-logoff-blacklist.txt von der automatischen Abmeldung ausgenommen werden. Änderungen an dieser Liste sollten nur durch die zuständige Administration erfolgen. ERP-Suite Software-Audit $SOFTWAREAUDIT Erfasst die vorgesehenen ERP-Suite-Systeminformationen und führt den eingerichteten Datenabgleich durch. Empfohlene Einstellungen: Verwenden Sie vorzugsweise die vorbereitete Aufgabe ERP-Suite Software Audit . Hinterlegen Sie bei der Einrichtung die korrekte Kundennummer und die vom Anbieter bereitgestellte Freigabe. Stellen Sie sicher, dass der ERP-Suite-Pfad korrekt ist. Planen Sie die Aufgabe einmal täglich außerhalb der Hauptarbeitszeit ein. AppParameter / AppParameter2: leer Diese Funktion sollte nur verwendet werden, wenn der Software-Audit für das jeweilige Kundensystem eingerichtet und freigegeben wurde. Empfohlene Reihenfolge für ein Wartungsfenster Ein möglicher Ablauf ist: Mit $AUSLOGGEN Benutzer zum Beenden der ERP-Suite-Sitzungen auffordern. Mit $CREATENOLOCKINI den Wartungszustand aktivieren. Mit $BÜROWARE-BEENDEN , $WEBWARE-BEENDEN oder $PROZESSE-BEENDEN benötigte Komponenten beenden. Sicherung, Aktualisierung oder andere Wartungsaufgabe durchführen. Mit $PROZESSE-STARTEN oder $STARTSERVICE benötigte Komponenten wieder starten. Mit $DELETENOLOCKINI den Wartungszustand aufheben. Verwenden Sie für den gesamten Ablauf dieselbe modale Farbgruppe oder keine (Global) , wenn während der Wartung keine andere modale Aufgabe laufen darf. Planen Sie zwischen den einzelnen Schritten ausreichend Zeit ein. Sicherheits- und Prüfhinweise Vor der Aktivierung einer neuen Funktionsaufgabe: Pfade, Dateimasken, Dienstnamen und Prozessnamen kontrollieren. Berechtigungen des Kontos prüfen, unter dem der BWScheduler ausgeführt wird. Zeitfenster und Wochentage kontrollieren. Bei Intervall 0 eine gültige Ausführungszeit innerhalb des Zeitfensters eintragen. Bei Intervall größer 0 die Ausführungszeit leer lassen. Eine geeignete modale Gruppe auswählen. Kritische Funktionen zunächst manuell in einer Testumgebung ausführen. Nach der Ausführung die Aufgabenanzeige und das Protokoll kontrollieren. Besondere Vorsicht ist bei $DELETEALLNOLOCKINI , $DELETEFILE , $DELETEFILES , $KILLPROCESS , $PROZESSE-BEENDEN , $BÜROWARE-BEENDEN , $WEBWARE-BEENDEN und $RDS-LOGOFF erforderlich. Installieren des PowerBI Servers über den FlowManager Der Power BI Server muss als Dienst über den FlowManager installiert werden. Parameter: wwwin64.exe User Passwort /F Beispiel: wwwin64.exe 510 510 /F Es ist Folgendes zu beachten: Verzögerter Start des Dienstes: Aktivieren Berechtigungen prüfen! (Hat der Dienstuser auch genügend Berechtigungen im ERP-Suite-Ordner) Kein Neustart bei Dienstfehlern (das schlägt sich mit der NoLock.ini, wenn der Dienst aufgrund dieser beendet wird) Abhängigkeit des Dienstes zur ZEN-Datenbank einfügen! Modale Gruppen im BWScheduler Überblick Modale Gruppen steuern, welche modalen Aufgaben gleichzeitig ausgeführt werden dürfen. Dadurch lassen sich Aufgaben voneinander trennen, die nicht parallel laufen sollen, während unabhängige Aufgaben weiterhin gleichzeitig gestartet werden können. Die Zuordnung erfolgt direkt in den Einstellungen der jeweiligen Aufgabe. Zur besseren Übersicht wird die gewählte Gruppe außerdem in der Aufgabenliste mit ihrer entsprechenden Farbe angezeigt. Grundprinzip Für modale Aufgaben gelten folgende Regeln: Aufgaben derselben Farbgruppe werden nacheinander ausgeführt. Aufgaben unterschiedlicher Farbgruppen dürfen gleichzeitig ausgeführt werden. Die Einstellung keine wird als globale modale Gruppe behandelt. Eine globale modale Aufgabe darf nur starten, wenn keine andere modale Aufgabe läuft. Solange eine globale modale Aufgabe läuft, kann keine andere modale Aufgabe starten. Nicht-modale Aufgaben sind von der Gruppensteuerung nicht betroffen. Die Gruppenzuordnung erfolgt anhand der Scheduler-Aufgabe. Gleichlautende Prozess- oder Aufgabennamen haben daher keinen Einfluss auf die Unterscheidung. Verfügbare Gruppen Einstellung Anzeige Verhalten keine Global Sperrt sich mit allen modalen Aufgaben Rot Rot Sperrt nur andere Aufgaben der Gruppe Rot und globale Aufgaben Grün Grün Sperrt nur andere Aufgaben der Gruppe Grün und globale Aufgaben Blau Blau Sperrt nur andere Aufgaben der Gruppe Blau und globale Aufgaben Orange Orange Sperrt nur andere Aufgaben der Gruppe Orange und globale Aufgaben Gelb Gelb Sperrt nur andere Aufgaben der Gruppe Gelb und globale Aufgaben Violett Violett Sperrt nur andere Aufgaben der Gruppe Violett und globale Aufgaben Türkis Türkis Sperrt nur andere Aufgaben der Gruppe Türkis und globale Aufgaben Pink Pink Sperrt nur andere Aufgaben der Gruppe Pink und globale Aufgaben Braun Braun Sperrt nur andere Aufgaben der Gruppe Braun und globale Aufgaben Grau Grau Sperrt nur andere Aufgaben der Gruppe Grau und globale Aufgaben Beispiele Zwei Aufgaben in derselben Gruppe Aufgabe A und Aufgabe B sind beide der Gruppe Grün zugeordnet. Wenn Aufgabe A bereits läuft, wartet Aufgabe B, bis Aufgabe A beendet ist. Erst danach wird Aufgabe B gestartet. Aufgaben in unterschiedlichen Gruppen Aufgabe A ist der Gruppe Grün und Aufgabe B der Gruppe Blau zugeordnet. Beide Aufgaben dürfen gleichzeitig laufen, da sie unterschiedlichen Gruppen angehören. Aufgabe ohne Farbgruppe Aufgabe A verwendet die Einstellung keine (Global) . Aufgabe B ist der Gruppe Orange zugeordnet. Läuft Aufgabe B bereits, wartet Aufgabe A. Läuft Aufgabe A bereits, wartet Aufgabe B. Aufgabe A startet erst, wenn keine andere modale Aufgabe aktiv ist. Mehrere gleichnamige Aufgaben Mehrere Aufgaben dürfen denselben Namen besitzen. Für die Steuerung ist ausschließlich die bei der jeweiligen Scheduler-Aufgabe eingestellte modale Gruppe maßgeblich. Beispiel: „Datenabgleich“ in Gruppe Grün „Datenabgleich“ in Gruppe Blau Diese beiden Aufgaben dürfen gleichzeitig ausgeführt werden, obwohl ihre Bezeichnungen identisch sind. Modale Gruppe einstellen Öffnen Sie im BWScheduler die Einstellungen der gewünschten Aufgabe. Stellen Sie sicher, dass eine modale Aufgabenart ausgewählt ist. Wählen Sie unter Modale Gruppe die gewünschte Farbe oder keine aus. Speichern Sie die Einstellung. Kontrollieren Sie die Zuordnung in der Spalte Modale Gruppe der Aufgabenliste. Anzeige in der Aufgabenliste Die Spalte Modale Gruppe zeigt die aktuelle Zuordnung jeder Aufgabe: Bei einer Farbgruppe enthält die Zelle den Gruppennamen und wird passend eingefärbt. Bei keine wird Global angezeigt. Bei nicht-modalen Aufgaben wird ein Gedankenstrich angezeigt. Damit kann die Gruppenzuordnung auch bei gleichnamigen Aufgaben direkt kontrolliert werden. Empfohlene Zuordnung Verwenden Sie dieselbe Farbe für Aufgaben, die auf dieselben Daten, Dateien, Dienste oder sonstigen gemeinsam genutzten Ressourcen zugreifen und deshalb nicht gleichzeitig laufen sollen. Verwenden Sie unterschiedliche Farben, wenn die Aufgaben unabhängig voneinander sind und parallel ausgeführt werden dürfen. Verwenden Sie keine (Global) nur für Aufgaben, die während ihrer gesamten Laufzeit jede andere modale Ausführung ausschließen müssen. Hinweise zur Ausführung Eine wartende Aufgabe wird gestartet, sobald ihre Gruppe wieder verfügbar ist. Das Warten verändert nicht die eingestellte Startzeit oder das Intervall der Aufgabe. Werden mehrere Aufgaben derselben Gruppe gleichzeitig fällig, werden sie nacheinander abgearbeitet. Die Farbgruppe ist nur bei modalen Aufgaben wirksam. Änderungen an der Gruppenzuordnung gelten nach dem Speichern und Aktualisieren der Einstellungen. Kontrolle bei unerwartetem Verhalten Prüfen Sie bei unerwarteten Wartezeiten oder parallelen Ausführungen: Ist die Aufgabe als modale Aufgabe eingerichtet? Ist die erwartete Farbe in der Spalte Modale Gruppe sichtbar? Läuft bereits eine Aufgabe derselben Farbe? Läuft eine Aufgabe mit der Anzeige Global ? Haben zwei gleichnamige Aufgaben möglicherweise unterschiedliche Gruppenzuordnungen? Die Bezeichnung einer Aufgabe oder eines gestarteten Prozesses bestimmt nicht die Gruppenzugehörigkeit. Maßgeblich ist immer die Einstellung Modale Gruppe der jeweiligen Scheduler-Aufgabe. Wie kann ich alle Dienste einer Webware oder ERP-Suite beenden? Hierfür gibt es die Aufgabevorlagen: "Webware und alle Dienste beenden" und "ERP-Suite und alle Dienste beenden" Beim Erstellen der Aufgabe wird eine entsprechende Konfigurationsdatei im Programmpfad erstellt, welche die zu beendenden Dienste und Prozesse enthält. Diese Datei kann natürlich einen beliebigen Namen haben und darf auch in einem anderen Pfad liegen (mit Pfadangabe). Diese Liste enthält alle Dienste und Prozesse, welche beendet werden sollen. Abgearbeitet wird diese Liste von oben nach unten. Dienste: Dienstname oder Prozessname ohne .exe ; DIENST ; Wartezeit nach dem Beenden ; Dienstpfad (aktuell nicht verwendet) Beispiel: wws;DIENST;30 WEBWARE WWS-Produktiv22;DIENST;30 Dieser Eintrag beendet den Dienst wws (idealerweise wird hier der Displayname des Dienstes angegeben!) und wartet anschließend noch 30 Sekunden, bevor der nächste Dienst beendet wird. Prozesse: Prozessname ohne .exe ; Programmpfad (optional) Wenn ein Prozessname ohne Pfad angegeben wird, dann werden ALLE Prozesse im Speicher mit dieser Signatur beendet. Wichtig: Der Programmpfad wird als Teilstring geprüft und prüft den Pfad von links beginnend! Beispiel: wwwin64;X:\ERPSuite --> beendet alle Prozesse auch unter X:\ERPSuite_TEST wwwin64;X:\ERPSuite\ --> beendet nur Prozesse unter X:\ERPSuite\*... aber auch X:\ERPSuite\TEST1 und X:\ERPSuite\Test2 Wie läuft so ein Beenden ab? Zuerst wird der Inhalt der WWProzessliste.DAT oder der angegebenen Datei ausgelesen und geprüft. Hierbei werden die verschiedenen Parameter ausgelesen und die Dienste und Prozesse vom System geprüft, ob diese auch vorhanden sind. Anschließend wird eine NoLock.ini im Programmpfad der in den globalen Einstellungen hinterlegten ERP-Suite erstellt. Wenn andere Instanzen in komplett unterschiedlichen Pfaden beendet werden sollen, müsste das Anlegen der INI entweder über eine weitere Aufgabe erfolgen oder in einer Aufgabengruppe ausgeführt werden. Dann werden alle Dienste nach einander beendet und anschließend geprüft, ob die Prozesse noch im Speicher sind. Sollte sich ein Prozess nicht beenden lassen, wird anschließend versucht, diesen Prozess über den Kill-Befehl zu beenden. ACHTUNG: Hierfür darf im Dienst nicht eingestellt sein, dass dieser sich im Fehlerfall neu startet! Anschließend werden die gefundenen Prozesse beendet. Hier kann auch zur Sicherheit z. B. als Option auch noch der Prozess "wwr" angegeben werden. Welche Version wird hier empfohlen/benötigt? BWScheduler/FlowManger ab Version 5.07 Wie ist ein Prozess anzugeben? Prozesse müssen immer OHNE die Dateiendung angegeben werden. Wie sind Dienste anzugeben? Dienste werden am besten über den Dienstnamen beendet. Somit ist die Instanz immer korrekt zugeordnet. Alternativ kann auch der Prozessname angegeben werden. z. B. "wwr" oder "wws" Hierbei wird der ERSTE gefundene Dienst beendet, wo dieser Prozessname zutrifft. Sind immer alle Parameter in der WW/BWProzesslite.dat anzugeben? Nein, bei Diensten muss DIENST angegeben werden und bei Prozessen reicht der Prozessname ohne .exe Das Semikolon ist nur bei angegebenen Parametern erforderlich und kann weggelassen werden. Wichtig: Der WWS muss immer VOR dem WWR beendet werden! WWProzessliste.dat wws;DIENST SoftENGINE BWMail;DIENST;15;X:\ERPSuite\Produktiv wws32;DIENST wws32;DIENST wws64;DIENST wws64;DIENST wwwin32;x:\BWERP.700\ wwwin64 wwin32d wwin64d bwwin32 bwwin64 bwwin32d bwwin64d wwmail wwmail64 wwsyssrv wwdesk dbgdump wwdba32 wwdba64 wwdba wwflwsrv wwa wwad wwsvc32 wwsvc64 ERP Display (Zusätzliches ERP-Anzeigedisplay) Anzeigen von Belegpositionen (Artikelnummer, Bezeichnung, Menge) sowie Zusatzinformationen. ERPDisplay – Kundendisplay für Lieferschein- oder Belegpositionen ERPDisplay ist eine Windows-Hintergrundanwendung zur Darstellung von Lieferscheinpositionen auf einem separaten Kundendisplay. Die Anwendung ist für folgende Umgebung vorgesehen: Virtuos-Kundendisplay mit 1024 × 600 Pixeln Windows-Arbeitsplatz mit lokal angeschlossenem Kundendisplay ERP-System innerhalb einer RDP-Sitzung Datenaustausch über eine lokale XML-Datei oder eine SMB-/UNC-Netzwerkfreigabe Erforderliches Framework: .NET Framework 4.8 ERPDisplay läuft ohne sichtbares Hauptfenster. Die Bedienung erfolgt über ein Symbol im Windows-Infobereich neben der Uhr. Systemaufbau ERP-System in der RDP-Sitzung │ │ schreibt anzeige.xml ▼ SMB-/UNC-Netzwerkfreigabe │ │ Dateiänderung ▼ ERPDisplay auf dem lokalen Arbeitsplatz │ ▼ Lokal angeschlossenes Virtuos-Display Das Kundendisplay wird nicht in die RDP-Sitzung übernommen. Es bleibt Bestandteil des lokalen Windows-Arbeitsplatzes. Voraussetzungen Windows 10 oder Windows 11 .NET Framework 4.8 Virtuos-Display als zusätzlicher Windows-Bildschirm Bildschirmauflösung 1024 × 600 Pixel Windows-Anzeigemodus Diese Anzeigen erweitern Lesezugriff des lokalen Benutzers auf die XML-Datei Schreibzugriff des ERP-Benutzers auf die XML-Datei Installation ERPDisplay in einen lokalen Programmordner kopieren, beispielsweise: C:\Programme\ERPDisplay Prüfen, ob sich mindestens folgende Dateien im Programmordner befinden: ERPDisplay.exe ERPDisplay.exe.config anzeige.xml ERPDisplay.exe starten. Im Windows-Infobereich erscheint das ERPDisplay-Symbol. Über Erkannte Bildschirme prüfen, welcher Bildschirm das Kundendisplay ist. ERPDisplay verhindert den gleichzeitigen Start mehrerer Programminstanzen innerhalb derselben Windows-Sitzung. Automatischer Programmstart ERPDisplay sollte beim Anmelden des lokalen Windows-Benutzers gestartet werden. Win + R drücken. Folgenden Befehl eingeben: shell:startup Eine Verknüpfung zu ERPDisplay.exe in diesem Ordner anlegen. ERPDisplay sollte nicht als Windows-Dienst ausgeführt werden. Windows-Dienste laufen in der nicht interaktiven Session 0 und können das Kundendisplay im Benutzerdesktop nicht zuverlässig ansteuern. Bedienung über das Tray-Symbol Ein Rechtsklick auf das ERPDisplay-Symbol öffnet das Menü. Menüpunkt Funktion Anzeigedatei festlegen … Lokale XML-Datei oder UNC-Pfad auswählen bzw. eingeben Anzeigedatei neu laden Aktuelle Datei manuell erneut einlesen Erkannte Bildschirme Bildschirmindex, Gerätename und Auflösung anzeigen Darstellungsgröße Anzeige zwischen Normal, Mittel und Groß umschalten Beenden Displayfenster und ERPDisplay schließen Ein Doppelklick auf das Tray-Symbol liest die Anzeigedatei ebenfalls neu ein. Anzeigedatei festlegen Die Anzeigedatei kann auf drei Arten angegeben werden. Auswahl über das Tray-Menü Rechtsklick auf das ERPDisplay-Symbol. Anzeigedatei festlegen … auswählen. Lokalen Dateipfad oder UNC-Pfad eingeben. Mit OK bestätigen. Beispiel für einen UNC-Pfad: \\Fileserver\ERPDisplay\KASSE01\anzeige.xml Die Auswahl wird benutzerspezifisch gespeichert: %LocalAppData%\Firma2\ERPDisplay\Anzeigepfad.txt Diese Benutzereinstellung hat Vorrang vor der Einstellung in ERPDisplay.exe.config . Darstellungsgröße Die Größe der gesamten Kundenanzeige kann während des Betriebs über das Tray-Menü geändert werden: Darstellungsgröße ├── Normal ├── Mittel └── Groß Die Änderung wird sofort übernommen und benutzerspezifisch gespeichert unter: %LocalAppData%\Firma2\ERPDisplay\Anzeigegroesse.txt Modus Darstellung Maximal sichtbare Zeilen Normal Standard 8 Mittel Vergrößert 7 Groß Stark vergrößert 6 Der Standardwert wird in ERPDisplay.exe.config festgelegt: Gültige Konfigurationswerte sind Normal , Mittel und Gross . Konfiguration über ERPDisplay.exe.config Lokale Datei: UNC-Netzwerkpfad: Relativer Pfad neben ERPDisplay.exe: Empfohlene Netzwerkstruktur Für jeden Arbeitsplatz sollte ein eigenes Verzeichnis verwendet werden: \\Fileserver\ERPDisplay\ ├── KASSE01\anzeige.xml ├── KASSE02\anzeige.xml ├── KASSE03\anzeige.xml └── LAGER01\anzeige.xml Beispiel für Arbeitsplatz KASSE01 : \\Fileserver\ERPDisplay\KASSE01\anzeige.xml Das ERP muss die Kennung des aktuellen Arbeitsplatzes kennen und die XML-Datei in dessen Verzeichnis schreiben. Empfohlene Berechtigungen Benutzer/Gruppe Berechtigung Lokaler Arbeitsplatzbenutzer Lesen ERP-Anwendung bzw. ERP-Benutzer Lesen, Schreiben, Ändern Andere Arbeitsplatzbenutzer Kein Zugriff oder nur auf das eigene Verzeichnis XML-Format: Positionen anzeigen Attribute des Elements Anzeige Attribut Pflicht Bedeutung modus Ja Positionen oder Leer titel Nein Überschrift im oberen Bereich belegnummer Nein Lieferschein- oder Belegnummer information Nein Information für den Modus Leer Normale Positionszeile Attribut Bedeutung artikelnummer Artikelnummer bezeichnung Artikelbezeichnung menge Menge einschließlich optionaler Einheit Vollbreitenzeile Eine Vollbreitenzeile verwendet die gesamte Tabellenbreite. Sie eignet sich für Hinweise, Statusmeldungen oder zusätzliche Informationen. Fettformatierung Text innerhalb von [b] und [/b] wird fett dargestellt: Befestigungssatz [b]Premium[/b] Die Formatierung kann in Artikelnummer, Bezeichnung, Menge und Vollbreitenzeilen verwendet werden. XML-Format: Anzeige leeren Wenn keine Lieferscheinpositionen vorhanden sind, wird der Modus Leer verwendet: Dadurch wird die Positionstabelle geleert und die angegebene Information dargestellt. Wird die XML-Datei vollständig gelöscht, zeigt ERPDisplay automatisch: Willkommen Warte auf neue Anzeigedaten. Sicheres Aktualisieren der XML-Datei Die ERP-Anwendung sollte anzeige.xml nicht langsam und direkt überschreiben. ERPDisplay könnte die Datei sonst lesen, während sie erst teilweise geschrieben wurde. Empfohlenes Verfahren: Gesamten XML-Inhalt in eine temporäre Datei schreiben. Datei vollständig schließen. Temporäre Datei atomar in anzeige.xml umbenennen bzw. die vorhandene Datei ersetzen. Beispiel: anzeige.tmp schreiben ↓ Datei schließen ↓ anzeige.tmp → anzeige.xml ERPDisplay überwacht Änderungen, Neuanlagen, Umbenennungen und Löschungen. Die XML-Datei muss als UTF-8 gespeichert werden. XML-Sonderzeichen müssen maskiert werden: Zeichen XML-Schreibweise & & < < > > " in Attributen " Bildschirmauswahl Die Bildschirmauswahl wird in ERPDisplay.exe.config konfiguriert. Automatische Erkennung Reihenfolge der automatischen Erkennung: Zusätzlicher Bildschirm mit genau 1024 × 600 Pixeln Anderer zusätzlicher Bildschirm Der Hauptbildschirm wird niemals als automatischer Fallback verwendet. Wenn kein zusätzlicher Bildschirm vorhanden ist, öffnet ERPDisplay kein Anzeigefenster und meldet den Fehler über das Tray-Symbol. Fester Bildschirmindex Die verfügbaren Indizes können über Erkannte Bildschirme angezeigt werden. Fester Windows-Gerätename Der Gerätename ist meist stabiler als der Index, da sich Bildschirmindizes nach dem Umstecken verändern können. Verhalten bei Netzwerkunterbrechungen ERPDisplay verwendet bei einem UNC-Pfad eine ereignisbasierte Dateiüberwachung. Bei erreichbarer Freigabe: keine permanente Abfrage der XML-Datei automatisches Einlesen bei Dateiänderungen sehr geringe Netzlast Bei nicht erreichbarer Freigabe: ERPDisplay bleibt aktiv die letzte gültige Anzeige bleibt erhalten ohne vorherige Daten erscheint ein Wartezustand ERPDisplay versucht automatisch, die Verbindung wiederherzustellen Das Wiederholungsintervall wird in Millisekunden konfiguriert: Der Wert 10000 entspricht zehn Sekunden. Netzlast Die Überwachung arbeitet bei einer bestehenden SMB-Verbindung ereignisbasiert. Die XML-Datei wird nur bei einer tatsächlichen Änderung gelesen. Die mitgelieferte Beispieldatei ist kleiner als 1 KB. Änderungshäufigkeit Ungefähre XML-Nutzdaten pro Tag einmal pro Minute etwa 1 MB alle 30 Sekunden etwa 2 MB alle 10 Sekunden etwa 6 MB Hinzu kommen SMB-Protokoll- und Metadatenpakete. Bei normaler Nutzung liegt die gesamte Netzlast üblicherweise nur bei wenigen Megabyte pro Arbeitsplatz und Tag. Nur während die Freigabe nicht erreichbar ist, erfolgt entsprechend NetzwerkWiederholungMs eine kurze Verfügbarkeitsprüfung. Wichtige Einstellungen Beispiel einer vollständigen Konfiguration: Einstellung Bedeutung BildschirmModus Auto , Index oder Geraetename BildschirmIndex Nullbasierter fester Bildschirmindex BildschirmGeraetename Fester Windows-Gerätename ImmerImVordergrund Anzeigefenster im Vordergrund halten Darstellungsgroesse Normal , Mittel oder Gross Anzeigedatei Lokaler Pfad, relativer Pfad oder UNC-Pfad DateiAenderungsverzoegerungMs Wartezeit vor dem Lesen einer geänderten Datei NetzwerkWiederholungMs Wiederholungsintervall bei nicht erreichbarem Ordner Fehlerbehebung Tray-Symbol wird nicht angezeigt Prüfen, ob ERPDisplay bereits läuft. Den ausgeblendeten Bereich des Windows-Infobereichs öffnen. Alte ERPDisplay-Instanz vollständig beenden. Neu erstellte ERPDisplay.exe starten. In den Windows-Einstellungen festlegen, dass das ERPDisplay-Symbol immer angezeigt wird. Kein Displayfenster sichtbar Windows-Anzeigemodus auf Diese Anzeigen erweitern stellen. Über Erkannte Bildschirme prüfen, ob das Display vorhanden ist. Auflösung des Virtuos-Displays auf 1024 × 600 stellen. BildschirmModus , BildschirmIndex und BildschirmGeraetename prüfen. Beachten, dass der Hauptbildschirm nicht als automatischer Fallback verwendet wird. UNC-Datei wird nicht gelesen UNC-Pfad im lokalen Windows-Explorer öffnen. Lese- und Freigabeberechtigungen prüfen. Sicherstellen, dass ERPDisplay unter demselben Windows-Benutzer läuft, der Zugriff auf die Freigabe besitzt. Im Tray Anzeigedatei neu laden auswählen. Prüfen, ob %LocalAppData%\Firma2\ERPDisplay\Anzeigepfad.txt einen alten Pfad enthält. Änderungen werden nicht angezeigt XML-Datei auf gültige XML-Syntax prüfen. Datei als UTF-8 speichern. Sicherstellen, dass wirklich die konfigurierte Datei geändert wird. Temporäre Datei schreiben und anschließend atomar ersetzen. Bei einfachen NAS-Systemen prüfen, ob SMB-Änderungsbenachrichtigungen unterstützt werden. XML-Fehlermeldung Bei ungültigem XML bleibt die letzte gültige Anzeige bestehen. Typische Ursachen: fehlendes Wurzelelement unbekannter Modus unbekannter Zeilentyp nicht maskiertes & fehlendes Anführungszeichen Datei wurde während des Schreibens gelesen Versionsinformation Komponente Version Anwendung ERPDisplay 1.3 Plattform .NET Framework 4.8 Oberfläche Windows Forms Zielauflösung 1024 × 600 Pixel Datenformat XML, UTF-8 ERP Mail ERPMail liest Maildaten aus einer INI-Datei, ersetzt Platzhalter, ergänzt optionale Anhänge und öffnet einen fertigen Entwurf in Microsoft Outlook Classic 365. Die Nachricht wird nicht automatisch versendet. Was macht der ERP-Mailer? ERPMail Kurzbeschreibung, Startparameter und Beispiel einer INI-Datei Kurzbeschreibung ERPMail liest Maildaten aus einer INI-Datei, ersetzt Platzhalter, ergänzt optionale Anhänge und öffnet einen fertigen Entwurf in Microsoft Outlook Classic 365. Die Nachricht wird nicht automatisch versendet. Was das Programm macht Konfiguration: Lädt die globale ERPMail-Konfiguration und wertet den Startparameter für die INI-Datei aus. Maildaten: Liest Empfänger, CC, BCC, Betreff, HTML-Vorlage und bis zu drei Anhänge aus der Sektion [Allgemein] . Mailtext: Übernimmt den HTML-Text aus [Body] . Ist dieser Bereich leer, kann stattdessen eine externe HTML-Datei verwendet werden. Platzhalter: Liest Einträge aus [Label] und ersetzt Platzhalter wie ##Anrede## . Dabei wird die Groß- und Kleinschreibung nicht berücksichtigt. Outlook: Startet Outlook bei Bedarf und öffnet die vorbereitete Nachricht einschließlich der Outlook-Standardsignatur zur manuellen Kontrolle. Versand: Der Benutzer prüft Empfänger, Inhalt und Anhänge und klickt anschließend selbst auf Senden . Mögliche Startparameter Parameter Bedeutung /INI=Datei Gibt die zu verarbeitende INI-Datei an. Datei.ini Die INI-Datei kann auch direkt ohne /INI= übergeben werden. /UPDATE Startet die im Programm enthaltene LiveUpdate-Funktion. /LOG Wird vom Programm abgefragt. Die Verfügbarkeit hängt von den Standardparametern des PHXFrameworks ab. /V=Datei Ist als Parameter registriert, wird im aktuellen Programmstand jedoch noch nicht verarbeitet. Beispielaufruf ERPMail.exe /INI="C:\ERP\Mail\Rueckgabe.ini" oder ERPMail.exe /INI=Mailversand_000.ini Beispiel einer INI-Datei Empfohlene Reihenfolge: [Allgemein] , danach [Label] und [Body] als letzter Bereich der Datei. [Allgemein] from= AbsenderImAuftragVon= to=kunde@example.com cc=sachbearbeitung@example.com bcc= Betreff=Erinnerung zur Rückgabe Ihres Verleihgeräts HTMLVorlage= Attachment1=C:\ERP\Dokumente\Verleihschein.pdf Attachment2= Attachment3= [Label] @@Anrede@@=Sehr geehrte Frau Mustermann @@Gerätebezeichnung@@=Sauerstoffkonzentrator @@Seriennummer@@=SN-123456 @@Rückgabedatum@@=31.07.2026 [Body]

##Anrede##,

wir möchten Sie freundlich daran erinnern, das medizinische Verleihgerät ##Gerätebezeichnung## mit der Seriennummer ##Seriennummer## zurückzugeben.

Als Rückgabetermin wurde der ##Rückgabedatum## vereinbart.

Mit freundlichen Grüßen

Wichtige Hinweise Eine neue INI-Datei anlegen Fehlt die INI-Datei oder ist sie leer, legt ERPMail den Bereich [Body] an, öffnet die Datei zur Bearbeitung und erzeugt noch keinen Outlook-Entwurf. HTML-Vorlage: HTMLVorlage wird nur verwendet, wenn kein Mailtext aus [Body] vorhanden ist. Hier ist der Dateiname anzugeben welche entweder mit Pfadangabe oder nur der Dateiname angegeben wird. Relative Pfade Anhänge werden zuerst relativ zum Programmverzeichnis und anschließend relativ zum konfigurierten ERP-Datenpfad gesucht. Body-Bereich Der Body endet beim Beginn der nächsten INI-Sektion. Deshalb sollte [Body] am Ende der Datei stehen. Versendekonto/Absender Diese optionalen Parameter legen den gewünschten Absender oder das Versendekonto fest. Dazu sind die entsprechenden Konfigurationen in Outlook oder im Exchangeserver erforderlich. Nicht konfigurierte und in Outlook eingerichtete Mailadressen werden von der Microsoft Outlook-API nicht akzeptiert! from=mainabsender@test.de Setzt den Absender für Microsoft Outlook auf eine bestimmte Mailadresse. Hier ist es aber wichtig, dass es sich hier um ein korrekt eingerichtetes Konto im Outlook handeln muss. AbsenderImAuftragVon=test@meinemailadresse.at Der Parameter AbsenderImAuftragVon setzt ein freigegebenes Postfach mit entsprechender Exchange-Berechtigung voraus . Die entsprechenden Einstellungen muss ihr IT-Betreuer durchführen. Labels Es können beliebige Labels verwendet werden welche dann automatisch in der Email durch den angegebenen Text ersetzt werden. Labels beginnen immer mit @@ und enden mit @@. Labels können selbst benannt und hinzugefügt werden und müssen nur in der Sekrtion "Label" abgelegt sein. Die ERPMailGlobal.INI: In der ERPMailGlobal.INI werden allgemeine Einstellungen definiert, wie z,B. der Datenpfad für den Mailversand, welcher als Basispfad eingestellt werden kann wo INI und andere Dateien gesucht werden, wenn keine Pfadangabe übergeben wird. Flussdiagramm_ERPMail.docx ERP Print Pilot ERPPrintPilot übernimmt PDF-Druckaufträge aus Microsoft Azure Blob Storage, verarbeitet sie über gotomaxx PDF-Mailer und überträgt anschließend lokale Ergebnisdateien zurück nach Azure.  ERPPrintPilot Technikerdokumentation Technische und betriebliche Dokumentation der Windows-Anwendung ERPPrintPilot mit Schwerpunkt auf Dateisynchronisation, Azure-Konfiguration, Sicherheit und Fehleranalyse. Wichtigste Aussage zur Microsoft Konfiguration Die vorliegende ERPPrintPilot-Version authentifiziert sich mit dem Zugriffsschlüssel des Azure Storage Accounts. Für diesen Betriebsmodus werden keine Microsoft Entra App Registration, keine Microsoft-Graph-Berechtigungen und kein Azure Key Vault benötigt. Für die Inbetriebnahme sind erforderlich: Azure-Abonnement Azure Storage Account privater Blob-Container Name und Zugriffsschlüssel des Storage Accounts Netzwerkzugriff vom Windows-Rechner zum Blob-Endpunkt lokale Arbeits- und Archivordner gotomaxx PDF-Mailer mit gültigem Druckprofil Für den sicheren Dauerbetrieb wird eine spätere Umstellung auf Microsoft Entra ID und Azure RBAC empfohlen. Diese Umstellung erfordert eine dafür freigegebene ERPPrintPilot-Version und kann nicht allein über das Azure-Portal aktiviert werden. Systemübersicht Bereich Ausführung Anwendung Windows-Desktop-Anwendung Laufzeit .NET Framework 4.8 Cloudspeicher Microsoft Azure Blob Storage Druckkomponente gotomaxx PDF-Mailer 6 Lokale Daten Arbeitsordner, Archive und gotomaxx-Protokolldatenbank Verzeichnisdienst optionales lokales Active Directory für E-Mail-Adressen ERPPrintPilot muss unter einem festgelegten Windows-Konto betrieben werden. Lokal geschützte Zugangsdaten und Zugriffstoken sind an den Rechner beziehungsweise das Benutzerkonto gebunden. Zuständigkeiten Rolle Aufgabe Azure-Administrator Storage Account, Container, Netzwerkzugriff und Zugriffsschlüssel bereitstellen Windows-Administrator Laufzeit, Dienstkonto, Ordnerrechte und geplanten Task einrichten gotomaxx-Techniker PDF-Mailer, Druckprofil, Steuerdateien und Archivpfad konfigurieren Applikationsbetreuer ERPPrintPilot konfigurieren, testen und überwachen Gesamtablauf Konfiguration laden | gotomaxx Installation prüfen | Druckaufträge aus Azure herunterladen | PDF und gleichnamige INI mit gotomaxx verarbeiten | Verarbeitete Dateien lokal archivieren | Dateien aus dem Uploadordner nach Azure übertragen Die Synchronisation wird nur ausgeführt, wenn das konfigurierte gotomaxx-Verzeichnis vorhanden ist. Fehlt die gotomaxx-Installation oder ist der Pfad falsch, werden weder Download noch Upload gestartet. Startparameter Parameter Wirkung /H vollständigen Workflow unbeaufsichtigt ausführen und danach beenden /P Archive bereinigen und danach beenden /S Sendeprotokoll erzeugen und danach beenden /BWPROT zusätzliche BWProt-Analyse aktivieren /VON= Beginn des Berichtszeitraums /BIS= Ende des Berichtszeitraums Synchronisation Download und Upload verwenden denselben Blob-Container. Die Trennung erfolgt über unterschiedliche Prefixe, die in Azure wie virtuelle Ordner erscheinen. Richtung Quelle Ziel Standardprefix Download Azure Blob Storage lokaler Arbeitsordner print/ Upload lokaler Uploadordner Azure Blob Storage scan/ Authentifizierung ERPPrintPilot erzeugt aus dem Storage-Account-Key eine kurzlebige Zugriffsfreigabe für den Container. Diese umfasst Lesen, Auflisten, Schreiben, Erstellen und Löschen. Der Zugriffstoken wird lokal geschützt gespeichert und bei Ablauf erneuert. Die reguläre Laufzeit beträgt in der vorliegenden Version ungefähr eine Stunde. Der Storage-Account-Key besitzt weitreichende Berechtigungen und ist wie ein privilegiertes Kennwort zu behandeln. Er darf nicht in BookStack, Tickets, E-Mails oder allgemein lesbaren Dateien dokumentiert werden. Download Der allgemeine Azure-Datenabgleich muss aktiviert sein. ERPPrintPilot liest Blobs unterhalb des konfigurierten Download-Prefixes. Es werden nur Dateien mit den Endungen .pdf und .ini heruntergeladen. Unterordner des Blob-Pfads werden im lokalen Arbeitsordner beibehalten. Die spätere PDF-Suche erfolgt rekursiv. Zu jeder PDF wird im gleichen Ordner eine gleichnamige INI-Datei erwartet. Authentifizierungsfehler führen zu einer Erneuerung des Zugriffstokens. Zeitüberschreitungen, Drosselungen und vorübergehende Azure-Fehler werden kurzzeitig wiederholt. Wenn Delete remote files after download aktiv ist, löscht ERPPrintPilot den Azure-Blob unmittelbar nach dem erfolgreichen Download. Der Druck ist zu diesem Zeitpunkt noch nicht abgeschlossen. Remote-Löschen sollte daher erst nach einem getesteten Wiederanlaufverfahren aktiviert werden. Druckverarbeitung ERPPrintPilot sucht im lokalen Arbeitsordner nach PDF-Dateien. Zu auftrag.pdf muss im selben Ordner auftrag.ini vorhanden sein. ERPPrintPilot ergänzt bei Bedarf die Auftragssteuerung. PDF und Steuerdatei werden an gotomaxx übergeben. Der Verarbeitungserfolg wird über das gotomaxx-Archiv und die Protokolldaten geprüft. Erfolgreich verarbeitete Dateien werden entfernt oder archiviert. Upload Der allgemeine Azure-Datenabgleich und der separate Upload müssen aktiviert sein. Der lokale Uploadordner muss vorhanden sein. Alle Dateien und Unterordner werden rekursiv verarbeitet; es besteht kein Dateitypfilter. Unterordner werden im Zielprefix beibehalten. Bereits vorhandene Blobs werden überschrieben. Bei konfiguriertem Archiv werden erfolgreich hochgeladene Dateien dorthin verschoben. Der lokale Uploadpfad muss nach dem Speichern und nach einem Neustart ausdrücklich kontrolliert werden. Bleibt der Wert nicht erhalten, darf der Upload nicht produktiv freigegeben werden. Gleichnamige Dateien aus unterschiedlichen Unterordnern können außerdem im flach geführten Uploadarchiv kollidieren. Microsoft Azure für den aktuellen Betrieb einrichten Erforderliche Ressourcen Ressource Erforderlich Zweck Azure-Abonnement Ja Bereitstellung und Abrechnung Ressourcengruppe empfohlen gemeinsame Verwaltung Azure Storage Account Ja Speicherung der Dateien privater Blob-Container Ja Container für print/ und scan/ Storage-Account-Key Ja Authentifizierung der aktuellen Programmversion Entra App Registration Nein im aktuellen Betriebsmodus nicht verwendet Azure Key Vault Nein im aktuellen Betriebsmodus nicht verwendet Microsoft Graph Nein wird nicht benötigt Storage Account und Container Im Azure-Portal einen Storage Account vom Typ General Purpose v2 anlegen. Sichere Übertragung über HTTPS aktiv lassen und mindestens TLS 1.2 verwenden. Eine zur erwarteten Last passende Standardredundanz wählen. Unter Data storage > Containers einen Container anlegen. Den anonymen Zugriff deaktiviert lassen. Für print/ und scan/ müssen keine echten Ordner angelegt werden. Sie entstehen mit den Blob-Namen. Shared Key und Zugriffsschlüssel Unter Security and networking > Access keys wird der Wert von Key1 oder Key2 benötigt. In ERPPrintPilot wird nur der Schlüsselwert hinterlegt, nicht die vollständige Connection String. Für die vorliegende Programmversion muss Allow storage account key access beziehungsweise AllowSharedKeyAccess aktiviert bleiben. Wird Shared Key deaktiviert, funktioniert die Synchronisation nicht mehr. Netzwerkzugriff Der Windows-Rechner benötigt ausgehend TCP 443 zu: https://.blob.core.windows.net Netzwerkvariante Verwendung Konfiguration Zugriff aus allen Netzen nur für einen kurzen Funktionstest öffentlichen Zugriff vorübergehend erlauben ausgewählte Netzwerke typischer On-Premises-Betrieb öffentliche Ausgangs-IP des Standorts freigeben Private Endpoint abgeschottete Netze Private DNS sowie Routing über VPN oder ExpressRoute bereitstellen Ein gültiger Account Key oder Zugriffstoken umgeht die Storage-Firewall nicht. Ist das Quellnetz nicht erlaubt, antwortet Azure weiterhin mit 403. ERPPrintPilot konfigurieren Azure Storage Einstellung Empfehlung für Ersttest Bedeutung Datenabgleich aktiv True Azure-Dateitransfer einschalten Storage Account kundenspezifischer Name Name ohne DNS-Suffix Account Key geheimer Schlüsselwert Zugriffsschlüssel des Storage Accounts Container Name kundenspezifischer Name privater Blob-Container Local path C:\ProgramData\ERPPrintPilot\Data Ziel des Downloads und Quelle der Druckverarbeitung Remote path print/ Prefix der Druckaufträge Delete remote files after download False Azure-Datei nach Download löschen Token expires in X minutes Standard belassen angezeigter Wert entspricht nicht zwingend der tatsächlichen Laufzeit Die Felder Tenant ID , Client ID , Client Secret und Vault Name bleiben im aktuellen Betriebsmodus leer. Azure Storage Upload Einstellung Empfehlung für Ersttest Bedeutung Datenabgleich aktiv False Upload erst nach erfolgreichem Downloadtest aktivieren Local path C:\ProgramData\ERPPrintPilot\Data.Upload Quelle aller Uploaddateien Remote path scan/ Zielprefix im Container Path to Archive-Folder C:\ProgramData\ERPPrintPilot\Upload.Archiv Archiv für hochgeladene Dateien Inbetriebnahme und Abnahme Vorbereitung dediziertes Windows-Konto festlegen .NET Framework 4.8 prüfen gotomaxx PDF-Mailer installieren und Druckprofil einrichten freigegebenes ERPPrintPilot-Paket installieren lokale Arbeits-, Upload- und Archivordner anlegen NTFS-Berechtigungen auf Dienstkonto und Administratoren begrenzen Azure Storage Account und privaten Container anlegen Netzwerkerreichbarkeit des Blob-Endpunkts prüfen ERPPrintPilot-Einstellungen eintragen geplanten Task unter dem vorgesehenen Windows-Konto anlegen Download und Druck testen Unter print/test/ die Dateien abnahme-001.pdf und abnahme-001.ini mit ungefährlichen Testdaten bereitstellen. Remote-Löschen deaktiviert lassen. ERPPrintPilot interaktiv starten und den Workflow auslösen. Prüfen, ob beide Dateien im lokalen Arbeitsordner vorhanden sind. Verarbeitung und Zielausgabe in gotomaxx kontrollieren. Das gotomaxx-Archiv und die Protokolldaten prüfen. Bestätigen, dass die Azure-Testdateien noch vorhanden sind. Upload testen Prüfen, ob der Uploadpfad nach Speichern und Neustart unverändert geladen wird. Eine eindeutig benannte Testdatei in den lokalen Uploadordner legen. Upload aktivieren und den Workflow erneut starten. Prüfen, ob die Datei unter scan/ mit dem erwarteten relativen Pfad vorhanden ist. Bei aktiviertem Archiv prüfen, ob die lokale Datei verschoben wurde. Freigabekriterien Download, Druck und Upload wurden mit Testdaten erfolgreich durchgeführt. Fehler sind im ERPPrintPilot-Protokoll oder im zentralen Syslog auffindbar. Zugangswerte stehen nicht im Anwendungspaket oder in frei lesbaren Dateien. Ein Wiederanlauf nach Programmabbruch wurde getestet. Das Betriebskonto kann geschützte Werte nach einem Neustart weiterhin lesen. Remote-Löschen wird erst nach Freigabe des Wiederanlaufverfahrens aktiviert. Fehleranalyse Symptom Wahrscheinliche Ursache Maßnahme Synchronisation startet nicht gotomaxx-Pfad fehlt oder ist falsch gotomaxx-Installationspfad prüfen 403 AuthenticationFailed falscher Account Key oder ungültiger Zugriffstoken Account Key prüfen und Einstellungen erneut speichern 403 AuthorizationPermissionMismatch Zugriffsrechte passen nicht Authentifizierungsmodus und Containerzugriff prüfen 403 ohne passenden Authentifizierungscode Storage-Firewall blockiert den Client öffentliche IP, VNet-Regel, Private Endpoint und DNS prüfen 404 Account, Container oder Datei nicht gefunden Namen und Prefixe exakt prüfen 408 oder 5xx temporäre Netz- oder Azure-Störung Wiederholungen abwarten, danach Netzwerk und Azure-Status prüfen 429 Azure drosselt Anfragen Ausführungsfrequenz und parallele Instanzen reduzieren keine Blobs gefunden falsches oder leeres Prefix Remote path sowie Groß- und Kleinschreibung prüfen PDF bleibt liegen gleichnamige INI fehlt Dateipaar und Ablageordner prüfen Uploadpfad fehlt Pfad wurde nicht übernommen oder Ordner fehlt Einstellung nach Neustart prüfen und Ordner anlegen Anwendung bleibt hängen gotomaxx-Prozess wurde nicht beendet gotomaxx prüfen und Prozess kontrolliert beenden Überwachung Im Regelbetrieb sollten mindestens folgende Werte überwacht werden: erfolgreiche und fehlgeschlagene Downloads und Uploads Anzahl unbearbeiteter PDF-Dateien im lokalen Arbeitsordner Alter der ältesten Datei in print/ , im Arbeitsordner und in scan/ Fehler 403, 404, 429 und 5xx Laufzeit und Abbrüche des gotomaxx-Prozesses freier Speicherplatz in Arbeits- und Archivordnern Ablaufdaten von Entra-Anmeldeinformationen nach einer späteren Migration Sicherheit und Wiederanlauf Sicherheitsmaßnahmen alle mit Installations- oder Testpaketen gelieferten Kennwörter und Schlüssel vor Produktion ersetzen Zugangswerte nur in den vorgesehenen geschützten Feldern speichern Storage-Account-Keys regelmäßig rotieren das Windows-Betriebskonto nicht für normale Benutzerarbeit verwenden anonymen Containerzugriff deaktiviert lassen Storage-Firewall auf benötigte Standorte oder private Verbindungen begrenzen Arbeits- und Archivordner sichern Azure Blob Soft Delete und Versionierung prüfen zentrale Diagnoseprotokolle und Alarmierung aktivieren Wiederanlauf nach Abbruch ERPPrintPilot und gotomaxx nicht erneut starten, bevor der Status geprüft wurde. In Azure prüfen, ob der Auftrag noch unter print/ vorhanden ist. Im lokalen Arbeitsordner nach PDF und gleichnamiger INI suchen. Im gotomaxx-Archiv und in den Protokollen prüfen, ob der Auftrag bereits verarbeitet wurde. Unter scan/ prüfen, ob Ergebnisdateien bereits hochgeladen wurden. Erst danach entscheiden, ob der Auftrag erneut ausgeführt, nur hochgeladen oder manuell abgeschlossen wird. Parallele ERPPrintPilot-Instanzen sollten vermieden werden. Arbeits- und Archivordner dürfen während eines laufenden Workflows nicht manuell bereinigt werden. Empfohlene Zielarchitektur mit Microsoft Entra ID Für den Dauerbetrieb sollte der Storage-Account-Key von der Windows-Station entfernt werden. Microsoft empfiehlt die Autorisierung von Blobzugriffen über Microsoft Entra ID und Azure RBAC. Falls weiterhin ein SAS benötigt wird, sollte ein User Delegation SAS verwendet werden. Erforderliche Microsoft Konfiguration Unter Microsoft Entra ID > App registrations eine Single-Tenant-App für ERPPrintPilot registrieren. Application (client) ID und Directory (tenant) ID dokumentieren. Eine vom Hersteller unterstützte Anmeldeinformation konfigurieren. Für Produktion ist ein Zertifikat gegenüber einem Client Secret zu bevorzugen. Dem Service Principal unter Storage Account > Access control IAM die Rolle Storage Blob Data Contributor auf Storage-Account-Ebene zuweisen. Die neue ERPPrintPilot-Version mit Entra-ID-Zugriff testen. Erst nach erfolgreichem Test Shared Key am Storage Account deaktivieren. Microsoft-Graph-API-Berechtigungen werden dafür nicht benötigt. Die Storage-Berechtigung wird über Azure RBAC und nicht über die API Permissions der App Registration vergeben. Azure Key Vault ist nur erforderlich, wenn die eingesetzte ERPPrintPilot-Version Werte nachweislich daraus liest. In diesem Fall benötigt der Service Principal die Rolle Key Vault Secrets User und Netzwerkzugriff zum Vault. Ein Key Vault beseitigt nicht automatisch die Notwendigkeit einer sicheren Erstanmeldung. Begriffe Begriff Bedeutung Blob Dateiobjekt in Azure Blob Storage Container Sammlung von Blobs in einem Storage Account Prefix Anfang eines Blob-Namens, der wie ein virtueller Ordner wirkt Account Key weitreichender Zugriffsschlüssel eines Storage Accounts SAS zeitlich und funktional begrenzte Zugriffsfreigabe User Delegation SAS über Microsoft Entra ID autorisierter SAS Service Principal technische Identität einer Entra App Registration Azure RBAC rollenbasierte Zugriffssteuerung für Azure-Ressourcen und Daten Private Endpoint private Netzwerkverbindung zu einem Azure-Dienst Referenzen Azure Storage SAS Überblick Blobzugriff mit Microsoft Entra ID Azure-Rolle für Blobdaten zuweisen Integrierte Azure Storage Rollen Shared-Key-Autorisierung verhindern Azure Storage Firewall und Netzwerkzugriff App in Microsoft Entra ID registrieren App-Anmeldeinformationen verwalten Azure RBAC für Key Vault Key Vault Netzwerkzugriff ERP-Suite Connect ERP-Suite Starter User Profil Verwaltung in der ERP-Starter Datenbank (SQL) Sämtliche Einstellungen und Benutzerprofile werden in einer SQLITE Datenbank verwaltet, die im Programmverzeichnis des BWStarters liegt: Aufgerufen wird der SQL-Bearbeitungsmodus hier: Die Tabelle 'Settings' hat folgende Spalten: - In der Category 'BWStarterGlobal' in der Section 'Username' sind die Kennwörter abgelegt, welche im Standard verschlüsselt werden. - In der Category 'BWStarterUser_' sind die Einstellungen des Users abgelegt - also das Userprofil Die angezeigte Tabelle kann ähnlich wie eine Excel-Tabelle bearbeitet werden, verändern aber keine Werte in der Datenbank. Werte können in den Zellen NICHT bearbeitet oder gelöscht werden. Massenlöschung von Zeilen, z.B. ein Userprofil komplett löschen, kann auch z.B. per SQL-Befehl erfolgen: DELETE from Settings where Category = "BWStarterUser_admin-erpaustria1" Diese Option sollte nur von erfahrenen Administratoren durchgeführt werden. Die Löschfunktion ist ebenfalls als Button in den Bedienerbezogenen Einstellungen zu finden. Empfohlen ist zuvor ein Select zu machen, das Ergebnis zu kontrollieren und anschließend das "SELECT *" durch "DELETE" zu ersetzen. !!! Sicherung der .sqlite vor Löschungen !!! Was kann der ERP-Suite Starter und was sind die Kernfunktionen? Der ERP-Suite Starter bietet eine einheitliche Oberfläche für ERP-Suite RDP-Verbindungen welche optional auch als Ersatz für die Windows-Shell (Explorer) verwendet werden kann. Damit ist es möglich, die normale Desktopansicht auf die ERP-Suite zu reduzieren und das Sicherheitsrisiko zu minimieren. Mit dem Starter ist es ebenfalls möglich, einen CTI-Client wie 3CX oder andere VoIP-Clients zu starten, damit die ERP-Suite auch über TAPI Anrufe auslösen oder annehmen kann. Sonderwünsche können auf Anfrage gerne realisiert werden, sofern diese in das Starterkonzept passen. Der ERP-Starter hat grundsätzlich zwei Ansichten, welche über die Einstellungen konfiguriert werden kann. Die Benutzeransicht sowie die Ansicht für Administratoren Es gibt im Starter folgende Bereiche: Bediener/Codewort sowie Mandantenauswahl Startprogramme (dynamische Anzeige auf Basis der Usereinstellungen) Einstellungen Wartungsmodus Administrative Tätigkeiten Beenden Administratoranzeige Der Wartungsmodus Über den Wartungsmodus kann die Produktivversion für normale User gesperrt werden. Diese Sperre kann dauerhaft oder für eine bestimmte Dauer aktiviert werden und deaktiviert sich nach Ablauf automatisch. Das Einloggen ist dann nur mehr für die Administratoren möglich. Die administrativen Tätigkeiten haben folgende Menüpunkte: Aktualisierung einer BüroWARE-Instanz (kopiert eine Instanz z. B. in eine Spielwiese oder erstellt eine Entwicklungsumgebung Datenbankassistent mit erhöhter Priorität starten Startet den Datenkankassistenten (32 oder 64Bit) und setzt die Prozesspriorität auf „hoch“ Logdateien öffnen SoftENGINE ERP Scheduler starten Windows Server und ZEN Datenbankanalyse Serveranalyse für die ERP-Suite Windows Benutzer abmelden (erfordert den ERP Scheduler) Erlaubt einem Bediener ohne Administratorrechte, andere Bediener von der RDP-Sitzung abzumelden. ERP-Starter Grundeinrichtung Wie kann ich den ERP-Starter als Windows-Shell einrichten? Dieses erfolgt am besten über eine benutzerdefinierte Gruppenrichtlinie am AD-Server. Erstellen sie dazu am AD-Server in der Richtlinienverwaltung eine neue Gruppenrichtlinie über der OU wo ihre User enthalten sind. Benennen sie dieses z. B. ERP-Starter Legen Sie im Active Directory eine Gruppe z. B. GRP_ERP_Starter an und fügen Sie die benötigten User in diese Gruppe ein. Dann übernehmen Sie diese Gruppe in der Richtlinie im Block "Sicherheitsfilterung" und fügen hier noch den RDP-Server hinzu, für den dieses Objekt gelten soll, damit dieses nur auf diesem Server gültig ist. Anschließend bearbeiten Sie dieses Richtlinienobjekt und suchen den folgenden Eintrag: Wechseln Sie in den Ast "Remotedesktopsitzungs-Host" in den Unterast "Umgebung für Remotesitzung" Öffnen Sie den Eintrag "Ein Programm beim Herstellen der Verbindung ausführen" und aktivieren Sie diese Einstellung. In die Felder ist dann das Programm mit der kompletten Pfadangabe einzutragen und das Arbeitsverzeichnis ist der Programmpfad des Starters. Beispiel: K:\ERPSuite\Produktiv\APP.ERPAustria\ERPStarter\BWStarter.exe K:\ERPSuite\Produktiv\APP.ERPAustria\ERPStarter Um die Einstellungen zu übernehmen, öffnen Sie am AD-Server eine Eingabeaufforderung (Console) als Administrator und geben den folgenden Befehl ein: gpupdate /force Wiederholen Sie dieses nach der erfolgreichen Verarbeitung am RDS-Server, wo der Starter und die ERP-Suite liegen. Meistens reicht dieser Befehl am RDS-Server, hängt aber von den Einstellungen ab, die Sie in der GPO konfigurieren! Achten Sie darauf, die GPO korrekt zu konfigurieren und dass die User die erforderlichen Berechtigungen besitzen. Eine falsch konfigurierte GPO kann zur Folge haben, dass Sie sich nicht mehr anmelden können! Welche Möglichkeiten gibt es noch, um die Shell einzurichten? Sie können die Shell auch direkt in den meisten RDS-Clients konfigurieren. Diese Möglichkeit sollte aber eher zum Testen und nicht für den Produktivbetrieb verwendet werden. Eine weitere Möglichkeit ist die Einstellung direkt beim User im Active Directory: Ich habe alles eingerichtet, aber der Server erlaubt oder startet die Anwendung nicht, woran kann das liegen? Die Funktion für beschleunigte RDS-Anmeldung bei der Benutzer bereits vor der vollständigen Gruppenrichtlinien- und Tokeninitialisierung auf den Desktop weitergeleitet werden, kann dieses verursachen. ➡ Diese beschleunigte Anmeldung kann dazu führen, dass beim Start einer alternativen Shell die AD-Rechte/Token noch nicht vollständig geladen sind – und die Shell deshalb mit „Zugriff verweigert“ scheitert. Microsoft nennt diese Funktion: ✅ “Schnellere Anmeldung/Abmeldung” oder “Fast Logon Optimization” Diese ist ab Server 2016 standardmäßig aktiviert, was bei Kiosk-/Shell-Szenarien massive Probleme verursacht. Eine weitere Einstellung ist folgende: gpedit.msc Computerkonfiguration → Administrative Vorlagen → Windows-Komponenten → Remotedesktopdienste → Remotedesktopsitzungs-Host → Umgebung für Remotesitzung → Remotestart nicht aufgeführter Programme zulassen Diese Funktion muss aktiviert werden, oder der ERP-Starter in die Liste der erlaubten Programme aufgenommen werden. Welche Einstellung kann das Starten des BWStarters als Shell beeinflussen? Der Registereintrag fQueryUserConfigFromDC kann das korrekte Laden der Usereinstellungen unterbinden. Prüfen Sie diesen Eintrag, ggf. welcher durch Änderungen am Verhalten des RCM (Remoteverbindungs Manager) verursacht werden. https://learn.microsoft.com/en-us/troubleshoot/windows-server/remote/remote-connection-manager-changes Wie kann ich den Starter unter TSPlus als Shell einrichten? In TSplus musst du verhindern, dass TSplus den vollständigen Windows-Desktop erzwingt: TIPP: Einstellungen/Screenshots unten prüfen, da nicht alle hier angegebenen Einstellungen wirklich erforderlich sind!! AdminTool → Advanced → Session Desktop for all users auf No Use Windows Shell auf No Application Command Line auf Yes lassen, damit die Vorgabe aus der .rdp -Datei bzw. dem RDP-Client akzeptiert wird. Force WinXshell auf No – sonst startet TSplus seine eigene Ersatz-Shell. Benutzer abmelden und eine neue Sitzung starten. Eventuell wenn es für alle gelten soll "Fallback application path if no assigned application" den Starter hinterlegen. Zusätzlich sollte der Benutzer in TSplus nur deine veröffentlichte Anwendung zugewiesen haben. Optional kannst du Force logoff if no assigned application aktivieren, damit keine Sitzung ohne zugewiesene Anwendung entsteht. Wichtig: Wenn explorer.exe weiterhin startet, prüfe auf dem Windows-11-Zielrechner die Richtlinie „Beim Herstellen der Verbindung ein Programm starten“ . Sie muss aktiviert sein, damit alternate shell aus der RDP-Datei greift. TSplus verwendet standardmäßig die Windows-Shell; mit Use Windows Shell = No verhinderst du dieses Verhalten. https://docs.tsplus.net/tsplus/advanced-features-session/ Wichtige Einstellungen findest du hier: Dem User muss eine Anwendung zugewiesen werden, dann wird diese Applikation automatisch gestartet. Im ERP-Starter folgende Einstellung deaktivieren: Optionale Einstellung: Wie kann ich die Einstellungen testen? Einfach eine RDP-Sitzung mit dem angelegten User durchführen. Aber nicht mit dem Hauptuser, der am Rechner direkt arbeitet! Wie kann ich eine bedienerbezogene Einstellung löschen? Wie kann ich eine Entwicklung.WORK mit dem BWStarter anlegen? Um mit dem BWStarter eine Entwicklung.WORK anlegen zu können, ist die Programmversion V5.60 oder höher erforderlich.   Hierbei wird automatisch der Ordner der Entwicklungsversion mit dem Zusatz ".WORK" ergänzt. Die Aktualisierung aktualisiert NUR den Vorlageordner! Sollten in diesem Ordner weitere Daten ausgeschlossen werden, dann ist die Vorlagedatei BWCopyVorlageEntwicklungWork.rcj vom BWStarter-Programmordner in den Unterordner "Scripte" im Starter Programmordner zu kopieren. In dieser Vorlage können dann weitere Dateien oder Mandanten ausgeschlossen werden. Es können bei Ordnerausschlüssen keine Platzhalter wie *, oder ? verwendet werden. Nachdem die Vorlage aktualisiert wurde, muss der Ordner umkopiert werden in z. B. T1234 (Ticket 1234)  Sobald sich hier ERP-Suite Datenbefinden wird diese Instanz automatisch im BWStarter angezeigt. Nach dem Starten der ERP-Suite ist dann noch der gewünschte Mandant festzulegen, da diese Instanzen einstanzen von den Mandanten befreit wurden. Wählen Sie hier z. B. einen Mandanten in der Hauptentwicklung oder aus der Spielwiese aus. Bitte beachte, dass alle mandantenbezogenen Daten hier NICHT im Programmordner liegen und bei der Verwendung des Mandanten berücksichtigt werden müssen. Wenn bei der Entwicklung mandantenbezogene Daten wichtig sind, dann ist entweder der Mandant in die Work-Entwicklung zu übernehmen oder es wird der Mandant der Hauptentwicklung (Entwicklung ohne den Zusatz .WORK ) verwendet, welcher vom Überschreiben über den Schieberegler geschützt werden muss. Eine Aktualisierung der WORK-Entwicklungen ist nicht vorgesehen. Wie richte ich die 2FA für ERP-Suite mit dem ERP-Starter ein? Um die 2 Faktorauthentifizierung für die ERP-Suite (WinUI) zu aktivieren, muss die APP vorher im Azure Portal angelegt und registriert werden. Registrieren Sie eine neue APP mit folgenden Parametern: Die folgenden IDs werden für den ERP-Starter benötigt: Anschließend tragen Sie die beiden Werte (Client-ID & Verzeichnis-ID) in den ERP-Suite-Starter unter "Azure Client-ID" und "Azure TenantID"ein. Anschließend können Sie die Authentifizierung der ERP-Suite auf "AzureAD" umgestellt werden. Achtung: Für die 2FA-Erweiterung ist eine Zusatzlizenz erforderlich! Wie richte ich die REST-API im ERP-Starter ein? Die REST-API kann ERP-Suite relevante Daten (keine Personenbezogenen) an den ERP-Partner übermitteln. Dieses wird dazu verwendet, von SoftENGINE bereitgestellte Changelogs und Informationen wie z. B. "Ein Fehler in Version xx betrifft ...." rasch bearbeiten zu können. Diese Funktion ist ausschließlich für SoftENGINE Partner verfügbar und benötigt eine freigeschaltete Partnerlizenz. Voraussetzungen: REST-API von ERP-Austria oder eines Partners, der diese Anfrage in der gleichen Art umsetzen kann. ERP-Starter ab V6.33 oder höher beim Kunden ERP-Suite 7.0 oder höher mit aktivierten Webservices beim Partner Freischaltung der REST-API beim Partner (Port 443 empfohlen) Freischaltung zum Server des Partners ausgehend vom Kundenserver (Standard: Port 443 TCP) Einrichtung: Starten Sie den ERP-Starter und klicken Sie auf "A" und anschließend auf ERP-Starter Grundeinrichtung. Anschließend klicken Sie auf "Weiter" bis zu dieser Seite und geben den Freischaltcode ein. Den Freischaltcode erhalten Sie über den Vertrieb von ERP-Austria und ist nur für Partner bestimmt. Mit diesem Freischaltcode werden API-KEY und RES-API Server automatisch bestimmt und festgelegt. Anschließend geben Sie die Kundennummer des Kunden beim ERP-Partner ein. Welche Daten werden übermittelt? (Stand 20.10.2025) ERP-Suite Version (7.00.403.123456) Actian Version (16.01.010) ERP-Starter-Version Das Datum der letzten Aktualisierung der ERP-Suite Werden personenbezogene oder firmenrelevante Daten übertragen? NEIN Diese Funktion dient ausschließlich der Verbesserung und Geschwindigkeit des Services. Generelle Infos Installation von Microsoft .NET 4.8 auf Windows Server 2016/2019/2022 Installieren Sie .NET Framework 4.8 unter Windows Server 2016 über folgenden Link: https://learn.microsoft.com/en-us/dotnet/framework/install/on-windows-10#net-framework-48 Installieren Sie .NET Framework 4.8 unter Windows Server 2019 über folgenden Link: https://learn.microsoft.com/de-de/dotnet/framework/install/on-server-2019 Ab Server 2022 ist .NET 4.8 über den Server-Manager - " Verwalten - Rollen und Features hinzufügen - Features" zu installieren. Was sind die Dateien *.sqlite.wal und *.sqlite.shm in den Programmpfaden? SQLite .wal (Write-Ahead Log) und .shm (Shared Memory) sind temporäre Dateien, die entstehen, wenn der WAL-Modus für eine Datenbank aktiviert ist. Sie dienen der Leistungssteigerung, indem Schreibvorgänge in die .wal-Datei ausgelagert werden, statt direkt in die Hauptdatenbank, während die .shm-Datei den Zugriff im gemeinsamen Speicher verwaltet, um gleichzeitiges Lesen und Schreiben zu ermöglichen.  Diese Dateien sollten nicht manuell gelöscht werden, da u.U. ein Datenverlust entstehen kann. .wal-Datei (Write-Ahead Log): Hier werden alle Änderungen (INSERT, UPDATE, DELETE) zunächst protokolliert, bevor sie in die eigentliche .db-Datei übertragen werden. Dies macht Schreibvorgänge schneller, da nicht sofort die Hauptdatenbankdatei gesperrt werden muss. .shm-Datei (Shared Memory): Diese Datei dient als Shared-Memory-Index für die WAL-Datei. Sie hilft SQLite, mehrere Verbindungen effizient zu verwalten, die gleichzeitig auf die WAL-Daten zugreifen.  Import 2 BüroWARE Import2BW Actian/Pervasive Kompatibilitätsmodus Ab Version 7.00.008 gibt es in Import2BW einen Kompatibilitätsmodus, der folgenden Fehler verhindert: Dieser tritt auf, wenn in Kombination mit einer aktuelleren BW (mit der erweiterten Satzlänge) eine ältere PSQL V13 vor V13.20 verwendet wird. Auszug aus der Actian Doku: Die BTRVEX -Funktion wurde mit der Veröffentlichung von Actian PSQL v13 R2 (Version 13.30) eingeführt. Diese Version brachte mehrere Neuerungen mit sich, darunter die Unterstützung größerer Datenmengen und erweiterte API-Funktionen.  Wesentliche Neuerungen in PSQL v13 R2 (13.30):   •   Neue Dateiformat-Version 13.0 : Ermöglicht Dateigrößen bis zu 64 TB und eine Rekordanzahl von über 4 Milliarden.   •   Einführung von BTRVEX und BTRVEXID : Diese neuen Einstiegspunkte ähneln BTRCALL und BTRCALLID, verwenden jedoch erweiterte Datentypen und unterstützen größere Datenpuffer bis zu 252 KB.   •   AES-192-Verschlüsselung : Für das neue Dateiformat wird AES-192 zur Verschlüsselung langer Eigentümernamen verwendet.   •   “UPSERT”-Funktionalität : Erweiterung des INSERT-Befehls um die ON DUPLICATE KEY UPDATE-Klausel zur Implementierung von “Upserts”. Diese Verbesserungen zielen darauf ab, die Leistung und Flexibilität von Actian PSQL zu steigern und Entwicklern erweiterte Werkzeuge für die Datenbankentwicklung bereitzustellen. Import2BW nutzt standardmäßig diese erweiterte Satzlänge, das kann aber wie folgt deaktiviert werden: Import2BW Guide Import2BW Stundenaufzeichnung Die Excel Datei muss wie folgt aufgebaut sein (Auftragsnummer/Belegnummer, Artikelnummer, Summe Arbeitszeiten, Belegart): Erstellung der Import Datei Mit Klick auf „Neu“ kann eine Importdatei erstellt werden. Bei Vorlage können wir einfach auf „weiter“ klicken. Bei dem nächsten Schritt muss die Datenquelle ausgewählt werden. Hier verwenden wir die Excel-Datei. Dann wählen wir die BüroWARE aus Vorlage brauchen wir keine also können wir die nächsten Punkte durchklicken. Nachdem wir die Voreinstellungen getroffen haben müssen wir jetzt noch einige Sachen umstellen. Der erste Punkt wäre die Header-Datenzuweisung. Hier müssen wir für den SKZ (Satzkennzeichen) statt ART => POS angeben, da wir in die Positionsdaten einfügen wollen. Nachdem das erledigt ist, müssen wir die einzelnen Spalten aus der Excel-Datei zuweisen. Dies geschieht in der Datenzuweisung. Quelle Feldname BW Variable Feldposition Auftrag-/Belegnummer ad POS_3_8 Artikelnummer af POS_18_25 Summe Arbeitszeit az POS_164_8 Belegart ac POS_2_1 Nachdem die Felder richtig zugewiesen wurden ist der letzte Punkt die Speicherung der .dta Datei. Standardmäßig wird die Datei im Hauptverzeichnis (D:\BueroWare\BWERP) als Standard.dta abgespeichert, aber dieser Name & Pfad kann angepasst werden. In der BüroWARE finden Sie im Dropdownmenü die BüroWARE komplett & weiters dann unter Tools => Standardschnittstelle Warenwirtschaft Sie finden dann beim Auswählen der Datei im ausgewählten Pfad die .dta Datei. Diese dann auswählen und dann unten links die Taste „Datenimport starten“ klicken. Welchen Datenbanktreiber muss ich bei Import 2 BüroWARE installieren? Ab Version 7.02.001 ist eine Verwendung der 32Bit oder 64Bit Version von Import2BW möglich. Zu beachten ist, dass bei 32-Bit-Programmen zwingend der 32-Bit-Datenbanktreiber erforderlich ist und bei 64Bit der 64Bit-Datenbanktreiber. Abhängig von der installierten Office-Version kann es erforderlich sein, eine ältere Version zu nehmen oder von 32 auf 64-Bit umzustellen oder umgekehrt. Microsoft Access Database Engine 2016 Redistributable https://www.microsoft.com/de-de/download/details.aspx?id=54920 Installieren der Microsoft 365 Access Runtime https://support.microsoft.com/de-de/office/herunterladen-und-installieren-von-microsoft-365-access-runtime-185c5a32-8ba9-491e-ac76-91cbe3ea09c9 Microsoft Access Database Engine 2010 Redistributable https://ftp.erpaustria.com/Datenbank/Microsoft Office Database Driver/2010/MicrosoftDatabaseDrivers_2010.exe Sollte beim Setup die Meldung kommen, dass bereits eine 64Bit bzw. 32Bit-Version installiert ist, kann das Setup mit folgendem Befehl in der Command Line trotzdem durchgeführt werden: accessdatabaseengine.exe /quiet Welche Einstellung ist bei welchem installierten Datenbanktreiber einzustellen? Empfohlen Microsoft 365 Access Runtime Microsoft.ACE.OLEDB.16.0 ✅ Access Database Engine 2016 Microsoft.ACE.OLEDB.16.0 ✅ Access Database Engine 2010 Microsoft.ACE.OLEDB.12.0 ✅/❌ Access Database Engine 2007 Microsoft.ACE.OLEDB.12.0 ❌ Microsoft OLE DB Provider for Jet Microsoft.Jet.OLEDB.4.0 ❌ Info: Bei der Auswahl in Import 2 BüroWARE selbst gibt es beim Datenbankprovider keinen Unterschied zwischen 32- und 64-Bit Nachtrag/Änderung ab Version 7.03.xxx: Ab V7.03 kann der Datenbanktreiber auch auf „Automatische Ermittlung“ gestellt werden. Das ist erforderlich, wenn Import2BW als 32Bit und 64Bit abwechselnd verwendet werden soll, da von Microsoft nur entweder 32Bit oder 64Bit ACE-Treiber der gleichen Version gleichzeitig installiert werden können. Sind beide erforderlich, müssen zwei unterschiedliche Treiberversionen installiert werden. z.B.: Microsoft.ACE.OLEDB.16.0 als 64bit und Microsoft.ACE.OLEDB.12.0 oder Microsoft.Jet.OLEDB.4.0 32Bit Anschließend muss in den Einstellungen dann der Treiber auf "Automatische Ermittlung" gestellt werden. Hinweis: Einmalige automatische Ermittlung prüft, welcher Treiber funktioniert und fixiert diesen dann für alle nachfolgenden Programmstarts. Wie kann ich einen tschechischen oder slowakischen Notiztext importieren? Um über Import 2 BüroWARE einen Notiztext importieren zu können, welcher NICHT ANSII kompatibel ist, wird Import 2BW V7.01.006 oder höher benötigt. Ab dieser Version ist es möglich, Notiztexte aus jeder unterstützten Datenquelle (Excel, CSV, MSACCESS, MSSQL, MYSQL u.s.w.....) direkt in die Notiztabelle zu importieren. Was ist erforderlich? 1. Der korrekte Zielmandant für die PUT_RELATION muss eingestellt werden: 2. Festlegen der Parameter für die PUT_RELATION Hierbei sind folgende Parameter zu beachten, wenn in die Notiztexttabelle importiert werden soll: PUT_RELATION( Zielbereich ; Index ; Schriftart (optional) ; Schriftgröße (optional) ; Codepage (optional) ) Mit Version 7.01.006 werden momentan folgende Ziele erlaubt: @... = Importiert immer in die Standardnotiztabelle (S_RVTX21.DTK oder S_RVTX_R00.sedbvar) @LT,00 = Artikellangtext Sprache 00 @LT,01 = Artikellangtext Sprache 01 @AT = Artikelnotiztext @LT,99 = Artikelwarntext @NT = Adressnotiztext @WT = Adresswarntext ... Beispiel: PUT_RELATION(@LT,10;IT1;Tahoma;10;1252) WICHTIG/INFO: Der Datenimport über die PUT-Relation wird IMMER ausgeführt, auch wenn der Datenimport in der Vorlage deaktiviert wurde! Der Zielbereich im Header ist in diesem Fall irrelevant, ausgenommen es wird gleichzeitig auch ein Datenimport über die Standardschnittstelle angestrebt. z. B. Artikelneuanlage + Notiztext über die PUT-Relation. Codepage Region / Sprache Beschreibung 1250 Mitteleuropa (Tschechisch, Polnisch, Ungarisch, Slowakisch, Kroatisch) Central European 1252 Westeuropa (Deutsch, Englisch, Französisch, Spanisch, Niederländisch) Western European (ANSI) MailBridge 365 für SMTP, POP3 und EWS Kurzanleitung für die Microsoft 365 Einrichtung Kurzanleitung · Stand 17. September 2026 Diese Seite enthält alle Microsoft-365-Angaben, die für MailBridge 365 benötigt werden. Die Anwendung darf auf alle Exchange-Online-Postfächer des Tenants zugreifen; in Microsoft 365 ist keine Postfachliste einzurichten. Voraussetzungen Ein Microsoft-365-Tenant mit Exchange Online Ein Konto, das App-Registrierungen erstellen und Administratorzustimmung erteilen darf Ausgehender HTTPS-Zugriff des MailBridge-Servers auf login.microsoftonline.com und graph.microsoft.com über Port 443 App registrieren https://entra.microsoft.com öffnen. Entra ID → App-Registrierungen → Neue Registrierung wählen. Als Namen beispielsweise MailBridge 365 eintragen. Nur Konten in diesem Organisationsverzeichnis auswählen. Die Umleitungs-URI leer lassen und die App registrieren. Aus der Übersicht notieren: Verzeichnis-ID (Tenant-ID) Anwendungs-ID (Client-ID) API-Berechtigungen einrichten Unter API-Berechtigungen → Berechtigung hinzufügen → Microsoft Graph → Anwendungsberechtigungen folgende Rechte hinzufügen: Berechtigung Benötigt für Mail.Send E-Mail-Versand Mail.ReadWrite Mailabruf, Ordner, Entwürfe und Statusänderungen User.Read.All Benutzerinformationen und sekundäre E-Mail-Adressen Calendars.Read Termine, wenn die Kalender-Synchronisation verwendet wird Contacts.Read Kontakte, wenn die Kontakt-Synchronisation verwendet wird Danach Administratorzustimmung für den Tenant erteilen . Bei allen verwendeten Rechten muss der Status Gewährt angezeigt werden. Client Secret erstellen Zertifikate & Geheimnisse → Clientgeheimnisse → Neues Clientgeheimnis öffnen. Beschreibung und Laufzeit festlegen. Das Secret erstellen. Sofort den angezeigten Wert kopieren. Benötigt wird der Secret-Wert, nicht die Geheimnis-ID. MailBridge 365 eintragen In MailBridge 365 unter Microsoft Graph eintragen: Feld Wert Tenant-ID Verzeichnis-ID aus der App-Registrierung Client-ID Anwendungs-ID aus der App-Registrierung Client Secret Kopierter Wert des Clientgeheimnisses Server-URL https://graph.microsoft.com Azure-Auth.-URL https://login.microsoftonline.com OAuth-Scope https://graph.microsoft.com/.default Einstellungen speichern und MailBridge 365 beziehungsweise den Windows-Dienst neu starten. Funktion prüfen Im Protokoll muss die OAuth2-Tokenanforderung mit HTTP 200 beantwortet werden. Versand mit einem Microsoft-365-Postfach testen. Mailabruf beziehungsweise EWS-Synchronisation testen. Falls aktiviert: Termine und Kontakte testen. Damit ist die Microsoft-365-Einrichtung abgeschlossen. Weitere Postfächer benötigen keine zusätzliche Freigabe in Microsoft 365. MailBridge 365 – Microsoft-365-Einrichtung ] Dokumentversion 1.4 · Stand 16. September 2026 Technikerunterlage für App-Registrierung, Microsoft-Graph-Berechtigungen, EWS-Proxy und sichere Datenübergabe für die Installation am Windows Server. Ziel dieser Anleitung MailBridge 365 ist ein lokaler Windows-Dienst. Er stellt bestehenden Anwendungen SMTP AUTH, POP3, einen HTTPS-Webclient und einen EWS-kompatiblen Endpunkt zur Verfügung. Der EWS-Proxy übersetzt unterstützte EWS-Anfragen intern auf Microsoft Graph. Gegenüber Microsoft 365 meldet sich der Dienst ohne interaktive Benutzeranmeldung über OAuth2 an. Nach Abschluss dieser Anleitung sind: eine eigene Anwendung im richtigen Microsoft-Entra-Tenant registriert, die benötigten Microsoft-Graph-Anwendungsberechtigungen eingerichtet, die tenantweite Administratorzustimmung erteilt, ein Client Secret erstellt und sicher übergeben, die verwendeten Postfächer und Funktionen dokumentiert, EWS-, Graph-, Cache- und Synchronisationseinstellungen festgelegt, alle Informationen für die Installation am Windows Server vorhanden. Wichtig: Der Connector benötigt keine persönlichen Microsoft-365-Benutzerkennwörter. Tenant-ID, Client-ID und Client-Secret-Wert gehören zur registrierten Anwendung. Aktueller Microsoft-Zeitplan für EWS Microsoft beginnt am 1. Oktober 2026 mit der stufenweisen Sperre von EWS in Exchange Online. Am 1. April 2027 wird EWS in Exchange Online vollständig und dauerhaft abgeschaltet. Die Übergangseinstellungen EWSEnabled und EWSAllowedAppIDs können bestehende direkte EWS-Anwendungen nur vorübergehend weiter zulassen und ersetzen keine Migration. MailBridge 365 verwendet EWS nicht für die Verbindung zu Microsoft 365. Der EWS-kompatible Endpunkt befindet sich ausschließlich lokal zwischen der Bestandsanwendung und MailBridge 365. Die Verbindung von MailBridge 365 zu Exchange Online erfolgt über OAuth2 und Microsoft Graph. Für MailBridge 365 selbst muss daher keine App-ID in EWSAllowedAppIDs eingetragen werden. Andere Anwendungen im Kunden-Tenant, die weiterhin direkt per EWS auf Exchange Online zugreifen, müssen separat ermittelt und bewertet werden. Microsoft hat keinen allgemeinen Termin veröffentlicht, an dem jede einzelne EWS-Funktion vollständig oder identisch in Graph verfügbar sein soll. Der Funktionsumfang muss deshalb für jede Bestandsanwendung getestet werden. Microsoft-Zeitplan zur EWS-Abschaltung EWSAllowedAppIDs für die Übergangsphase Microsoft-Leitfaden zur EWS-Graph-Migration Inhaltsübersicht Auftrag und Voraussetzungen App in Microsoft Entra ID registrieren Microsoft-Graph-Berechtigungen vergeben Administratorzustimmung erteilen Client Secret erstellen und sichern Postfachzugriff sinnvoll begrenzen Datenübergabe an den Windows-Techniker Vorbereitung und Einrichtung am Windows Server Abnahme und Funktionstest Fehlerzuordnung Secret-Erneuerung Offizielle Microsoft-Quellen 1. Auftrag und Voraussetzungen Funktionsweise Bestehende Anwendung | | SMTP AUTH / POP3 / EWS / HTTPS-Webclient v MailBridge 365 auf dem Windows Server | | OAuth2 Client Credentials / HTTPS v Microsoft Entra ID und Microsoft Graph | v Exchange Online Der Connector arbeitet als Hintergrunddienst mit einer eigenen Anwendungsidentität. Es findet keine interaktive Microsoft-365-Benutzeranmeldung statt. Deshalb werden Anwendungsberechtigungen benötigt. Voraussetzungen in Microsoft 365 Aktiver Microsoft-365-Tenant mit Exchange Online Mindestens ein verwendbares Benutzer-, Shared- oder Funktionspostfach Konto mit Berechtigung zum Erstellen einer App-Registrierung Konto mit Berechtigung zum Erteilen einer tenantweiten Administratorzustimmung Festgelegte Microsoft-365- und Exchange-Ansprechperson Wenn die Schaltfläche für die Administratorzustimmung deaktiviert ist, muss ein entsprechend berechtigter Microsoft-Entra-Administrator den betreffenden Schritt durchführen. Voraussetzungen am Windows Server Unterstütztes Windows-System mit .NET Framework 4.8 Lokale Administratorrechte für Installation und Dienstverwaltung Funktionierende DNS-Auflösung und korrekte Systemzeit Ausgehendes HTTPS über TCP-Port 443 Erreichbarkeit von login.microsoftonline.com und graph.microsoft.com Bei großen Nachrichten gegebenenfalls Erreichbarkeit von durch Graph bereitgestellten Upload-Endpunkten unter outlook.office.com Fester Programm- und Datenpfad Schreibrechte des Windows-Dienstkontos im Datenpfad Festgelegte lokale SMTP-, POP3-, EWS-Proxy- und Webclient-Ports Vor Beginn festlegen Welche Postfächer dürfen Nachrichten versenden? Welche Postfächer dürfen über POP3 oder den Webclient gelesen werden? Welche ERP-Systeme verwenden den EWS-Proxy und welche Postfächer fragen sie ab? Soll EWS alle Nachrichten oder nur Gesendete Elemente bereitstellen? Sollen vom ERP versendete Nachrichten bei der Rücksynchronisation aus Gesendete Elemente unterdrückt werden, um Dubletten im ERP zu vermeiden? Werden Termine und Kontakte lesend benötigt? Ab welchem Datum und welcher Uhrzeit dürfen Mails beziehungsweise Termine bereitgestellt werden? Sollen abgerufene Nachrichten in Exchange als gelesen markiert werden? Dürfen Nachrichten nach erfolgreichem POP3-Abruf gelöscht werden? Darf ein POP3-Client mit DELE Nachrichten in Exchange löschen? Soll das lokale Journalpostfach aktiviert werden? Soll Exchange den App-Zugriff serverseitig auf bestimmte Postfächer begrenzen? Wer ist für die Erneuerung des Client Secrets verantwortlich? Benötigte Microsoft-Graph-Rechte Berechtigung Typ Verwendung Mail.Send Application / Anwendung Versand aus den freigegebenen Exchange-Online-Postfächern Mail.ReadWrite Application / Anwendung Abruf, Gelesen-Markierung, Löschung und Entwurfsverarbeitung großer Nachrichten User.Read.All Application / Anwendung Anzeigename und sekundäre SMTP-, SIP-, X500- und weitere Proxyadressen für EWS ResolveNames Calendars.Read Application / Anwendung Optional: lesender Terminabgleich über den EWS-Proxy Contacts.Read Application / Anwendung Optional: lesender Kontaktabgleich über den EWS-Proxy Keine Redirect URI erforderlich: Der Connector verwendet den OAuth2 Client-Credentials-Flow. Unter Authentication / Authentifizierung muss keine Web-, SPA- oder Public-Client-Umleitungsadresse eingetragen werden. 2. App in Microsoft Entra ID registrieren Microsoft Entra Admin Center öffnen Öffnen Sie: https://entra.microsoft.com Kontrollieren Sie vor der Registrierung oben rechts, dass der produktive Kunden-Tenant ausgewählt ist. Eine registrierte Anwendung kann später nicht in einen anderen Tenant verschoben werden. Navigation Microsoft Entra Admin Center > Entra ID > App registrations / App-Registrierungen > New registration / Neue Registrierung Registrierung durchführen Wählen Sie New registration / Neue Registrierung . Vergeben Sie einen eindeutigen Namen, beispielsweise: MailBridge 365 - Wählen Sie als unterstützten Kontotyp: Accounts in this organizational directory only Nur Konten in diesem Organisationsverzeichnis Lassen Sie Redirect URI / Umleitungs-URI leer. Wählen Sie Register / Registrieren . Nach dem Speichern öffnet sich die Übersichtsseite der App. Werte sofort erfassen Portalbezeichnung Benötigter Wert Hinweis Directory (tenant) ID Tenant-ID als GUID Nicht mit der primären Microsoft-365-Domain verwechseln Application (client) ID Client-ID als GUID Nicht die Object-ID verwenden Display name Anzeigename der App Dient zum späteren Auffinden der Registrierung Nicht verwechseln: Für den Connector werden die Directory (tenant) ID und die Application (client) ID benötigt. Die Object-ID der App oder des Service Principals ist dafür nicht geeignet. 3. Microsoft-Graph-Berechtigungen vergeben Navigation App-Registrierung > API permissions / API-Berechtigungen > Add a permission / Berechtigung hinzufügen Rechte hinzufügen Wählen Sie Microsoft Graph . Wählen Sie Application permissions / Anwendungsberechtigungen . Wählen Sie ausdrücklich nicht die delegierten Berechtigungen. Suchen Sie nach Mail.Send und markieren Sie diese Berechtigung. Suchen Sie nach Mail.ReadWrite und markieren Sie diese Berechtigung. Suchen Sie nach User.Read.All und markieren Sie diese Berechtigung. Wenn Termine und Kontakte über den EWS-Proxy synchronisiert werden sollen, markieren Sie zusätzlich Calendars.Read und Contacts.Read . Bestätigen Sie mit Add permissions / Berechtigungen hinzufügen . Warum werden zwei Rechte benötigt? Mail.Send erlaubt der Anwendung den Versand ohne angemeldeten Benutzer. Das Recht enthält jedoch keinen allgemeinen Lese- oder Änderungszugriff. Mail.ReadWrite erlaubt Lesen, Erstellen, Aktualisieren und Löschen von Nachrichten ohne angemeldeten Benutzer. Es enthält aber keine Versandberechtigung. Calendars.Read und Contacts.Read werden ausschließlich benötigt, wenn in der Connector-Konfiguration Termine und Kontakte synchronisieren aktiviert wird. Der Zugriff ist in dieser Ausbaustufe lesend. Der Connector benötigt Mail.ReadWrite zusätzlich für: POP3- und Webclient-Abruf, Markieren als gelesen, Löschen von Exchange-Nachrichten, Erstellen und Verarbeiten von Entwürfen bei großen Nachrichten, Upload-Sitzungen für große Anhänge. Nicht benötigtes Standardrecht entfernen Falls nach der Registrierung noch User.Read vom Typ Delegated / Delegiert eingetragen ist, kann dieses Recht entfernt werden. Der Connector verwendet keine delegierte Benutzeranmeldung und benötigt es nicht. Sicherheitswirkung: Nach der Administratorzustimmung gelten die vergebenen Anwendungsberechtigungen grundsätzlich tenantweit. Der Connector verwendet nur die lokal konfigurierten Postfächer. Für eine zusätzlich durch Exchange erzwungene Begrenzung siehe Abschnitt 6. 4. Administratorzustimmung erteilen Das bloße Hinzufügen der Berechtigungen reicht nicht aus. Anwendungsberechtigungen werden erst nach der tenantweiten Administratorzustimmung wirksam. Navigation App-Registrierung > API permissions / API-Berechtigungen Zustimmung durchführen Wählen Sie Grant admin consent for beziehungsweise Administratorzustimmung für erteilen . Kontrollieren Sie den Sicherheitsdialog. Erwartet werden Mail.Send , Mail.ReadWrite und User.Read.All sowie bei aktiviertem Termin-/Kontaktabgleich zusätzlich Calendars.Read und Contacts.Read . Klären Sie unerwartete zusätzliche Rechte, bevor Sie zustimmen. Bestätigen Sie die Zustimmung. Aktualisieren Sie die Ansicht. Prüfen Sie bei beiden Rechten den grünen Status Granted for / Gewährt für . Erwarteter Sollzustand Eintrag Typ Status Microsoft Graph Mail.Send Application Granted for Microsoft Graph Mail.ReadWrite Application Granted for Microsoft Graph User.Read.All Application Granted for Microsoft Graph Calendars.Read Application Optional, bei Terminabgleich: Granted for Microsoft Graph Contacts.Read Application Optional, bei Kontaktabgleich: Granted for Delegierte Rechte Nicht benötigt Keine erforderlich Wenn die Schaltfläche deaktiviert ist: Das verwendete Konto darf keine tenantweite Zustimmung erteilen. Eine Benutzerzustimmung reicht nicht aus. Ein berechtigter Entra-Administrator muss den Schritt durchführen. Bei späteren Änderungen: Werden die API-Berechtigungen geändert, muss die Administratorzustimmung erneut erteilt werden. Erst danach erscheinen die geänderten Rechte in neu ausgestellten Zugriffstokens. 5. Client Secret erstellen und sichern Der aktuelle Connector authentifiziert sich mit einem Client Secret. Dieses wird bei der Einrichtung am Windows Server per DPAPI für den lokalen Computer verschlüsselt gespeichert. Navigation App-Registrierung > Certificates & secrets / Zertifikate & Geheimnisse > Client secrets > New client secret / Neuer geheimer Clientschlüssel Secret erstellen Tragen Sie eine nachvollziehbare Beschreibung ein, beispielsweise: MailBridge 365 - Windows Server Legen Sie die Laufzeit fest. Microsoft begrenzt Client Secrets auf maximal 24 Monate und empfiehlt eine Laufzeit unter 12 Monaten. Wählen Sie Add / Hinzufügen . Kopieren Sie unmittelbar den Inhalt der Spalte Value / Wert . Dokumentieren Sie das Ablaufdatum. Planen Sie mindestens 30 Tage vor Ablauf einen Termin zur Erneuerung ein. Entscheidend - VALUE, nicht SECRET ID: Der Windows-Techniker benötigt den Inhalt der Spalte Value / Wert . Die Secret ID ist nur eine Kennung und kann nicht als Kennwort verwendet werden. Der Secret-Wert wird nach dem Verlassen der Seite nicht erneut angezeigt. Geht der Wert verloren, muss ein neues Secret erstellt werden. Sichere Übermittlung Der Secret-Wert darf nicht zusammen mit Tenant-ID und Client-ID in einer normalen E-Mail versendet werden. Geeignete Übertragungswege sind beispielsweise: freigegebener Eintrag in einem Passwortmanager, zeitlich begrenzter Secret-Link, getrennte Übermittlung über einen zweiten Kommunikationskanal, direkte Eingabe durch den berechtigten Administrator am Windows Server. Nach der Eingabe darf keine Klartextkopie in einer Textdatei, E-Mail oder ungeschützten Dokumentation auf dem Server verbleiben. Hinweis zur Microsoft-Empfehlung: Microsoft bevorzugt für Produktionssysteme Zertifikate oder föderierte Identitäten. Diese Connector-Version verwendet derzeit ein Client Secret. Kurze Laufzeit, geschützte Übertragung und geplante Rotation sind deshalb besonders wichtig. 6. Postfachzugriff sinnvoll begrenzen Basisbetrieb Der Connector begrenzt seine Verwendung auf die in der Absender- und Benutzerverwaltung eingetragenen Mailadressen. Dies ermöglicht eine schnelle Inbetriebnahme. Die Entra-Anwendungsberechtigungen erlauben technisch grundsätzlich Zugriff auf die entsprechenden Daten aller Exchange-Online-Postfächer des Tenants, solange Exchange keine zusätzliche Einschränkung erzwingt. Erhöhte Absicherung mit Exchange Application RBAC Für eine serverseitig erzwungene Beschränkung sollte bei neuen Installationen Role Based Access Control for Applications / Application RBAC in Exchange Online verwendet werden. Empfohlene Vorgehensweise: Zulässigen Empfängerbereich in Exchange Online definieren. Die Exchange-Anwendungsrolle Application Mail.Send auf diesen Bereich begrenzen. Die Exchange-Anwendungsrolle Application Mail.ReadWrite auf denselben benötigten Bereich begrenzen. Alle Benutzer-, Shared- und Funktionspostfächer aufnehmen, die der Connector verwenden soll. Mindestens ein erlaubtes Postfach testen. Mindestens ein Postfach außerhalb des Bereichs als Negativtest verwenden. Wichtig für große Nachrichten: Jedes Versandpostfach benötigt im wirksamen Exchange-Scope sowohl Mail.Send als auch Mail.ReadWrite , weil große Nachrichten über Entwurf und Upload-Sitzung verarbeitet werden. Legacy Application Access Policies Microsoft kennzeichnet Application Access Policies inzwischen als Legacy und empfiehlt für neue Einschränkungen Application RBAC. Bereits vorhandene Legacy-Policies können den Zugriff weiterhin beeinflussen und müssen insbesondere bei HTTP 403 geprüft werden. Für die Einrichtung der Einschränkung werden benötigt: Angabe Wert Application (client) ID ________________________________________________ Erlaubte Postfächer ________________________________________________ Weiteres erlaubtes Postfach ________________________________________________ Nicht erlaubtes Testpostfach ________________________________________________ Zuständiger Exchange-Administrator ________________________________________________ 7. Datenübergabe an den Windows-Techniker Diese Liste kann ausgefüllt an den ausführenden Windows-Techniker übergeben werden. Der Client-Secret-Wert wird getrennt davon über einen sicheren Übertragungsweg bereitgestellt. Microsoft-365- und Entra-Daten Feld Einzutragender Wert Kunde / Tenant ________________________________________________ Primäre Microsoft-365-Domain ________________________________________________ Directory (tenant) ID ________________________________________________ Application (client) ID ________________________________________________ App-Anzeigename ________________________________________________ Client Secret - Value Separat und sicher übergeben: [ ] erledigt Secret gültig bis ____________________ Erinnerung zur Rotation [ ] angelegt Admin Consent für Mail.Send [ ] gewährt Admin Consent für Mail.ReadWrite [ ] gewährt Admin Consent für User.Read.All [ ] gewährt Termin-/Kontaktabgleich [ ] nicht benötigt [ ] aktiviert Admin Consent für Calendars.Read [ ] nicht benötigt [ ] gewährt Admin Consent für Contacts.Read [ ] nicht benötigt [ ] gewährt Exchange Application RBAC [ ] nicht gewünscht [ ] eingerichtet [ ] separat beauftragt Microsoft-365-Ansprechpartner ________________________________________________ Kontakt ________________________________________________ Postfächer und Funktionen Feld Einzutragender Wert Versandpostfächer ________________________________________________ Weitere Versandpostfächer ________________________________________________ POP3-/Webclient-Postfächer ________________________________________________ Weitere Abrufpostfächer ________________________________________________ EWS-Postfächer ________________________________________________ EWS-Betriebsart [ ] vollständiger Mailabgleich [ ] nur Versand und Gesendete Elemente Eigene Versandkopien erneut ans ERP übertragen [ ] ja [ ] nein, Dubletten vermeiden Termine über EWS/Graph [ ] nicht benötigt [ ] lesend bereitstellen Kontakte über EWS/Graph [ ] nicht benötigt [ ] lesend bereitstellen Mails bereitstellen ab ____________________ Datum/Uhrzeit Termine bereitstellen ab ____________________ Datum/Uhrzeit Exchange-Abruf [ ] aktiv [ ] nicht benötigt Nach RETR als gelesen markieren [ ] ja [ ] nein Automatisch nach Abruf löschen [ ] ja [ ] nein POP3- DELE an Exchange weitergeben [ ] erlauben [ ] nicht erlauben Journalpostfach [ ] aktivieren [ ] zunächst deaktiviert lassen Server- und Netzwerkdaten Feld Einzutragender Wert Windows-Servername ________________________________________________ Installationspfad ________________________________________________ Datenpfad ________________________________________________ Dienstkonto ________________________________________________ SMTP-Adresse und Port ________________________________________________ POP3-Adresse und Port ________________________________________________ EWS-Proxy-Adresse und Port ________________________________________________ Webclient-Adresse und Port ________________________________________________ Gemeinsames lokales EWS-Kennwort Separat und sicher übergeben: [ ] erledigt Zulässige EWS-Client-IP-Adressen ________________________________________________ Erlaubte Client-IP-Adressen ________________________________________________ Proxy erforderlich [ ] nein [ ] ja: ______________________________ Nicht eintragen: Keine Microsoft-365-Benutzerkennwörter, keine OAuth-Tokens und keinen Client-Secret-Wert im Klartext in diese BookStack-Seite eintragen. Für den Connector werden keine persönlichen Microsoft-365-Kennwörter benötigt. 8. Vorbereitung und Einrichtung am Windows Server Programm- und Datenordner festlegen Der Installationspfad bezeichnet den vollständig gelieferten Programmordner. Er enthält MailBridge365.exe , MailBridge365.exe.config , die benötigten DLL-Dateien sowie den Ordner runtimes mit den nativen SQLite-Komponenten. Die Kundeneinstellungen liegen daneben in MailBridge365.settings.config . Der Datenpfad enthält dagegen alle veränderlichen Betriebsdaten: ├── Queue Versandwarteschlange und DeadLetter ├── State SQLite-Datenbank und Synchronisationsstände ├── Mailboxes postfachbezogener Mail-, Termin- und Kontaktcache ├── Users Benutzerverwaltung und Benutzerkennwörter ├── Secrets gemeinsame Kennwörter und OAuth-Client-Secret ├── Certificates automatisch erzeugte lokale TLS-Zertifikate ├── Log normales sowie getrenntes EWS-/Graph-Protokoll └── Actions Ausgaben der E-Mail-Automatisierung Bleibt das Feld Datenpfad leer, verwendet MailBridge 365 den Programmordner auch als Datenpfad. Die genannten Datenordner entstehen dann direkt neben der EXE. Für einen Windows-Dienst ist ein eigener, lokal beschreibbarer Datenpfad meist übersichtlicher. Das Dienstkonto benötigt dort Änderungsrechte. Bei einem UNC-Pfad sind zusätzlich passende Freigabe- und NTFS-Rechte sowie eine bereits beim Dienststart verfügbare Netzwerkverbindung erforderlich. Nicht nur die EXE kopieren: Zum Programm gehören auch die DLL-Dateien und der Ordner runtimes . Bei Updates muss MailBridge365.settings.config erhalten bleiben. Geheimnisse unter \Secrets und \Users\Secrets sind per Windows DPAPI an den Computer gebunden und müssen nach einem Serverwechsel neu gespeichert werden. Netzwerk prüfen login.microsoftonline.com ist per HTTPS erreichbar. graph.microsoft.com ist per HTTPS erreichbar. Erforderliche Graph-/Outlook-Upload-Endpunkte sind erreichbar. DNS-Auflösung funktioniert unter dem späteren Dienstkonto. Datum, Uhrzeit und Zeitzone des Servers stimmen. Proxy oder SSL-Inspection blockiert die Microsoft-Endpunkte nicht. Lokale Ports sind nur für berechtigte Quellsysteme geöffnet. Microsoft-Graph-Felder im Connector Connector-Feld Wert oder Quelle TenantId Directory (tenant) ID aus der Entra-App ClientId Application (client) ID aus der Entra-App Client Secret Inhalt der Spalte Value / Wert; lokal eingeben GraphBaseUrl https://graph.microsoft.com/v1.0 OAuthScope https://graph.microsoft.com/.default Parallele Graph-Anfragen je Postfach Standard 2 Wiederholungen bei Graph-Drosselung Standard 3 Mails bereitstellen ab Globale Untergrenze mit Datum und Uhrzeit; ältere Elemente werden nicht angeboten Termine bereitstellen ab Globale Untergrenze mit Datum und Uhrzeit; ältere Termine werden nicht angeboten Der Connector berücksichtigt bei HTTP 429 , 503 und 504 den von Microsoft gelieferten Retry-After -Wert und wiederholt die Anfrage automatisch. Für den laufenden Abgleich verwendet der Connector Microsoft-Graph-DeltaLinks. Ordner- und Elementmetadaten werden in einer lokalen SQLite-Datenbank gespeichert; vollständige MIME-Inhalte werden erst bei Bedarf geladen. Dadurch muss nicht bei jedem Abruf das gesamte Postfach heruntergeladen werden. Eine reine Cache-Bereinigung erzeugt keine Löschanweisung an das ERP-System. Benötigte lokale Komponenten aktivieren Die Protokolle können unabhängig voneinander aktiviert werden. Nicht benötigte Listener sollten ausgeschaltet bleiben. Komponente Einstellung Verhalten SMTP SMTP aktivieren Startet den lokalen SMTP-Eingang. Ist SMTP deaktiviert, werden fehlende SMTP-Adresse, Port, Benutzername, Kennwort und Absenderfreigaben nicht als Konfigurationsfehler behandelt POP3 POP3 aktivieren Startet den lokalen POP3-Endpunkt für Benutzerpostfächer, lokale Unzustellbarkeiten und das Journal EWS EWS-Graph-Proxy aktivieren Startet den lokalen HTTPS-Endpunkt /EWS/Exchange.asmx Webclient HTTPS-Webclient aktivieren Startet die lokale Browseroberfläche zur Postfach- und Journalprüfung Das Deaktivieren von SMTP beendet nur den SMTP-Listener. Der EWS-Versand, POP3, Webclient, Graph-Abgleich und die Verarbeitung bereits vorhandener Warteschlangeneinträge bleiben entsprechend ihrer eigenen Einstellungen aktiv. Geheimnisse speichern Starten Sie die Connector-Oberfläche mit lokalen Administratorrechten. Tragen Sie Tenant-ID und Client-ID ein. Geben Sie den Client-Secret- Wert in das dafür vorgesehene Geheimnisfeld ein. Speichern Sie die Konfiguration. Kontrollieren Sie, dass das Geheimnis anschließend als ******** angezeigt wird. Entfernen Sie alle temporären Klartextkopien des Secrets. Die Anwendung speichert das Client Secret DPAPI-verschlüsselt für den lokalen Computer. Bei einem Serverwechsel oder einem geänderten Datenpfad muss es am neuen Ziel erneut eingegeben werden. Benutzer und Postfächer einrichten Öffnen Sie die Benutzerverwaltung auf der Registerkarte Übersicht . Legen Sie im Bereich Vorgaben für neue Benutzer fest, ob neue Konten den Exchange-Online-Abruf, den Modus Nur Mailversand und Gesendete Elemente , die optionale Unterdrückung gesendeter Elemente und die Dublettenvermeidung erhalten sollen. Wählen Sie Vorgaben speichern . Diese Werte gelten nur für anschließend manuell oder automatisch neu angelegte Benutzer; bestehende Konten bleiben unverändert. Legen Sie die benötigten lokalen POP3-/SMTP-Benutzer an. Verwenden Sie vollständige Mailadressen als Benutzernamen. Prüfen Sie die übernommenen Vorgaben für jeden neu angelegten Benutzer. Legen Sie die erlaubten SMTP-Absender fest. Aktivieren Sie Löschfunktionen nur entsprechend der dokumentierten Kundenentscheidung. Vergeben Sie für das Journalpostfach ein eigenes lokales Kennwort. Aktivieren Sie die Journalfunktion erst nach erfolgreichem Funktionstest und wenn sie tatsächlich benötigt wird. EWS-Proxy für ein ERP-System einrichten Der EWS-Proxy behält die vom ERP erwartete EWS-Struktur bei und verarbeitet die unterstützten Anfragen intern über Microsoft Graph. Im ERP wird als EWS-Server-URL die lokale HTTPS-Adresse des Connectors eingetragen, beispielsweise: https://:/EWS/Exchange.asmx Einstellung Bedeutung EWS-Proxy aktiv Startet den lokalen HTTPS-Endpunkt EWS-Port Frei wählbarer lokaler TCP-Port; in Firewall und ERP identisch konfigurieren Gemeinsames EWS-Kennwort Lokales Kennwort für alle ERP-Benutzer; hat Vorrang vor dem jeweiligen Benutzerkennwort Benutzerkennwort Fallback, wenn kein gemeinsames EWS-Kennwort gesetzt ist Zulässige Client-IP-Adressen Beschränkt den Zugriff auf bekannte interne ERP-Systeme Exchange-Online-Abruf Muss für Postfächer aktiv sein, deren Daten über Graph bereitgestellt werden Nur Mailversand und Gesendete Elemente Zeigt nur die notwendigen Basisordner und synchronisiert ausschließlich Nachrichten aus Gesendete Elemente ; Versand bleibt möglich Nachrichten aus „Gesendete Elemente“ nicht übertragen Hält auch Gesendete Elemente für den Client leer; der EWS-Versand funktioniert weiterhin. Diese Benutzervorgabe ist standardmäßig deaktiviert Doppelte Mails im Ordner „Gesendete Elemente“ vermeiden Unterdrückt im eingeschränkten Modus die erneute Rückgabe einer über den Connector versendeten Nachricht an das ERP; externe Versandkopien aus Outlook oder Mobilgeräten bleiben sichtbar Termine und Kontakte synchronisieren Optionaler lesender Abgleich; benötigt Calendars.Read und Contacts.Read Das lokale EWS-Kennwort ist kein Microsoft-365-Benutzerkennwort. Es ist technisch eine eigene lokale Einstellung; bei Bedarf kann bewusst derselbe Wert wie beim Client Secret eingetragen werden. Das Client Secret im Graph-Feld meldet den Connector bei Microsoft an, das gemeinsame EWS-Kennwort authentifiziert das interne ERP-System am Connector. Beim ersten erfolgreich validierten EWS-Zugriff kann der Connector ein noch nicht vorhandenes Postfach automatisch in der Benutzerverwaltung anlegen. Das neue Konto übernimmt die zuvor gespeicherten Vorgaben für neue Benutzer . Bestehende Benutzer und deren Einstellungen werden dadurch nicht verändert. Die Dublettenvermeidung gilt nur zusammen mit Nur Mailversand und Gesendete Elemente . Sie verändert oder löscht keine Nachricht in Microsoft 365 und bereinigt keine bereits vorhandenen ERP-Dubletten. Die zur Erkennung benötigten Versandkennungen werden lokal unter \State\connector-state.db gespeichert. Postfachbezogene Cachedateien liegen übersichtlich unter \Mailboxes\ ; das lokale Journal verwendet \Mailboxes\_Journal . EWS-/Graph-Diagnose und lokale Daten Das getrennte EWS-/Graph-Protokoll liegt unter \Log . Die Detailstufe ist einstellbar; Mailinhalte können ausgelassen werden, damit Protokolle klein und datenschutzfreundlicher bleiben. Ein lokaler Synchronisationsreset pro Benutzer verwirft den lokalen Zustand. Bereits übertragene Elemente können dadurch erneut bereitgestellt werden, ohne Inhalte in Microsoft 365 zu löschen. Cache-Größe und Aufbewahrung begrenzen lokale MIME-Dateien. Metadaten, UIDLs, Seen-Status und DeltaLinks bleiben in SQLite erhalten. Bei vielen Postfachinhalten verhindert die Kombination aus DeltaLinks, Metadatenindex und bedarfsgeladenem MIME unnötige Vollabrufe. Lizenzhinweis: Ist die Lizenzprüfung ungültig, ist nur ein normales Postfach zulässig. Das Journal kann dann nicht aktiviert werden. Weitere manuell oder per EWS angefragte Postfächer werden abgewiesen und im Dateiprotokoll vermerkt. 9. Abnahme und Funktionstest OAuth2 und Dienststart Der Dienst startet ohne Konfigurationsfehler. Ein OAuth2-Token wird erfolgreich angefordert. Im Protokoll steht kein invalid_client und kein HTTP 401. Tenant-ID, Client-ID und verwendetes Postfach werden korrekt angezeigt. SMTP-Versand Eine Testmail wird aus einem erlaubten Postfach versendet. Der Graph-Aufruf endet mit HTTP 202. Die Nachricht liegt im Ordner Gesendete Elemente des Absenders. Ein nicht erlaubter Absender wird lokal abgewiesen. Wenn große Nachrichten benötigt werden, wurde zusätzlich eine Nachricht mit großem Anhang getestet. POP3 und Webclient Eine vorhandene Nachricht wird angezeigt. Die Nachricht kann vollständig abgerufen werden. Die UIDL bleibt bei wiederholter Anmeldung stabil. Die Gelesen-Markierung entspricht der Kundenentscheidung. Die Löschfunktion entspricht der Kundenentscheidung. Ein POP3- DELE wird nur bei aktivierter Berechtigung und sauberem QUIT an Exchange weitergegeben. EWS-Proxy und Graph-Synchronisation Das ERP erreicht die lokale URL /EWS/Exchange.asmx über HTTPS. Die Anmeldung funktioniert mit dem gemeinsamen EWS-Kennwort oder dem konfigurierten Benutzerkennwort. Die vollständige Ordnerhierarchie des eigenen Postfachs ist sichtbar. In der Betriebsart Nur Mailversand und Gesendete Elemente werden aus anderen Ordnern keine Nachrichten übertragen. Senden über EWS funktioniert und die Nachricht erscheint in Gesendete Elemente . Falls die Dublettenvermeidung aktiviert ist, erscheint eine über das ERP versendete Nachricht nach der Exchange-Synchronisation nicht ein zweites Mal im ERP. Eine außerhalb des Connectors versendete Testnachricht aus Outlook oder einem Mobilgerät wird weiterhin in das ERP synchronisiert. Falls aktiviert, werden Kalender und Kontakte lesend angezeigt. Die globalen Untergrenzen für Mails und Termine werden eingehalten. Ein erneuter Abgleich verwendet den gespeicherten Delta-Zustand und erzeugt keine unnötigen Dubletten. Das getrennte EWS-/Graph-Protokoll unter \Log enthält den Test ohne aktivierte Mailinhalte. Journal Es existiert nur ein Journalpostfach. Das Journalpostfach hat ein eigenes lokales Kennwort. Die Journalfunktion ist nur bei tatsächlichem Bedarf aktiviert. Eine ein- und eine ausgehende Testnachricht erscheinen jeweils genau einmal. Das Journalpostfach versendet keine Nachrichten. SMTP-, POP3-, EWS- und Webclient-Vorgänge werden entsprechend der aktivierten Journalregeln erfasst. Exchange Application RBAC Ein erlaubtes Postfach kann verwendet werden. Ein Postfach außerhalb des Scopes wird abgewiesen. Versand und Lesezugriff wurden getrennt geprüft. Abschluss Secret-Ablaufdatum ist dokumentiert. Verantwortliche Person für die Rotation ist festgelegt. Installations- und Datenpfad sind dokumentiert. Firewall- und Proxy-Freigaben sind dokumentiert. Kundenspezifische Lösch- und Journalentscheidungen sind dokumentiert. 10. Fehlerzuordnung Symptom Wahrscheinliche Ursache und Prüfung AADSTS7000215 oder invalid_client Falscher Secret-Wert, Secret-ID statt Value, falsche Client-ID oder abgelaufenes Secret HTTP 401 Tenant-ID, Client-ID, Client Secret und Token-Endpunkt prüfen HTTP 403 Admin Consent, Typ Application, Exchange Application RBAC und vorhandene Legacy Application Access Policies prüfen HTTP 404 beim Postfach Mailadresse, Exchange-Online-Lizenz und tatsächliche Postfachexistenz prüfen HTTP 429 Microsoft-Graph-Drosselung; Retry-After wird automatisch beachtet HTTP 503 oder 504 Temporäre Microsoft-Störung; automatische Wiederholung und Protokoll prüfen Kleine Nachrichten funktionieren, große nicht Mail.ReadWrite im wirksamen Scope sowie Graph-/Outlook-Upload-Endpunkte prüfen Token funktioniert, bestimmtes Postfach nicht Exchange Application RBAC oder Legacy Application Access Policy prüfen Keine POP3-Nachrichten Exchange-Abruf beim Benutzer, lokale Übertragungs-UIDLs und Postfachinhalt prüfen EWS meldet Authentication required Gemeinsames lokales EWS-Kennwort, Benutzername, Client-IP-Freigabe und EWS-URL prüfen; das Entra-Client-Secret gehört nicht in das ERP-Kennwortfeld EWS zeigt keine oder unvollständige eigene Ordner Exchange-Online-Abruf des Benutzers, Graph-Rechte, erste Ordnerabfrage und EWS-/Graph-Protokoll prüfen; ERP-Ordneransicht anschließend neu laden Nur Gesendete Elemente werden übertragen Beim Benutzer ist die Betriebsart Nur Mailversand und Gesendete Elemente aktiv; dies ist beabsichtigt Eine ERP-Versandkopie erscheint doppelt in Gesendete Elemente Beim Benutzer den eingeschränkten EWS-Modus und Doppelte Mails im Ordner „Gesendete Elemente“ vermeiden aktivieren; die Einstellung wirkt nur auf künftige Rücksynchronisationen Neue Benutzer erhalten unerwartete EWS-Einstellungen In der Benutzerverwaltung die Vorgaben für neue Benutzer prüfen; Änderungen daran wirken nicht rückwirkend auf vorhandene Konten Termine oder Kontakte fehlen Funktion im Connector sowie Calendars.Read beziehungsweise Contacts.Read samt Admin Consent prüfen Ältere Elemente fehlen Globale Einstellung Mails bereitstellen ab beziehungsweise Termine bereitstellen ab prüfen SQLite unable to open database file Schreibrechte des Dienstkontos auf Datenpfad und Datenbankordner sowie erreichbaren lokalen Pfad prüfen Weiteres EWS-Postfach wird abgewiesen Lizenzstatus prüfen; bei ungültiger Lizenz ist nur ein normales Postfach zulässig Typische Verwechslungen Falsch Richtig Object-ID als Client-ID verwendet Application (client) ID verwenden Secret-ID als Kennwort verwendet Client-Secret-Value verwenden Delegierte Rechte eingetragen Application permissions verwenden Rechte hinzugefügt, aber keine Zustimmung erteilt Grant admin consent ausführen Persönliches Microsoft-365-Kennwort eingetragen Am lokalen Protokoll das Connector-Benutzerkennwort oder gemeinsame EWS-Kennwort verwenden; zur Graph-Anmeldung den Client-Secret-Value im Connector hinterlegen Shared-Mailbox nicht im Exchange-Scope Alle verwendeten Shared-/Funktionspostfächer aufnehmen 11. Secret-Erneuerung Ein abgelaufenes Secret führt zu einem vollständigen Ausfall der Microsoft-Graph-Anmeldung. Die Erneuerung muss vor dem Ablauf erfolgen. Empfohlener Ablauf Mindestens 30 Tage vor Ablauf ein neues Client Secret in derselben App-Registrierung erstellen. Den neuen Value / Wert sofort sicher erfassen. Wartungsfenster abstimmen. Neues Secret in der Connector-Oberfläche am Windows Server eingeben. Einstellungen speichern und Dienst neu starten. OAuth2-Anmeldung und Testversand prüfen. Falls verwendet, POP3, Webclient und EWS-Proxy einschließlich Ordnerabgleich prüfen. Erst nach erfolgreicher Abnahme das alte Secret in Entra ID löschen. Neues Ablaufdatum und nächste Erinnerung dokumentieren. Kein unterbrechungsfreier Parallelbetrieb: Der aktuelle Connector verwendet jeweils ein aktives Client Secret. Deshalb darf das alte Secret erst entfernt werden, nachdem das neue Secret am Server eingetragen und erfolgreich getestet wurde. 12. Offizielle Microsoft-Quellen App in Microsoft Entra ID registrieren Microsoft Graph ohne angemeldeten Benutzer verwenden App-Anmeldeinformationen und Client Secrets verwalten Microsoft-Graph-Berechtigungsreferenz Role Based Access Control for Applications in Exchange Online Application Access Policies - Legacy Dokumentationsstand: Diese Anleitung wurde am 16. September 2026 geprüft. Microsoft kann Portalbezeichnungen, Rollen, Grenzwerte und Empfehlungen ändern. Bei Abweichungen haben die verlinkten Microsoft-Learn-Seiten und die Sicherheitsrichtlinien des Kunden-Tenants Vorrang. Interne Dokumentation Feld Eintrag Kunde ________________________________________________ Ticket / Auftrag ________________________________________________ Erstellt durch ________________________________________________ Microsoft-365-Konfiguration abgeschlossen am ________________________________________________ Windows-Server-Installation abgeschlossen am ________________________________________________ Technische Abnahme durch ________________________________________________ Nächster Secret-Wechsel spätestens am ________________________________________________ MailBridge 365 – Technische Gesamtdokumentation Version 3.19.1 · Stand 16. September 2026 Technische Gesamtdokumentation für Installation, Betrieb, SMTP, POP3, Webclient, Journal sowie EWS- und Graph-Synchronisation. Überblick MailBridge 365 verbindet ältere Anwendungen und Mailprogramme mit Microsoft 365. Die angebundene Anwendung kann weiterhin klassisches SMTP AUTH für den Versand, POP3 für den Abruf oder einen kompatiblen Teil von Exchange Web Services verwenden. Die Kommunikation mit Microsoft 365 erfolgt sicher über OAuth2 und Microsoft Graph. Ältere Anwendung │ ├── SMTP AUTH ──► MailBridge 365 ──► Microsoft Graph ──► Versand │ ├── POP3 ◄────── MailBridge 365 ◄── Microsoft Graph ◄── Posteingang │ └── EWS ◄──────► MailBridge 365 ◄──► Microsoft Graph ◄──► Exchange Es wird keine SMTP- oder POP3-Anmeldung mit einem Microsoft-365-Kennwort durchgeführt. Der Connector verwendet stattdessen eine eigene Anwendung in Microsoft Entra ID. Ende von EWS in Exchange Online Microsoft beginnt am 1. Oktober 2026 mit der stufenweisen Sperre von Exchange Web Services in Exchange Online. Ab 1. April 2027 ist EWS dort vollständig und dauerhaft abgeschaltet. Microsoft sieht über diesen Termin hinaus keine Ausnahmen vor. Die Änderung betrifft Microsoft 365 und Exchange Online; EWS in einem lokalen Exchange Server ist nach aktueller Ankündigung nicht betroffen. Zeitpunkt Bedeutung Bis September 2026 EWS-Abhängigkeiten erfassen, verwendete Vorgänge prüfen und die Umstellung testen Ab 1. Oktober 2026 Microsoft beginnt, EWS mandantenweise zu sperren; ohne vorbereitete Übergangsfreigabe können bestehende Anwendungen unterbrochen werden Übergangsphase EWSEnabled und EWSAllowedAppIDs können genehmigte EWS-Anwendungen vorübergehend weiter zulassen; sie ersetzen keine Migration Ab 1. April 2027 EWS ist in Exchange Online vollständig und dauerhaft abgeschaltet Microsoft bezeichnet die Graph-Abdeckung für die große Mehrheit typischer EWS-Szenarien als nahezu vollständig. Es gibt jedoch keinen veröffentlichten Termin, an dem jede einzelne EWS-Funktion vollständig oder identisch in Microsoft Graph nachgebildet sein soll . Sonderfunktionen und Hybridfälle müssen deshalb anhand der tatsächlich verwendeten Anwendung geprüft werden. MailBridge 365 stellt den EWS-Endpunkt ausschließlich lokal für kompatible Bestandsanwendungen bereit. Gegenüber Exchange Online verwendet der Connector OAuth2 und Microsoft Graph und ruft dort kein EWS auf. Deshalb benötigt MailBridge 365 selbst keine Freigabe über EWSAllowedAppIDs . Andere Anwendungen, die weiterhin direkt per EWS auf Exchange Online zugreifen, müssen unabhängig davon geprüft und gegebenenfalls für die Übergangsphase freigegeben werden. Offizielle Microsoft-Informationen: Zeitplan zur EWS-Abschaltung in Exchange Online EWSAllowedAppIDs für die Übergangsphase Migration von EWS zu Microsoft Graph Zuordnung von EWS-Vorgängen zu Graph Leistungsumfang SMTP AUTH mit AUTH LOGIN und AUTH PLAIN POP3-Zugriff auf Microsoft-365-Postfächer OAuth2-Anmeldung über Microsoft Entra ID Versand und Abruf über Microsoft Graph Lokaler EWS-zu-Graph-Proxy für bestehende ERP-Anbindungen Exchange-Ordnerhierarchie mit stabilen Graph-Ordnerkennungen Optionaler lesender Abgleich von Kalenderterminen und Kontakten Optionaler EWS-Modus nur für Versand und Gesendete Elemente Optionale Vermeidung doppelter Versandkopien im Ordner Gesendete Elemente Globale Vorgaben für die manuelle und automatische Neuanlage von Benutzern Dynamisches Absendepostfach anhand der From: -Adresse Ablage versendeter Nachrichten im richtigen Ordner Gesendete Elemente Versand großer Nachrichten und Anhänge Persistente Warteschlange mit automatischen Wiederholungsversuchen Rückgabe dauerhaft unzustellbarer Ausgangsmails über POP3 Eigene POP3-/SMTP-Benutzer mit individuellem Kennwort und Kontosperre Ein lokales, dublettenfreies Journalpostfach für ein- und ausgehende Mails Optionale E-Mail-Automatisierung mit Steuerzeichen, INI-Ausgabe und nachgelagerter Aktion Optionales STARTTLS für SMTP und POP3 Freigabe nach Client-IP, Absenderadresse, Absenderdomain und POP3-Postfach Verschlüsselte Speicherung von Kennwort und Client Secret Windows-Dienst für den unbeaufsichtigten Betrieb Grafische Oberfläche für Konfiguration, Status und Live-Protokoll Lokaler HTTPS-Webclient zur Postfachprüfung und optionalen Nachrichtenlöschung Persistente SQLite-Indizes und Graph-DeltaLinks für große Postfächer Einstellbare globale Stichtage für E-Mails und Termine Separates EWS-/Graph-Diagnoseprotokoll mit mehreren Detailstufen Voraussetzungen Unterstütztes Windows-Client- oder Windows-Server-Betriebssystem .NET Framework 4.8 Microsoft-365-Mandant mit Exchange Online Berechtigung zum Erstellen einer App-Registrierung in Microsoft Entra ID Administratorzustimmung für die benötigten Microsoft-Graph-Berechtigungen Lokale Windows-Administratorrechte für die Dienstinstallation Ausgehender HTTPS-Zugriff auf Port 443 Zugriff auf folgende Ziele: login.microsoftonline.com graph.microsoft.com outlook.office.com outlook.office.com wird insbesondere für von Microsoft Graph bereitgestellte Upload-Adressen bei großen Anhängen benötigt. Vorbereitung in Microsoft 365 App-Registrierung anlegen Öffnen Sie das Microsoft Entra Admin Center . Wechseln Sie zu Identität → Anwendungen → App-Registrierungen . Erstellen Sie eine neue, nur für den eigenen Mandanten vorgesehene Anwendung. Verwenden Sie beispielsweise den Namen MailBridge 365 . Notieren Sie die Anwendungs-ID (Client-ID) . Notieren Sie die Verzeichnis-ID (Tenant-ID) . Öffnen Sie Zertifikate und Geheimnisse . Erstellen Sie ein neues Client Secret. Notieren Sie sofort den angezeigten Secret-Wert. Der Secret-Wert kann im Microsoft-Portal später nicht erneut angezeigt werden. Hinterlegen Sie außerdem einen internen Termin zur rechtzeitigen Erneuerung vor dem Ablaufdatum. Microsoft-Graph-Berechtigungen vergeben Fügen Sie unter API-Berechtigungen folgende Microsoft Graph-Anwendungsberechtigungen hinzu: Berechtigung Verwendung Mail.Send Nachrichten aus einem Microsoft-365-Postfach versenden Mail.ReadWrite POP3-Abruf sowie Erstellen und Senden großer Nachrichten User.Read.All Anzeigename und sekundäre SMTP-, SIP-, X500- und weitere Proxyadressen für EWS ResolveNames Calendars.Read Optional: Kalendertermine über den EWS-Proxy lesen Contacts.Read Optional: Kontakte über den EWS-Proxy lesen Erteilen Sie anschließend die Administratorzustimmung für den Mandanten . Ohne Administratorzustimmung kann der Connector nicht auf die Postfächer zugreifen. Microsoft-Dokumentation zu Graph-Berechtigungen Zugriff auf Postfächer begrenzen Die Graph-Anwendungsberechtigungen können standardmäßig Zugriff auf alle Postfächer des Mandanten ermöglichen. Für einen möglichst kleinen Berechtigungsumfang empfiehlt sich Role Based Access Control for Applications in Exchange Online . Microsoft-Dokumentation zu Application RBAC Die Einrichtung von Exchange Application RBAC sollte durch die zuständige Microsoft-365-Administration erfolgen. Wichtig ist, dass die für SMTP und POP3 benötigten Postfächer vollständig im gewählten Bereich enthalten sind. Sicherheitshinweis: Berechtigungen aus Microsoft Entra ID und Exchange Application RBAC können additiv wirken. Lassen Sie die endgültige Berechtigungskonfiguration durch die Microsoft-365-Administration prüfen. Installation Programmdateien bereitstellen Kopieren Sie den vollständig gelieferten Programmordner an seinen endgültigen Speicherort. Verwenden Sie einen eigenen Ordner, beispielsweise: C:\MailBridge365 Verschieben oder löschen Sie diesen Ordner nach der Dienstinstallation nicht. Starten Sie MailBridge365.exe für die erstmalige Einrichtung mit Als Administrator ausführen . Die Dienstinstallation verwendet genau die EXE am aktuellen Speicherort. Eine zusätzliche Kopie der Anwendung wird nicht angelegt. Der technische Windows-Dienstname lautet MailBridge365 . In der Windows-Diensteverwaltung wird er als SMTP, POP3 und EWS MailBridge 365 angezeigt. Erkennt die Anwendung noch eine Installation unter dem früheren Dienstnamen, bietet die Oberfläche die automatische Umstellung an. Dabei wird der alte Dienst beendet und entfernt; Programmdateien, Einstellungen, Daten und Warteschlange bleiben bestehen. Vorhandene Installation kopieren oder verschieben Kennwörter und Client Secret sind nicht in der EXE oder ihrer Konfigurationsdatei enthalten. Sie liegen standardmäßig in folgenden verschlüsselten Dateien: \Secrets\smtp-password.bin \Secrets\oauth-client-secret.bin \Secrets\ews-client-password.bin Wird nur die EXE mit ihrer Konfigurationsdatei, aber ohne die Datenunterordner kopiert, müssen das gemeinsame SMTP/POP3-Kennwort und das OAuth-Client-Secret am neuen Speicherort erneut eingegeben werden. Dasselbe gilt nach einer Änderung des Datenpfads, wenn am neuen Ziel noch keine verschlüsselte Datei vorhanden ist. Die Oberfläche prüft dies vor dem Speichern und nennt den fehlenden Zielpfad. Bereits ausgefüllte Einstellungen bleiben dabei zur Korrektur erhalten. Die Verschlüsselung ist an den Windows-Computer gebunden. Beim Umzug auf einen anderen Computer müssen die beiden Geheimnisse daher auch dann neu eingegeben werden, wenn die verschlüsselten Dateien mitkopiert wurden. Verhalten beim ersten Start Beim ersten Start öffnet sich die grafische Oberfläche. Da noch keine Zugangsdaten hinterlegt sind, kann die lokale Instanz zunächst einen Konfigurationsfehler anzeigen. Bestätigen Sie diese Meldung und tragen Sie anschließend unter Einstellungen die benötigten Werte ein. Die Oberfläche besteht aus drei Bereichen: Übersicht: Status der lokalen Instanz und des Windows-Dienstes sowie die verwendeten Endpunkte und Pfade; außerdem Lizenzverwaltung und LiveUpdate Einstellungen: Konfiguration von Allgemein, POP3, SMTP, EWS-Proxy, Microsoft Graph, EWS-/Graph-Log, Webclient und Mail-Automatisierung Live-Protokoll: Laufende Diagnosemeldungen mit farblicher Kennzeichnung Lizenzierung und LiveUpdate Bei jedem Programmstart wird die Lizenz über das PHXFramework geprüft. Bei einem normalen interaktiven Start kann dabei der Lizenzdialog angezeigt werden. Beim Start als Windows-Dienst oder mit --nogui erfolgt dieselbe Prüfung ohne Dialogfenster. Den aktuellen Zustand zeigt die untere Statusleiste als Lizenz: gültig oder Lizenz: Demo / nicht gültig an. Über Übersicht → Lizenz verwalten kann der Lizenzdialog auch während des Betriebs geöffnet werden. Nach dem Schließen wird die Lizenz erneut geprüft und die Statusanzeige aktualisiert. Bei einer ungültigen Lizenz bleibt der Connector grundsätzlich betriebsfähig, ist jedoch auf ein normales Benutzerpostfach beschränkt. Das automatisch vorhandene Journalpostfach zählt nicht als normales Benutzerpostfach, seine Journalfunktion wird bei ungültiger Lizenz aber automatisch deaktiviert und kann nicht aktiviert werden. Ein weiteres manuell angelegtes oder über EWS angefragtes Postfach wird abgewiesen. Bereits gespeicherte zusätzliche Konten werden nicht gelöscht. Der Lizenzstatus und lizenzbedingte Ablehnungen werden im PHX-Lizenzprotokoll sowie im normalen Connector-Protokoll festgehalten. Über Übersicht → LiveUpdate wird die Aktualisierungsfunktion des PHXFrameworks gestartet. Sobald ein Update bestätigt und vorbereitet wurde, beendet die Oberfläche die lokale Connector-Instanz und stoppt den installierten Windows-Dienst. Danach wird das Programm geschlossen, damit der Updater die Programmdateien ersetzen kann. Falls der Dienst mangels Berechtigung nicht gestoppt werden kann, muss die Oberfläche als Administrator gestartet werden. Kundeneinstellungen liegen getrennt in MailBridge365.settings.config und werden durch den Austausch der erzeugten EXE.config nicht überschrieben. Konfiguration Registerkarte Allgemein Feld Beschreibung Empfehlung Datenpfad Ablageort für Warteschlange, Protokolle, POP3-Status und Geheimnisse Leer lassen, um den Programmordner zu verwenden Warteschlange prüfen Abstand zwischen zwei Prüfungen der Versandwarteschlange 10 Sekunden Maximale Versandversuche Höchstzahl der Versuche vor dem Verschieben nach DeadLetter 50 Verbindungs-Timeout Maximale Dauer einer Verbindung zu Microsoft 365 30 Sekunden Maximale Wartezeit beim Beenden Zeit für aktive SMTP-/POP3-Sitzungen zum sauberen Abschluss 30 Sekunden Ausführliche Debugprotokollierung Schreibt zusätzliche Diagnoseinformationen Nur zur Fehlersuche aktivieren Programmdateien und Betriebsdaten sind zwei getrennte Bereiche. Der gelieferte Programmordner enthält die Anwendung und alle benötigten Laufzeitdateien: ├── MailBridge365.exe ├── MailBridge365.exe.config ├── MailBridge365.settings.config ├── PHXFramework.dll ├── weitere mitgelieferte DLL-Dateien └── runtimes ├── win-x64\native\e_sqlite3.dll └── win-x86\native\e_sqlite3.dll Wichtig: Für Installation und Update muss immer der vollständig gelieferte Programmordner verwendet werden. Das alleinige Kopieren oder Umbenennen der EXE reicht nicht aus. MailBridge365.settings.config enthält die Kundeneinstellungen und muss bei einem Update erhalten bleiben. Der in der Konfiguration angegebene Datenpfad enthält die veränderlichen Betriebsdaten. Ist das Feld leer, ist der Datenpfad identisch mit dem Programmordner; die folgenden Ordner liegen dann direkt neben der EXE. Für einen Windows-Dienst ist ein eigener beschreibbarer Datenpfad meist übersichtlicher: ├── Queue │ ├── Incoming\\message.eml + envelope.xml │ ├── Pending\\message.eml + envelope.xml │ └── DeadLetter\\message.eml + envelope.xml ├── State │ ├── connector-state.db │ ├── Pop3 (nur Altbestand/Migration) │ └── EwsReplay (lokale Wiederholungsstände) ├── Mailboxes │ ├── - │ │ ├── Cache │ │ │ ├── Mail │ │ │ │ ├── Inbox │ │ │ │ ├── SentItems │ │ │ │ └── Folders\ │ │ │ ├── Calendar\index.xml │ │ │ └── Contacts\index.xml │ │ └── Drafts │ └── _Journal │ ├── Incoming │ └── Messages\<00>\<00>\.eml ├── Users │ ├── pop3-users.xml │ └── Secrets\.bin ├── Secrets │ ├── smtp-password.bin │ ├── oauth-client-secret.bin │ └── ews-client-password.bin ├── Certificates │ ├── MailBridge365-selfsigned.pfx │ └── MailBridge365-selfsigned-password.bin ├── Log │ ├── MailBridge365-.log │ └── MailBridge365-EWS-Graph-.log └── Actions └── Pending Die Postfachordner bestehen aus einem lesbaren Teil der Mailadresse und einer kurzen eindeutigen Kennung. Dadurch bleibt die Zuordnung für Administratoren erkennbar, ohne dass ungewöhnliche Zeichen oder gleichartige Adressen zu ungültigen beziehungsweise kollidierenden Windows-Pfaden führen. Ein abweichender lokaler Pfad oder UNC-Pfad kann angegeben werden. Das Konto des Windows-Dienstes benötigt dort die erforderlichen Zugriffsrechte. Bei einem UNC-Pfad benötigt das Computerkonto des Connector-Computers, beispielsweise FIRMA\MAILSERVER$ , passende Freigabe- und NTFS-Rechte am Zielserver. Außerdem müssen Netzwerkverbindung und Namensauflösung bereits beim Start des Windows-Dienstes verfügbar sein. Ein lokaler Datenpfad ist für einen besonders ausfallsicheren Betrieb vorzuziehen. Registerkarte EWS-Proxy Der EWS-Proxy stellt für bestehende Anwendungen einen lokalen, TLS-geschützten Teilumfang von Exchange Web Services bereit. Intern werden die Anforderungen mit Microsoft Graph und der vorhandenen Versandwarteschlange verarbeitet. Feld Beschreibung Empfehlung EWS-Graph-Proxy aktivieren Startet den lokalen EWS-Endpunkt Erst nach vollständiger Konfiguration aktivieren EWS-Adresse Lokale Bindeadresse 127.0.0.1 auf demselben Server, sonst eine gezielt erreichbare Serveradresse EWS-HTTPS-Port TCP-Port des lokalen Endpunkts 8444 Erlaubte EWS-Client-IP-Adressen Positivliste der zugelassenen Quelladressen Nur die Server der angebundenen Anwendung eintragen Gemeinsames EWS-Clientkennwort Optionales Kennwort für alle EWS-Benutzer; wird zuerst geprüft Für ERP-Legacy-Anbindungen ein eigenes langes Kennwort vergeben Microsoft-Bearer-Token interner Clients akzeptieren Akzeptiert das vom unveränderten ERP gesendete Bearer-Token ohne zweite Tokenprüfung Nur zusammen mit einer engen EWS-Client-IP-Positivliste verwenden Max. Einträge je EWS-Antwort Seitengröße für E-Mails; bei Terminen und Kontakten zugleich deren Cachegrenze 1000 MIME-Cache maximal Maximale Gesamtgröße vollständig geladener E-Mails 10240 MB MIME-Cache Aufbewahrung Zeitliche Bereinigung der vollständigen E-Mail-Dateien; 0 deaktiviert sie 30 Tage Cache aktualisieren Mindestabstand zwischen zwei Graph-Synchronisationen 30 Sekunden EWS-Löschungen an Exchange weitergeben Erlaubt DeleteItem über Graph Standardmäßig deaktiviert lassen Termine und Kontakte synchronisieren Stellt Kalendertermine und Kontakte über den EWS-Proxy lesend bereit Erst nach Vergabe von Calendars.Read und Contacts.Read aktivieren Globale Synchronisations-Stichtage Die beiden Felder befinden sich unter Einstellungen > Microsoft Graph : Feld Beschreibung Beispiel E-Mails bereitstellen ab Begrenzt E-Mails global für POP3, Webclient und EWS 14.09.2026 08:00 Termine bereitstellen ab Begrenzt Kalendertermine global; zukünftige Vorkommen älter angelegter Serien bleiben enthalten 14.09.2026 00:00 Die Eingabe gilt in der lokalen Zeitzone des Windows-Servers. Ein leeres Feld bedeutet unbegrenzt . Der E-Mail-Stichtag wird direkt an Microsoft Graph übergeben und bleibt Bestandteil des DeltaLinks. Dadurch werden ältere Mailinhalte weder vorab heruntergeladen noch später über den Connector bereitgestellt. MIME-Dateien werden unverändert nur bei einem tatsächlichen Abruf geladen. Nach einer Änderung des Stichtags beginnt der betroffene Graph-Abgleich mit einem neuen Delta-Stand. Nicht mehr zulässige lokale Metadaten werden still entfernt. Dabei entsteht ausdrücklich keine EWS-Löschanweisung an das ERP . Für Termine verwendet der Connector bei gesetztem Stichtag eine Kalenderansicht, die Serientermine in ihrem relevanten Zeitraum auflöst. E-Mail-Metadaten werden ohne feste Gesamtanzahl in der lokalen SQLite-Datei \State\connector-state.db geführt. Nach dem Erstabgleich verwendet der Connector je Ordner den von Microsoft Graph gelieferten DeltaLink und ruft nur noch Änderungen ab. Vollständige Mailinhalte werden erst bei Bedarf geladen. Die Größen- und Altersbereinigung des MIME-Dateicaches erzeugt niemals eine EWS-Löschanweisung an das ERP. Löschereignisse entstehen ausschließlich aus einer tatsächlichen Graph-Änderung oder einer ausdrücklich erlaubten Client-Löschung. Registerkarte EWS-/Graph-Log Dieser Reiter steuert ein eigenes tägliches Diagnoseprotokoll ausschließlich für die Kommunikation des Connectors mit dem EWS-Client und Microsoft Graph. Das normale Live-Protokoll bleibt davon unabhängig bestehen. Feld Beschreibung Empfehlung Detailstufe Legt fest, wie ausführlich EWS- und Graph-Vorgänge in die separate Datei geschrieben werden Im Normalbetrieb 1 – Standard , zur Fehlersuche vorübergehend 2 – Detailliert oder 3 – Protokoll Mailinhalte protokollieren Nimmt bei Detailstufe 3 zusätzlich MIME-/Mailinhalte in das Diagnoseprotokoll auf Aus Datenschutz- und Speichergründen deaktiviert lassen und nur gezielt kurzzeitig einschalten Änderungen an diesen Einstellungen werden nach einem Neustart der lokalen Instanz beziehungsweise des Windows-Dienstes wirksam. Über Live-Protokoll → EWS-/Graph-Log öffnen lässt sich die Datei des aktuellen Tages direkt öffnen. Der einzutragende EWS-Endpunkt lautet: https://:/EWS/Exchange.asmx Das Serverzertifikat wird automatisch erzeugt und im Datenpfad wiederverwendet. Es ist selbstsigniert und muss daher auf dem Computer der angebundenen Anwendung als vertrauenswürdig hinterlegt oder dort ausdrücklich akzeptiert werden. Die EWS-Anmeldung verwendet Benutzername und Kennwort aus der Benutzerverwaltung . Das Konto darf nicht gesperrt sein und der Schalter für den Exchange-Online-Abruf muss aktiviert sein. Ein EWS-Benutzer kann nur auf sein eigenes Postfach zugreifen und nur mit seiner eigenen Absenderadresse senden. Optional kann im Reiter EWS-Proxy ein gemeinsames EWS-Clientkennwort hinterlegt werden. Der Proxy prüft dieses Kennwort zuerst. Stimmt es nicht, wird als Fallback weiterhin das individuelle Kennwort des angegebenen Benutzers geprüft. Das gemeinsame Kennwort hebt weder Kontosperren noch die benutzerspezifische Ordnerfreigabe auf und wird DPAPI-verschlüsselt gespeichert. Wenn der ERP-Client sein vorhandenes Microsoft-Tenant-Client-Secret weiterhin zur Tokenbeschaffung verwendet, bleibt dessen Struktur unverändert. Mit Microsoft-Bearer-Token interner Clients akzeptieren nimmt der Proxy das daraus entstandene Bearer-Token an, ohne es nochmals kryptografisch zu prüfen. Die Quelladresse muss in der EWS-IP-Positivliste stehen; das in ExchangeImpersonation genannte Konto muss vorhanden, entsperrt und für den Exchange-Online-Zugriff aktiviert sein. Diese Option ist nur für abgeschottete interne Netze vorgesehen. In der Benutzerverwaltung kann zusätzlich Nur Mailversand und den Ordner „Gesendete Elemente“ synchronisieren aktiviert werden. Der Schalter hält den Exchange-Online-Zugriff automatisch aktiv, beschränkt den EWS-Nachrichtenabruf aber auf sentitems . In dieser Betriebsart werden nur die notwendigen Basisordner an den EWS-Client übermittelt; benutzerdefinierte und versteckte Exchange-Ordner werden nicht angelegt. Posteingang und alle anderen Ordner werden beim Nachrichtenabruf leer beantwortet. Versand über CreateItem / SendItem bleibt vollständig möglich. Die Einstellung betrifft den EWS-Proxy und ändert nicht eigenständig das Verhalten eines separat verwendeten POP3-Clients. Mit Nachrichten aus „Gesendete Elemente“ nicht übertragen kann zusätzlich auch die Rückübertragung aus sentitems vollständig abgeschaltet werden. Der Basisordner bleibt sichtbar, enthält für den Client jedoch keine synchronisierten Nachrichten. Das Erstellen und Versenden neuer Nachrichten über EWS ist davon nicht betroffen. Die Option ist standardmäßig deaktiviert. Für diesen eingeschränkten Modus steht zusätzlich Doppelte Mails im Ordner „Gesendete Elemente“ vermeiden zur Verfügung. Der Connector merkt sich die Kennungen der über seinen EWS-Endpunkt versendeten Nachrichten und unterdrückt deren anschließende Rückübertragung aus Microsoft 365 an denselben EWS-Client. Damit erscheint eine vom ERP versendete Nachricht dort nicht zuerst als lokaler Versand und danach ein zweites Mal als synchronisierte Exchange-Kopie. Die Nachricht bleibt in Microsoft 365 und Outlook unverändert einmal vorhanden und wird weiterhin journalisiert. Nachrichten, die außerhalb des Connectors etwa mit Outlook oder einem Mobilgerät gesendet wurden, werden weiterhin regulär an das ERP übertragen. Die Dublettenvermeidung wirkt nur zusammen mit Nur Mailversand und den Ordner „Gesendete Elemente“ synchronisieren . Sie entfernt keine bereits vorhandenen Dubletten aus dem ERP. Bei einer absichtlich ausgelösten Bereinigung des lokalen Synchronisationsstands können noch vorhandene Nachrichten erneut angeboten werden. Ist das adressierte Postfach noch nicht in der Benutzerverwaltung vorhanden, legt der Connector es nach einer erfolgreichen vertrauenswürdigen EWS-Anmeldung automatisch an. Das gilt für das gemeinsame EWS-Clientkennwort und den ausdrücklich freigegebenen internen Bearer-Modus. Zuvor wird der Zugriff auf das Postfach über Microsoft Graph geprüft. Das neue Benutzerkonto übernimmt die unter Vorgaben für neue Benutzer gespeicherten Werte für Exchange-Online-Abruf, EWS-Synchronisation, Unterdrückung gesendeter Elemente und Dublettenvermeidung. Ein bestehendes Konto und dessen Einstellungen werden niemals automatisch überschrieben; gesperrte Konten bleiben gesperrt. Bei aktivierter Option Termine und Kontakte synchronisieren ergänzt der Proxy den EWS-Ordnerbaum um Kalender und Kontakte und überträgt deren Inhalte lesend über SyncFolderItems , FindItem und GetItem . Auch spätere Änderungen werden über EWS-Pull-Benachrichtigungen an das ERP gemeldet. Die Daten werden unter DataPath\Mailboxes\\Cache\Calendar beziehungsweise Contacts zwischengespeichert. Dafür benötigt die Entra-App zusätzlich die Anwendungsberechtigungen Calendars.Read und Contacts.Read . Änderungen durch das ERP sowie Aufgaben werden in dieser Ausbaustufe nicht unterstützt. Kalendertermine werden bei GetItem zusätzlich als iCalendar-Inhalt in MimeContent bereitgestellt. Dadurch können auch ältere ERP-Clients, die den Termin nicht ausschließlich aus den strukturierten EWS-Feldern aufbauen, den Kalendereintrag vollständig übernehmen. Unterstützt werden: GetFolder und FindFolder für den jeweils freigegebenen Mailordner FindItem , GetItem und GetAttachment einschließlich MIME-Inhalt CreateItem mit SaveOnly , SendOnly und SendAndSaveCopy SendItem für lokal gespeicherte Entwürfe UpdateItem für gelesen/ungelesen DeleteItem , sofern ausdrücklich aktiviert SyncFolderItems mit lokalem Synchronisationsstand SyncFolderHierarchy für die Ordnererkennung ResolveNames für die in den ERP-Protokollen verwendete Postfachprüfung Subscribe , GetEvents und Unsubscribe für Pull-Subscriptions Bei ResolveNames berücksichtigt der Proxy die Clientanforderung ReturnFullContactData=true . Die Antwort enthält dann zusätzlich zum Postfach einen vollständigen EWS-Kontakt mit Anzeigename, bis zu drei sekundären SMTP-, SIP-, X500- oder weiteren Proxyadressen und ContactSource . Die primäre SMTP-Adresse bleibt separat im Mailbox -Block. Dafür ist die Graph- Anwendungsberechtigung User.Read.All mit Administratorzustimmung erforderlich. Kann Graph die Benutzerinformationen nicht lesen, bleibt die Namensauflösung funktionsfähig, liefert jedoch nur die primäre Adresse und protokolliert einen Warnhinweis. Dies ist für ältere ERP-Verbindungstests erforderlich, die eine reine Postfachauflösung trotz NoError nicht als erfolgreiche Verbindung anerkennen. Für den freigegebenen Standardordner verwendet der Proxy die von Microsoft Graph gelieferte unveränderliche Ordner-ID. Dadurch erkennt ein bereits eingerichteter ERP-Client seinen bisherigen Microsoft-365-Ordner auch nach der Umstellung auf den Proxy wieder. Übermittelt der Client beim Abonnieren zusätzlich seine alte vollständige Exchange-Ordnerliste, akzeptiert der Proxy die Anfrage, ignoriert die nicht freigegebenen Ordner und erstellt intern ausschließlich ein Abonnement für den erlaubten Ordner. Die SOAP-Struktur des Clients muss nicht geändert werden. Der EWS-Systemordner publicfoldersroot wird für die Kompatibilität mit der ERP-Ordnerverwaltung angeboten. Ein vollständiger inhaltlicher Abgleich echter Exchange-Online-Public-Folder-Postfächer über Microsoft Graph ist jedoch nicht Bestandteil dieser Version. Nicht enthalten sind schreibende Kalender-/Kontaktoperationen, Aufgaben, Regeln, vollständiger Public-Folder-Inhaltsabgleich, Stellvertretungen, Streaming-/Push-Abonnements und sonstige EWS-Spezialbereiche. Der EWS-Proxy ist deshalb eine Kompatibilitätsschicht für typische Mailzugriffe und keine vollständige Exchange-Server-Nachbildung. EWS-Nachrichten werden je Benutzerpostfach unter DataPath\Mailboxes\\Cache\Mail gespeichert. Posteingang, Gesendete Elemente und weitere Ordner besitzen darunter getrennte Verzeichnisse. Nachrichten liegen als einzelne .eml -Dateien im jeweiligen Ordner und erhalten keinen eigenen Unterordner. Die unveränderliche Graph-ID ist eindeutig indiziert. Wiederholte FindItem -, GetItem - oder SyncFolderItems -Aufrufe legen dieselbe Nachricht daher nicht mehrfach ab. Innerhalb des Aktualisierungsintervalls werden Anfragen direkt aus dem lokalen Cache beantwortet. Ist Graph vorübergehend nicht erreichbar, bleibt der bereits vorhandene Cache lesbar; der Fehler wird im Protokoll ausgewiesen. Beim Versand meldet der Connector Erfolg, nachdem die Nachricht dauerhaft in seiner lokalen Warteschlange gespeichert wurde. Die anschließende Graph-Zustellung erfolgt durch die bestehende Warteschlangenverarbeitung und ist im Live-Protokoll nachvollziehbar. Dadurch gehen angenommene Nachrichten bei einem vorübergehenden Graph- oder Netzwerkfehler nicht verloren. Kann eine über EWS angenommene Nachricht auch nach den konfigurierten Wiederholungsversuchen nicht an Microsoft Graph übergeben werden, stellt der Connector sie dem ursprünglichen EWS-Benutzer als lokale Nachricht im Posteingang bereit. Der Betreff beginnt mit Unzustellbar: , der Header X-MailBridge365-Delivery-Error enthält den technischen Fehler. Dies gilt auch für Benutzer mit Nur Mailversand und Gesendete Elemente synchronisieren : Normale Posteingangsmails werden in diesem Modus weiterhin nicht übertragen, lokale Unzustellbarkeiten jedoch schon. Die Rückmeldung besitzt eine stabile EWS-ID und wird nach erfolgreichem GetItem nicht erneut als neues Synchronisationsereignis gemeldet. Sie bleibt im lokalen Posteingang sichtbar, bis sie über EWS gelöscht wird oder durch einen anderen freigegebenen Zugriff wie POP3 oder Webclient aus DeadLetter entfernt wurde. Die Funktion Lokalen Synchronisationsstand bereinigen setzt auch diesen Rückgabestand zurück und bietet noch vorhandene Unzustellbarkeiten erneut an. Für einen ersten Funktionstest liegt Test-EwsProxy.ps1 bei. Beispiel: .\Test-EwsProxy.ps1 -Server 127.0.0.1 -Port 8444 ` -User benutzer@firma.at -Password "LokalesKennwort" Registerkarte SMTP Feld Beschreibung Beispiel SMTP aktivieren Startet den lokalen SMTP-Eingang. Bei deaktivierter Option werden fehlende SMTP-Adresse, Port, Benutzername, Kennwort und Absenderfreigaben nicht beanstandet Nur aktivieren, wenn Anwendungen per SMTP senden sollen SMTP-Adresse Lokale IP-Adresse, auf der SMTP angenommen wird 127.0.0.1 SMTP-Port Port für die ältere Anwendung 2525 Erlaubte Client-IP-Adressen Geräte, die den Connector verwenden dürfen 127.0.0.1,::1 SMTP-Benutzername Gemeinsamer lokaler Benutzername alte-anwendung Gemeinsames SMTP/POP3-Kennwort Gemeinsames lokales Kennwort Sicheres, eigenes Kennwort SMTP STARTTLS erzwingen Erfordert eine verschlüsselte Verbindung vor der Anmeldung Für LAN-Zugriffe aktivieren TLS-Zertifikat-Thumbprint Fingerabdruck des Windows-Zertifikats Nur bei STARTTLS erforderlich Ungültige/selbstsignierte TLS-Zertifikate zulassen Verwendet auch ein abgelaufenes, selbstsigniertes oder nicht vertrauenswürdiges Zertifikat Nur für Tests oder kontrollierte interne Netze Fehlendes TLS-Zertifikat automatisch erstellen Erstellt ohne eingetragenen Thumbprint einmalig ein selbstsigniertes Notfallzertifikat Nur als interne Notlösung verwenden Erlaubte Absender Vollständige Adressen erlaubter Absendepostfächer rechnung@firma.at Erlaubte Absender-Domains Alternative Freigabe einer vollständigen Domain firma.at Maximale Nachrichtengröße Grenze der kompletten SMTP-/MIME-Nachricht in Byte 26214400 Maximale Empfänger Höchstzahl der Empfänger pro Nachricht 100 Mehrere Werte werden mit Komma oder Semikolon getrennt. Ist SMTP aktivieren ausgeschaltet, startet kein SMTP-Listener. POP3, EWS-Proxy, Webclient, Journal und die Verarbeitung bereits vorhandener Warteschlangeneinträge können unabhängig davon weiterlaufen. Für bestehende Konfigurationen ist SMTP nach dem Update standardmäßig weiterhin aktiviert. Wichtig: Sobald mindestens eine vollständige Adresse unter Erlaubte Absender eingetragen ist, wird ausschließlich diese Adressliste verwendet. Die Domainfreigabe dient nur als Alternative, wenn die Adressliste leer ist. Registerkarte POP3 Feld Beschreibung Empfehlung POP3 aktivieren Schaltet den POP3-Endpunkt ein Nur bei benötigtem Mailabruf aktivieren POP3-Adresse Lokale IP-Adresse, auf der POP3 angenommen wird 127.0.0.1 POP3-Port Port für den alten Mailclient 2110 Erlaubte POP3-Postfächer Vollständige Adressen einzelner Postfächer eingang@firma.at Erlaubte POP3-Domains Erlaubt alle Postfächer einer Domain firma.at POP3 STLS erzwingen Erfordert Verschlüsselung vor der Anmeldung Für LAN-Zugriffe aktivieren Maximale Nachrichten Höchstzahl der noch nicht übertragenen Nachrichten pro Anmeldung 1000 Maximale POP3-Mailgröße Maximale MIME-Größe einer Nachricht in Byte 52428800 Nach RETR als gelesen markieren Markiert vollständig abgerufene Nachrichten in Outlook als gelesen Nach Bedarf Übertragene Nachrichten bei QUIT löschen Löscht erfolgreich übertragene Nachrichten nach sauberem Sitzungsende Nur nach bewusster Entscheidung aktivieren POP3-DELE in Exchange zulassen Gibt ein ausdrückliches DELE des Clients bei sauberem QUIT an Exchange weiter Nur aktivieren, wenn der Mailclient löschen darf Der POP3-Benutzername ist immer die vollständige Mailadresse des gewünschten Postfachs. Für nicht verwaltete, über die Freigabelisten erlaubte Postfächer wird das gemeinsame lokale SMTP/POP3-Kennwort verwendet. Das persönliche Microsoft-365-Kennwort ist dafür nicht erforderlich. Über Benutzerverwaltung auf der Registerkarte Übersicht können zusätzlich eigene Konten angelegt werden. Für ein dort vorhandenes Konto ist bei POP3 immer dessen individuelles Kennwort erforderlich. Das gemeinsame Kennwort wird für dieses Konto nicht mehr akzeptiert. Nicht eigens angelegte Postfächer können weiterhin über die Postfach- oder Domainfreigabe und das gemeinsame Kennwort verwendet werden. Für jedes verwaltete Konto stehen folgende Optionen zur Verfügung: Option Bedeutung Benutzer / Mailadresse Vollständige Mailadresse und POP3-Benutzername Kennwort Lokales Kennwort für POP3 und SMTP AUTH; kein Microsoft-365-Kennwort Exchange-Online-Abruf Erlaubt für dieses Konto den Microsoft-Graph-Abruf durch POP3 und EWS EWS-Synchronisation Optional: Nur Mailversand und den Ordner „Gesendete Elemente“ synchronisieren; andere EWS-Ordner bleiben leer Übertragung unterdrücken Optional: Nachrichten aus „Gesendete Elemente“ nicht an ERP oder EWS-Mailclient übertragen; der Versand bleibt möglich Doppelte gesendete Mails Verhindert im eingeschränkten EWS-Modus, dass eine über den Connector versendete Nachricht anschließend als zweite Versandkopie aus Microsoft 365 an das ERP zurückgegeben wird Lokalen Synchronisationsstand bereinigen Einmalige Vormerkung: Beim nächsten POP3- oder EWS-Abruf werden die lokalen Übertragungsstände dieses Benutzers zurückgesetzt Journalpostfach Kennzeichnet das einmalige, rein lokale Archivpostfach Journalfunktion Aktiviert die Übernahme ein- und ausgehender Mailkopien Konto gesperrt Verhindert SMTP-, POP3-, Webclient- und EWS-Zugriffe dieses Kontos Vorgaben für neue Benutzer Oberhalb der Benutzerliste befindet sich der getrennte Bereich Vorgaben für neue Benutzer . Dort können folgende Startwerte festgelegt werden: Exchange-Online-Abruf aktivieren Nur Mailversand und den Ordner „Gesendete Elemente“ synchronisieren Nachrichten aus „Gesendete Elemente“ nicht übertragen Doppelte Mails im Ordner „Gesendete Elemente“ vermeiden Mit Vorgaben speichern werden diese Werte dauerhaft gespeichert. Sie gelten ab diesem Zeitpunkt sowohl für die manuelle Neuanlage über Neu als auch für Benutzer, die nach einer erfolgreichen vertrauenswürdigen EWS-Anmeldung automatisch angelegt werden. Vorhandene Benutzer werden durch eine Änderung der Vorgaben ausdrücklich nicht verändert. Die abhängigen Optionen werden automatisch konsistent gehalten: Ohne Exchange-Online-Abruf kann der Modus für Gesendete Elemente nicht aktiviert werden; ohne diesen Modus ist auch die Übertragungsunterdrückung nicht aktiv. Wenn gar keine gesendeten Elemente übertragen werden, ist die zusätzliche Dublettenvermeidung nicht erforderlich und wird deaktiviert. Die Vorgaben und Benutzerkonten liegen gemeinsam in \Users\pop3-users.xml ; eine manuelle Bearbeitung der XML-Datei ist nicht erforderlich. Beim Bearbeiten eines Kontos zeigen acht Sternchen an, dass bereits ein Kennwort gespeichert ist. Bleibt dieser Platzhalter unverändert, wird das bisherige Kennwort beibehalten. Die Bereinigung wird beim nächsten Abruf automatisch ausgeführt und anschließend im Benutzerkonto wieder deaktiviert. Noch in Exchange vorhandene Nachrichten werden erneut angeboten. Dabei wird keine Nachricht in Microsoft 365 gelöscht oder verändert; im ERP können durch den gewünschten erneuten Import Duplikate entstehen. Für das rein lokale Journalpostfach steht diese Funktion nicht zur Verfügung, da bereits per POP3 gelöschte Journaldateien nicht aus Exchange wiederhergestellt werden können. Ein verwaltetes Konto darf sein eigenes Postfach auch als SMTP-Absender verwenden. Die bisherigen gemeinsamen SMTP-Zugangsdaten und Absenderfreigaben bleiben parallel bestehen. Änderungen in der Benutzerverwaltung werden von einer laufenden Instanz automatisch übernommen. SMTP, POP3 und das Live-Protokoll werden beim Öffnen oder Schließen der Benutzerverwaltung nicht gestoppt. Eine Änderung gilt für die nächste Anmeldung; eine bereits authentifizierte Verbindung läuft regulär bis zu ihrem Ende weiter. Beim ersten Öffnen wird journal@localhost automatisch als deaktiviertes Journalpostfach angelegt. Es darf genau ein Journalpostfach geben. Seine Adresse kann beim Bearbeiten geändert werden. Vor der erstmaligen Aktivierung muss ein neues lokales Kennwort für das Archivsystem vergeben werden. Das Journalpostfach kann nicht für SMTP AUTH verwendet werden und greift nicht auf Exchange Online zu. Das Archivsystem meldet sich mit der Journaladresse am lokalen POP3-Endpunkt an. Abgeholte Journalnachrichten werden nur nach einem ausdrücklichen DELE und einem sauberen QUIT lokal entfernt. Ausgehende SMTP- und EWS-Nachrichten werden vor dem Graph-Versand abgelegt. Eingehende Nachrichten werden beim POP3-, EWS- oder Webclient-Abgleich übernommen. Beim EWS-Abgleich werden sowohl der Posteingang als auch Gesendete Elemente berücksichtigt. Die vollständigen MIME-Dateien werden im Hintergrund geladen; das Öffnen einer einzelnen Nachricht ist daher nicht erforderlich. Stabile Graph-UIDLs und die MIME-Message-ID verhindern, dass dieselbe Nachricht über mehrere Zugriffswege doppelt journalisiert wird. Jede Journalnachricht wird als einzelne .eml -Datei unter \Mailboxes\_Journal\Messages gespeichert. Der dauerhafte SQLite-Index \State\connector-state.db bleibt auch nach dem Löschen einer Journalnachricht erhalten. Ein wiederholter Abruf derselben Quellmail erzeugt daher keinen neuen Journaleintrag. Beim erstmaligen Wechsel von einer Version vor 3.18.18 auf Version 3.18.18 oder neuer werden ältere Cache-, Journal- und Synchronisationsdaten nicht in die neue Ordnerstruktur übernommen. Die Programmkonfiguration, Benutzerverwaltung und verschlüsselten Geheimnisse bleiben erhalten. Microsoft-365-Inhalte werden beim nächsten Zugriff neu abgeglichen; in einer produktiven Installation ist deshalb vor der Umstellung eine gesonderte Migrationsplanung erforderlich. Ein Postfach ist erlaubt, wenn entweder seine vollständige Adresse oder seine Domain freigegeben ist. Eine Domain wird ohne @ eingetragen. Die Freigabe von firma.at schließt tochter.firma.at nicht automatisch ein. Sicherheitshinweis: Eine Domainfreigabe erlaubt jedem berechtigten Client, mit dem gemeinsamen Kennwort auf alle Postfächer dieser Domain zuzugreifen, soweit auch die Microsoft-365-App Zugriff besitzt. Einzelne Postfachfreigaben sind daher vorzuziehen. Registerkarte Mail-Automatisierung Feld Beschreibung E-Mail-Steuerzeichen auswerten Aktiviert oder deaktiviert die Funktion global Eingehende E-Mails (POP3) prüfen Wertet Steuerzeichen beim Abruf einer Nachricht über POP3 aus Ausgehende E-Mails (SMTP) prüfen Wertet Steuerzeichen beim Versand einer Nachricht über SMTP aus Erkannte Steuerzeichen aus der E-Mail entfernen Entfernt erkannte [[NAME=WERT]] -Felder nach der Auswertung aus Betreff sowie Text- und HTML-Inhalt Ausgabeordner für INI-Dateien Zielordner; leer verwendet \Actions\Pending Nachgelagertes Programm Optionales Programm, das nach dem Erstellen einer INI-Datei gestartet wird Die globale Option muss aktiviert sein. Anschließend können Eingangs- und Ausgangsprüfung unabhängig voneinander ein- oder ausgeschaltet werden. Die Entfernung der Steuerzeichen erfolgt nur, wenn mindestens ein gültiges Steuerzeichen erkannt und in eine INI-Datei übernommen wurde. Anlagen werden nicht verändert. Steuerzeichen können im Betreff oder Nachrichtentext in folgender Form stehen: [[AUFTRAG=4711]] [[KUNDENNUMMER=10025]] [[AKTION=LieferscheinDrucken]] Ein Name beginnt mit einem Buchstaben und darf anschließend Buchstaben, Zahlen, Punkt, Bindestrich und Unterstrich enthalten. Jede in einer aktivierten Richtung verarbeitete Mail mit mindestens einem erkannten Steuerfeld erzeugt eine eigene UTF-8-kodierte INI-Datei: [Message] QueueId=7d7e5f... Direction=Ausgang CreatedUtc=2026-09-03T10:15:30.0000000Z Sender=versand@firma.at Recipients=empfaenger@firma.at Subject=Auftrag 4711 MessageId= MimeDate=2026-09-03T12:15:00.0000000+02:00 ControlCount=3 [Variables] AUFTRAG=4711 KUNDENNUMMER=10025 AKTION=LieferscheinDrucken Direction enthält je nach Verarbeitungsweg den Wert Eingang oder Ausgang . Bei Eingang wird die Nachricht beim POP3-Abruf geprüft. Bei Ausgang erfolgt die Prüfung bei der SMTP-Annahme vor der Ablage in der Versandwarteschlange. Ist ein nachgelagertes Programm hinterlegt, wird es nach erfolgreicher INI-Erstellung gestartet. Als erstes Argument erhält es den vollständigen Pfad der INI-Datei. Werte aus der Mail werden nicht als Befehlszeile ausgeführt. Bei einem eigenen Ausgabeordner muss das Konto des Windows-Dienstes dort Änderungsrechte besitzen. Sicherheitshinweis: Inhalte eingehender Mails sind nicht vertrauenswürdig. Das nachgelagerte Programm muss erlaubte Aktionen und Werte selbst prüfen. Es sollte eine INI-Datei erst nach erfolgreicher Verarbeitung entfernen oder in einen eigenen Archivordner verschieben. Registerkarte Microsoft Graph Feld Beschreibung Wert Tenant-ID Verzeichnis-ID aus der App-Registrierung Mandantenspezifische GUID Client-ID Anwendungs-ID aus der App-Registrierung Anwendungsspezifische GUID Client Secret Secret-Wert aus Microsoft Entra ID Vertraulich behandeln Graph-Basisadresse Microsoft-Graph-Endpunkt https://graph.microsoft.com/v1.0 OAuth-Scope OAuth2-Berechtigungsbereich https://graph.microsoft.com/.default Parallele Graph-Anfragen je Postfach Gemeinsame Obergrenze für Versand, POP3 und Webclient 2 (zulässig: 1 bis 4) Wiederholungen bei Graph-Drosselung Anzahl direkter Wiederholungen bei HTTP 429, 503 und 504 3 (zulässig: 0 bis 10) Kennwort und Client Secret werden automatisch unter DataPath\Secrets verschlüsselt für den lokalen Computer gespeichert. Ein eigener Dateipfad ist nicht erforderlich. Nach dem Speichern zeigt die Oberfläche ******** an. Dies bedeutet, dass bereits ein Wert vorhanden ist. Der Platzhalter wird nicht als Kennwort gespeichert. Registerkarte Webclient Feld Beschreibung Empfehlung HTTPS-Webclient aktivieren Startet die lokale Weboberfläche Nur bei Bedarf aktivieren Webclient-Adresse IP-Adresse des HTTPS-Endpunkts 127.0.0.1 , für LAN-Zugriff 0.0.0.0 HTTPS-Port Frei wählbarer TCP-Port 8443 Nachrichten im Webclient löschen erlauben Zeigt die endgültige Löschfunktion an Nur für berechtigte Benutzer aktivieren Nach einem Dienstneustart ist der Webclient beispielsweise unter https://127.0.0.1:8443 erreichbar. Bei einer LAN-Freigabe muss zusätzlich die Client-IP in Erlaubte Client-IP-Adressen enthalten und der Port in der Windows-Firewall freigegeben sein. Das TLS-Zertifikat wird automatisch unter \Certificates erzeugt und bei späteren Starts wiederverwendet. Es muss kein Thumbprint konfiguriert werden. Weil es selbstsigniert ist, meldet ein Browser das Zertifikat zunächst als nicht vertrauenswürdig. Für eine warnungsfreie interne Verwendung kann das erzeugte Zertifikat auf den zugreifenden Geräten durch die Administration als vertrauenswürdig verteilt werden. Die Anmeldung erfolgt mit einer Mailadresse und dem zugehörigen Kennwort aus der Benutzerverwaltung. Normale Benutzer sehen ausschließlich ihr eigenes Exchange-Postfach und lokale Unzustellbarkeiten. Das Journalpostfach wird mit dem aktivierten Journalbenutzer geöffnet. Der Webclient verwendet sichere Sitzungscookies, CSRF-Schutz und beendet inaktive Sitzungen nach 30 Minuten. HTML-Mailinhalte werden nicht als aktiver Fremdcode ausgeführt, sondern HTML-kodiert als Text angezeigt. Ist die Löschfunktion freigegeben, werden Exchange-Nachrichten sofort über Microsoft Graph gelöscht. Journal- und Dead-Letter-Nachrichten werden lokal entfernt. Die Löschung wird protokolliert. Einstellungen speichern Tragen Sie alle erforderlichen Werte ein. Wählen Sie Speichern . Die Anwendung schreibt die Eingaben dauerhaft in MailBridge365.settings.config . Anschließend wird die vollständige Konfiguration geprüft. Fehler bei dieser Prüfung werden als Warnung angezeigt, setzen die gespeicherten Eingaben jedoch nicht zurück. Korrigieren Sie den genannten Wert und speichern Sie erneut. Die dauerhafte Einstellungsdatei liegt neben der EXE und wird nicht aus der Programmvorlage neu erzeugt. Dadurch bleiben Einstellungen bei einem erneuten Build oder einem Update im selben Programmordner erhalten. Eine vorhandene MailBridge365.settings.config darf beim Aktualisieren nicht gelöscht oder durch eine leere Datei ersetzt werden. Läuft der Windows-Dienst bereits, übernimmt er Änderungen erst nach einem Neustart über Übersicht → Dienst neu starten . Netzwerkbetrieb und TLS Anwendung und Connector auf demselben Computer Verwenden Sie vorzugsweise: Adresse: 127.0.0.1 Erlaubte Client-IP-Adressen: 127.0.0.1,::1 Damit sind SMTP und POP3 nur lokal erreichbar. Zugriff aus dem lokalen Netzwerk Für den Zugriff von einem anderen Computer: Stellen Sie die gewünschte Listen-Adresse auf 0.0.0.0 oder auf eine konkrete lokale IP-Adresse. Tragen Sie ausschließlich die benötigten Client-IP-Adressen ein. Erstellen Sie passende eingehende Regeln in der Windows-Firewall. Aktivieren Sie STARTTLS beziehungsweise STLS. Hinterlegen Sie den Thumbprint eines geeigneten Zertifikats. Das Zertifikat muss einschließlich privatem Schlüssel im Zertifikatsspeicher Lokaler Computer\Persönlich vorhanden sein. Das Dienstkonto NETWORK SERVICE benötigt Leserechte auf den privaten Schlüssel. Ein abgelaufenes, selbstsigniertes oder anderweitig nicht vertrauenswürdiges Zertifikat wird nur verwendet, wenn Ungültige/selbstsignierte TLS-Zertifikate zulassen aktiviert ist. Diese Einstellung hebt ausschließlich die Prüfung im Connector auf. Der SMTP- oder POP3-Client muss das Zertifikat ebenfalls akzeptieren beziehungsweise dessen Aussteller als vertrauenswürdig kennen. Für ein manuell ausgewähltes Zertifikat bleibt der Thumbprint erforderlich. Alternativ kann Fehlendes TLS-Zertifikat automatisch erstellen aktiviert werden. Ist kein Thumbprint eingetragen, erzeugt der Connector beim nächsten Start ein selbstsigniertes Zertifikat mit dem Computernamen als Zertifikatsname. Das Zertifikat ist fünf Jahre gültig und wird dauerhaft unter DataPath\Certificates gespeichert. Sein zufälliges PFX-Kennwort liegt dort separat und durch Windows DPAPI verschlüsselt. Beim nächsten Start wird dasselbe Zertifikat erneut verwendet. Ein verwendbares Zertifikat mit eingetragenem Thumbprint hat Vorrang. Kann dieses Zertifikat nicht geladen werden, wird bei aktivierter Notfalloption ebenfalls das automatisch erzeugte Zertifikat benutzt. Das automatisch erzeugte Zertifikat ermöglicht die TLS-Aushandlung, ersetzt aber kein vertrauenswürdiges Unternehmens- oder öffentliches Zertifikat. Der Client kann es weiterhin wegen des unbekannten Ausstellers oder eines nicht zum Verbindungsnamen passenden Computernamens ablehnen. Der private Schlüssel wird beim Programmstart in einen Windows-kompatiblen Schlüsselcontainer geladen und während der gesamten Laufzeit gemeinsam für SMTP und POP3 verwendet. Dadurch kann der Windows-TLS-Stack auf den Schlüssel zugreifen, ohne für jede Clientverbindung einen neuen Schlüssel anzulegen. Unterstützt werden SMTP STARTTLS und POP3 STLS. Implizites SMTPS auf Port 465 und implizites POP3S werden nicht unterstützt. Wichtig: Stellen Sie die SMTP- und POP3-Ports niemals öffentlich im Internet bereit. Windows-Dienst einrichten Prüfen Sie zunächst über Lokalen Proxy starten , ob die Konfiguration fehlerfrei ist. Beenden Sie eine laufende lokale Instanz bei Bedarf. Wählen Sie unter Übersicht die Aktion Dienst installieren . Bestätigen Sie die Windows-Administratorabfrage. Warten Sie auf die Meldung, dass der Dienst installiert und gestartet wurde. Die Installation erfolgt direkt durch die Anwendung. Es werden keine externen Installationsskripte benötigt. Der Dienst startet automatisch mit Windows und läuft unter dem Konto NETWORK SERVICE . Die Installation erstellt alle benötigten Datenunterordner und vergibt die Schreibrechte für Warteschlange, Index, Journal, EWS-Cache, Benutzerverwaltung, Protokolle und Zertifikate. Die Aktion Dienst neu starten prüft und repariert diese Ordnerrechte erneut. Wenn der Dienst läuft, startet die Oberfläche keine zweite lokale Instanz auf denselben Ports. Status und Live-Protokoll können trotzdem angezeigt werden. Kontrolliertes Beenden des Dienstes Beim Stoppen oder Neustarten beendet der Connector nicht sofort alle Clientverbindungen: SMTP und POP3 nehmen keine neuen Verbindungen mehr an. Bereits aktive Sitzungen dürfen ihre laufende Übertragung und die Abmeldung regulär abschließen. Sobald keine aktiven Clientverbindungen mehr vorhanden sind, wird der Dienst unmittelbar beendet. Sind nach Ablauf der unter Maximale Wartezeit beim Beenden eingestellten Zeit weiterhin Verbindungen aktiv, werden diese getrennt und der Dienst wird beendet. Das Zeitlimit gilt gemeinsam für SMTP und POP3 und kann zwischen 5 und 300 Sekunden eingestellt werden. Der Standardwert beträgt 30 Sekunden. Beginn, Wartezustand und ein gegebenenfalls erreichtes Zeitlimit werden protokolliert. Alte Anwendung konfigurieren SMTP-Versand Einstellung im alten Programm Wert SMTP-Server IP-Adresse oder DNS-Name des Connector-Computers SMTP-Port Standardmäßig 2525 Authentifizierung SMTP AUTH LOGIN oder PLAIN Benutzername Gemeinsamer SMTP-Benutzer oder verwaltete Mailadresse Kennwort Gemeinsames Kennwort beziehungsweise individuelles Benutzerkennwort Verschlüsselung STARTTLS entsprechend der Connector-Konfiguration Die Mail muss genau eine gültige From: -Adresse enthalten. Diese Adresse bestimmt das Microsoft-365-Absendepostfach und muss im Connector erlaubt sein. From: rechnung@firma.at → Versand über das Postfach rechnung@firma.at → Ablage in Gesendete Elemente von rechnung@firma.at POP3-Abruf Einstellung im alten Mailclient Wert POP3-Server IP-Adresse oder DNS-Name des Connector-Computers POP3-Port Standardmäßig 2110 Benutzername Vollständige Microsoft-365-Mailadresse Kennwort Individuelles Benutzerkennwort, andernfalls gemeinsames Kennwort Verschlüsselung STLS entsprechend der Connector-Konfiguration Falls ein alter Client ausschließlich Port 110 unterstützt, kann der POP3-Port auf 110 geändert werden. Prüfen Sie vorher, ob dieser Port bereits verwendet wird und ob für das Binden des Ports ausreichende Rechte vorhanden sind. Verhalten des POP3-Abrufs Zuerst werden lokale, dauerhaft unzustellbare Ausgangsmails des angemeldeten Benutzers geprüft. Sind solche lokalen Nachrichten vorhanden, werden in dieser Anmeldung nur diese Nachrichten angeboten. Microsoft 365 wird dabei nicht abgefragt. Der Betreff erhält beim Abruf das Präfix Unzustellbar: . Der technische Versandfehler wird zusätzlich im Mail-Header X-MailBridge365-Delivery-Error mitgegeben. Nach vollständigem RETR und einem sauberen QUIT wird die lokale Nachricht aus DeadLetter entfernt. Bei einem Verbindungsabbruch bleibt sie für den nächsten Abruf erhalten. Sind keine lokalen unzustellbaren Nachrichten vorhanden und ist der Exchange-Online-Abruf für das Konto aktiv, wird der Posteingang über Microsoft Graph geladen. Ist der Exchange-Online-Abruf für das Konto deaktiviert, dient POP3 ausschließlich zur Rückgabe lokaler unzustellbarer Nachrichten. Bereits erfolgreich übertragene Nachrichten werden zuerst anhand ihrer UIDL ausgefiltert. Das Nachrichtenlimit wird erst danach angewendet. Bei aktivem Journal werden neue Nachrichten bereits beim Öffnen des Postfachs in das lokale Journal übernommen, auch wenn der Client danach nur LIST und UIDL , aber kein RETR sendet. Bei einem Limit von 10 werden daher bis zu zehn noch nicht übertragene Nachrichten angeboten. Sind die neuesten Nachrichten bereits übertragen, rücken ältere, noch nicht übertragene Nachrichten nach. Pro Postfach ist gleichzeitig nur eine POP3-Sitzung zulässig. Neue Nachrichten erscheinen bei der nächsten POP3-Anmeldung. RETR überträgt den originalen MIME-Inhalt der Nachricht. TOP liefert nur den gewünschten Teil und gilt nicht als vollständiger Abruf. UIDL verwendet stabile Nachrichtenkennungen. Optional wird eine vollständig abgerufene Nachricht als gelesen markiert. Im Modus nicht löschen bleiben Nachrichten in Microsoft 365 erhalten und werden nach erfolgreichem Abruf lokal als bereits übertragen vermerkt. Im Löschmodus werden Nachrichten erst bei einem sauberen QUIT gelöscht. Jede erfolgreich mit RETR gelieferte Graph-Nachricht wird zusätzlich lokal als übertragen vermerkt. Eine fehlgeschlagene Exchange-Löschung führt deshalb nicht zu einem dauerhaften erneuten Angebot derselben Nachricht. Mit POP3-DELE in Exchange zulassen wird ein echtes DELE des Clients erst bei einem sauberen QUIT über Microsoft Graph ausgeführt. Ist die Option aus, lehnt der Connector DELE für Exchange-Nachrichten ab. Ein Verbindungsabbruch vor QUIT führt im Löschmodus nicht zur Löschung. RSET hebt Löschvormerkungen der aktuellen Sitzung auf. Der dauerhafte Übertragungsstatus befindet sich in der SQLite-Datenbank unter: \State\connector-state.db Löschen Sie diese Datei nicht unbedacht. Andernfalls können bereits übertragene und in Microsoft 365 belassene Nachrichten erneut angeboten werden. Nachrichtengröße und Anhänge Die Standardgrenze für die vollständige SMTP-Nachricht beträgt 25 MiB. Dazu gehören Nachrichtentext, MIME-Kopfzeilen, Anhänge und die durch Base64 entstehende Vergrößerung. Der Connector wählt den Versandweg automatisch: Kleine Nachrichten werden direkt als MIME-Nachricht versendet. Große Nachrichten werden als Entwurf angelegt. Große Anhänge werden blockweise über eine Microsoft-Graph-Upload-Sitzung übertragen. Nach erfolgreichem Upload wird der Entwurf versendet. Bei einem Fehler startet der nächste Warteschlangenversuch den Vorgang neu. Zusätzlich gelten immer die Größen- und Empfängergrenzen von Exchange Online und des betreffenden Postfachs. Microsoft-Dokumentation zu großen Anhängen Warteschlange und Wiederholungsversuche Eine SMTP-Nachricht wird zunächst dauerhaft in der lokalen Warteschlange gespeichert. Erst danach bestätigt der Connector die Annahme gegenüber der alten Anwendung. \Queue ├── Incoming ├── Pending └── DeadLetter Ordner Bedeutung Incoming Nachricht wird gerade übernommen Pending Nachricht wartet auf Versand oder einen erneuten Versuch DeadLetter Nachricht konnte dauerhaft nicht versendet werden Bei vorübergehenden Fehlern versucht der Connector den Versand erneut. Von Microsoft Graph vorgegebene Wartezeiten werden berücksichtigt. Ohne eine solche Vorgabe wird der Abstand schrittweise erhöht. Unerwartete Fehler werden standardmäßig nach einer Minute erneut versucht. Zusätzlich schützt eine zentrale Begrenzung alle Graph-Zugriffe durch SMTP, POP3 und Webclient. Standardmäßig werden je Postfach höchstens zwei Anfragen gleichzeitig ausgeführt. Bei HTTP 429 (Drosselung), 503 oder 504 wird die Anfrage bis zu drei Mal direkt wiederholt. Der Connector beachtet dabei den Microsoft-Header Retry-After ; fehlt er, wird exponentiell mit einem kleinen Zufallsanteil gewartet. Die Wartezeit ist abbrechbar, damit der Dienst sauber beendet werden kann. Jede Wiederholung erscheint mit Postfach, Vorgang, HTTP-Status und Wartezeit im Protokoll. Nach Erreichen der maximalen Versuchszahl wird die Nachricht nach DeadLetter verschoben. Beim nächsten POP3-Abruf des Absenders wird sie als lokale Unzustellbarkeit angeboten. Dabei wird in derselben Sitzung nicht zusätzlich der Microsoft-365-Posteingang abgefragt. Der Ordner und das Protokoll sollten dennoch regelmäßig überwacht werden. Wurde die Nachricht ursprünglich über EWS angenommen, erscheint dieselbe lokale Unzustellbarkeit außerdem im EWS-Posteingang des Absenders. FindItem , SyncFolderItems und EWS-Pull-Benachrichtigungen liefern dabei dieselbe stabile lokale Nachrichten-ID; dadurch wird sie nicht bei jeder Abfrage erneut ins ERP übertragen. Erst eine ausdrücklich erlaubte EWS-Löschung entfernt den Eintrag aus DeadLetter . Abgrenzung: Diese lokale Rückmeldung betrifft Fehler, bei denen die Übergabe an Microsoft Graph endgültig scheitert. Nimmt Microsoft 365 die Mail zunächst an und erzeugt erst später einen eigenen Zustellbericht, ist dieser Bericht eine normale Nachricht im Exchange-Online-Posteingang und wird im vollständigen Posteingangsmodus regulär synchronisiert. Hinweis: In einem seltenen Grenzfall kann eine Nachricht doppelt versendet werden, wenn Microsoft 365 die Nachricht angenommen hat, die Bestätigung den Connector aber nicht mehr erreicht. Protokollierung Das Live-Protokoll befindet sich in der Oberfläche unter Live-Protokoll . Die Protokolldateien liegen zusätzlich unter: \Log Das getrennte EWS-/Graph-Diagnoseprotokoll wird bei aktivierter Detailstufe als folgende Tagesdatei geführt: \Log\MailBridge365-EWS-Graph-yyyy-MM-dd.log Das Protokoll enthält unter anderem: Start und Ende des Connectors Angenommene und abgewiesene Verbindungen Versandstatus und Warteschlangen-ID POP3-Anmeldungen und Abrufstatus OAuth2- und Microsoft-Graph-Fehler Wiederholungsversuche und Dead-Letter-Vorgänge ungültige Lizenz und die dadurch wirksame Benutzerbegrenzung gesperrte oder entsperrte Benutzerkonten bewusst deaktivierte oder lizenzbedingt nicht bereitgestellte Postfächer automatisch deaktivierte Journalfunktion Der bereinigte SMTP- und POP3-Dialog wird immer aufgezeichnet. Er ist nicht von der Einstellung Ausführliche Debugprotokollierung abhängig. C: kennzeichnet Befehle des Clients, S: die Antworten des Connectors. Eine kurze Sitzungskennung verbindet zusammengehörige Zeilen auch bei mehreren gleichzeitigen Verbindungen: Unbekannte Befehle werden mit ihrem tatsächlichen Befehlsnamen protokolliert. Nicht druckbare Binärdaten, beispielsweise ein irrtümlich direkt gesendeter TLS-Handshake, erscheinen als kurze Hex-Darstellung. Nur die Argumente bleiben aus Sicherheitsgründen ausgeblendet. [PROTOCOL] SMTP[a1b2c3d4] C: EHLO altsystem [PROTOCOL] SMTP[a1b2c3d4] C: AUTH LOGIN [PROTOCOL] SMTP[a1b2c3d4] S: 235 2.7.0 Authentication successful [PROTOCOL] SMTP[a1b2c3d4] C: [PROTOCOL] POP3[e5f6a7b8] C: USER postfach@firma.at [PROTOCOL] POP3[e5f6a7b8] C: PASS [PROTOCOL] POP3[e5f6a7b8] S: +OK 3 messages [PROTOCOL] SMTP[a1b2c3d4] C: Unbekannter Befehl: XCLIENT; Argumente ausgeblendet Folgende Inhalte werden niemals in das normale Live- und Hauptprotokoll übernommen: Kennwörter hinter PASS Base64-Anmeldedaten von SMTP AUTH LOGIN und AUTH PLAIN OAuth2-Tokens und Client Secrets SMTP-Nachrichteninhalt nach DATA über POP3 übertragener MIME-Nachrichteninhalt Argumente unbekannter SMTP- oder POP3-Erweiterungsbefehle Bei POP3-Kommandos wie LIST und UIDL werden die normalen Serverzeilen mitgeführt. Bei großen Postfächern können die täglichen Protokolldateien deshalb deutlich wachsen und sollten hinsichtlich Speicherverbrauch überwacht werden. Der allgemeine Debugmodus ergänzt unabhängig davon weitere technische Diagnoseinformationen im Hauptprotokoll. Kennwörter, Client Secrets, OAuth-Tokens und Nachrichtentexte werden dort ebenfalls nicht protokolliert. Aktivieren Sie den Debugmodus nur während der Fehlersuche und deaktivieren Sie ihn danach wieder. Getrenntes EWS-/Graph-Diagnoseprotokoll Für eine gezielte Schnittstellenanalyse stehen vier Detailstufen zur Verfügung: Stufe Inhalt 0 – Aus Es wird keine separate EWS-/Graph-Datei geschrieben 1 – Standard Vorgang, betroffenes Postfach, Ergebnis, HTTP-Status und EWS-Antwortcode 2 – Detailliert Zusätzlich Ziel-URLs, Laufzeiten, Datenmengen, Wiederholungen und vollständige Fehlerdetails 3 – Protokoll Zusätzlich bereinigte HTTP- und SOAP-Protokolldaten Die Option Mailinhalte protokollieren wirkt ausschließlich zusammen mit Stufe 3. Ist sie deaktiviert, werden EWS-Felder wie MIMEContent , Body und Content durch einen Platzhalter mit Zeichenanzahl ersetzt. Ist sie aktiviert, können Mailtext, MIME-Daten und Anlageninhalte personenbezogene oder vertrauliche Daten enthalten. Einzelne Mailinhalte werden deshalb auf 64 KiB und komplette Protokolleinträge auf 256 KiB begrenzt. Die Option sollte nur für eine konkrete Fehlersuche und nur so kurz wie erforderlich eingeschaltet werden. Kennwörter, Client Secrets, OAuth-Tokens und der Wert des HTTP-Headers Authorization werden unabhängig von Detailstufe und Inhaltsoption niemals ausgegeben. Die Detailstufe 3 – Protokoll kann dennoch große Tagesdateien erzeugen; freier Speicherplatz und Aufbewahrung der Dateien sind zu überwachen. Microsoft-Graph-Aktivitäten Die wichtigsten Microsoft-Graph-Aktionen werden unabhängig vom Debugmodus mit der Stufe [GRAPH] protokolliert. Damit ist erkennbar, ob der Connector gerade sendet, den Posteingang auflistet oder eine Nachricht für POP3 abruft. Beim Versand enthält das Protokoll unter anderem: Queue-ID und verwendetes Absendepostfach Anzahl der Empfänger und MIME-Gesamtgröße, jedoch keine Empfängeradressen gewählter Versandweg: direkt oder über Entwurf und Upload-Sitzung Anzahl und Gesamtgröße der Anhänge, jedoch keine Dateinamen oder Inhalte Fortschritt großer Anhänge pro Datenblock verkürzte Graph-Nachrichtenkennung und HTTP-Status Beim POP3-Abruf enthält es unter anderem: abgefragtes Postfach und eingestelltes Nachrichtenlimit Nummer und Größe jeder abgerufenen Posteingangsseite Anzahl geprüfter, bereits übertragener und angebotener Nachrichten Beginn und Ende eines MIME-Abrufs einschließlich Byteanzahl Markierung als gelesen oder Löschung über Microsoft Graph automatische Wiederholungen mit HTTP-Status, Wiederholungsnummer und Wartezeit Hinweis, wenn Graph wegen lokaler Unzustellbarkeiten oder einer Benutzereinstellung bewusst nicht abgefragt wird Auch die Anforderung eines OAuth2-Access-Tokens wird mit HTTP-Status und Gültigkeitsende protokolliert. Das Token selbst, Client Secret, Mailbetreff, Nachrichtentext, Anhanginhalte und Empfängeradressen werden nicht ausgegeben. [GRAPH] Versand startet; Queue-ID=...; Postfach=versand@firma.at; Empfänger=2; MIME-Bytes=18425 [GRAPH] Direkter Versand beantwortet; Queue-ID=...; Postfach=versand@firma.at; HTTP=202 [GRAPH] POP3-Abruf startet; Postfach=einkauf@firma.at; maximales Angebot=100 [GRAPH] POP3-Abrufliste fertig; Postfach=einkauf@firma.at; geprüft=12; bereits übertragen=9; angeboten=3 Bei aktivierter Dublettenvermeidung bestätigt das detaillierte EWS-Protokoll die Unterdrückung einer eigenen Versandkopie beispielsweise mit: [EWS-DETAIL] Eigene Versandkopie nicht erneut an den EWS-Client übertragen; Postfach=...; Graph-ID=...; Message-ID=... Funktionstest SMTP testen Im Programmordner befindet sich das Testskript Test-SmtpProxy.ps1 . .\Test-SmtpProxy.ps1 ` -From "rechnung@firma.at" ` -To "empfaenger@firma.at" Test mit Anhang: .\Test-SmtpProxy.ps1 ` -From "rechnung@firma.at" ` -To "empfaenger@firma.at" ` -AttachmentPath "C:\Temp\Test.pdf" Kontrollieren Sie anschließend: Die Meldung im Live-Protokoll. Den Eingang beim Empfänger. Den Ordner Gesendete Elemente des verwendeten Absendepostfachs. POP3 testen Im Programmordner befindet sich das Testskript Test-Pop3Proxy.ps1 . .\Test-Pop3Proxy.ps1 -Mailbox "eingang@firma.at" Das Skript zeigt den Postfachstatus und die UIDL-Liste an. Es ruft keine Nachricht vollständig ab und löscht keine Nachricht. Fehlerbehebung Lokale Instanz startet nicht Prüfen Sie: Sind Tenant-ID, Client-ID, Benutzername und erlaubte Absender ausgefüllt? Wurden das gemeinsame Kennwort und das Client Secret gespeichert? Ist der SMTP- oder POP3-Port bereits durch einen anderen Prozess belegt? Ist bei aktiviertem TLS ein gültiger Zertifikat-Thumbprint hinterlegt? Erscheint 454 TLS not available , ist kein verwendbares Zertifikat geladen. Prüfen Sie den Zertifikatsspeicher Lokaler Computer\Persönlich , den Thumbprint, den privaten Schlüssel und gegebenenfalls die Option für ungültige/selbstsignierte Zertifikate. Als Notlösung kann die automatische Zertifikatserstellung aktiviert werden. Besitzt die Anwendung Zugriff auf den Datenpfad? Öffnen Sie anschließend das Live-Protokoll und aktivieren Sie bei Bedarf vorübergehend den Debugmodus. Fehlende NuGet-, PHX- oder SQLite-Laufzeitdatei Eine erfolgreiche Kompilierung garantiert bei einem klassischen .NET-Framework-Projekt nicht, dass alle indirekten Abhängigkeiten einer referenzierten DLL im Zielordner liegen. Die Konfigurationsdatei des PHXFramework.dll wird ebenfalls nicht automatisch in die Konfiguration des Hauptprogramms übernommen. Deshalb müssen immer die EXE-Konfiguration, alle verwalteten DLLs und der vollständige Ordner runtimes ausgeliefert werden. Der Connector prüft die wichtigsten Dateien vor dem Start der PHX-Lizenzierung. Fehlende Dateien werden gesammelt angezeigt und zusätzlich in MailBridge365-StartupError.log protokolliert, sofern der Ordner beschreibbar ist. Bei Library e_sqlite3 not found muss insbesondere folgende Datei für einen normalen 64-Bit-Prozess vorhanden sein: runtimes\win-x64\native\e_sqlite3.dll Führen Sie in Visual Studio NuGet-Pakete wiederherstellen , anschließend Projektmappe bereinigen und Projektmappe neu erstellen aus. Der Build bricht nun bereits ab, falls die nativen SQLite-Dateien des Pakets SQLitePCLRaw.bundle_e_sqlite3 nicht verfügbar sind. Verschlüsselte Kennwort- oder Secret-Datei wurde nicht gefunden Öffnen Sie die Einstellungen und geben Sie je nach Meldung das gemeinsame SMTP/POP3-Kennwort, das OAuth-Client-Secret oder das gemeinsame EWS-Kennwort erneut ein. Kontrollieren Sie außerdem den Datenpfad. Die verschlüsselten Dateien werden automatisch im Unterordner Secrets abgelegt; der Wert kann nicht aus der Konfigurationsdatei rekonstruiert werden. Windows-Dienst startet nicht Prüfen Sie zusätzlich: Befindet sich die EXE noch im Ordner, aus dem der Dienst installiert wurde? Ist MailBridge365.settings.config weiterhin neben der EXE vorhanden? Besitzt NETWORK SERVICE Zugriff auf Programm- und Datenpfad? Besitzt NETWORK SERVICE Änderungsrechte auf \State ? Ist ein konfigurierter UNC-Pfad beim Systemstart erreichbar? Kann der Computer die Microsoft-Endpunkte über HTTPS erreichen? OAuth2-Anmeldung schlägt fehl Typische Ursachen sind: falsche Tenant-ID falsche Client-ID abgelaufenes oder falsch eingetragenes Client Secret fehlende Administratorzustimmung blockierter Zugriff auf login.microsoftonline.com Erstellen Sie bei einem abgelaufenen Secret ein neues Secret in Microsoft Entra ID und speichern Sie den neuen Wert anschließend in der Oberfläche. Microsoft Graph antwortet mit 403 Forbidden Prüfen Sie: Sind Mail.Send , Mail.ReadWrite und User.Read.All als Anwendungsberechtigungen vorhanden? Sind bei aktiviertem Termin-/Kontaktabgleich zusätzlich Calendars.Read und Contacts.Read als Anwendungsberechtigungen vorhanden? Wurde die Administratorzustimmung erteilt? Enthält ein verwendeter Exchange-RBAC-Bereich das betroffene Postfach? Existiert das Absendepostfach und ist es für den Versand geeignet? POP3 meldet „mailbox is temporarily unavailable“ Prüfen Sie: Ist die vollständige Postfachadresse oder deren Domain erlaubt? Kann Microsoft Graph das Postfach öffnen? Ist bereits eine andere POP3-Sitzung für dasselbe Postfach aktiv? Besitzt die Entra-Anwendung Mail.ReadWrite für dieses Postfach? Ist das gemeinsame lokale Kennwort korrekt? Bei einem Konto aus der Benutzerverwaltung prüfen Sie zusätzlich das individuelle Kennwort, den Kontostatus und die Option Exchange-Online-Abruf . Die konkrete Microsoft-Graph-Fehlermeldung steht im Live-Protokoll. Nachricht bleibt in Pending Der Connector versucht vorübergehend fehlgeschlagene Nachrichten automatisch erneut zu senden. Prüfen Sie im Protokoll den letzten Fehler und die Warteschlangen-ID. Bei einem dauerhaften Fehler müssen Absenderfreigabe, Microsoft-365-Berechtigungen, Nachrichtengröße und Empfänger geprüft werden. Nachricht liegt in DeadLetter Beheben Sie zuerst die im Protokoll angegebene Ursache. Verschieben oder verarbeiten Sie die Dateien im Ordner DeadLetter nur nach Rücksprache mit dem zuständigen Support, damit keine Nachricht beschädigt oder doppelt versendet wird. Nachricht erscheint im ERP doppelt unter Gesendete Elemente Aktivieren Sie beim betroffenen Benutzer sowohl Nur Mailversand und den Ordner „Gesendete Elemente“ synchronisieren als auch Doppelte Mails im Ordner „Gesendete Elemente“ vermeiden . Die zweite Option ist nur in dieser Kombination wirksam. Starten Sie danach den Abgleich erneut und kontrollieren Sie bei Bedarf das EWS-/Graph-Protokoll. Die Einstellung verhindert künftige doppelte Rückübertragungen von Nachrichten, die über den Connector versendet wurden. Sie löscht keine bereits vorhandenen Dubletten aus dem ERP. Versandkopien, die außerhalb des Connectors entstanden sind, werden weiterhin übertragen. Betrieb und Wartung Überwachen Sie regelmäßig das Live-Protokoll und den Ordner DeadLetter . Kontrollieren Sie den freien Speicherplatz des Datenpfads. Sichern Sie Konfiguration, Warteschlange, POP3-Status und Geheimnisdateien. Erneuern Sie das Client Secret rechtzeitig vor dessen Ablauf. Prüfen Sie nach Änderungen in Microsoft 365 den SMTP- und POP3-Zugriff. Halten Sie die Listen erlaubter IP-Adressen und Postfächer möglichst klein. Deaktivieren Sie die Debugprotokollierung nach abgeschlossener Fehlersuche. Datensicherung Für eine vollständige Sicherung sollten folgende Daten gemeinsam gesichert werden: MailBridge365.settings.config \Queue \Mailboxes \State \Certificates \Secrets \Users \Actions Der Ordner \Log kann für Nachweis- und Diagnosezwecke zusätzlich gesichert werden, ist für eine technische Wiederherstellung aber nicht erforderlich. Programmdateien werden aus dem zur gesicherten Version passenden Installationspaket wiederhergestellt; die vollständige Laufzeitumgebung einschließlich runtimes und der DLL-Dateien muss dabei erhalten bleiben. Die Geheimnisdateien sind über Windows DPAPI an den lokalen Computer gebunden. Eine reine Kopie auf einen anderen Computer reicht daher nicht aus. Auf einem neuen Computer müssen das gemeinsame Kennwort und das Client Secret erneut über die Oberfläche gespeichert werden. Deinstallation Starten Sie MailBridge365.exe mit Administratorrechten. Öffnen Sie Übersicht . Wählen Sie Dienst deinstallieren . Bestätigen Sie die Sicherheitsabfrage und die Windows-Administratorabfrage. Prüfen Sie, ob der Dienst als Nicht installiert angezeigt wird. Die Deinstallation entfernt ausschließlich die Registrierung des Windows-Dienstes. Programmdateien, Konfiguration, Warteschlange, POP3-Status, verschlüsselte Geheimnisse und Protokolle bleiben erhalten und können nach einer abschließenden Datensicherung manuell entfernt werden. Supportinformationen Stellen Sie bei einer Supportanfrage möglichst folgende Informationen bereit: Zeitpunkt des Fehlers betroffene Funktion: SMTP, POP3, OAuth2 oder Dienststart verwendetes Absender- beziehungsweise POP3-Postfach relevante Meldungen aus dem Live-Protokoll aktivierte Netzwerk- und TLS-Einstellungen Information, ob der Fehler dauerhaft oder nur zeitweise auftritt Übermitteln Sie niemals das gemeinsame SMTP/POP3-Kennwort, das Client Secret oder OAuth-Tokens per unverschlüsselter E-Mail. OnlinePay Zahlungsmodul Einrichtung Umfang Die Installation von Online-Pay enthält zwei ausführbare Programme: Online-Pay.exe Mit diesem Tool werden die Terminals konfiguriert und können auch getestet werden. Die Schnittstelle kann als Applikation oder Dienst laufen. Online-PayTray.exe Dieses Tool kann optional pro Windows-User für Kassenarbeitsplätze eingerichtet werden um ggf. Zahlungen oder Terminalfunktionen abzubrechen und die Steuerung wieder an die Handelskasse zu übergeben. Installation Wichtig Für die Einrichtung von OnlinePay sind folgende Informationen erforderlich: Verbindungsart: TCP/IP oder seriell TCP/IP: IP-Adresse und Port (Zahlungsanbieter/IT-Betreuer) (beides kann aber auch über den integrierten Netzwerkscan gefunden werden) wichtig ist eine fixe IP        seriell: Serieller Anschluss (COM-Port) Baud-Rate Stop Bits, ParityBits und FlowControl Die Terminalkennwörter liegen dem Terminal üblicherweise bei bzw. müssen beim Anbieter erfragt werden. Je nach Zahlungsanbieter werden auch nicht alle Kennwörter genutzt. Registrierung Initialisierung Autorisierung Gutschriften  1. Download Die OnlinePay Bankomatschnittstelle kann über unseren FTP-Server heruntergeladen werden. Dieser ist erreichbar unter ftp.erpaustria.com. Melden Sie sich hier einfach mit "bwpartner" als Benutzername und Passwort an. Navigieren Sie hier zu Phoenix Entwicklung  und rechtsklicken Sie auf das Verzeichnis BueroWARE Online-Pay, um über das Menü den Download zu starten. Nun sollte der Download eines Archives (Archiv.zip) gestartet werden. 2. Entpacken  Sobald dieses fertig heruntergeladen ist, kann es in das richtige Verzeichnis verschoben und dort entpackt werden: Sollte sich zB. am gleichen Laufwerk wie die BüroWARE-Installationen bereits ein Verzeichnis mit dem Namen APP.PhoenixDS befinden, wird das Archiv am besten dorthin verschoben und entpackt: 3. Live Update Öffnen SIe im daraufhin erstellten Verzeichnis die Anwendung Online-Pay.exe Bevor mit der Anbindung an die BüroWARE und das Terminal fortgefahren werden kann, muss die Schnittstelle als erstes auf die neueste Version Version aktualisiert werden. Folgen Sie hier einfach dem Assistenten durch das Update. OnlinePay startet sich dabei neu. Wichtig: bei Updates muss der Dienst SoftENGINE OnlinePay (wenn OnlinePay als Dienst installiert worden ist) sowie falls verwendet die OnlinePay-Tray.exe beendet werden , damit alle Komponenten aktualisiert werden können. Lizenz Jede Kassa wird in Onlinepay einzeln lizenziert. Werden mehrere Schnittstellen auf getrennten PCs ausgeführt (ohne zentralen Server), müssen auch getrennte Lizenzen verwendet werden. Läuft OnlinePay am Server, können in einer Lizenz auch mehrere Kassen lizenziert werden.  Die Anzahl der lizenzierten Kassen bezieht sich dabei nur auf die laufenden Kassen. Die Lizenzen werden nicht einzelnen Kassen zugeordnet, die Sie in OnlinePay eingerichtet haben. Wenn Sie zB. 5 Kassen lizenziert haben, können Sie 10 Kassen einrichten, aber es können nur 5 (beliebige) Kassen zugleich laufen. Lizenz einspielen Ihre Lizenz für OnlinePay erhalten Sie von ERP Austria per Mail. Die angehängte Lizenzdatei können Sie herunterladen und in OnlinePay importieren. Hier können Sie den Lizenzschlüssel über "Lizenzdatei öffnen" importieren, die Seriennummer und Name werden dann automatisch befüllt. (Alternativ kann die Seriennummer auch manuell eingetragen werden) Anschließend auf "Seriennummer Freischalten" klicken. Sollte sich die Lizenz nicht freischalten lassen, wenden Sie sich bitte an den Support. Verwendung ohne Lizenz OnlinePay lässt sich auch ohne Lizenz als Demoversion verwenden.  Dabei läuft die Schnittstelle in einem eingeschränktem Modus mit einem erhöhten Resourcenverbrauch. BüroWARE Kassa verbinden Im nächsten Schritt muss über die globalen Einstellungen rechts oben der Programm- und Mandantenpfad der zu verwendenden BüroWARE definiert werden. Der Mandantenpfad muss nur befüllt werden, wenn die Schnittstelle grundsätzlich nur mit einem Mandanten arbeiten soll. ansonsten kann dieses Feld leer gelassen werden. In der SoftENGINE Kassa sind folgende Einstellungen notwendig: Navigieren Sie in den Kassenstammdaten zu den OnlinePay-Einstellungen: Hier muss die Giro-/Kreditkartenanbindung entsprechend auf 2: Online-Pay umgestellt werden. Tragen Sie den Kommunikationspfad entsprechend ein. Legen Sie diesen bitte zuvor im OnlinePay-Programmpfad als Unterordner an. Hinterlegen Sie bitte das Formular 026 als Zahlvorgangsprotokoll und hinterlegen Sie den gewünschten Drucker. Beim Kassenschnitt sollte entweder "automatisch ausführen" oder "Nach Abfrage" ausgewählt werden. Damit kann der Tagesabschluss im Bankomatterminal nicht übersehen oder vergessen werden. In den Basisdaten ist dann im Menü "Bearbeiten/Kassiervorgang Abschließen und Drucken" noch einzustellen, wie die Kassenlade bei reinen Kartenzahlungen reagieren soll: Wenn in der SoftENGINE Kassa alle Einstellungen getroffen sind, können Sie in der Schnittstelle über den Button "Kassenstammdaten prüfen" die neuen Einstellungen aus der Kassa laden. mehrere Kassen Werden im eingetragenen BüroWARE-Pfad mehrere (in der BüroWARE konfigurierte Kassen) erkannt, legt OnlinePay für jede Kassa einen eigenen Punkt in den Einstellungen an: hier kann dann für jede Kassa das Terminal und die restlichen Einstellungen vorgenommen werden. Dabei können auch unterschiedliche Terminals/Verbindungsprotokolle usw. verwendet werden, da die Terminalkonfiguration nur für die jeweilige Kassa gilt.  Wichtig: Jedes Bankomatterminal darf nur einer Kassa zugeordnet werden, da es sonst zu Problemen bei der Zuordnung/Kommunikation kommen kann.  Bankomatterminal verbinden Bankomatterminals können sowohl über TCP/IP als auch den COM-Port an OnlinePay angebunden werden.  In beiden Fällen müssen die entsprechenden Initialsierungs/Registirierungskennwörter des Terminals in der Schnittstelle eingetragen werden. Sie erhalten diese von Ihrem Zahlungsanbieter. TCP/IP für die Anbindung per TCP muss die Verbindungsart auf TCP/IP umgestellt werden (Online Pay startet sich dabei neu) Ist die IP Adresse und der Port des Terminals bekannt, können diese Daten direkt eingetragen werden.  Online Pay bietet aber auch die Möglichkeit, Zahlungsterminals im Netzwerk zu suchen und die Schnittstelle darauf einzustellen. Verlassen Sie hierfür die Einstellungen und starten Sie über das Fernglas "Zahlungsterminals im Netzwerk suchen" den entsprechenden Assistenten. Der Assistent führt Sie durch die Suche. Es können immer nur 254 IP-Adressen durchsucht werden.  Natürlich können auch externe Netzwerkscanner verwendet werden, um vorhandene Terminals zu finden. RS-232 Soll das Terminal über eine serielle Schnittstelle /RS-232 angebunden werden, navigieren Sie in die Einstellungen der Kassa: Dort muss die Verbindungsart auf "Seriell" gestellt werden, außerdem der verwendete COM-Port mit der entsprechenden Baud-Rate und der Anzahl der Stopbits konfiguriert werden.   Welcher COM-Port verwendet wird, kann über den Gerätemanager oder den Konsolenbefehl change port /query herausgefunden werden. OnlinePay testen Starten Sie die Schnittstelle der jew. Kassa in der Applikation und führen Sie eine Diagnose durch: Hier sollten keine Fehler = roten Einträge auftauchen. Starten Sie über die Online Pay-Applikation einen Zahlungsvorgang: hierbei wird eine Zahlung über 1 € an das Terminal gesendet. bei erfolgreicher Zahlung kommt vom Bankomatterminal eine entsprechende Rückmeldung, die auch in der Schnittstelle angezeigt wird. Im letzten Schritt sollten die Vorgänge von der SoftENGINE Kassa aus getestet werden. Starten Sie über Kassendesktop - Einstellungen eine elPAY Diagnose Die Rückmeldung vom Terminal sollte nun auf dem richtigen Drucker ausgedruckt werden Kassieren Sie in der Kassa einen Testbeleg und führen Sie eine Bankomatzahlung durch Die Zahlung sollte am Bankomaten aufgerufen werden und nach erfolgreichem Abschluss auch an die Kassa zurückgegeben werden. Die Bankomatbons sollten auf dem eingestellten Drucker ausgedruckt werden. OnlinePay verwenden Wenn die OnlinePay Bankomatschnittstelle soweit erfolgreich eingerichtet und getestet worden ist, kann sie für den Produktiveinsatz gestartet werden. Das ist entweder als Applikation oder als Dienst möglich.  Zum Start der Applikation einfach die jeweilige Kassa auswählen und über den grünen Pfeil starten. Jede Kassa muss einzeln gestartet werden. alternativ kann OnlinePay als Dienst installiert werden.  Hierbei muss einfach "Als Dienst Installieren" ausgewählt werden. Der Dienst wird standardmäßig unter der Bezeichnung "SoftENGINE Online-Pay Service" installiert. Der Dienst beinhaltet immer alle aktiven Kassen. Soll eine Kassa nicht mitgestartet werden, kann dies in den Kasseneinstellungen festgelegt werden: Hier muss das Häkchen "aktiv" entfernt werden. Wichtig die selbe Kassa darf nicht zugleich als Dienst und Applikation laufen/gestartet werden! getestete Terminals/Anbieter Anbieter Terminal funktioniert Einschränkungen Ticket/Partner/Kunde Hobex ja mehrere telecash CCV Plus Mobile A960 ja Rückmeldung vom Terminal dauert länger wegen Cloudupload des Zahlungsbelegs #11102 Partner: Comfuse 02.2026 telecash clover flex 4 nein #11102 Partner: Comfuse 12.2025 Online-Pay Tray Über das Zusatztool "Online-Pay Tray.exe" kann die Schnittstelle auch Admin-Zugang auf dem Server direkt mit dem Windowsbenutzer der Kassa gesteuert werden. Funktionen Online-Pay Tray stellt dabei folgende Funktionen zur Verfügung: aktuelle Kartenzahlung abbrechen: wenn das Terminal blockiert ist bzw. keine Rückmeldung an die Kassa erfolgt, legt Online-Pay ein Outfile mit Fehlercode an, damit die aktuelle Zahlung auch vor erreichen des 5-min Timeouts der SoftENGINE Kassa abgebrochen und ggf. neu gestartet werden kann. Infopanel mit Terminalstatus Terminalfunktionen wie Initialisierung, Diagnose und Kassenabschluss Konfiguration Wie kann das Zusatztool “Online-PayTray.exe” konfiguriert werden? 1. Starten Sie im Programmordner der Schnittstelle bei dem entsprechenden Windows-User das Programm Online-PayTray.exe Nach dem Starten befindet sich dieses Tool in der Taskleiste ganz rechts unten im Tray-Bereich: Klicken Sie mit der rechten Maustaste auf das Symbol und dann mit der linken Maustaste auf “Einstellungen” Anschließend öffnen sich die Einstellungen und sie können die gewünschte Kasse für den angemeldeten Windows-User einstellen. Wichtig : Die Einstellungen sind IMMER mit dem aktuellen Windows Anmeldebenutzer verknüpft. Um auch aktive Informationen über den aktuellen Status des Terminals zu erhalten, können Sie den Verbindungsserver aktivieren. Mit einem Klick (linke Maustaste) auf das Symbol können Sie die Infomaske öffnen, wenn der direkte Verbindungsserver für diese Kasse aktiviert wurde. Dieser ist pro Kasse freizuschalten und per 23.07.2024 noch im Betastatus. Öffnen Sie dazu die globalen Einstellungen und wählen Sie unter der gewünschten Kasse die Toolbox-Einstellungen aus. Aktivieren Sie hier den “Direkten Verbindungsserver”. Sollte der Dienst oder die Toolbox bereits laufen, ist ein Neustart des Online-Pay Dienstes über den Windows Dienstmanager und der damit verbundenen Toolbox (Online-PayTray.exe) erforderlich. Die Toolbox benötigt hierfür keine weiteren Einstellungen und übernimmt diese automatisch. Hinweise/bekannte Probleme: Wenn der Verbindungsserver neu gestartet wird, muss die Oberfläche der Toolbox einmal beendet und wieder geöffnet werden, damit die geänderten Einstellungen übernommen werden. Übersicht der Einstellungen Hier werden die wichtigsten Einstellungen für OnlinePay erläutert. Änderungen werden jeweils nach einem Neustart der Schnittstelle (als App bzw. Dienst) berücksichtigt. Globale Einstellungen ... Terminal Serviceart Über die Serviceart wird definiert, wie OnlinePay die Infiles aus dem Kassensystem im INOUT-Ordner erkennt.  Eventgesteuert - Modus Change (Standard): OnlinePay prüft den Change-Timestamp der Infile.XXX-Dateien. Es werden nur Infiles mit "jüngeren" Änderungszeitstempel verarbeitetet, ältere werden ignoriert und im Log protokolliert. Eventgesteuert - Modus Create: OnlinePay prüft den Create-Timestamp der Infile.XXX-Dateien. Es werden nur Infiles mit "jüngeren" Erstellungszeitstempel verarbeitetet, ältere werden ignoriert und im Log protokolliert. Abhängig vom System cached Windows uU. die Erstellungszeit kürzlich gelöschter Dateien und setzt diese auch für neu erstellte Dateien mit dem gleichen Namen. In dem Fall sollte die Serviceart "Modus Change" verwendet werden.  Zeitgesteuert: OnlinePay prüft unabhängig von den Timestamps alle 0,1 Sekunden auf vorhandene Infiles und verarbeitet diese.  Voraussetzungen und FAQ Die OnlinePay Bankomatschnittstelle von ERP Austria ermöglicht ein Zusammenspiel Ihrer SoftENGINE Kassa 4.x mit einem ZVT-fähigen Bankomatterminal. An dieser Stelle sollen einige häufig gestellte Fragen beantwortet werden. Voraussetzungen: In der Kassa (BW Kassa 4.x) muss die Option „Online Pay“ lizenziert sein. Das Terminal muss vorweg im Netzwerk mit einer statischen IP-Adresse eingerichtet werden, die Terminalkennwörter müssen für die Installation bereitgehalten werden - diese erhalten Sie vom Provider. Einrichtung Wir unterstützen Sie gerne bei der Ersteinrichtung , die Installation und Anbindung an Kassa und Bankomatterminal inkl. Tests ist üblicherweise in ca. 30-45 Minuten erledigt. Dabei wird die OnlinePay Schnittstelle installiert, die Verbindung zum Terminal hergestellt, weitere Einstellungen zur Anbindung an die Kassa vorgenommen und einige Tests durchgeführt. OnlinePay wird dabei üblicherweise direkt am Terminal-/BüroWARE-Server installiert, bei Betrieb von lokal installierten Kassen wird die Schnittstelle auf den einzelnen PCs eingerichtet. Kosten Verrechnung pro Monat und Terminal per SEPA Einzug  und jährlich möglich. Kündbar schriftlich 3 Monate vor Jahresende. Die Anzahl der Lizenzen richtet sich nach der Anzahl der Bankomatterminals . 4 Kassen und insg. 1 Bankomatterminal = 1 Lizenz 4 Kassen und 4 Terminals = 4 Lizenzen OnlinePay kann sowohl am Terminalserver als auch für zB. Standalone Kassen direkt auf dem Kassen-PC eingerichtet werden. Bei Interesse senden wir Ihnen gerne ein konkretes Angebot. Demoversion/Testmodus Die Verbindung zu vorhandenen Terminals kann vorweg auch ohne OnlinePay-Lizenz getestet werden (eingeschränkter Funktionsumfang) Verwendbare Geräte/Anbieter Grundvoraussetzung ist ein ZVT-fähiges Bankomatterminal (zB. ingenico Desk/3500, yomani touch XR PINPAD), das per TCP/IP (LAN/WLAN) oder COM an den Kassen-PC oder Server angebunden werden kann. Vom Zahlungsanbieter bekommen Sie normalerweise ein aktuelles Terminal angeboten. Zu den folgenden Anbietern gibt es bereits zertifizierte Anbindungen oder erfolgreiche Tests: hobex (zertifiziert) VR Pay PayONE/SIX (zertifiziert) Global Payments (zertifiziert) Für Kunden in AT würden wir hobex empfehlen . Generell sind auch Anbindungen zu anderen Terminals/Anbietern möglich, diese müssten von Ihnen getestet werden. (auch ohne Lizenz, aber mit eingeschränktem Funktionsumfang möglich). Die OnlinePay-Schnittstelle wird laufend weiterentwickelt und bei Bedarf gerne an weitere Terminals/Zahlungsanbieter angebunden. Umstieg von elPay-Terminals Wichtig: PayONE lässt den Support für die alte elPay-Schnittstelle auf. Vorhandene Terminals können zwar noch verwendet werden, ein Umstieg auf ein neues ZVT-fähiges Terminal ist hier aber sinnvoll. Dieses kann ebenfalls über PayONE oder einen alternativen Anbieter wie hobex bezogen werden. Was muss ich bei einem SumUp Zahlungsterminal einstellen? SumUp-Terminal in PhoenixDS Online-Pay Zweck dieser Dokumentation Diese Anleitung beschreibt die Einrichtung eines SumUp Solo oder Virtual Solo in PhoenixDS Online-Pay . Die Anbindung erfolgt über die SumUp Cloud API . Online-Pay und das SumUp-Terminal kommunizieren daher nicht direkt über eine lokale IP-Adresse miteinander. Beide Geräte benötigen eine funktionierende Internetverbindung. Wichtig: Für Zahlungen werden ein SumUp-Händlerkonto, ein geheimer API-Key und die für Kartenpräsenz-Zahlungen vorgesehenen Affiliate-Daten benötigt. Die Zugangsdaten müssen vertraulich behandelt werden. Funktionsprinzip PhoenixDS Online-Pay ------ HTTPS ------> SumUp Cloud API | | v SumUp Solo / Virtual Solo Online-Pay übermittelt die Zahlungsanforderung an SumUp. Die SumUp Cloud leitet sie an den gekoppelten Reader weiter. Das Ergebnis wird anschließend von Online-Pay abgefragt und an das Kassensystem zurückgegeben. Das SumUp-Terminal muss sich nicht im selben lokalen Netzwerk wie der Online-Pay-Server befinden. Beide Seiten müssen jedoch das Internet erreichen können. Unterstützte Funktionen Die aktuelle SumUp-Anbindung unterstützt: Zahlung Zahlungsablehnung und Abbruch am Terminal Abbruch eines laufenden Reader-Checkouts durch Online-Pay Diagnose und Reader-Status Geräteinformationen Kopplung eines Solo oder Virtual Solo Folgende Vorgänge werden derzeit nicht über die SumUp-Anbindung angeboten: Gutschrift Storno einer bereits abgeschlossenen Zahlung Belegwiederholung Tagesabschluss Diese Funktionen werden in Online-Pay für eine SumUp-Kasse nicht angeboten beziehungsweise mit einer eindeutigen Meldung abgewiesen. Voraussetzungen Vor der Einrichtung müssen folgende Voraussetzungen erfüllt sein: Ein vollständig eingerichtetes SumUp-Händlerkonto ist vorhanden. Ein unterstützter SumUp Solo oder Virtual Solo ist vorhanden beziehungsweise im SumUp-Konto freigeschaltet. Online-Pay kann die SumUp Cloud über HTTPS erreichen. Das SumUp-Terminal besitzt eine aktive Internetverbindung über WLAN oder Mobilfunk. Ein geheimer SumUp API-Key ist vorhanden. Affiliate-Key und zugehörige Affiliate-App-ID sind vorhanden. Der Reader ist für eine neue API-Kopplung vom bisherigen Benutzerkonto abgemeldet. Eine lokale Terminal-IP-Adresse und ein lokaler Terminalport werden für SumUp nicht benötigt. SumUp API-Key erstellen Der API-Key gehört zum SumUp-Händlerkonto und erlaubt Online-Pay den Zugriff auf die benötigten SumUp-Funktionen. Im SumUp Dashboard anmelden. Das Profil öffnen und Einstellungen auswählen. Für Entwickler und anschließend Toolkit öffnen. Den Bereich API Keys auswählen. Einen neuen geheimen API-Key erstellen und eindeutig benennen, beispielsweise PhoenixDS Online-Pay . Den Schlüssel unmittelbar sicher speichern. Der im Dashboard angezeigte Public Key ist nicht der benötigte API-Key. Für Online-Pay wird der geheime API-Key verwendet, der üblicherweise mit sup_sk_ beginnt. SumUp zeigt einen neu erzeugten geheimen Schlüssel möglicherweise nur einmal vollständig an. Geht er verloren, muss ein neuer Schlüssel erstellt und der alte Schlüssel widerrufen werden. Affiliate-Daten Für Zahlungen an einem physischen oder virtuellen SumUp-Reader werden zusätzlich benötigt: Affiliate-Key Affiliate-App-ID Diese Daten identifizieren die Kartenpräsenz-Integration gegenüber SumUp. Sie werden von PhoenixDS beziehungsweise im Rahmen der Freigabe durch SumUp bereitgestellt und dürfen nicht durch frei erfundene Werte ersetzt werden. Allgemeine Kasseneinstellungen in Online-Pay Online-Pay öffnen. Mit der rechten Maustaste auf die gewünschte Kasse klicken. Zahlungsterminal konfigurieren auswählen. Die allgemeinen Einstellungen der Kasse öffnen. Einstellung Empfohlener Wert Beschreibung Aktiv aktiviert Aktiviert die Verarbeitung für diese Kasse. Terminalprotokoll SumUp Verwendet die SumUp Cloud API. Verbindungsart ohne Bedeutung für SumUp SumUp verwendet immer eine HTTPS-Verbindung zur Cloud. IP-Adresse leer beziehungsweise ohne Bedeutung Für SumUp wird keine lokale Terminal-IP verwendet. Port ohne Bedeutung Für SumUp wird kein lokaler Terminalport verwendet. Timeout 1 5000 Zeitlimit für den Aufbau einer Cloud-Verbindung in Millisekunden. Timeout 2 180000 Maximale Wartezeit für einen Zahlungsvorgang in Millisekunden. Protokollierung Erweitert Empfohlen für Einrichtung und Fehleranalyse. Sprache DE Gemeinsame Spracheinstellung der Kasse. Währung EUR ISO-Währungscode für Zahlungen. Zeichensatz/CodePage des Terminals ohne Bedeutung für SumUp Die SumUp Cloud API überträgt Daten als Unicode. Andere Kassen auf demselben Online-Pay-System können weiterhin mit ZVT, PhoenixDS ZVT, Hobex ZVT oder O.P.I. betrieben werden. SumUp-Einstellungen Die anbieterspezifischen Einstellungen befinden sich im Unterordner SumUp Einstellungen der betreffenden Kasse. Sie können außerdem in der geöffneten Terminalserver-Oberfläche aufgerufen werden: Rechtsklick in die Meldungsliste und SumUp-Einstellungen und Kopplung auswählen. Alternativ im Menü Tools den Eintrag SumUp-Einstellungen und Kopplung auswählen. Beschreibung der Einstellungen Einstellung Eingabe Beschreibung API-Key erforderlich Geheimer API-Key des SumUp-Händlerkontos. Er wird verschlüsselt gespeichert und nicht protokolliert. Merchant-Code optional Händlercode des SumUp-Kontos. Bleibt das Feld leer, versucht Online-Pay ihn automatisch über die SumUp API zu ermitteln. Reader-ID automatisch Eindeutige ID des gekoppelten Readers. Sie wird nach erfolgreicher Kopplung automatisch gespeichert. Affiliate-Key für Zahlungen erforderlich Geheimer Schlüssel für Kartenpräsenz-Zahlungen. Er wird verschlüsselt gespeichert und nicht protokolliert. Affiliate-App-ID erforderlich Zum Affiliate-Key gehörende Anwendungs-ID, beispielsweise at.phoenixds.onlinepay . Den von PhoenixDS oder SumUp vorgegebenen Wert verwenden. Reader-Name frei wählbar Bezeichnung des Readers im SumUp-Konto, beispielsweise PhoenixDS Kasse 01 . Kopplungscode nur zur Kopplung Einmaliger 8- oder 9-stelliger Code, der am Solo oder Virtual Solo angezeigt wird. API-Key und Affiliate-Key sind geheime Zugangsdaten. Sie dürfen nicht per unverschlüsselter E-Mail versendet, in Screenshots veröffentlicht oder in Supportprotokolle kopiert werden. SumUp Reader koppeln 1. Reader vorbereiten Für die API-Kopplung darf der Solo nicht mit einem Benutzer am SumUp-Konto angemeldet sein. Falls der Reader bereits angemeldet ist: Das obere Menü am Solo öffnen. Einstellungen öffnen. Den Bereich Über / About auswählen. Vom bestehenden Konto abmelden. Anschließend: Den Solo einschalten. Eine Internetverbindung herstellen. API auswählen. Connect / Verbinden auswählen. Den angezeigten Kopplungscode bereithalten. Der Kopplungscode ist laut SumUp nur für kurze Zeit gültig. Die Kopplung sollte daher unmittelbar abgeschlossen werden. 2. Kopplung in Online-Pay starten Die betreffende Kasse in Online-Pay öffnen. SumUp-Einstellungen und Kopplung aufrufen. API-Key, Affiliate-Key und Affiliate-App-ID kontrollieren. Einen eindeutigen Reader-Namen eintragen. Den am Reader angezeigten Kopplungscode eingeben. Speichern und koppeln auswählen. Die Kopplung am SumUp-Gerät bestätigen. In Online-Pay anschließend Connect auswählen. Nach erfolgreichem Start der Kopplung speichert Online-Pay die von SumUp zurückgegebene Reader-ID automatisch. Der verwendete Kopplungscode wird danach aus den Einstellungen entfernt. Beim normalen Programm- oder Dienststart wird niemals automatisch ein neuer Reader gekoppelt. Die Kopplung ist eine bewusst ausgelöste Aktion in der Oberfläche. Verbindung und Zahlung testen Nach der Kopplung sollte die Inbetriebnahme in folgender Reihenfolge geprüft werden: In Online-Pay Connect auswählen. Reader-Status und Geräteinformationen über die Diagnose prüfen. Eine Testzahlung mit einem kleinen Betrag, beispielsweise 1,00 EUR, starten. Eine Zahlung bewusst am Reader abbrechen und die Rückmeldung prüfen. Eine Zahlung erfolgreich durchführen. Kontrollieren, ob Betrag, Ergebnis und Belegnummer korrekt an das Kassensystem zurückgegeben werden. Das SumUp-Terminal sollte während des Betriebs eingeschaltet, mit dem Internet verbunden und nach Möglichkeit mit Strom versorgt sein. Netzwerk und Firewall Online-Pay benötigt eine ausgehende HTTPS-Verbindung zur SumUp Cloud: Richtung Quelle Ziel Port Ausgehend Online-Pay / RDS-Server api.sumup.com TCP 443 Es wird kein eingehender Port auf dem RDS-Server für das SumUp-Terminal benötigt. Falls ein Proxy, Webfilter oder eine Firewall eingesetzt wird, muss die HTTPS-Kommunikation zur SumUp API erlaubt sein. Eine TLS-Auftrennung oder Inhaltsmanipulation durch Sicherheitssoftware kann die Verbindung beeinträchtigen. Protokolldateien Die SumUp-Protokolle werden je Kasse unterhalb des Online-Pay-Programmordners gespeichert: \Log\SumUp\PHXFrameworkSumUp_Kasse001_YYYYMMDD.log Für die Einrichtung und Fehleranalyse sollte die gemeinsame Einstellung Protokollierung auf Erweitert stehen. API-Key und Affiliate-Key werden nicht in das Protokoll geschrieben. Identifikatoren und technische Transaktionsangaben können für die Nachverfolgung eines Vorgangs enthalten sein. Fehlerbehebung API-Key fehlt oder ist ungültig Mögliche Ursachen: Es wurde versehentlich der öffentliche Schlüssel statt des geheimen API-Keys eingetragen. Der API-Key wurde widerrufen. Beim Kopieren wurden Zeichen ausgelassen. Der Schlüssel gehört nicht zum erwarteten SumUp-Händlerkonto. Lösung: Im SumUp Dashboard einen gültigen geheimen API-Key kontrollieren oder neu erstellen und anschließend in Online-Pay speichern. Merchant-Code konnte nicht ermittelt werden Mögliche Ursachen: Der API-Key ist ungültig. Das SumUp-Konto ist noch nicht vollständig eingerichtet. Der Zugriff zur SumUp API wird blockiert. Lösung: Zuerst API-Key und Internetverbindung prüfen. Falls erforderlich, den Merchant-Code aus dem SumUp-Konto ausdrücklich in Online-Pay eintragen. Affiliate-Key oder Affiliate-App-ID fehlt Ohne gültige Affiliate-Daten kann Online-Pay keine Kartenpräsenz-Zahlung am Reader starten. Lösung: Die von PhoenixDS beziehungsweise SumUp bereitgestellten Werte vollständig eintragen. Die Affiliate-App-ID darf nicht unabhängig vom zugehörigen Affiliate-Key geändert werden. Kopplungscode wird nicht akzeptiert Mögliche Ursachen: Der Kopplungscode ist abgelaufen. Der Reader ist noch mit einem SumUp-Benutzer angemeldet. Der Code wurde falsch eingegeben. Reader und Online-Pay haben keine Internetverbindung. Lösung: Am Reader einen neuen Code erzeugen und die Kopplung innerhalb weniger Minuten erneut durchführen. Reader-ID fehlt Ohne Reader-ID ist noch kein Gerät vollständig mit dieser Kasse gekoppelt. Lösung: Die Kopplung über SumUp-Einstellungen und Kopplung durchführen. Die Reader-ID nicht manuell erfinden. Reader ist gekoppelt, aber nicht erreichbar Prüfung: Ist der Reader eingeschaltet? Besteht eine Internetverbindung? Ist der Reader im richtigen SumUp-Händlerkonto vorhanden? Zeigt das Gerät noch einen Kopplungs- oder Anmeldebildschirm? Ist in Online-Pay die zur Kopplung gehörende Reader-ID gespeichert? Zeitüberschreitung oder unklares Zahlungsergebnis Wenn eine Zahlungsanforderung bereits von SumUp angenommen wurde und danach die Verbindung abbricht, kann das Ergebnis zunächst unklar sein. Nicht sofort erneut kassieren. Zuerst den Vorgang im SumUp Dashboard beziehungsweise anhand der im Protokoll enthaltenen Transaktionskennungen prüfen. Dadurch wird eine mögliche Doppelzahlung vermieden. Der interne Fehlercode 7005 kennzeichnet in der SumUp-Anbindung ein unklares Ergebnis, das manuell überprüft werden muss. Vorgang wird als „nicht unterstützt“ gemeldet Gutschrift, Storno einer abgeschlossenen Zahlung, Belegwiederholung und Tagesabschluss sind in der aktuellen SumUp-Anbindung nicht umgesetzt. Für diese Vorgänge muss der vorgesehene Ablauf im SumUp Dashboard beziehungsweise nach Vorgabe des Zahlungsdienstleisters verwendet werden. Test- und Produktivbetrieb SumUp bietet für API-Tests ein Sandbox-Händlerkonto an. Die Sandbox verarbeitet keine echten Zahlungen. Sie ersetzt jedoch nicht in jedem Fall das Verhalten eines realen oder von SumUp bereitgestellten virtuellen Readers. Vor dem Produktivbetrieb müssen deshalb mindestens folgende Fälle mit dem vorgesehenen SumUp-Gerät getestet werden: erfolgreiche Zahlung abgelehnte Zahlung Abbruch am Terminal Verbindungsunterbrechung während einer Zahlung Verhalten bei Zeitüberschreitung Wiederanlauf von Online-Pay und Reader Abnahmecheckliste SumUp-Händlerkonto ist vollständig eingerichtet. Geheimer API-Key wurde erstellt und sicher hinterlegt. Affiliate-Key und Affiliate-App-ID sind vorhanden. Online-Pay kann api.sumup.com über HTTPS erreichen. SumUp-Terminal besitzt eine stabile Internetverbindung. Terminalprotokoll der Kasse steht auf SumUp . Währung ist korrekt eingestellt, beispielsweise EUR . Reader-Name ist eindeutig. Reader wurde über einen aktuellen Kopplungscode gekoppelt. Reader-ID wurde automatisch gespeichert. Diagnose und Reader-Status funktionieren. Erfolgreiche Zahlung wurde getestet. Ablehnung und Zahlungsabbruch wurden getestet. Vorgehen bei einem unklaren Zahlungsergebnis ist bekannt. Erweiterte Protokollierung wurde während der Abnahme geprüft. Sicherheitshinweise API-Key und Affiliate-Key wie Passwörter behandeln. Schlüssel niemals in Tickets, Screenshots oder normalen E-Mails veröffentlichen. Bei Verdacht auf Offenlegung den betreffenden Schlüssel unverzüglich widerrufen und ersetzen. Nur berechtigten Mitarbeitern Zugriff auf die SumUp-Einstellungen geben. SumUp Dashboard und hinterlegte Transaktionen regelmäßig kontrollieren. Weiterführende Informationen SumUp – Autorisierungsverfahren SumUp – API-Keys erstellen und schützen SumUp – Solo über die Cloud API anbinden SumUp – Reader API Die verfügbaren Funktionen und Freigabeanforderungen können sich durch Änderungen bei SumUp verändern. Bei einer Neueinrichtung sollten die aktuellen SumUp-Unterlagen geprüft werden. Was muss ich bei einem Zahlungsterminal mit O.P.I. Schnittstelle einstellen? O.P.I.-Zahlungsterminal in PhoenixDS Online-Pay Zweck dieser Dokumentation Diese Anleitung beschreibt die Einrichtung eines Zahlungsterminals über die O.P.I.-Schnittstelle in PhoenixDS Online-Pay . Als Beispiel wird ein CCV Pad Next verwendet. Die genaue Bezeichnung der Menüpunkte am Terminal kann abhängig von Firmware, Netzbetreiber und Terminalkonfiguration abweichen. Wichtig: Die O.P.I.-Funktion muss am Terminal beziehungsweise durch CCV oder den Netzbetreiber freigeschaltet und eingerichtet sein. Die Konfiguration in Online-Pay allein aktiviert O.P.I. nicht am Terminal. Funktionsprinzip O.P.I. verwendet zwei getrennte TCP-Verbindungen: Befehlskanal: Online-Pay verbindet sich mit dem Zahlungsterminal. Rückkanal: Das Zahlungsterminal verbindet sich zurück mit Online-Pay auf dem RDS-Server. Online-Pay / RDS-Server CCV-Terminal Zahlungsanforderung -----------------> TCP-Port 20002 TCP-Port 20007 <----------------- Anzeigen und Belegdaten Für eine funktionierende Verbindung müssen beide Kommunikationsrichtungen im Netzwerk und in der Firewall freigegeben sein. Beispielkonfiguration Komponente Beispielwert IP-Adresse des CCV-Terminals 10.10.10.140 IP-Adresse des RDS-Servers beispielsweise 10.10.10.10 O.P.I.-Befehlsport am Terminal 20002 O.P.I.-Rückkanal-Port in Online-Pay 20007 Kasse 01 Workstation-ID 01 Die im Online-Pay-Protokoll angezeigte Adresse 127.0.0.1 mit einem zufälligen hohen Port gehört zur internen Kommunikation von Online-Pay. Sie ist nicht der O.P.I.-Port des Terminals. Voraussetzungen Vor der Einrichtung müssen folgende Voraussetzungen erfüllt sein: Das CCV-Terminal ist für O.P.I. freigeschaltet. Terminal und RDS-Server können sich gegenseitig über das Netzwerk erreichen. Das Terminal besitzt nach Möglichkeit eine feste IP-Adresse oder eine feste DHCP-Zuordnung. Der O.P.I.-Befehlsport des Terminals ist bekannt. Beim CCV Pad Next ist dies häufig 20002 . Der Rückkanal des Terminals ist auf die IP-Adresse des RDS-Servers und den vorgesehenen Rückkanal-Port eingestellt. Die Windows-Firewall erlaubt die benötigten Verbindungen. Bei mehreren Kassen wird für jede gleichzeitig aktive Kasse ein eigener Rückkanal-Port verwendet. Vorbereitung des CCV-Terminals Am Terminal oder durch den zuständigen Netzbetreiber müssen mindestens folgende Werte eingerichtet werden: Einstellung am Terminal Beispiel Bedeutung Schnittstelle O.P.I. Aktiviert die Kassenanbindung über O.P.I. Befehlskanal / Port 20002 Port, auf dem das Terminal Anforderungen von Online-Pay annimmt Zieladresse des Rückkanals IP-Adresse des RDS-Servers Adresse, zu der das Terminal Anzeigen und Belegdaten sendet Rückkanal-Port 20007 Muss mit der Einstellung in Online-Pay übereinstimmen Workstation-ID 01 Kennung der zugeordneten Kasse Die Änderung dieser Werte kann sich im geschützten Servicebereich des Terminals befinden. Falls die Einstellungen nicht sichtbar sind, muss CCV, der Terminalbetreuer oder der Netzbetreiber die O.P.I.-Konfiguration durchführen. Einrichtung in Online-Pay Online-Pay öffnen. Mit der rechten Maustaste auf die gewünschte Kasse klicken. Zahlungsterminal konfigurieren auswählen. Zuerst die allgemeinen Kasseneinstellungen bearbeiten. Anschließend den Unterordner O.P.I. Einstellungen öffnen. Allgemeine Kasseneinstellungen Einstellung Empfohlener Wert für das Beispiel Beschreibung Aktiv aktiviert Aktiviert die Verarbeitung für diese Kasse. Terminalprotokoll O.P.I. Verwendet die O.P.I.-Schnittstelle. Verbindungsart TCP/IP Verbindung zum Terminal über das Netzwerk. IP-Adresse 10.10.10.140 IP-Adresse des Zahlungsterminals. Port 20002 O.P.I.-Befehlsport des Terminals. Timeout 1 5000 Zeitlimit für den Verbindungsaufbau in Millisekunden. Timeout 2 180000 Maximale Wartezeit für einen Zahlungsvorgang in Millisekunden. Protokollierung Erweitert Empfohlen für Einrichtung und Fehleranalyse. Sprache DE Sprache für die Kommunikation mit dem Terminal. Währung EUR ISO-Währungscode für Zahlungen. Zeichensatz/CodePage des Terminals 28591 - Westeuropäisch (ISO) Entspricht ISO-8859-1 und ist für das getestete CCV-Terminal erforderlich. Zeichensatz: Für die getestete CCV-Konfiguration ist 28591 - Westeuropäisch (ISO) korrekt. Dadurch werden Umlaute in Beleg- und Anzeigetexten richtig verarbeitet. O.P.I. Einstellungen Einstellung Empfohlener Wert für das Beispiel Beschreibung Rückkanal-Port 20007 Port, auf dem Online-Pay Verbindungen vom Terminal annimmt. Lokale IP-Adresse 0.0.0.0 Online-Pay lauscht auf allen lokalen Netzwerkadressen. Alternativ kann die feste IP-Adresse des RDS-Servers eingetragen werden. Workstation-ID 01 Kassenkennung im O.P.I.-Protokoll. Muss zur Terminalkonfiguration passen. POP-ID leer Optionale Point-of-Payment-ID. Nur eintragen, wenn CCV oder der Netzbetreiber einen Wert vorgibt. Application-Sender PhoenixDS Online-Pay Name der sendenden Kassenanwendung. XML-Namespace verwenden deaktiviert Beim getesteten CCV Pad Next muss diese Option deaktiviert sein. Unterschrift automatisch bestätigen deaktiviert Nur aktivieren, wenn ein organisatorisch und technisch abgesicherter Freigabeablauf besteht. Nachlaufzeit Rückkanal ms 500 Kurze Wartezeit, damit abschließende Anzeige- oder Belegdaten übernommen werden können. Diagnose-Anforderung Diagnosis Herstellerabhängiger O.P.I.-Befehlsname für die Diagnose. Tagesabschluss-Anforderung ReconciliationWithClosure Herstellerabhängiger O.P.I.-Befehlsname für den Tagesabschluss. CCV Pad Next: Die Option XML-Namespace verwenden muss für die getestete Konfiguration deaktiviert sein. Bei aktiviertem Namespace antwortete das Terminal mit FatalError und ParsingError . Windows-Firewall und Netzwerk Für das Beispiel werden folgende Verbindungen benötigt: Richtung Quelle Ziel TCP-Port Ausgehend RDS-Server / Online-Pay CCV-Terminal 20002 Eingehend CCV-Terminal RDS-Server / Online-Pay 20007 Der eingehende Port muss auf dem RDS-Server in der Windows-Firewall freigegeben sein. Zusätzlich dürfen Netzwerk-Firewalls oder VLAN-Regeln die Kommunikation nicht blockieren. Mehrere Kassen auf demselben RDS-Server Jede gleichzeitig aktive O.P.I.-Kasse benötigt einen eigenen Rückkanal-Port. Kasse Beispiel Rückkanal-Port Kasse 01 20007 Kasse 02 20008 Kasse 03 20009 Der jeweilige Port muss sowohl in Online-Pay als auch im zugehörigen Terminal eingetragen und in der Firewall freigegeben werden. Verbindung testen Nach dem Speichern der Einstellungen sollte Online-Pay beziehungsweise die betreffende Terminalverbindung neu gestartet werden. Die Inbetriebnahme sollte in folgender Reihenfolge getestet werden: Anmeldung beziehungsweise Initialisierung des Terminals. Diagnose über das Kontextmenü der Kasse. Testzahlung mit einem kleinen Betrag, beispielsweise 1,00 EUR. Abbruch einer Zahlung am Terminal. Erfolgreiche Zahlung einschließlich Kunden- und Händlerbeleg. Tagesabschluss. Bei einer erfolgreichen Initialisierung enthält das erweiterte Protokoll unter anderem: PROVIDER PHXFrameworkOPI initialize Command=10.10.10.140:20002 DevicePort=20007 OPI TX OPI RX Im XML der Anforderung darf für die beschriebene CCV-Konfiguration kein zusätzliches xmlns -Attribut enthalten sein. Protokolldateien Die O.P.I.-Protokolle werden unterhalb des Online-Pay-Programmordners gespeichert: \Log\OPI\PHXFrameworkOPI_Kasse001_YYYYMMDD.log Für die Einrichtung und Diagnose sollte die Einstellung Protokollierung vorübergehend auf Erweitert stehen. Sensible Kartendaten wie PAN, Track-Daten, PIN-Informationen und Zugangsdaten werden nicht im Klartext protokolliert. Fehlerbehebung FatalError / ParsingError Mögliche Ursache: Das Terminal kann die gesendete XML-Struktur nicht verarbeiten. Prüfung: XML-Namespace verwenden deaktivieren. Als Zeichensatz 28591 - Westeuropäisch (ISO) einstellen. Verbindung anschließend neu initialisieren. Ungültige O.P.I.-Nachrichtenlänge oder negativer Längenwert Mögliche Ursache: Es wird der falsche Terminalport verwendet oder die Gegenstelle liefert auf diesem Port kein O.P.I.-XML. Prüfung: Für das CCV-Beispiel den Befehlsport 20002 verwenden. Nicht den Rückkanal-Port als Befehlsport eintragen. Prüfen, ob O.P.I. am Terminal wirklich aktiviert ist. Keine Verbindung zum Terminal Mögliche Ursachen: IP-Adresse oder Port ist falsch. O.P.I. ist am Terminal nicht aktiviert. Eine Firewall blockiert den Befehlsport. Terminal und RDS-Server befinden sich in getrennten Netzen ohne passende Freigabe. Zahlung startet, aber Anzeigen oder Belege fehlen Mögliche Ursache: Der Rückkanal erreicht Online-Pay nicht. Prüfung: Zieladresse des Rückkanals am Terminal kontrollieren. Rückkanal-Port am Terminal und in Online-Pay vergleichen. Eingehende Windows-Firewall-Regel prüfen. Bei mehreren Kassen sicherstellen, dass jeder Rückkanal-Port nur einmal verwendet wird. Rückkanal-Port ist bereits belegt Mögliche Ursache: Eine zweite Kasse oder ein anderes Programm verwendet denselben lokalen Port. Lösung: Für jede O.P.I.-Kasse einen eigenen Rückkanal-Port konfigurieren. Umlaute werden falsch dargestellt Prüfung: Zeichensatz auf 28591 - Westeuropäisch (ISO) stellen. Beachten, dass eine fehlerhafte Darstellung nur im verwendeten Logreader auftreten kann, obwohl die eigentliche Datei korrekt gespeichert wurde. Abnahmecheckliste O.P.I. ist am Terminal aktiviert. Terminal-IP-Adresse ist fest vergeben oder reserviert. Befehlsport stimmt mit der Terminalkonfiguration überein. Rückkanal zeigt auf die IP-Adresse des RDS-Servers. Rückkanal-Port stimmt in Terminal und Online-Pay überein. Windows-Firewall erlaubt beide Kommunikationsrichtungen. Workstation-ID ist eindeutig und korrekt zugeordnet. Zeichensatz ist 28591 - Westeuropäisch (ISO) . XML-Namespace ist für das CCV Pad Next deaktiviert. Anmeldung und Diagnose wurden erfolgreich getestet. Erfolgreiche Zahlung wurde getestet. Zahlungsabbruch wurde getestet. Belegtexte und Umlaute wurden geprüft. Tagesabschluss wurde erfolgreich getestet. Wichtige Hinweise O.P.I.-Details können abhängig von Terminalmodell, Firmware und Netzbetreiber abweichen. Die Befehlsnamen für Diagnose und Tagesabschluss sind herstellerabhängig und müssen im Zweifelsfall mit CCV oder dem Netzbetreiber abgestimmt werden. Bei einem unklaren Zahlungsergebnis darf eine Zahlung nicht ungeprüft wiederholt werden. Zuerst muss der Status am Terminal beziehungsweise beim Netzbetreiber kontrolliert werden. Die beschriebenen Werte bilden die erfolgreich getestete XML-Verarbeitung mit einem CCV-Terminal ab. Zahlung, Storno, Diagnose und Tagesabschluss müssen vor dem Produktivbetrieb vollständig abgenommen werden. Weiterführende Herstellerinformationen CCV Pad Next – Produktinformation CCV System Manual mit O.P.I.-Hinweisen Die vollständige CCV-O.P.I.-Spezifikation ist gegebenenfalls direkt bei CCV anzufordern.