Email through webservice instead of smtp

I've been wrapping my head around a rather common issue. Companies not wanting to use an smtp mail server, but rather a webservice call (to EWS for example) to send emails.

This way, we cannot have the mails sent through the built-in email system. That's ok, we just make a common component that wraps the service call; done. But then you lose the possibility to create emails in a webflow. There could be a workaround where you (much like the html2pdf solutions) call the email like the webscreen that it actually is (can only be done through and capture the output of that call, and send that through the webservice. (I have yet to test this option to validate if it is really possible) 

But, I'd rather still use the builtin "Send Email" functionality. So my thought was to wrongly configure an smtp server and catch the emails in the system email tables. It seems possible through a hidden config in the database to tell the scheduler service to not pick up any emails. Perfect. Then my preferred option would be to create a light bpt process on top of the sent_email table, but it doesn't expose events, so that's a no-go. So, I was reverting back to a timer to send the emails, but it seems all the email tables are read-only, so I would not be able to update the email status to "sent" anyway.

I actually thought as far as to inject a database trigger directly on the sent_email table to create a record into a table which I could use as trigger for a light bpt process, but that seems too much of a hack. (and only really possible on an on-premise environment) And I would much rather like a solution that I could maybe put in a Forge component.

I considered so many options and hacks that I lost count and track. Is there really no way to use Emails (in a webflow), which for me is the bare minimum requirement and the builtin "Send Email" (which I basically already have given up on)? Any thoughts or ideas?

Well, I guess you could create an "SMTP" server (outside the Platform) that calls a REST service exposed by the Platform, which in turn calls EWS. But this is a bit laborious :).

I have to say, this is a dead end. I tried everything but always run into blocking consequences. We'll just have to discard the builtin email system completely and even the way we can create emails in the platform.

I guess we'll just tell developers that they'll have to provide the necessary html content themselves.

Bummer! Though I admit that's what we do as well, providing our own content, as it's very difficult to control what gets sent through the Platform e-mail.

Hi Tim,

Another option, for on premises, would be to implement your own version of the Scheduler service that is responsible just for sending emails, making sure you configure all Scheduler service instances running on your front-ends to not send emails.

This "New Scheduler" service would be running alongside the other OutSystems services on the server, reading emails from that system table and using the records' contents to send emails (updating them with the outcome of the EWS call, for instance).

This approach, with some tweaks could possibly be used to bypass the one SMTP server configuration per environment limitation, but would not work for a cloud environment.

In the meanwhile, you can maybe up vote this idea to provide an Email API for OutSystems (it could allow you to easily implement your EWS component, for instance).