Run Azure Logic app on different subscription - azure-blob-storage

I have logic app and Storage account both on different subscription. I want to run logic app when resource event occurs on storage account which is at different subscription. How I can do that..

There are multiple methods to achieve this. Easiest one is to create a logic app for the storage account trigger in the same subscription and make it do an HTTP POST to the logic app created in different subscription. Let me know if you need detailed explanation on this.

Related

Play & App Store Webhooks / Server Side Code on subscription start and cancel

I need to add server side logic when a user buys and cancels a subscription. To me this seems like a basic feature that many apps probably use. However as it turns out it's not that simple to setup up the need webhooks.
My App will be available on android and iOS, so I will need to configure both, which is why I thought about using RevenueCat. But it turns out, this is a paid feature for $110/month, which is way too much for a/my new app. This is probably the biggest time saver for RevenueCat compared to using the official InApp Purchases packages, so I don't see why they would make it a paid feature.
Anyways what the best way to handle webhooks with the Play Store and the App Store? Any Guides and Tipps would be very helpful!
Apple and Google both offer server-to-server notifications that will notify you when a subscriber cancels.
Apple guide: Enabling Server-to-Server Notifications
Google guide: Real-time developer notifications
If you have your own user Ids, they won't be present in these server notifications so on your server you can save the user Id along with the transaction identifier of their original purchase. That way when a notification comes in you can look up the user from the transaction identifier and flag them as cancelled.
Alternatively, the RevenueCat API is included on their free plan so you can periodically poll their GET /subscribers endpoint to get the latest subscription status for a user. This obviously won't be real-time, but may be enough for your use-case.
Update: I decided to solve this issue similar as #enc_life suggested with the RevenueCat API. For validation the purchase, I send a request to my server, that checks with if the user actually bought the subscription. For canceling the subscription, I execute a function everyday on my server, that checks for all subscribers if the subscription is still valid.

Prevent conflicts when creating events in a resource calendar using Google Calendar V3

I'm trying to solve a problem of preventing double bookings using the Google Calendar Api (v3). I'm using Google resources in a GSuite environment. The bookings are made from a centralized platform on behalf of multiple users and are applied to multiple rooms (resources). The responsible application authenticates using a Service Account. The resource calendars are all configured to only accept invitations that do not conflict.
So far I found out that there are at least two ways to book a resource:
Create an event in the resource calendar
Create an event in a personal calendar en add the resource as attendee
I found out that in the first senario, events can be added to the resource calendar, even if they cause a conflict. There is no failure in the api response, the event is just added.
I tested the second scenario with my personal calendar and found out that the room needs to respond to the event invitation. Apparently that process may take several minutes before the room responds.
I'm building an api that should respond as fast as possible, but I want it to only create an event if it doesn't conflict. Of course I can use the free/busy information to reduce the chance of conclicts, but I would like to eliminate that chance entirely.
Does anyone know if Google provides functionality for this problem out of the box?
Thanks in advance.
Google does not do any validation on the api. You send what you want inserted and they insert it. Its up to you to ensure that it does not conflict with anything already there.
May i suggest that you check before you insert it and then do a double check in a few minutes to ensure there is no conflicts if there is then delete it again.

Slack API : Ability to view all recently added users to Slack Channel

I am working on a POC to proof out the ability to get a list of all the new users who have been added to a specific Slack Channel. From my initial review of the Slack API I am not seeing anything that showcases this ability, I was curious to see if anyone had worked on something similar or could point me to resources that would be a viable solution.
I believe there is no ready-made API method available, that will give you that specific information. However, Slack is very flexible and you can use the existing building blocks to easily add additional features as needed.
E.g. To get the requested information you can develop a small Slack app that listens to the member_joined_channel and member_left_channel events to keep track of when members joined a channel.
If you need a historical record of membership in a channel, you could use the Slack API's groups.history method, page through results, and build a membership log by looking for events of type member_joined_channel and member_left_channel through time.

QnAMaker bot archiving conversations?

I'm a user of the Bot Framework, and of the sample QnAMaker also. As the owner of the bot, I would like all the conversations to be archived, so I can browse through them afterwards to learn about the expectations of my bot's users, what conversations went well, went bad, etc.
Is there a built-in mechanism in either the bot framework or the QnAMaker sample to archive conversations and give access to the bot's owner?
At this time, I'm unaware of a built-in feature that accomplishes that. However, you could always extract whatever necessary information (text, timestamp, etc.) and then store it in a database entry indexed by the user's channel id or some other identifying value.
Then you could make an endpoint for a REST API that serves the information back to the user, or just serve a web page that displays the information via HTML.
You can declare variables to store specific information in session and prompt the user for the specific information. Like asking for the users name and invoking session.userData[userNameKey] = results.response;
You can setup a database in Microsoft Azure and add .set('storage', tableStorage); to your bot object if you are using the Azure Table Service.
Check out https://learn.microsoft.com/en-us/bot-framework/nodejs/bot-builder-nodejs-state
For QnAMaker, there is a recordQnAFeedback object that you should be able to use to store the dialog in a database as well.
Hope that helps.

Is the WebOS calendar api really as limited as it sounds?

A recent Ars Technica article rekindled my interest in WebOS so I was looking at the Services API (because I'm interested in building a replacement calendar app). I discovered the following text at the top of the calendar services API documentation:
Note: To prevent unauthorized use of
private user data, this API provides
access only to records created by your
application; that is, you cannot
access records owned by another
application.
What is the point of even having an API if you can't access data created by other applications? At that point there would be no reason for me to use their API rather than building the data storage myself. Am I missing something? Can any WebOS developers weigh in on this?
P.S. If they named their os "WebOS" you would think they'd know something about sane URLs. Check out that ridiculous calendar api doc url!!
The reason for the limited access is because of security, but not just that. Some services have agreements that limit how their data can be used. For example, having an API that would let a random webOS app access your Facebook calendar data would be working around the FaceBook terms of service that control how that data can be used. The same applies to LinkedIn, Google Calendar, and any other service from which the system is pulling information.
If you just need to post an occasional event, there's a better API to use that lets you cross-launch the calendar app with data that the user can accept into their own calendar. That way, you don't create your own bucket, but the user has to manually accept the event.
The reason to use the calendar APIs is to expose your own data to the user of the device. FlightView, for example, uses it to publish a calendar to the user of upcoming flights that he or she is interested in, and if those get rescheduled, it can automatically change them. The Fandango app uses this to push movie times for theaters the user likes into their calendar view. There's lots of possibilities.

Resources