I need a GMB account to publish notifications to more than one topic.
Reason: A company (which I do not work with) and my own company both need to receive notifications from the same GMB account.
The issue is that the GMB API seems to allow a GMB account to publish to only a single topic.
See here: https://developers.google.com/my-business/reference/rest/v4/Notifications
"There will be only one notification settings resource per-account."
This is the GMB endpoint for subscribing a topic to receive notifications from an account:
PUT https://mybusiness.googleapis.com/v4/accounts/<ACCOUNT ID>/notifications
Body:
{
"topicName": "<TOPIC NAME>",
"notificationTypes": [
"NEW_REVIEW"
]
}
However, this request simply removes the account's existing notification settings. There seems to be no way to request notifications for multiple topics.
Why do you need multiple topics? A cloud-pubsub topic can have multiple subscriptions, each of which will recieve a copy of every message published to the topic.
See https://cloud.google.com/pubsub/docs/overview#publisher-subscriber-relationships for a diagram.
Related
I have an Azure Service Bus topic. Messages send to the topic contain application properties.
I want to set permissions on the topic based on values of one or more application properties, i.e. only when identity A sends a message with property e.g. Destination = 'service' the message is allowed to be added to the topic.
The reason behind this: assume a topic where there are multiple publishers and multiple subscribers to consume the messages from the publishers. But each message shall only go to specific consumers using filters. An actor with bad intentions or just by accident could choose a filter value and send the message therefore to wrong consumers. And I don't want to create multiple topics. I want to limit the publishers to send messages to certain consumers by limiting their permissions by message attributes with certain values on a certain topic.
Is this possible? If yes, how?
You can start a separate app which will peek the message in the queue
check for the properties and then abandon the messages.
To peek create a receiver and use receiver.ReceiveMessageAsync();
to peek the message. After this you can apply your logic to filter
the messages using the properties.
After that use AbandonAsync to abandon the message with wrong properties.
// create a reciever and peek the messages.
await using var client = new ServiceBusClient(connectionString);
//reciever
ServiceBusReceiver receiver = client.CreateReceiver(queueName) ;
// get the messages
ServiceBusReceivedMessage receivedMessage = await receiver.ReceiveMessageAsync();
// write you logic for filtering the message
//now we can abandon the message. Here "reason":" Wrong message" is optional
await receivedMessage.AbandonAsync(new Dictionary<string, object> { { "Reason", "wrong properties"} });
Refernce:
Refer the article by sfeldman
Peek messages
You can't use ServiceBus (or any message broker) the way you describe.
My advice is to consider messages only as signals to do something. But the service is entirely responsible to check if the message is legitimate or not (by calling the source service or another source of truth synchronously for example).
Imagine this scenario:
SourceApp send a DeletedEvent{CustomerId="42"}.
DestApp receives this message, and before deleting data related to this customer, makes an HTTP call to the customer service GET CustomerService/42.
If the customer is deleted => perfect
If not... something went wrong, what you described by an actor with bad intentions or just by accident
Also, if you use the same topic for a lot of applications consider using AAD authentication, with managed identity per app. Or at least forbid sharing SAS keys. Every app should have dedicated connection string, scoped to the subscription or the topic with only the access needed.
I am sure this has been asked many times but am unable to find relevant answer. Is there any way to send Azure monitor alerts to slack via Logic apps or some other way. I have found this template - https://github.com/Azure/azure-quickstart-templates/tree/master/demos/alert-to-slack-with-logic-app and integrated it into my azure system but it is not working.
Have tried some work around mentioned at - https://github.com/Azure/azure-quickstart-templates/issues/3319 but all in vain
Direct Webhook from action group using slack incoming webhook is not supported , as azure sends alert using its own schema.
Any input is highly appreciated ...
Azure Logic Apps is definitely an option, but if you are not needing complicated workflows, just send the alert directly from Azure Monitor to a Slack channel. You can do this by generating a unique email for the Slack channel and using that email in your Azure Monitor alert action group settings. Another option would be to send the alert to your company alert email inbox and have it automatically forwarded to that Slack channel email address. With this approach you completely remove the dependency and complexity of Azure Logic Apps.
https://slack.com/help/articles/206819278-Send-emails-to-Slack#h_01F4WDZG8RTCTNAMR4KJ7D419V
I have tried to send a message to the topic of Azure Service Bus but it is not having any subscribers for now and it was showing there is no matching subscription found for it. So I have created a temporary subscriber for that and sent the message successfully.
So my question is it compulsory to having a subscriber to send the message to the topic??
Thanks for the help!
You do not have to have subscriptions under the topic to be able to publish messages. But in order to receive messages, subscriptions have to exist. Subscribers can come online later and fetch those events. Without subscriptions, subscribers will not get anything as the topic doesn't know what to retain and for whom.
I am using Azure API Management for managing our APIs. Its containing product and all. Now I also want to catch some of the customer information into my database.
So my question is : "Is there anyway such that whenever someone is subscribing any product, my API will trigger?"
What I want to do is I will create an API which will fetch the details from Azure via REST API for all subscriptions and I want to call (auto trigger) that API whenever someone subscribe any product successfully. I know we can set the Approval workflow, we can send notification email also to any specific email id, but can we call any HTTP request?
Also if anyone have more idea about Developer portal then please share. (can we customize it, till what level, how, etc.)
Thanks in Advance..
One way is to put an Event Grid system topic on the resource group containing API Management service with
filter for Resource Write Success
subject filter / Subject begins with /subscriptions/{subscriptionId}/resourceGroups/{resourceGroup}/providers/Microsoft.ApiManagement/service/{apiManagementService}/subscriptions
and forward to Azure Function or WebHook - basically filter for activities logged as Subscribe to product or Update subscription on the resource.
In Azure Service Bus, if below is the sequence of events, then all's fine -
Create Topic
Create Subscriptions inside Topic
Send Messages to Topic
With above, the subscriptions are triggered when a message is sent. This is expected.
However, if we modify the above sequence like this
Create Topic
Send Messages to Topic
Create Subscriptions inside Topic
In this case, as messages are sent to a topic whilst no subscriptions were in place, when the subscriptions are indeed created, the previously sent messages don't show up in their list. Those messages are essentially 'lost'. Am not able to see those messages in Service Bus Explorer too.
The above sequence flow is relevant because we have detached publishers and subscribers, where the publisher just sends a message and subscribers, when they come online, create the subscriptions and handle them. The order in which the publisher and subscriber come online is not guaranteed.
How can I access/process messages sent to the topic before the subscriptions are created? What happens to such messages in the first place?
Thanks
It turns out that the above behavior is by design - if no subscriptions are there, then the message is lost.
To overcome this, Azure Service Bus provides a property on topic to enable the pre-filtering of messages before they are sent. So, if no filters/subscriptions are available, it'll throw an exception
Set the option on the Topic
namespaceManager.CreateTopicAsync(new TopicDescription(topicName)
{
EnableFilteringMessagesBeforePublishing = true
});
Whilst sending the message, check for exception
try
{
await topicClient.SendAsync(brokeredMessage);
}
catch (NoMatchingSubscriptionException ex)
{
// handle the exception, maybe send it to dead letter queue using DeadLetterAsync
}