As per subject, GetMatchingProductForId() returns results, eg. when querying by EAN and trying to get an ASIN back, only if active offers exist for that ASIN.
Essentially, if noone (else) is selling this product while we query, we can't get an ASIN for our EANs.
This behaviour is consistent with MWS's documentation.
The same behaviour applies to ListMatchingProducts() it does /not/ return results for non-buyable products.
As an example, using GetMatchingProductForId() for EAN 8301029074792 on the UK marketplace returns nothing whereas if you perform the same search using Seller Central you see that a listing does exist for that product.
Since Amazon wants developers not to create products if they already exist in their database, I wonder how we're supposed to query by EAN in order to get an ASIN.
There is no easy solution for this kind of problem. Both the affiliate's itemLookup and mws GetMatchingProductForId don't return asins if there's no current seller.
One solution I came up is to create a bot/crawler to programmatically run through all your (no matched) EAN/UPC list to the seller central's add-a-product page, search the EAN/UPC in the search bar and get the data result.
It returns the ASIN for the specific UPC/EAN query even though there's no current seller for the item.
Related
I am currently exploring MongoDB.
I built a notes web app and for now the DB has 2 collections: notes and users.
The user can create, read and update his notes.
I want to create a page called /my-notes that will display all the notes that belong to the connected user.
My question is:
Should the notes model has an ownerId field or the opposite - the user model will have a field of noteIds of type list.
Points I found relevant for the decision making:
noteIds approach:
There is no need to query the notes that hold the desired ownerId (say we have a lot of notes then we will need indexes and search accross the whole notes collection). We just need to find the user by user ID and then get all the notes by their IDs.
In this case there are 2 calls to DB.
The data is ordered by the order of insertion to the notesIds field in the document.
ownerId approach:
We do need to find the notes by their ownerId field across the notes collection which might be more computer "intensive".
We can paginate / sort the data as we want - more control over the data.
Are there any more points you can think of?
As I can conclude this is a question of whether you want less computer intensive DB calls vs more control over the data.
What are the "best practices"?
Thanks,
A similar use case is explained in the documentation. If there is no limit on number of notes a user can have, it might be better to store a userId reference field in notes document.
As you've figured out already, pagination would be easier in the second approach. Also when updating notes, you can simply updateOne({ _id: "note_id", userId: 1 }) instead of checking user's document if the note actually belong to the user.
I use Solr to index and search on a system with about 100,000 products and 300,000 users. The field to index is "price". But for each user, the price may be different.
For example:
- For Product1 and User1, User2.
- User1 sees the Product1's price 100$.
- But User2 cannot not see the price (User2 has to fulfill some conditions to see the price) although User2 still sees Product1 when searching.
At the time of indexing, we cannot determine to set the price for a specific user or not. The product has a flag called "Required Contract". And when a user log in, we will check if the user has applied the "contract" for that product to show or hide the price.
The straight forward solution for this problem is to create different "price" fields for each user. So when indexing, we loop through the list of users and index the "price" field for that user. And when searching, we use the correct "price" field for the login user. Obviously, this is not a practical solution.
My question is how to index "price" field in this case or is there any other approaches on the solution?
It seems that you don't have specific prices for each user, but for groups of users. Presumably a not-very-high number of unique groups. If so, a simple solution is to have multiple price fields (price_group_1, price_group_2, ...), one for each user group, and let your display-code show the one matching the users group.
After researching for a while I came up with 2 solutions:
1/ The first one is to duplicate a document that requires the condition. The duplicated document contains no price (or any value assigned to it). Because the numbers of documents requiring conditions are not too much so duplicating is not a waste of resources. So when doing a searching, by combining some other flags the result is the duplicated documents not the original one that fulfill my requirements.
2/ Another approach is using Function Queries. I figured this out by searching on Google for my problem as I didn't know about that feature at the beginning.
Hope that can help someone's problems!
I have a very interesting problem in relation to CakePHP. I have a client that is currently selling products on eBay, and wants to start selling products on their own website as well. There would, then, be two separate sales avenues: (1) eBay, and (2) website.
However, they do want to have a seamless website experience for their customers. Basically, they want their current eBay sites to be categories within their current website, and their current eBay auction items to be searchable on their website.
A simple CakePHP website would have two tables: products and categories, with the simple table relation of "products belongsTo categories" and "categories hasMany products". How would I then add in the eBay categories and products? Basically, I want the http://site/products/index to return a list of ALL products, both in the products table and on eBay. I want http://site/categories/index to return a list of all defined categories in the categories table plus the categories items are listed in on eBay.
eBay has a very good pretty much real-time request query API, so I've been thinking about an option to do this, but am wondering if there is a better way... I don't think this option would work very well with PaginatorComponent...
Method:
(1) In beforeFind, capture the request parameters and save to a persistent variable
(2) In afterFind, make a request to the eBay API based on the request parameters, then manually add the results to the $results array.
Again, I think this would work for basic find operations, but I'm not sure this would work with pagination because I'm not sure how to deal with, say, a 20 item page limit (i.e. How do I deal with a page 2 when only 18 items from the database were on page 1, and now on page 2 I need to start at 19 instead of 21 from the database?)
Is there a CakePHP syntax that I'm overlooking here, or do I just start working on coding for all of these eventualities?
I'm coding on a CakePHP 2.6.0 platform.
Thanks so much for your help!
One possible approach would be to read all the products from each datasource, sort them in memory and paginate from there. The number of products would of course play a major role here.
A second one, if the number of products does not change too often, would involve a background process to retrieve their ID, and the most essential data, from eBay and write them in the common Product table, flagging the rows created.
Then Paginator can then show your results, but other fast-changing data can be retrieved on-the-fly from eBay for the flagged products while composing the page.
I would like to update my products with the Amazon MWS API. The problem: I only have the products ASIN's to identify them. Not the SellerSKU.
As far as I have seen until now, the Feed to update the products Data does only accept the SKU as an unique identifier for my product. Is there a way to get around this? Have I just missed the possibility to update with ASIN?
You can use the GetReport operation with the _GET_MERCHANT_LISTINGS_DATA ReportType to retrieve a document that will associate the ASINs with SKUs.
The SKU can be set by the Seller. In this case, the SKU was simply the Article No. Now I have the SKU and can simply use it.
I have a strange requirement in Solr.
The business model is like for each store in state (say victoria), we have different sales catalog (like Richmond, Brunswick etc) which in turn act as fulfillment centers on their own.
so my url of storeId- vic and catalogId-Richmond will retrieve me catalogues with richmond's store.
Now the requirement is I need to filter out the products based on the inventory for each of these sales catalogues.
I constructed a TI table which has the following structure
catentry_id -------- QUANTITY_RICFUL-------------QUANTITY_BrunFUL
1234-------------------0------------------------------------20
I had incorporate the changes in solr query to add these columns in the final result too.
But I do not know how to filter out the products in the front end during catalogue navigation or during search.
Any help would be much appreciated!!!
So basically you want to tie the returned catalog entries in a list with inventory? For instance, when they click on a category you do not want to display products with no inventory?
This would be a customization you can either do at the Solr Level or at the JSP level. You should probably track inventory in commerce (import it) into a field Solr can key off of and then only return items with the flag set to greater than zero. I am not sure if you need actual inventory or just a boolean. Are you using a single fulfillment center or multiple ones? Multiple gets a bit trickier and it would require them to log in most likely but then fulfillment would be addressed by the ship to address.
If the store is set up with ATP inventory then you should just get this for free, as products not in stock will simply not be displayed. Check out this page in the infocenter - http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=%2Fcom.ibm.commerce.user.doc%2Fconcepts%2Fcosatpatpandnonatp.htm
I am not sure what you are trying to ask here but it seems you are trying to display a Quantity dropdown or display an Quantity field under each product on a search page which to me makes no sense from a UI perspective. Also keep in mind if you have integrated with a 3rd party inventory model that runs every few mins/hours etc. How often do you plan to run indexing etc?
I would rather leave such complexity to a Prodcut Detail page. If you do require to show an Quantity field on the search page I would rather prefer displaying a QuickView popup/modal that displays the color/size attributes with the quantity dropdown etc and enable a user to add an item to his/her shopping cart.