Interfacing OWA with VFP App

[JRB-Bldr]

Does anyone have any idea how to go about interfacing Micro$oft's OWA to a VFP app?

Up until now my client's technical staff has been un-able to give me advice on how to 'connect' my VFP app to their Email Server so that I can automatically send 100's of emails to their employees through THEIR SMTP Server so as to meet THEIR project requirement. The only 'Public interface' is via Outlook Web Access (a.k.a. OWA).

What I have to possibly work with is Outlook 2003 for either a POP or Exchange Account - but their SMTP Server is secured such that it is not Publically available.
And I can write a Web Services interface (or anything else for that matter) if necessary.

If anyone has any suggestions that I can take back to the client to help them figure out how it can be done, I'd appreciate it.

Thanks,
JRB-Bldr

 

[TamarGranor]

Do you have to go through Outlook? Could you use something like Blat (

http://www.blat.net/)

instead?

Tamar

 

[JRB-Bldr]

I am already using Outlook for all of the client customer's emails today - and it is working well.

But that does not mean that I HAVE to use it for this other client customer - that's why I mentioned Web Services above.

But, if I can get things working, I WOULD HAVE to use the client's Email Server (Exchange) in such a manner that the emails would actually be Sent from that instead of another Email Server.

If there was an alternative approach to Outlook I would be happy to consider it.

Thanks,
JRB-Bldr

 

[Olaf Doschke]

Well, blat is an alternative, but it depends on the accessibility of an SMTP server. If an exchange server exists, and MAPI is installed on that server, and it is configured correctly, then typically CDO.Message is precoinfigered with the correct settings to send mails via the local Exchange, AFAIK. At CDO.Message is what I would think of, when you mention Exchange.

But that is Exchange Online, then this does not apply, then you also have to handle the OWA web interface API. I never did so, but there is an API you can run with http requests. As said here: [URL unfurl="true"]http://msdn.microsoft.com/en-us/library/exchange/aa142564(v=exchg.65).aspx[/url]

Outlook Web Access does not expose COM objects, or provide an object hierarchy. Instead, you can obtain the components of Outlook Web Access by using a URL; for example,

https://mail.example.com/exchange/username/Inbox/?Cmd=contents

Bye, Olaf.

 

[JRB-Bldr]

Olaf - Thanks

The link you gave may have pointed me in the correct direction.

It says:
Outlook Web Access components are only available by means of the HTTPS GET and POST methods.

That I can most likely do by using my Chilkat objects (

http://www.example-code.com/foxpro/http.asp)

if I can get the appropriate URL and login credentials from the client.

I'll explore this avenue for a while and see where it enables me to go.

Thanks,
JRB-Bldr

 

[Olaf Doschke]

Yes, you can also use MsXml2.XmlHttp or the vfp libcurl wrapper by Carlos Alloatti or go lower level and use winsock or win api or other components, but Chilkat would also be fine.

Bye, Olaf.

 

[JRB-Bldr]

Well so far I keep hitting dead ends with this project since I cannot get the client to give me a WSDL that I can access.

Instead I have put together from a number of sources an .ASMX that seems to go close to where I need it to go.

Example:
http(s)://servername/EWS/Exchange.asmx

And the most recent approach reference in that direction that I have found is:

http://blog.oscarscode.com/dot-net/get-started-with-exchange-web-services-ews/

If someone has any suggestions on how to convert their sample code to VFP code, I'd appreciate it.
Otherwise I will keep playing with it and see where it goes (if anywhere).

Thanks,
JRB-Bldr

 

[Olaf Doschke]

It says it's SOAP based Webservice, so you might try with the webservice tab of the task pane, but I fear you won't get far, as it's some newer version of soap. Also what you need is a url to wsdl, the wsdl itself is only halfways helpful.

This overview is stating you also can use the outlook object model (OOM = COM automation as we know it), but that has the prerequisite of a local outlook 2013 installation instead of a click to run installation or using outlook webbased only. It's still possible your client simply installs the full blown outlook, that doesn't hinder the usage as is and enables you to recycle your code base. It's still something else to automate exchange than outlook.

If your customer wants to save the cost of licenses your best bet is to write a wrapper in dotnet using the EWS managed api, perhaps.

I haven't done that myself and not evaluated any of the development technologies, so I'd be interested to hear from you, whatever you get working. Not every technology is giving the access to all Exchange components, so you are limited and the best bet may be the EWS managed API.

Bye, Olaf.

 

[JRB-Bldr]

Olaf - thanks for the input.

whatever you get working
I'll certainly give it my all, but I am afraid that there is a great deal of non-support (whether from ignorance or territorial bureaucracy) from the client side despite their requirement by another client department to make this happen.

We'll see where things go from here.

Thanks,
JRB-Bldr