I'm trying to get the most recently updated cases from ServiceNow, using the REST API.
I know I can run this call: /api/sn_customerservice/{api_version}/case?sys_updated_on>={given date}
The problem is that some background process updates the sys_updated_on field for many cases that don't actually have any activity on them. So a case that has a last activity from 2019 may have its sys_updated_on updated today.
I have no access to change the behavior of whatever is updating the sys_updated_on field.
I know I can pull a list of records and then make a second API call to /api/sn_customerservice/{api_version}/case/{id}/activities to check the date of the most recent activity for a given case. But that's two API calls for every case (of which there are thousands).
Is there any way to get a list of just the cases that have had recent activity?
Limitations: this is a personal project and I only have access to the API with my user credentials. I don't have a development account.
The design of Case API is to get case records
The design of activity endpoint within Case API is mainly to get activity stream details of given input case.
The usecase you have is - To get list of cases that have had recent activity. It definitely makes sense to first get the recent activities for all cases in a limited timeline like a day or a week and then only query details of those related cases to the activity stream records.
However to do this you will need to implement a scripted REST API to query sys_journal_field table and get case sys_ids which have recent activity in activity stream.
Related
I am trying to do what I thought would be a very simple task which is to use the Facebook API to retrieve insights about ads, but I'm having so much trouble. I know how to use multiple API calls to retrieve the list of ads, and then retrieve the insights for each ads using an API call for each one.
However, I'm limited at 200 API calls per hour, so this is no good if I wanted to pull all ads from all-time. There is a way to batch call the ad insights using an endpoint like:
act_XXXXXXXXXXXXXXX/ads?fields=insights{cpc, impressions}
But then I am unable to specify the timeframe so it only grabs stats from the past month. Usually I would specify the timeframe with a field of
date_preset=maximum
(or whatever I want the date_preset to be), but in this case if I add it as another field it does not affect the the insights (I presume since they are using those brackets as a special way to pull the bulk insights).
I swear to god if I figure this out I'm releasing it publicly and loudly for free because I think it's ridiculous that this is so roundabout.
Do this: act_XXXXXXXXXXXXXXX/ads?fields=insights.date_preset(maximum){cpc, impressions} This is called a nested query.
With Microsoft Graph, I can set a subscription on a resource. In my case an event. I am going to be using an admin authenticated account to access multiple calendars.
Is there a way to set a subscription to get notifications on all the calendars the admin can see?
If not, is there a way to send in a block of subscriptions with a single request? Because we are limited to how many requests we can specify in a specific timeframe. (I'm not sure what the limit is) but if I have 500 calendars I need to set subscriptions on so I get notifications of changes, how are you supposed to do this and not get hit by the request per timeframe limit?
Currently, there isn't a way to send multiple subscription creation requests in the same HTTP REST call. Every different resource for which a subscription is being created would have its own HTTP call into the Graph REST API.
You can recommend a "batching" feature (so multiple REST requests can be processed in the same HTTP call to the Graph API) on UserVoice: https://officespdev.uservoice.com/
There is also a consideration that, in my experience, the number of simultaneous subscriptions allowed is around 20, so 500 subscriptions might be out of the question. The best advice I've been given on the subject is to loop through all the objects one at a time to refresh them in sequence. The throttling that follows is a different issue altogether.
When a 429/"Unknown Error" comes back (ie throttling), it comes with a retry-after header which should be observed. I might point out that throttling, for me, is still a huge issue.
I have been pondering about this for a while now and been unsuccessful in finding any information on the topic of subsequent api (ajax) requests.
Let's say we have list of users and one of them is updated. After updating the user, I would like to retrieve the entire, updated list of users.
My question regards two actions:
Update user
Retrieve all users
It is clear to me, that the React component initiates the view action to update the user resulting in an API request via the dispatcher. What isn't clear to me is where the second request to retrieve the users happens.
Looking at Facebook's Chat example...
Does it happen in the web API utils?
Does the store do this after it has been notified of the update?
Does the component do this after it has been notified of the change?
Currently I would do this in the API but I would like to know if there are any tested pattern for solving this problem.
You don't need two actions doing two XHR calls. You actually want just one action that results in two XHR calls. Beware of the tendency to think that you should cause a cascade of actions -- this is exactly the anti-pattern that Flux was created to avoid.
The side effect of updating the entire list of users should be something the UserStore is doing in response to the USER_UPDATED action.
The UserStore will update the user record. This can happen either optimistically or after the server call completes. The XHR call to update the user server-side can happen either within the updateUser() action creator or within the store. However, you will need to create actions for the success/error of that call, so that the store can respond appropriately.
The next step, again, can happen either optimistically or after you get the data back from the server. The store, in this case, would make a XHR call to retrieve the list of users to update all the relevant records it holds.
But like the last XHR, you will want to create two new actions based on success or error of this second XHR.
Creating new actions keeps your application very flexible and resilient. So that if any other store ever needs to know about the result of these XHRs, it will already be receiving that data.
I'd be remiss if I didn't mention that, if you have control over the server-side code, you should simply build an end point to update the user and return the new list of users -- this would make the client side code much simpler and the entire thing would be more efficient.
I'm just getting started with the DocuSign REST API (creating a proof-of-concept integration with my company's product) and am trying to wrap my head around everything. There are a couple things I can't find much info on:
When creating an Envelope, does the documentId matter? I assume if there are multiple documents the documentId for each would need to be different. Is it used anywhere else?
Periodically, I'd like to check the Audit Events for an Envelope. It would be much easier if I could look up the Envelope (or go straight to the Audit Events without looking up the Envelope) with a documentId instead. Is this possible?
Our product already stores documents, and therefore has a documentId - so that is the ID I am using when creating Envelopes. What I'd like to do is, with whatever document I am viewing in our product is check to see if there are any non-completed Envelopes pending. Then I wouldn't need to store any DocuSign related data in our system (i.e. envelopeId).
Can I look up an Envelope by the documentId used to create it?
The documentId is a client defined property and is simply there to help you tag the documents that were used for given envelopes. If you want to track the documents that you're supplying in your envelopes (which it sounds like you are) then you can use it to uniquely identify the underlying docs and if you already have a system that has generated the documentIds then that should make things easier.
No there is not a way to retrieve envelope information through documentId. The best solution is most likely to store a simple table on your side that links documentIds to envelopeIds, then given the documentId you want to search for use the linked envelopeId to retrieve its status.
You should note, though, that there are certain API call limits in place for some API calls and requesting envelope status is one of them. You are not allowed to request status on a given envelope more than 1 once every 15 mins. Instead, the DocuSign Connect module is recommended if you want to track real-time status (DocuSign Connect pushes status out to you as soon as it happens instead of you polling for status every so often).
For more info on API call limits check out the API Best Practices doc in the DocuSign Developer Center under the Go Live section:
https://www.docusign.com/developer-center/go-live/certification
I know how to get the list of organizations for a user.
However, I want to let the user type in the user/organization name and provide autocomplete for that name where the autocomplete includes all user/organizations, not just the organizations they belong to.
It would be too long to get the entire list (and I am not sure that GitHub even exposes that), but the top 5-20 for any given prefix is all I want.
The Search API smells more like a single transaction search and not an autocomplete API, so while I could use it, most likely it would hit the rate limit too often and give a bad UX.
There is something close to this with https://github.com/autocomplete/users?q=prefix, but that is not part of the official GitHub API, so I know that the back end does support these kind of queries... I am just not finding it from the API documentation, and I don't want to access a non-API URL.
GitHub does not do this for you and likely never will. One option you have is to construct a service like that yourself and constantly update your list of users. One way to update the list of users (sanely) is to do the following:
Make an initial GET to /users?per_page=100
Save the ETag header that's returned and use pagination to get all of the most recent ones
On future requests send along the ETag and when there are new users, save the newest ETag.
Repeat.
So you'll be able to then build an auto-completion service yourself so long as you keep your listing of GitHub users up-to-date.
Also note, that sending along the ETag will save your ratelimit if there is nothing new to return.