Ideal Scenario.
The user makes the order.
Firebase Server sends the request to Stripe.
Stripe Confirm Payment Method and sends a webhook to Firestore. At this point, I can create the order on the server. But:
webhook sometimes is fast and others not
need to create a temp order and update it later with the data from the hook
Problems till here
how to know the id of the created order to update later?
is there some way to send data automatically from the server to the client?
The most common way to handle this is to attach metadata to your PaymentIntent with a UUID for your Order ID. At the same time you create a corresponding order in your database. Then, that same Order ID will come through via your Webhook (via the metadata you set) when the payment has been completed and you update your database accordingly for that order.
Related
I am using Azure API Management.
I have create an API, a product and a subscription
The API is generic. it does a lookup of sales order history and requires a customer id to show that customers orders onyl. The relation between customer and subscription is intended as 1:1.
However I dont want subscribers to see other subscribers data. I thought, I could set a fixed parameter (e.g. customer id) to each subscription to be passed to the API on any call.
Or how can limit API to be only show subscriber specific data? Somehow the API has to differentiate between subscriber. Any idea?
When calling an API using a subscription key, the context.Subscription and context.User (not for standalone subscriptions) are set for use in policies.
Since you have a 1:1 relation between customer and subscription, you could set a header in the request to the backend with the user's email using the below policy statement in the inbound policy section
<set-header name="x-customer-email" exists-action="override">
<value>#(context.User.Email)</value>
</set-header>
We are trying to develop a SCIM enabled Provisioning system for provisioning data from an Enterprise Cloud Subscriber(ECS) to Salesforce(Cloud Service Provider-CSP). We are following SCIM 1.1 standard.
What are we able to do:
We are able to perform CRUD operations on User object using Salesforce auto-generated userId field
Exact Problem:
We are not able to update/delete User object using externalId provided by ECS.
Tried something as below... But it is not working, Unknown_Exception is thrown...
XXX/my.salesforce.com/services/scim/v1/Users/701984?fields=externalId
Please note that it is not possible to store Salesforce userId in ECS's database due to some compliance reasons. So we have to completely depend upon externalId only.
Possible Workaround:
Step1: Read the userId based on externalId from Salesforce
Step2: Update the User object using the salesforce UserId obtained in Step1.
But this two step process would definitely degrade the performance.
Is there any way to update/delete the User by externalId
Could you please guide us on this..
Thanks so much....
I realize this is old thread but wanted to note that you CAN update Users from REST using an external ID. The endpoint in above question is incorrect. Following is how it should be set, send as a PATCH request:
[instance]/services/data/v37.0/sobjects/user/[external_id__c]/[external id value]
Instance = your instance i.e. https://test.salesforce.com/
external_id__c = API name of your custom external Id field on User
external id value = whatever the value of the user's external Id
NOTES:
Salesforce responds with an HTTP 204 status code with No Content in the body, this isn't usual for patch requests, but it is 'success' response
The external id on user has to be a custom field, make sure it is set
as UNIQUE
Ensure the profile/permission set of the user that is making the call
has the Manage Users permission & has access to the external id field
It is pretty common pattern for other applications, too, to search first and then perform on update on the returned object. Your workaround seems fine to me. What performance problem are you concerned about? Are you concerned about Salesforce not being able to process more requests or are you concerned about the higher response time in your application because you need to make multiple requests? Have you actually measured how much an extra call costs?
For example, I need to validate email during registration process (check, if it already exists in database). In this case i have no need to store any data.
Should i utilize flux way and call server side (nodejs) api through Actions or just call server side api right from the registration form component?
Since you are calling the server I would go through actions , receive the answer call dispatch and put it in a simple store where your email status become "verified" instead of "unverified".
Store is not only storing things but keeping your data workflow states updated.
Just my opinion but I would do that. It will be cleared to do like that to master your data flow in the future.
I'm trying to build a web app using AngularJS and Firebase that sends an email to two users that match on certain parameters. The users submit their information first and if there is a match with another person in the database, I want to send an email to both those people. For example, if two people, A and B both have the age of 25, I would like to send A and B an email with certain information. Is this possible using Firebase?
If you are NOT running a server
Yes
You could achieve it by using a service like Zapier.
You could create a zap linking FireBase and an e-mail service like Mandrill.
A Zap combines triggers and actions — whenever the trigger event occurs, Zapier automatically completes the action for you!
When there is a match, update a special key in your FireBase database.
As Zapier is listening to updates of that particular key, it will react by sending your e-mails via Mandrill.
March 2017 UPDATE
New tools have now been added to Firebase to trigger database event handlers:
database events triggers: https://firebase.google.com/docs/functions/database-events
cloud functions for FireBase: https://firebase.google.com/docs/functions/functions-and-firebase
using cloud functions to send e-mails through sendGrid:
https://cloud.google.com/functions/docs/tutorials/sendgrid
If you are running a server
Your server can easily check the values in FireBase and send e-mails accordingly. That would then be a
Yes, of course :)
In the single page webapp I've recently built I'm getting data for my models using Restangular module. I'd like to add real-time updates to the app so whenever any model has been changed or added on the server I can update my model list.
I've seen this working very well in webapps like Trello where you can see the updates without refreshing the web page. I'm sure Trello webclient uses REST API.
What is a proper way to architect both server and client to archive this?
First of all, your question is too general and can have a lot of solutions that depend
on your needs and conditions.
I'll give you a brief overview for a single case when you want to leave REST APIs
and add some realtime with web sockets.
Get all data from the REST -- Sokets for notifications only.
Pros: Easy to implement both server side and client side. You only need to emit events on the server with
info about modified resource (like resource name and ID), and catch these events on the client side and fetch
data with REST APIs.
Cons: One more request to the server on every notification. That can increase traffic dramaticaly when you have a lot of active clients for a single resource (they will generate a lot of reverse requests to the server).
Get initial load from the REST -- Sockets for notifications with data payload.
Pros: All info comes with the notification and will not cause new requests to the server, so we have less traffic.
Cons: Harder to implement both server side and client side. You will need to add data to all the events on the server. You will need to fetch data from all the events on the client side.
Updated according to the comment
As for handling different types of models (just a way to go).
Client side.
Keep a factory for each model.
Keep in mind that you need realtime updates only for displayed data (in most cases), so you can easily
use memory caching (so you can find any entity by its ID).
Add listener for every type of changes (Created, Updated, Deleted).
In any listener you should call some initObject function, that will find entity in the cache by ID and extend it, if there is no entity with such ID, just create a new one and add it to cache.
Any Delete just removes an entity from the cache.
Any time you need this resource, you should return the link to cache object in order to keep two way databinding (that is why I use extend and not =). Of course, you need to handle the cases like: "User is editing the resource while notification about deleting comes".
Server side.
It is easier to send all the model then just modified fields (in both cases you must send the ID of resource).
For any Create, Update, Delete event push event to all engaged users.
Event name should contain action name (like New, Update, Delete) and the name of resource (like User, Task etc.). So, you will have NewTask, UpdateTask events.
Event payload should contain the model or just modified fields with the ID.
Collection changes can be handled in two ways: with add/update/remove items in collection or changing all the collection as a whole.
All modifications like PUT, POST, DELETE are made with REST of course.
I've made a super simple pseudo gist for the case 1). https://gist.github.com/gpstmp/9868760 but it can be updated for case 2) like so https://gist.github.com/gpstmp/9900454
Hope this helps.