How can I integrate email inbox from company account to my application? Gems like mail_room or gmail can connect to one mailbox given that you specify them.
I'm thinking about a web hook like a notification api, but I can't figure out how it works.
How can I add a web hook for inbox emails in company's gmail account? When a message is received in user#company.com or support#company.com I need to have a notification sent.
Check the Push Notifications for Gmail API.
1.Initial Cloud Pub/Sub Setup
The Gmail API uses the Cloud Pub/Sub API to deliver push
notifications. This allows notification via a variety of methods
including webhooks and polling on a single subscription endpoint.
Prerequisites
In order to complete the rest of this setup, make sure you fulfill the
Cloud Pub/Sub Prerequisites and then set up a Cloud Pub/Sub client.
Create a topic
Using your Cloud Pub/Sub client, create the topic that the Gmail API
should send notifications to. The topic name can be any name you
choose under your project (i.e. matching projects/myproject/topics/*,
where myproject is the Project ID listed for your project in the
Google Developers Console).
We recommend that you use a single topic for all Gmail API push
notifications for your application, due to Cloud Pub/Sub limits on the
number of topics.
Create a subscription
Follow the Cloud Pub/Sub Subscriber Guide to set up a subscription to
the topic that you created. Configure the subscription type to be
either a webhook push (i.e. HTTP POST callback) or pull (i.e.
initiated by your app). This is how your application will receive
notifications for updates.
more on the guide for additional info.
Related
My basic requirement is that I need to create "something" that is capable of intercepting emails incoming/outgoing from our mail server. It cannot be an extension to mail clients. Currently we consider only exchange server. In my research I found below resources that seems to be helpful.
Mail flow and the transport
Delivery agents and Delivery Agent connectors
Transport agents
From these transport agents seems to be quite old. Now I can't figure out what's the best from the remaining options(Mail flow and the transport or Delivery agents and Delivery Agent connectors).
Whatever I develop should be able to read email get some statistics (using mail header(s), amount of attachments etc...) and store it into a custom database. Additionally add some custom headers to incoming/outgoing mails.
Can anyone point me to right direction? Should it be some kind of a service that I can install in Exchange server? (admin center->mail flow-> connectors). For example, can I write it in c# and host it like an assembly? or may be a web hook to a hosted service where Exchange will forward emails in real time etc...
I couldn't find any examples/tutorials except this
If its OnPrem Exchange and you don't have or are considering Office365 then Transport Agents would be the right thing to use. They haven't change since 2013 but are still what is used for this type of thing the last SDK was 2010 but its still valid given the lack of change on the backend https://learn.microsoft.com/en-us/previous-versions/office/developer/exchange-server-2010/dd877026(v=exchg.140)
Delivery Agents are more for when you have an external gateway that you want to send and receive messages from.
Exchange 2010.
I've read about notification subscriptions, mailbox events, and EWS in Exchange and as i got it, the notiified client app have to stay connected to EWS all the time. Am i right?
My task looks easy - i need to trigger some action (web call most likely) when message arrives to mailbox. Is there anything for such task in EWS 2010? Is there anything like this in latest versions of Exchange Server on-prem?
For now I'm starting to think about forwarding email via trasnport rules to some unix-mta for further processing.
Yes that's correct EWS notifications require that the client application that receives the notifications stay connected if your using Stream notifications. Pull notification don't and push notifications don't but the client does need to be available to receive the heartbeat messages and then update the subscription.
There is nothing new in the later OnPrem version of Exchange there are web-hooks in Exchange Online in the Graph API
I am curious to know why Direct mail doesn't support the incoming emails to the same email address used to trigger the notifications. Why do we need to receive on another email?
Is there any architectural limitation to this in terms of security/functionality etc..
Providing email services that includes receiving emails is a different level of service then sending emails and far more complicated internally. DirectMail is a message sending service, not an email server. Alibaba does offer a full email service for its customers in China.
Hosting and receiving emails is far more complex. If you were to provide a service to send and receive emails you have to have an api waiting for an email to arrive, another to retrieve emails from the storage when the user requests, and another to send out the emails.
On the other hand DirectMail just has one service send out either predefined emails that get set up ahead of time or emails that are sent from Function Compute. This way there is no waiting/server overhead, just send and done.
For instance, Mixer's chat API requires bots to listen on a web socket, but Azure App Bots require apps to post to messages to it.
The bot is essentially an API server. The /api/messages route is one endpoint. You may define as many endpoints as you like on your bot server to handle whatever other activities you need to handle, such as websockets.
We are currently implementing a simple chat app that allows users to create conversations and exchange messages.
Our basic setup involves AngularJS on the front-end and SignalR hub on the back end. It works like this:
Client app opens a Websockets connection to our real-time service (based on SignalR) and subscribes to chat updates
User starts sending messages. For each new message, client app calls HTTP API to send it
The API stores the message in the database and notifies our real-time service that there is a new message
Real-time service pushes the message via Websockets to subscribed Clients
However, we noticed that opening up so many HTTP connections for each new message may not be a good idea, so we were wondering if Websockets should be used to both send and receive messages?
The new setup would look like this:
Client app opens a Websockets connection with real-time service
User starts sending messages. Client app pushes the messages to real-time service using Websockets
Real-time service picks up the message, notifies our persistence service it needs to be stored, then delivers the message to other subscribed Clients
Persistence service stores the message
Which of these options is more typical when setting up an efficient and performant chat system? Thanks!
You don't need a different http or Web API to persist message. Persist it in the hub method that is broadcasting the message. You can use async methods in the hub, create async tasks to save the message.
Using a different persistence API then calling signalr to broadcase isn't efficient, and why dublicate all the efforts?