Closed ju2wheels closed 9 years ago
Closing this, I cant reproduce it anymore, I think it may be a weird artifact of my having been using softlayer_api v3 in an irb instance and moved to 1.0.8 for testing while still leaving the same irb instance open with v3 stuff loaded and forgot.
If you inspect the capacityRestrictionType, capacityRestrictionMinimum and capacityRestrictionMaximum properties of a price (http://sldn.softlayer.com/reference/datatypes/SoftLayer_Product_Item_Price), you'll be able to see which price ID is valid for the # of cores you are ordering with.
Example: Price ID 40458 has a capacityRestrictionType of CORE (which refers to the number of cores the VSI being ordered with), and both the capacityRestrictionMinimum and capacityRestrictionMaximum properties of the price have a value of 4. That means this price must be used if you want to order SQL Server 2014 STD version with a 4 core VSI.
Price ID 40458 has capacityRestrictionMinimum & Maximum of 1, so that price may be sent in a 1 core VSI order.
If you send-in the wrong price, say the MS SQL 4 core price as part of a 1 core VSI order, the order will fail verification. This is due to some products licensing scheme which is per-socket or per-core.
Reopened, and updated my original post, messed up the provided example compared to what I was actually running thats why I couldnt reproduce.
@sergiocarlosmorales makes sense, thank you. Is there a list of capacityRestrictionType potential values anywhere?
Will leave this open, would be nice to have had some sort of filter method as part of ProductPackage or include these fields in the results, seem pretty important to making an accurate selection.
Considering adding sl_dynamic_attr of itemPriceReferences to ProductPackage and either merging with categories or pass it on to the item category initialization. If that change is ok with you guys I can take care of adding it.
@sergiocarlosmorales pls ignore previous question, will assume capacityRestrictionType must be of type product category item units unless told otherwise.
You should probably include it in the object mask of the call to getConfiguration then extract it from the price items in the ProductItemCategory class. If you want to make a full-blown product item price class (instead of the "ProductConfigurationOption" object) that would be fine too. ProductConfigurationOption was created to match some behavior on the Python side and as a... er... conservation of effort measure.
Works for me, I dont think going down a product item class route just to get the capacity restrictions is really necessary yet (it would be ignoring most of the item price data and retrieving only whats necessary to make an accurate category item selection).
Currently getting this (it works fine using a tweaked mask with getItemPriceReferences as a separate call though):
data = sl_client[:Product_Package].object_with_id(46).object_mask("mask[package.itemPriceReferences.itemPrice.capacityRestrictionMaximum,package.itemPriceReferences.itemPrice.capacityRestrictionMinimum,package.itemPriceReferences.itemPrice.capacityRestrictionType,package.itemPriceReferences.itemPrice.requiredCoreCount]").getConfiguration()
RuntimeError: HTTP-Error: 500 Internal Server Error
from /usr/lib/ruby/1.9.1/xmlrpc/client.rb:549:in `do_rpc'
from /usr/lib/ruby/1.9.1/xmlrpc/client.rb:420:in `call2'
from /usr/lib/ruby/1.9.1/xmlrpc/client.rb:410:in `call'
from /var/lib/gems/1.9.1/gems/softlayer_api-3.0.0/lib/softlayer/Service.rb:281:in `call_softlayer_api_with_params'
from /var/lib/gems/1.9.1/gems/softlayer_api-3.0.0/lib/softlayer/APIParameterFilter.rb:194:in `method_missing'
from (irb):16
from /usr/bin/irb:12:in `<main>'
Adding it to getCategories instead...
When looking at item selections, the descriptions should be as unique as possible so as to clearly differentiate them. Most of the items look fine except for the ones returned by database as shown below.
Running:
Gives this:
Whats the difference beyond potentially pricing? Is it arch/seat count/etc... Choosing the right id is useless here unless we know what we are ordering ;-) .