I am working on a pipeline which executes oAuth2 flow in order to access REST API json data. Once I have the bearer token I am executing a request which returns the following structure:
As you can see, since the response is quite large, there's paging enabled and as part of the response I get a link to the next page. In order to get to that resource I need to also present MS-ContinuationToken in the headers. So, this is how I basically do it in the config of the Copy activity that I use to get the data from the REST endpoint:
and the issue here is that I only get the first 2000 rows and the next page(s) don't seem to be visited at all. Pipeline executes successfully and only the first 2000 items are fetched.
NOTE: continuationToken and links.next.headers.value have the exact same values from the initial response.
Even if you fix the other issue you’ll have an issue with the “next” URL not including “v1”. This is a known issue in the partner center api team. I’ve escalated it pretty high. But they don’t want to break backwards compatibility by changing the “next” URI to include the v1 or to be relative. They are considering other options but I wouldn’t hold your breath.
I would ditch the idea of using data factory and instead write a .NET console app using the partner center SDK
(You might think to paginate manually with loops etc but the Copy activity doesn’t return eg the http headers, so you will need a complex set up to somehow store the data in a data store and be able to look up the last page in order to get the continuation token. I couldn’t figure it out)
Related
I am trying to update the "purchasable" flag on a product variation using REST API
/wp-json/wc/v3/products/<prodID>/variations/<varID>
I have tried sending a simple
{"purchasable":false}
as well as getting the current data for the variation, changing the "purchasable" entry to the new state, and submitting the entire data back to WooCommerce. In no case have I been able to change this value using REST API.
I am using jw-auth for authentication and have a proper token (I do receive a proper response back with all the data for the variation, but still with the old value of "purchasable" in it, so I know I'm communicating with the back-end).
Is there some setting elsewhere that needs to be set for me to be able to change this specific property? The variations have been created using REST API as well, and on the shop it works fine (I can pick the variations as expected).
What am I doing wrong? Or have I found a bug in WooCommerce? :-)
That field is listed as ReadOnly in the api docs. I believe Woo uses other criteria to set that value. In my research, it appears that setting the Stock Status to "outofstock" seems to be a common method for keeping an item from being purchased. Also, setting the price to null or empty.
https://woocommerce.github.io/woocommerce-rest-api-docs/#product-properties
I have written a pretty straightforward REST service in Domino 9.0.1. I have a view with about 160K records, each record has about 10 field, and the first field is the key.
From time to time I need to make a change to the service, and when I remake the web service call (from the url in my web browser for instance), the data doesn't necessarily change. It seems it is cached on the there server. I believe it is a server issue as I still get the same results even if I switch to another browser. Sometimes I will change my parm and I get DATA FOR THE PREVIOUS PARM I ENTERED. This is terrible.
How can I reset the web service or flush the cache?
You have few options:
1) Add unique parameter to REST url, e.g.: http://hostname/rest/api/endpoint?systemtime=...
Where you compute systemtime value using System.currentTimeMillis()
2) Use HTTP request cache control headers, see http://en.wikipedia.org/wiki/List_of_HTTP_header_fields#Avoiding_caching
Can someone explain the difference between this two frontends
Zend_Cache_Frontend_Capture and Zend_Cache_Frontend_Page?
the Capture is the default one for page caching ... the weird thing is, it makes the id with get variables, but there is no options to set make_id_with_get_variables like its the case in
Page frontend....
can someone explain this ?
Here is my effort to explain the differences between the two.
To start out, let's look at Zend_Cache_Frontend_Capture. The reference states that this class is designed to work only with Zend_Cache_Backend_Static.
You would use Zend_Cache_Frontend_Capture to cache entire pages that have no relation to the user accessing the site. You use this frontend when you have static data (that could change from time to time) that has no relation to the current user, that is, it is the same for all users (like an RSS feed or dynamically created JavaScript file for example.
Looking further into the Zend_Cache_Backend_Static, you will see that this backend is a bit special. It requires rules in your .htaccess file to assist with serving the cache. Once you have cached something with Frontend_Capture/Backend_Static, PHP and Zend Framework are NOT used in order to serve the cached data. Apache sees that the cache file exists based on your .htaccess and serves the content directly to the user without invoking PHP.
Zend_Cache_Frontend_Page on the otherhand works differently. With it, you can cache content not only based on the request URI, but also based on information in a cookie, session, GET, or POST parameters. By default, caching based on cookie, session, get, and post is disabled, so for this to have any effect on a user logged into your site, you have to tell the cache if there are any pages you want to cache based on that information.
Once I create a cache and tell it I want to cache based on cookie and session, I can now cache a dynamically generated page that is specific to one user. So if person A accesses /accounts/, the page can be cached for that specific user containing the list of their accounts that was pulled from the database. Now when person B accesses /accounts/, they do not see the cache for person A, so the page is now cached separately for them with each respective user's information in their own cache.
In summation:
Use the Capture frontend when you have data you can cache that is the same for ALL users. This will be a higher performance cache since PHP and ZF is not needed once the page is cached. The downside is having to add caching rules to .htaccess
Use the Page frontend if you want to cache pages with dynamic output based not only on request URI, but the cookies, session data, or get/post parameters.
Hope that is clear and helps you understand the differences.
EDIT:
I believe I see what the problem is, not sure if this is classified as a bug or not though.
Zend_Controller_Action_Helper_Cache::preDispatch() generates the cache ID based on the request URI (which includes the query string). Since the jQuery ticker appends a query string to the URL, you are caching one copy of the feed for each request URI. (Look for $reqUri in the aforementioned class method).
I see a couple of options: 1) See if you can get the ticker to not append the query string (at least for that specific URL) or 2) Manually start the Capture cache and pass your own ID, rather than letting the cache helper generated it based on the request URI.
I want to post some data to the server, and in response, I want to create a CSV file, with application/excel as the MIME Type (recently recognized as Internet Media Type), to force the browser to open the generated CSV file in Microsoft Excel. However, I also want to prevent user from re-submitting the same info (re-posting the form) by any accident as the result of refreshing the page.
With simple CRUD operations, I use Post/Redirect/Get pattern, so that any further refreshing will only send HTTP Get Request to the server, without any parameter, thus not changing server's state (Idempotence).
What is the recognized pattern for stopping user from re-submitting (re-posting) the same info to the server, when the response is not a page, but a file?
Any idea?
The Post/Redirect/Get pattern is an answer to a browsing event.
Here, there is no browsing action (the form submission only open a 3rd party app, i.e excel), and so any kind of browsing related pattern will be useless.
I suggest you use both a server side trace of the initial submission (with a unique token maybe), so you can prevent the file generation, and an easy to write client side script like <form onsubmit="this.onsubmit = function(){ return false ; }">
I can offer you one other solution.
Take hash (MD5/SHA256 ..) of your submitted data. The hash will be [fairly] unique.
Put it in list in a session with a time limit, say 5 minutes.
Even your user submit same data. Hash will be same and you can give error message to your user.
If different users can post same data, you can also hold user information in the list. And give error message according to user.
I am working on a gateway project. Several devices gets connected on communication bus of this gateway.
URI '[GET] /devices' gets list of devices.
List of devices is populated by scanning the bus. As scanning is a time consuming operation list is cached in gateway. Normally users access cached information.
But user has an option to get list of devices by forcing a scan. Please suggest me correct REST style representation for scanning. I could think of following options
1) '[GET] /devices/scan'
2) '[GET] /devices' with payload as {"action" : "scan"}
I am not so convinced with option1, as 'scan' is an action, thinking it as a resource is not making sense.
And with option2 I will end up having a payload to parse.
What is the correct way of representing scan scenario?
You can make it a query parameter as in GET /devices?scan=1. You can't have any payload in the content with a GET. You'd have to use a POST.