[Delphi] Contacts toevoegen aan Exchange 2000

[jelmervos]

Ik heb een Delphi applicatie (server) waar een database aan zit met een hoop contactpersonen erin. Nou wil ik deze exporteren naar Exchange 2000 zodat ze door de gebruikers zijn te gebruiken in Outlook 2000 en dat er voor de gebruikers maar 1 lijst lijkt te zijn. Dit kan best 1x in het uur worden gedaan.

Heeft iemand misschien een voorbeeld code hoe je de contactpersonen in Exchange bewerken kunt.

[Elissen]

Je kunt meerdere dingen doen.
1. Alles rechtstreeks in de database van Exchange douwen m.b.v. de Exchange OLEDB dataprovider (ADO).
2. Gberuik maken van de interfaces van Exchange.

De 2e optie is netter. Wellicht hoef je dan niet eens wat te veranderen voor een eventuele nieuwe versie van Exchange. De 1e is wel sneller. Je moet dan waarschijnlijk wel rekening houden met wijzigingen in de structuur tussen de verschillende service pack's.
Ik kan je hier helaas niet mee verder helpen. Ik heb hier ook geen Exchange server. In de Platform SDK staat staat wel meer dan genoeg info hierover.
De interfaces kan je importeren in Delphi met Project -> Import type libary

De Platform SDK kan je downloaden van http://www.microsoft.com/msdownload/platformsdk/sdkupdate/

[jelmervos]

Ik heb optie 2 geprobeerd (met CDO), dit werkt wel aardig, alleen jammer dat er een security fix in Outlook 2002 zit die voorkomt dat 3th party software zomaar bij het adresboek mogen. Dit is dus irritant en zeker niet de bedoeling.

Is hier een oplossing voor of zal ik optie 1 toch maar proberen?

[LordLarry]

Beide zullen wel onmogelijk gemaakt dan. Anders is het niet een volledige fix

Eigenlijk moet je die security freaks bedanken Nu hebben we wel meer veiligheid, maar je bent dus ook een stuk functionaleit kwijt. Als je het nog verder doordrijft kan je beter pen en papier gebruiken, dan krijg je nooit een computer virus. Ik snap het niet, als ik mn adressen wil bewerken moet ik dat toch weten?! Ik neem dan ook wel het risico van een virus, maar laat het aub mijn keuze zijn. Ik zou zeggen: Gebruik geen Outlook als je er niet mee om kan gaan en zoek wat anders als je bang bent voor virussen, maar laat Outlook met rust! En kettingzaag is inderdaad gevaarlijk, maar als je de scherpe messen verwijderd heb je er niets meer aan. Kan je niet tegen de scherpe messen, blijf dan uit de buurt.

[LordLarry]

Ow, en voor de mensen die willen weten hoe methode twee werkt:
http://www.djpate.freeserve.co.uk/AutoOutl.htm

[jelmervos]

Idd, daar zit wat in. Of gewoon optie inbouwen dat bepaalde apps altijd toegang mogen hebben.

Wat ik nu probeer is Exchange direct te benaderen. Zo is er een OLE DB provider, maar die is alleen geinstalleerd op de Exchange server. Helaas is dat niet mijn PC en gaat dat dus moeilijk.

[Elissen]

Hey, je software draait toch op de server? Die interfaces van Exchange zelf zijn niet dicht getimmerd. Nu automatiseer je 'slechts' Outlook (op een client?) die het vervolgens over het netwerk naar Exchange toestuurd. Beter is het om de interfaces van Exchange zelf te gebruiken, lijkt me. Of die DB-connectie. Of je stopt het in de active directory .

Kijk ook eens naar de type libary 'cdoex' (Microsoft CDO for Exchange 2000 Libary). Zit in die SDK.

[jelmervos]

Die OLE DB connectie is alleen beschikbaar op de computer waar Exchange op is geinstalleerd.

[Elissen]

