Email automation VFP9 and Outlook 365

[Steve-vfp9user]

For quite sometime I have seen the changes with different versions of Outlook. However, by changing the number at the end of the command line (or even removing it completely) it has always worked.

In a friends work place they have moved to Office 365 and have an app they use to send automated emails seamlessly.

Some of the command lines have been:

oOutlook = Createobject('Outlook.Application.11')
oOutlook = Createobject('Outlook.Application.12')
oOutlook = Createobject('Outlook.Application')

Now that Office Outlook 365 is in place we are getting the following error (even with Outlook open):

Class definition OUTLOOK.APPLICATION is not found

I noticed this thread:

http://www.tek-tips.com/viewthread.cfm?qid=1703134

and was just wondering is there no hope for the current coding, is there an alternative number instead of 11, 12 etc or should we be looking an alternative method of sending automated emails?

Unfortunately I do not personally have Office 365 so far short of buying it for test purposes, I'm at a bit of a dead end.

Version in use is VFP9


Thank you

Steve

 

[clipper01]

There may be other ways to do this using the Outlook client, but the approach below will certainly do it.

This is another great example of using the wwDotNetBridge approach, covered in a recent thread. Means that instead of dealing with the Outlook "client" , you use the services of the Office 365 Exchange Server directly using the MS recommended approach [link ]

http://msdn.microsoft.com/en-us/library/office/dd633710(v=exchg.80).aspx

[/url], all other methods of working direct to Exchange are now deprecated, even if they work at all.

the general steps are illustrated below, but in effect, the VFP code calls the Exchange methods for sending emails etc. It does require a bit of C# / visual studio knowledge, but it is becoming more apparent that this kind of cloud access will become a more common requirement of users

1)
create a C# class library with relevant methods, in this case , this gets the contact list, as a test. Call the assembly e.g. Fox2Net.dll

public List<ServiceReference1.ApiContact> GetContacts
{
ExchangeService service = new ExchangeService();
service.Credentials = new WebCredentials("username@xyz.com", "password");
service.Url = new Uri("[URL unfurl="true"]https://cas.cloudplatform1.com/ews/exchange.asmx");[/URL]
var contacts = service.FindItems(WellKnownFolderName.Contacts, new ItemView(int.MaxValue));
return contacts:
}

2)
on the VFP side , code like this, retrieves the contact list which you can then handle in VFP. Similar methods would work for sending emails etc

Do wwDotNetBridge
Local loBridge As wwDotNetBridge
loBridge = Createobject("wwDotNetBridge","V4")
loBridge.LoadAssembly("Fox2Net.dll")
loFox = loBridge.CreateInstance("Fox2Net.Main")
loContacts=lofox.GetContacts()

 

[Steve-vfp9user]

Hey clipper01

I feel that this may be a bit above my head however I'm always willing to have a go! Will post back when I know more.

Thank you

Steve

 

[Steve-vfp9user]

As an after thought on this, I remember somewhere Mike Lewis posting about the file location had to be mentioned when you email an attachment. I'm thinking this could be the cause because the actual folder has been moved to a different location on the server. I am aware of a similar app in use at another location where Office 365 is in use and the below works with the .11:

oOutlook = Createobject('Outlook.Application.11')

I wont be able to look at this for another week, but reflecting on this process, I have a feeling this may be the cause.

Thank you

Steve

 

[Olaf Doschke]

The number after Outlook.Application is just specifying a specific version. Office 365 is office in the cloud, there is nothing local to automate then. But now I use Office 365, too, and it doesn't prevent you from installing Office 2013 including Outlook 2013. Automation continues to work as always, then. The advantage of the 365 account is, you can sync and work on email from anywhere with web access. But only also installing the desktop software makes it bearable to work with office files, also with mail.

So the simple truth if you get error "Class definition OUTLOOK.APPLICATION is not found", then office isn't installed as normal desktop software. If you have an outlook online account that isn't automatable via OLE in the same way as ebay or any other online service isn't automatable via OLE, online applications are automatable via a web service or REST API, ODATA or any web api, typically based on HTTP protocol. It's the internet, not windows. OLE is windows exclusive.

The client user then may just use the OWA (Outlook web access). It's look and feel differs very much from the desktop client software. As pointed to by other links you can automate OWA via EWS API, for example, but it's of course much easier to install Outlook and not redevelop the automation.

Bye, Olaf.

 

[Mike Lewis]

I remember somewhere Mike Lewis posting about the file location had to be mentioned when you email an attachment.

Maybe. But that's got nothing to do with instantiating the Outlook object. Your CREATEOBJECT() doesn't know anything about file locations. Instead, it looks for information about the Outlook automation client, which it finds in the registry.

Given you are getting a "class not installed" message, that indicates that your customer needs to actually install Outlook on their system. Doing that won't prevent them using Outlook 365, nor should there be any problem in sharing documents between the two systems.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[clipper01]

Does that not defeat the whole purpose of Office 365, user then has to go back and buy Office "desktop"

It's just as easy to use the Exchange Server itself to do the mailing. The construction logic of the emails will not change, all that changes is that you will call the Exchange API instead of using Outlook automation.

 

[Mike Lewis]

Does that not defeat the whole purpose of Office 365, user then has to go back and buy Office "desktop"

I wouldn't have thought so. It's only a minority of users who will need to automate any of the Office processes. For many people, 365 will be a perfectly satisfactory platform. I wouldn't use it myself - but that's another story.

Mike



__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Well, you can automate Office 365 differently, but not like a desktop office.

The "whole purpose" depends on what you define it to be. If that mainly means no local installation that's right, but the desktop Office can and will be connected with your cloud account, so you don't have two office suites, you have Office in the cloud and on desktop, can easier work on documents and automate them as usual.

Bye, Olaf.

 

[Nigel Gomm]

have you looked at redemption's RDO?

it enables you to automate Office365 (and MS Exchange) in a very similar manner to automating outlook.

http://www.dimastr.com/redemption/rdo_introduction.htm

hth

n

 

[Mike Lewis]

have you looked at redemption's RDO? .... it enables you to automate Office365 (and MS Exchange) in a very similar manner to automating outlook.

Indeed it does. It could provide a good alternative to automating Outlook. But wouldn't you still need to have Outlook installed locally? I'm not sure about this. The stuff I've read seems a bit contradictory on this point.

Also, as I understand it, it doesn't allow you to automate other parts of Office 365. I can't see how it can help automate Word 365 or Excel 365, for example.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Nigel Gomm]

Mike,

you're right it doesn't help with excel or word etc but as op was asking about sending emails/automating outlook i thought it worth mentioning.

With redemption you have the redemption.dll installed locally and, in the absence of outlook, it uses a 'standalone MAPI' component to drive Office365/Exchange server over HTTP.

Works very smoothly, very similar object model to outlook and Dmitry is very good at answering questions (and of course a font of knowledge about outlook and exchange generally).


In my case at least, money well spent.

n

 

[Mike Lewis]

Thanks for the clarification, Nigel. You're right: it was definitely worth mentioning.

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Steve-vfp9user]

Apologies for not replying sooner.

I found the issue with this error and it did relate to the actual path of a file attachment when sending automated emails.

Mike Lewis had posted somewhere before that you must specify the actual path of any attachment.

What I wasn't informed of by my friend is that when they added new software to their network they also moved the application to inside another folder so basically the full path was incorrect when called for.

So by adding the new folder to the file path it works!

Cheers

Thank you

Steve