Is there a way to avoid race conditions when inserting events into Google Calendar using the API? I have an experimental app that needs to insert events into user's calendar. However, the user should not be double booked at a particular time.
The only true way of guaranteeing something like this is if Google provides a way. Other solutions are prone to race conditions (example, some other app that the user has updating it while my app is ignorant). The options as far as I can tell:
E-Tags with If-Match option - But this option is not valid for inserts according to the docs (https://developers.google.com/google-apps/calendar/v3/version-resources).
Important: There is no support for conditional modifications for
insert operations. Instead, it is guaranteed that if you are allowed
to provide a resource ID, then the operation will only succeed if no
existing entry has that ID.
So if I provide an if-match with the calendar etag and try to insert, it always fails regardless of the fact that the etag is correct.
Using "watch" for a brief period while the event is about to be inserted (https://developers.google.com/google-apps/calendar/v3/reference/events/watch). However, this solution is prone to race conditions due to the time take to get notified. One user inserting while my app gets notified of the update is problematic.
Sync the whole calendar with server periodically and consider the source of truth as the synced version and avoid double booking. Less optimal because new events added won't get synced fast enough, but the most likely will work.
What other solutions come to mind? I think #3 is the most suitable to guarantee consistency and integrity of data to avoid double booking.
I found a solution to this on this blog which states that you'll be using Calendar Resource API instead of the Google Calendar. I think this guide is what you're looking for.
Unlike a regular calendar, resources:
-Do not allow conflicts
-Can be shared across everyone on your Google Apps domain
-Can be invited (multiple at a time) to events, just like a person
-Their ability to share availability with everyone makes resources great for managing rooms schedules. Especially in a shared work
environment like your office.
FYI: This guide assumes you already have Google Apps. Currently only
paid accounts have access to resource calendars. If you’re
grandfathered in or using a personal Gmail account, this process won’t
make much sense.
Related
I have a User Microservice, that publishes events when a user is created, modified, or deleted. In addition, I have a Calendar Microservice that needs the user data. The Calendar service, subscribes to the user events and keeps a read only copy of the needed data.
I have just added an Account Microservice that needs the existing user data and I have used the same model as above. What is the best way to get the existing user data into the Account Microservice?
When I did the first Microservice I republished the user-modified event for every user. It was simple, because nothing else was using this event. If I republish now, for the new Account Microservice, the existing Calendar Microservice will also get the events. My logic is idempotent, but this is a lot of wasted work and will only get worse as I get more services.
I've loaded data a lot in the past. I know how to make it work, but I am looking for a best-practice and a way to do it with minimal coordination and dependencies with other services.
When I did the first Microservice I republished the user-modified event for every user. It was simple, because nothing else was using this event. If I republish now, for the new Account Microservice, the existing Calendar Microservice will also get the events. My logic is idempotent, but this is a lot of wasted work and will only get worse as I get more services.
What you probably want here is a design in which you pull, rather than push, copies of the events to new systems: see Greg Young, Polyglot Data.
In broad strokes - the subscriber keeps track of the high water mark, and asks for more events after some mark, and then the event store answers that query with zero or more new events, in order. The twitter timeline api can give you a sense for how that might work -- sadly, the images that explained the ideas seem to have been removed from the docs, but some of them have been captured here at stack overflow, and by the wayback machine
I have built a platform that in essence allows users:
to create a company profile and invite your colleagues,
create an office with a floor plan,
add tables and meeting rooms to the floor plan with each meeting room having a separate calendar,
book tables and meetings in meeting rooms.
The platform is built on Python/Django.
Now I am trying to implement a sync mechanism that would work with Office 365 and local Exchange distributions. The sync would be two way, that means an event created in Outlook would trigger an event to be created in our system and vice versa.
My first attempt was to use the EWS SOAP API (with exchangelib). But soon I've run into problems when figuring out how to create triggers for Outlook events. This ended in failure as synchronization would involve constant bombing of slow API-calls such as iterating through accounts and checking if anything changed in their calendars.
Second attempt involved using the Microsoft Graph API that has this neat push notification feature that would solve polling (or so I thought). But as I later found out, having the administrator link his privileged Exchange account and then being able to subscribe event changes for all associated accounts in one go was not possible (thanks to this article). So again this lead to the realization that polling (or making everyone link their personal accounts) was the only way to go.
What approach would you recommend to achieve two-way sync with Exchange that would involve only having the admin do the account linking with as little overhead and polling as possible?
Is there anyone who have developed large-scale applications that do something similar? If so, can you push me in the right direction?
A bit late to the game here, but maybe what you want is the EWS SubscribeToPushNotifications service. It's not implemented in exchangelib yet, but there's a ticket for it https://github.com/ecederstrand/exchangelib/issues/145
Implementing the basics should not be difficult.
Yes, Braintree and Taxamo have a couple of widgets facilitating their integration, but the way they work they are tied to the process of authorization of a credit card while what the tax services are interested in are SETTLED transactions (i.e. what is actually billed from the client at the end of the day),
settled transactions aren't the same thing as authorized transactions, voids, IO problems in API communication, client-side software bugs, even credit card company policies (chargebacks, presentment rejections etc) result with what is authorized not being equal to what is settled / billed,
special world of pain continues when you consider the complex formulas for mid-cycle subscription updates (proration), discount and addon calculations and the fact that none of my subscription API calls done using the sandbox don't have a transaction object (so I don't know the amounts being billed from the client),
meaning I have to reimplement a bunch of advanced logic done by Braintree to deduce what the client will see on his bank statement and hope to have gotten everything right, or have IRS on our back -_- (in Croatia companies get blocked over 1-3 euro imbalances in the tax reports)
So the question, am I missing something here?
is there a simple way to submit to Taxamo only settled transactions?
does maybe the sandbox and mock webhooks behave differently than production, is it possible that Subscription API calls and webhooks in production return a transaction object and that I just don't see it?
does the current Braintree and Taxamo integration at least "kind of work in practice 100% of the time" and I'm worrying too much?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
Braintree and Taxamo don't have an official integration package (the widgets available are not supported by Braintree, and Braintree had no hand in developing them). However, the two can be, and often are, used alongside each other. Because there's no official integration, the two integrations don't interact with one another, and the logic concerning when any action in Taxamo should take place in relation to an action in Braintree is up to a user to implement.
With that in mind, there's no 'out-of-the-box' solution to submit only settled transactions to Taxamo. Braintree does offer settlement batch summary reports, which contain the transactions that settle every night. Using the information there, you could submit your transactions to Taxamo every night alongside the settlement batches. However, be aware that transactions don't always settle immediately, so there will be a gap between the time that you submit a transaction for settlement and the time you submit the transaction to Taxamo.
Alternatively, you could store the transaction in Taxamo immediately and keep track of the transaction key that Taxamo generates to reference the tranasction. Then, if anything happens that prevents the transaction from settling, you can delete that transaction in Taxamo.
These are just two options to consider for an open-ended problem. As always, you should evaluate your business needs carefully, and do whatever you believe will work best.
As BladeBarringer mentioned in the comments to your question, the subscription response object does contain an array of transactions that you can reference. The most recent transaction is always at index [0] of that array.
I have a quick question...may sound a little straightforward but still want to throw it out there.
I am aware that typically a session is limited to a single browser and client instance.
With that said though say a user signs up on your mobile device and starts to do some shopping...maybe adds something to their cart and then decides that they want to complete the purchase on their desktop.
I have some people that want to call this a single session while technically its a new session.
Does this make any sense?
In theory this should work with Universal Analytics, at least for logged in users ( I assume that your users are logged in if they want to buy).
You can pass a client id as a parameter when you create the tracker. The client id is supposed to be formatted as UUID, so you'd have to store that along with your real client id in you backend system and pass it in to the tracker as a part of the confuguration json object (optional third parameter in ga create). Apparently this get retroactively applied to the running session (no written source for that but I recently attented a conference where a google employee said as much, so I assume this is legit).
So as far as it concerns data collection UA is ready for multidevice. I frankly do not know to what extent this already works in the Analytics Interface.
I recently had a glimpse at a Analytics Premium Account which already had some new multdevice reports. I don't know if the fact that those reports are, at least for the moment, absent from the free version means that multidevice tracking does not work yet on the free version (those reports are along the line of Venn diagramms for "How many users used more than one device" and the like).
I can't find much about this online so I was wondering if someone knew here.
Is SSRS 2005 if a user creates a subscription, will other users be able to view and edit those subsciptions? If not, is it possible to make subsciriptions visible to everyone?
Thanks
Quick answer is no.
Long answer is:
AFAIK, there is no site-wide subscription management functionality. The best you can do within Report Manager is site-wide schedule management, which allows admins to set up schedules at preferred times and let users choose those schedules when creating their subscriptions.
Our solution for controlling/centralising subscriptions was to set up a generic Windows user, log in to Report Manager and use that user to create all subscriptions. This means that all requests for subscriptions go through the IT department (+ or - depends on your situation. We didn't want users creating subscriptions themselves). All users who know the generic username/password can manage subscriptions in one place. Not ideal but it works for us.
Another option is that all the data for subscriptions is held on the Server, either in the Reporting Services database or in the Jobs themselves. If you are brave you can delve in and set up some sort of interface to access this.
This is definitely an area in which I find SSRS lacking.
Update:
You live and learn. I've just found that (provided you have sufficient privileges) if you open a report, then go to the subscriptions tab, you can view and edit any subscriptions that are set up on this report by any user. Still not ideal as you don't get an overview of the subscriptions across the system but better than the bleak picture I painted previously!