I am trying to make an ABAP OData, that receive a request, does some calculation, then, should return a message to the End User and make an decision based on the user input. So basically, the OData service should be put "on hold", before its receives a response.
Does anyone have a good idea?
Appreciate your response.
Regards!
OData is a special kind of REST. REST is stateless. What you want is stateful.
The good way to do turn this stateful flow into a stateless one is:
Send a first request (REST: POST, OData: CREATE) that creates and saves(!) a document that represents the calculation and its result. That first request may return the calculation's result to be presented to the user.
The user's choice then sends a second request that addresses the previously created document (e.g. via a GUID) and includes the user's choice. This means the second request neither has to send the computation input again, nor does it actually perform any calculations; it only changes the existing object's state.
If the calculation is not needed anymore afterwards, that second request may delete it. To prevent data leakage, removing older calculations after a time limit (e.g. 24h) may be a wise move.
Related
I am ideally looking for an API that returns all the messages posted(including replies) since a given timestamp.
conversations.history is supposed to be the one I should be using, but it does not return replies, it only returns parent message (only if the timestamp of the parent message satisfies the "oldest" param I supply - i.e. if the oldest supplied in the query is later than parent's ts but earlier than replies, neither parent nor replies will be returned).
Hence, I am trying to find if there is any other API that returns the threads based on "oldest" timestamp. i.e. all the threads which have replies since a given timestamp.
Note: I looked at conversations.replies, it is only useful if you know which thread's replies you are fetching.
Currently there is no API to do what you aspire to do.
The best work around is manually fetching all threads data in-memory and then applying filter.
Did you find an alternative solution to this question? I have the same use case and when contacting Slack support I received the same response that we need to use the combination of conversations.history & conversations.replies. This will be quite an intensive and continuously growing number of calls if we need to call conversations.replies for all threaded messages just to filter out the timestamps that fit the date range. This would be catastrophic in the long run.
Ideally slack need to update conversations.replies API to support getting all replies between oldest & latest parameter just like in history.
Another alternative I am considering is to change the implementation and use the Events API instead of the Web Client API and use queueing to store all incoming messages then this will make sure that all messages are captured and stored then apply the required filters.
Until now we used a SharePoint on-premise custom web service which delivered all users (approx 15,000) inclusive properties like aboutMe, skills, etc. and the direct manager. That job took approx. 15 minutes.
All the data was stored in a Lucene search index.
Now we have to switch to O365.
I am able to get all the desired information from Microsoft Graph but it would take way too long (3 - 5 hours):
Fetch all users via /v1.0/users (with paging)
Iterate through the collection and
get manager for given user via /v1.0/[user-id]/manager
get properties like aboutMe, skills for given User via /v1.0/[user-Id]?$select=aboutMe,skills
Is there any efficient way to do that task?
Ideally, you should just call Microsoft Graph for the data you want on-demand rather than attempting to sync it to your own database.
Assuming you can't do that, you can deduce the time this takes using /delta endpoint (Get incremental changes for users). When you use a delta token, you will only get back resources that have changed (adds, deletes, edits) since your previous request. So your first pass might take a few hours, but subsequent passes should take seconds.
You can control which properties you're "tracking changes" against using the $select query parameter. For example, if you only care about changes to the displayName then using /v1.0/users/delta?$select=displayName will ensure you only receive changes to that property. From the documentation:
If a $select query parameter is used, the parameter indicates that the client prefers to only track changes on the properties or relationships specified in the $select statement. If a change occurs to a property that is not selected, the resource for which that property changed does not appear in the delta response after a subsequent request.
Also, consider batching requests to improve your processes' overall performance. Batching allows you to send multiple queries to Microsoft Graph in a single request and get the complete results back in a single response.
I am working on a new mobile app which will be talking to a rails server. Originally the idea was to remain restful and follow all conventions, however this goes against the client side best practices and performance of minimizing HTTP requests. I was wondering when you should remain restful and make only one api call per resource type, and when should you make one call which will update, add, remove and return a list of a few different resources.
For example, the app I am working on will be a scorekeeping app. Upon login, I return both the user information, a list of games that the scorekeeper can then edit, as well as all of the stats associated with each game. Since this list is returned in the first call, the view is immediately changed to the game list which is already pre-populated. This is quite fast.
Now from my understanding, to remain restful I would have to first make the login call(POST) for the user information, then make another(GET) call for the games list.
Another example would be uploading stats. Each stat has an action associated with it, whether its delete, update, or create. Currently all the stats are stored in a JSON which will send one POST call to the server. The server will then loop through the list and delete, update, or create the stats as needed. Now restfully I should be making a separate POST, DELETE, or PUT calls for each stat correct?
I have a good understanding of what restful is, but I'm failing to understand when/why to use it, and when to just combine everything into one api call to increase performance for the end user.
Do you have
(a) an actual, measured performance problem,
(b) a good and well-thought out argument for why you will have one, or
(c) a vague concern that REST is chatty?
It sounds like (c). Yes, REST can be chatty. Usually that's addressed with caching and good endpoint design.
Now from my understanding, to remain restful I would have to first
make the login call(POST) for the user information, then make
another(GET) call for the games list.
That would be traditional. It would not be unreasonable for the initial POST to do a redirect to get the games list. You can perform the GET conditionally (If-Modified-Since, If-None-Match), which will save bandwidth and server time. You can also set an explicit expiration time for the result of the GET to save some calls to the server.
Another example would be uploading stats. Each stat has an action
associated with it, whether its delete, update, or create. Currently
all the stats are stored in a JSON which will send one POST call to
the server. The server will then loop through the list and delete,
update, or create the stats as needed. Now restfully I should be
making a separate POST, DELETE, or PUT calls for each stat correct?
In this case, it sounds like the verb you want is PATCH. You can invoke PATCH on a collection endpoint, such as /stats, and include all the updates in one call. I suggest using the structure defined in RFC 6902 for PATCH requests.
I am working w/ the Event Brite API and I have a need that I am trying to figure out the best approach for. Right now, I have an event that people will be registering for. At the final step of the registration process, I need to ask them some questions that are specific to my event. Sadly, these questions are data-driven from my website, so I am unable to use the packaged surveys w/ Event Bright.
In a perfect world, I would use the basic flow detailed in the Website Workflow of the EB documentation, ending upon the "3rd Party Next Steps" step (redirect method).
http://developer.eventbrite.com/doc/workflows/
Upon landing on that page, I would like to be able to access the order data that we just created in order to update my database and to send emails to each person who purchased a seat. This email would contain the information needed to kick off the survey portion of my registration process.
Is this possible in the current API? Does the redirect post any data back to the 3rd party site? I saw a few SO posts that gave a few keywords that could be included in the redirect URL (is there a comprehensive list?). If so, is there a way to use that data to look up order information for that order only?
Right now, my only other alternative is to set up a polling service that would pull EB API data, check for new values, and then kick off the process on intervals. This would be pretty noisy for all parties involved, create delay for my attendees, and I would like to avoid it if possible. Thoughts?
Thanks!
Here are the full set of parameters which we support after an attendee places an order:
http://yoursite.com/?eid=$event_id&attid=$attendee_id&oid=$order_id
It's possible that order_id and attendee_id would not be a numeric value, in which case it would return a value of "unknown." You'll always have the event_id though.
If you want to get order-specific data after redirecting an attendee to your site, you can using the event_list_attendees method, along with the modified_after parameter. You'll still have to look through the result set for the new order_id, but the result set will be much smaller and easier to navigate. You can get more information here: http://developer.eventbrite.com/doc/events/event_list_attendees/
You can pass the order_id in your redirect URL in order to solve this.
When you define a redirect URL, Evenbrite will automatically swap in the order_id value in place of the string "$order_id".
http://your3rdpartywebsite.com/welcome_back/?order_id=$order_id
or:
http://your3rdpartywebsite.com/welcome_back/$order_id/
When the user completes their transaction, they will be redirected to your external site, as shown here: /http://developer.eventbrite.com/doc/workflows/
When your post-transaction landing page is loaded, grab the order_id from the request URL, and call the event_list_attendees API method to find the order information in the response.
I have a Symfony app that populates the "widgets" of a portal application and I'm noticing something (that seems) odd. The portal app has iframes that make calls to the Symfony app. On each of those calls, a random user key is passed on the query string. The Symfony app stores that key its session using myUser->setAttribute(). If the incoming value is different from what it has in session, it overwrites the session value.
In pseudo-code (and applying a synchronous nature for clarity even though it may not exist):
# Widget request arrives with ?foo=bar
if the user attribute 'foo' does not equal 'bar'
overwrite the user attribute 'foo' with 'bar'
end
What I'm noticing is that, on a portal page with multiple widgets (read: multiple requests coming in more or less simultaneously) where the value needs to be overwritten, each request is trying to overwrite. Is this a timing problem? When I look at the log prints, I'd expect the first request that arrives to overwrite and subsequent requests to see that the user attribute they received matches what was just put into cache by the initial request.
In this scenario, it could be that subsequent requests begin (and are checked) even before the first one--the one that should overwrite the cached value--has completely finished. Are session values not really available to subsequent requests until one request has completed entirely or could there be something else that I'm missing?
Thanks.
Attributes of the user do not get written to storage until the end of the request (in sfUser::shutdown). Attributes get loaded into sfUser at the beginning of a request. So in this case, the second request would have to be initiated after the first request is finished. Your best options are probably
Add hardRead and hardWrite methods to sfUser (look at what sfUser::initialize and sfUser::shutdown do respectively).
Use another method of storing the information that has better support for concurrency. The database or potentially the caching system you're using could work. For example, I think this could be done using APC cache.
Note that depending on what class you're using for storage, user attributes may not get written to $_SESSION at all. Symfony supports using many methods for storing user attributes (e.g. database, cache).