Hallo Community,
ich sitze nun an meinem nächsten Projekt.
Meine Software bietet eine Schnittstelle, um aus Outlook Termine einzulesen und in meinem Programm bereizustellen. Die Kunden lesen ja nicht nur lokale Kalender - spätestens für das Auslesen von Kalendern von Resourcenpostfächern von Exchange (Belegung von Konferenzräumen etc.) artet es in riesigem Konfigurationsaufwand Serverseitig aus, um die Termine überhaupt einlesen zu "dürfen" - von der Stabilität von Outlook ganz zu schweigen.
Mapi über Outlook ist ja sowieso hoffnungslos veraltet. Also muss endlich eine neue Schnittstelle her. Was man als Vollzeitprogrammierer so von den Kunden mitbekommt scheinen ja die Exchange Web Services (EWS) das Mittel der Wahl zu sein - schließlich funktionieren die sowohl bei lokalen/internen Exchange-Servern (On-Premise) als auch bei Office365 (Cloud). Nun lese ich mich gerade ein und will schon Komponenten für EWS kaufen, da stolpere ich über diese Meldung auf
https://www.msxfaq.de/code/ews.htm :
Zitat:
Starting today, Exchange Web Services (EWS) will no longer receive feature updates
Sprich: Ich habe noch keine Komponente gekauft, da ist das Protokoll schon wieder veraltet.
Hat jemand Ideen, welche fertigen Komponenten (auch zukünftig) auf Exchange (On-Premise) und Office365 zugreifen können?
Ich habe das Gefühl, mit EWS würde ich jetzt auf ein totes Pferd setzen. Der Nachfolger scheint "Microsoft Graph" zu heißen, aber außer den unbezahlbaren Komponenten von cdata (von denen ich noch nicht mal weiß, ob sie meine Anforderungen bedienen können) habe ich in Bezug auf Delphi dazu nichts gefunden.
Es gibt einige "nur Cloud" (Office 365) Komponenten, die scheinen aber nicht mit Exchange Lokal arbeiten zu können...
Bisherige Ideen:
https://www.sync-components.com/clou...65-outlook-com
Nur Cloud, kein On-Premise Exchange (habe ich beim Support nachgefragt). Compilierte .exe-Demo zeigt schon beim ersten Verwenden HTTP400 Fehler - die sind also wohl nicht ganz "up-to-date" oder es gibt keine korrekte Fehlermeldung wenn die APP-ID nicht korrekt registiert ist? Schlechtes Bauchgefühl beim Kauf.
https://www.rapware.com/ews/introduction
Reine EWS Funktionalität. Würde *aktuell noch* mit On-Premise und Cloud funktionieren, aber wenn ich in der Anleitung schon lese:
Zitat:
16) Select the "Exchange" permission from the "Supported legacy APIs"
sieht man auch da wieder, dass EWS eigentlich bald tot ist...
Da bei "EasyMAPI" des selben Anbieters der Begriff "Windows NT" fällt, brauche ich auch da nicht mehr weiterlesen...
https://www.tmssoftware.com/site/tmsfnccloudpack.asp
Bewirbt "Outlook Calendar" - keine Ahnung, ob die damit wirklich Office365 meinen, oder den (man verzeihe mir) GoogleMail-Abklatsch "outlook.com" mit proprietärem Kalendersystem etc. Ohne kompilierte .exe-Demo schwer zu sagen.
https://www.cdata.com/drivers/exchange/
Da sind wir eigentlich ein ganzes Stück über der Schmerzgrenze - rein preislich. Zudem habe ich bis dato noch nie mit FireDAC gearbeitet. Ist bei Delphi 10.4 Pro ja dabei, k.a. ob da weitere Lizenzbedingungen (Folgekosten) zutreffen. Außerdem scheint das jetzt wieder was anderes wie Office 365 zu sein. Im Vergleich zu den "Plug-And-Play"-Komponenten von Sync-Components für 200€ wirkt dieser hochpreisige reine Datenbankconnector so, als ob da noch viel Zusatz Know-How erforderlich ist, und es wieder an vielen Kleinigkeiten scheitern, oder zumindest zeitaufwändig "klemmen" kann (FireDAC, ansprechen als Datenbank/Tabelle, ...).
Selbsprogrammieren über REST/
SOAP/
XML/
WSDL etc. fällt mangels Programmieraufwand und Einarbeitungszeit raus...
Sind euch noch andere Anbieter bekannt?
Ich muss eigentlich nur Termine mit den Details *lesen* können, aus allen für meinen Benutzer/meine APPID freigegegeben (Resourcen-)Kalendern. Serientermine können "aufgebröselt" geliefert werden (z.B. werden aus einem Abfragezeitraum für 4 Wochen aus einem Termin "jeden Montag 12-13h" 4 einzelne, unabhängige Termine - das ist für mich kein Problem (bei Rapware macht das nochmal über 300€ aus!). Preislich bin offen.
Frage 2 / Problem (Quasi eben selbst beantwortet, aber vielleicht hat noch wer eine gute Idee): Wie kann ich testen, ob die Komponente mit Office365 und Exchange geht? Ich habe selbst ein Office365 Konto - kein Problem. Leider haben alle "engeren" Kunden und Bekannten auch schon in die Cloud gewechselt, so dass ich mir lokal oder in Azure eine Domäne mit Exchange-Server aufsetzen müsste. Gibts da nicht ne einfachere Lösung, oder einen "offenen" Exchange-Server zum testen (der halt nix nach Extern senden kann). Hmmm... evtl. gibt es bei Internet-Anbeitern noch native Exchange-Postfächer zu mieten, die nicht bei Office365 liegen - die paar € im Monat machen dann auch nichts aus.
Danke vorab!
Delphi 10.4 32-Bit auf Windows 10 Pro 64-Bit, ehem. Delphi 2010 32-Bit auf Windows 10 Pro 64-Bit