Interop.Outlook / UiPath - Is there a way to send an email in an asynchronous way?

Help
, , ,
1

0

I’ve developed some custom activites for UiPath, some of them to send emails with some custom behaviours (Change the reply recipient of an email, take all the thread and re send it…)

Thing is, there weren’t any problem with it till we faced a security window on Outlook that you should push on “Allow” to continue sending or getting an email from it.

This pop up actually blocks any email outlook related activity (from UiPath too). We actually sorted it out with a Paralell activity for UiPath activities.

With custom activities things differs, as Interop’s Send method locks the CPU/Thread/Whatever, not allowing the Paralell activity to do its job.

UiPath custom activities should be inherited or derived from CodeActivity, which is synchronous, so I used AsyncCodeActivity that implements

protected override IAsyncResult BeginExecute(AsyncCodeActivityContext context, AsyncCallback callback, object state)

protected override void EndExecute(AsyncCodeActivityContext context, IAsyncResult result)

On BeginExecute I have my Send method, that still blocks the process. And yeah I’ve hacked to return something that has nothing to do with the process itself.

            return func.BeginInvoke(2, 1, callback, state);```



As you can see, I'm not really used with asynchronous or thread-related coding.
So, can anyone help me how to send an email (from Outlook, not SMTP or anything related to) in an asynchronous way? Seems like UiPath activities are doing it and I want to replicate.

Thanks you very much.

Kind regards,
2

Not sure why you want an async email sending requirement, but as you might have seen in outlook however fast or async you are - if you are using a single mailbox you will find all those items queued in the outbox which defeats the requirement.

I havent seen any explicit reason to send/bulk-send emails in async fashion unless you tend towards using multiple mailbox (which I havent tried as there hasnt been any need for that yet would love to hear why that requirement has been specified)

3

The requirement is as follows:

Any time you Get, or Send an email trought Outlook this pop up happens:

https://www.outlook-apps.com/wp-content/uploads/Outlook-security-warning.png

The way we handled this is by using a Paralel sequence, on our left we have the Send/Get activity and on our right we have the logic to handle this popup.

With any UiPath outlook activity, it works fine, first it goes on left, tries to send/get the email, the popup appears, UiPath goes to the right, pushes the button and finally the send/get email can be finished.

What is happening with my custom activities is that, first goes on left, tries to send/get the email, the popup appears, the send method from Interop LOCKS the thread/CPU, so UiPath does not goes to the right paralel side, thus, not working at all.

Thats why I’m looking for some kind of tool like sending an email async so when sending, CPU can be free for pushing the Allow button and then come back to actually end sending the email.

4

Basically the first child thread that uipath picks up is from right to left. And that popup can be stopped through outlook settings in your machine (in all Virtual machines) also clicking that popup might turn out to be bad design when you are migrating or scaling your bots over-time.

An alternate solution is to change the security settings only for the bot. Hope that makes sense.

Also along with UiPath you might also want to take a look at Microsoft flow for O365 features of automating your mailbox.

If I remember correctly apart from async interface you can use delegate method also for multi-threading; on the off chance of over-engineering your solution try a few that are easily accessible if time is of the essence or if your deadline is tight.

Hope this helps :slight_smile:

Regards

5

Thanks you very much for your time!

Thing is, we are not allowed to turn off those settings. I wish the solution was that easy! x)

6

I wish so too, so there might be other options that we havent explored yet; are those settings really regulated so strictly by your org?