Thanks Dmitry.
Is there a good source of information on store provider writing (client-side
dll). I have written some MAPI C++ code, but I cannot see how it could be
compiled to become a service for including with Outlook. I assume that it
would have to implement a minimum set of MAPI services.
I have just come across the COM Add-In. Perhaps this would be a better tool,
given that the use pattern would be Search -> List -> Display. Then the
results can be thrown away.
Merlin.
"Dmitry Streblechenko" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> You either need to write a store provider (Extended MAPI, C++/Delphi only)
> or create an addin which adds a PST file and syncs the data from your SOAP
> service when a user accesses a particular folder (a sync really).
>
> Dmitry Streblechenko (MVP)
> http://www.dimastr.com/
> OutlookSpy - Outlook, CDO
> and MAPI Developer Tool
>
>
> "MerlinB" <(E-Mail Removed)> wrote in message
> news:%(E-Mail Removed)...
> > What techniques/technologies should I consider in order to use Outlook
> (any
> > version) as a front-end to an external (non MAPI) system? It already
has
> a
> > Web front-end, so I do not need to consider the WebDAV or OWA type
> > facilities.
> >
> > The external system holds emails in MIME format, and provides
> > search/list/details facilities, that could be made available via SOAP
> calls.
> > The emails may contain TNEF attachments, and so Outlook should be able
to
> > display them as though from an Exchange source.
> >
> > Ideas:
> > 1. To create a 'service' that Outlook users could Add, via the Services
> menu
> > option. (Where is the documentation on these Services?)
> > 2. To add a Forms application, and use VBA to directly access the remote
> > facility, or build a DCOM server app to act as a proxy - so users do not
> > need to install SOAP api on their desktops.
> > 3. Write a MAPI server! I don't think.
> > 4. any other sensible ideas???
> >
> >
>
>
Similar Threads