(was iets het het toevoegen op vorige reply en je antwoordde er al op).

Delphi schreef op 16 augustus 2002 @ 21:09:
Die OLE DB connectie is alleen beschikbaar op de computer waar Exchange op is geinstalleerd.

Het draait toch op een server

[jelmervos]

Elissen schreef op 16 augustus 2002 @ 21:11:
(was iets het het toevoegen op vorige reply en je antwoordde er al op).


[...]

Het draait toch op een server

Ja, uiteindelijk wel, maar Delphi draait op mijn ontwerp PC en daar staat weer geen Exchange 2000 server op

[jelmervos]

Ik denk dat het heel moeilijk wordt wat ik wil.

Ik heb namelijk het probleem dat de Exchange server op een andere PC draait als waar ik ontwikkel. Het mooiste is als ik op afstand verbinding kan maken en de contactpersonen kan bewerken e.d.

Een lokale oplossing is er wel, maar dan krijg ik te maken met beveiliging. Ik mag niet zomaar even bij de contactpersonen zonder toestemming. Aangezien het een server is kan er geen toestemming worden gegeven door een gebruiker.

[Elissen]

Het ziet er naar uit dat die Exchange OLEDB provider alleen op de server zelf beschikbaar is. Hij zit iig niet in de Exchange SDK. Je kunt de software ontwikkelen, echter het gaat zeer vervelend. Je kunt niet debuggen (of je moet de remote-debugger gebruiken).

Als het puur om het verwerken van die gegevens is, is het misschien nog te doen. Je kunt de connectionstring ook run-time invullen.

Leuk voor een DB verkenner:

code:

uses AdoConEd;
[..]
EditConnectionString(ADOConnection1);

Als je de db-structuur hebt, en het valt allemaal wel mee (wat ik voor je hoop ) is het wellicht te doen om 'm 'blind' te ontwikkelen.

Een aantal dingen begrijp ik niet na je laatste post:
- Is het de bedoeling dat de software op de server zelf komt te draaien of op een andere machine?
- moet de software automatisch lopen, of moet een gebruiker de opdracht geven tot
- mag jij er niet bij, of de gebruikers niet (wijzigen).

[jelmervos]

Het zou toch het mooiste zijn als ik vanaf welke machine dan ook die database kan benaderen, omdat ik graag de mogelijkheid open wil laten of mijn server applicatie op dezelfde machine draait als de Exchange server (database).
Heeft die OLEDB driver wel de mogelijkheid om een andere machine te kiezen om verbinding heen te maken?

Mijn server applicatie moet eens in de zoveel tijd de contacten (relaties) in Exchange dumpen zonder tussenkomst van wie dan ook. Het kan dus niet via Outlook omdat deze die beveiliging heeft.

[Elissen]

Kan dat niet met een Remote Data Module / DCOM

[jelmervos]

Dat is een optie, maar dan krijg je natuurlijk wel weer een extra applicatie op de Exchange server die de verbinding maakt naar de Exchange database (via die OLEDB driver) en die vervolgens een DataSetProvider heeft.

Ik kan het proberen. Maar vind het geen nette oplossing.

[Tomatoman]

DCOM of een remote data module lijkt me juist een heel nette oplossing. Je maakt er op deze manier een three-tier applicatie van, waarbij de middle tier en de database op dezelfde machine draaien. Dat heeft als extra voordeel dat als de OLEDB driver verandert of er een andere manier opduikt om Exchange aan te spreken, je alleen de middle tier hoeft om te bouwen en alle client applicaties ongewijzigd blijven. Dat scheelt je een hoop configuratieproblemen.

[jelmervos]

Maar de server die dus ook alle contacts moet wegschrijven in Exchange is ook al een DCOM server. Hier zit namelijk en MSSQL client achter en de clients maken er verbinding mee.
Dan zou het dus zo zijn dat die DCOM server weer verbinding maakt met een andere DCOM server die weer op de Exchange server draait.
Is een oplossing.