I've been working on the update of the DHL shipping rates to support
the new "Out of Origin" feature in the ShipIt API. Trying to get the shipping rates to work, I've been debugging the code and don't see how it can work. In the order.shoppingcart.shipping.ShippingEvents class in the function getShipGroupEstimate, it creates a Map (around line 160) and then calls getExternalShipEstimate passing in the map. The first thing the code does is to look a property "serviceName" which is never populated therefore it drops out of the method without attempting to call the carriers' API. snippet from getShipGroupEstimate()..... // prepare the service invocation fields Map serviceFields = new HashMap(); serviceFields.put("initialEstimateAmt", new Double(shippingTotal)); serviceFields.put("shippableTotal", new Double(shippableTotal)); serviceFields.put("shippableQuantity", new Double(shippableQuantity)); serviceFields.put("shippableWeight", new Double(shippableWeight)); serviceFields.put("shippableItemInfo", itemInfo); serviceFields.put("productStoreId", productStoreId); serviceFields.put("carrierRoleTypeId", "CARRIER"); serviceFields.put("carrierPartyId", carrierPartyId); serviceFields.put("shipmentMethodTypeId", shipmentMethodTypeId); serviceFields.put("shippingContactMechId", shippingContactMechId); // call the external shipping service try { Double externalAmt = getExternalShipEstimate(dispatcher, storeShipMethod, serviceFields); ---------------------------- snippet from getExternalShipEstimate().... public static Double getExternalShipEstimate(LocalDispatcher dispatcher, GenericValue storeShipMeth, Map context) throws GeneralException { // invoke the external shipping estimate service Double externalShipAmt = null; if (storeShipMeth.get("serviceName") != null) { Based on the code I'm debugging, carrier rates couldn't possibly be working. Am I missing something or are carrier rates not working in ofBiz? Thanks, John |
I found the problem(s).
1. I was looking at the wrong argument for the serviceName attribute. That's why I missed the attribute. 2. The product_store_shipment_meth table was missing the service name for DHL so the service wasn't being invoked. I had to run the following SQL statement on the DB to solve that problem. UPDATE product_store_shipment_meth SET service_name='dhlRateEstimate' WHERE party_id='DHL'; The bug is that the demo data for DHL does NOT set the serviceName property. The ecommerce\data\DemoShipping.xml needs to be updated. I will report this as a bug if it hasn't been already. |
This information should go in the basic production setup guide (on docs.ofbiz.org), but not be the default in SVN as it will cause a bunch of error messages because it wouldn't be configured properly. -David On Sep 25, 2006, at 7:40 PM, John Martin wrote: > I found the problem(s). > > 1. I was looking at the wrong argument for the serviceName attribute. > That's why I missed the attribute. > > 2. The product_store_shipment_meth table was missing the service name > for DHL so the service wasn't being invoked. I had to run the > following SQL statement on the DB to solve that problem. > > UPDATE product_store_shipment_meth SET service_name='dhlRateEstimate' > WHERE party_id='DHL'; > > The bug is that the demo data for DHL does NOT set the serviceName > property. The ecommerce\data\DemoShipping.xml needs to be updated. I > will report this as a bug if it hasn't been already. |
Hi Dave,
I'm not quite sure what you mean. If you mean that setting the serviceName to call the API's wouldn't work properly. That is correct do to the missing access keys but the way that the service (at least DHL) is written, it will log an error and I believe even display that shipping properties need to be configured. For someone starting out, this is already explained in the guide and easy to configure. If we don't set the serviceName correctly, most new users will have no means to set the entity attribute. It is not a visible field in the EditProductStoreShipSetup form. My recommendation is to set the attribute for all of the carriers. USPS is prepopulated correctly. I don't see/understand why we wouldn't do the same for DHL and UPS. I've included the patch in the jira issue: https://issues.apache.org/jira/browse/OFBIZ-328 Thanks, John |
I could be wrong and I'm sure someone will point this
out if I am, but I believe the USPS services do not require (or even take) account information like FedEx, UPS and DHL would. ie there is no setup for USPS. This would be why it is setup in the demo data and the others are not. --- John Martin <[hidden email]> wrote: > Hi Dave, > > I'm not quite sure what you mean. If you mean that > setting the > serviceName to call the API's wouldn't work > properly. That is correct > do to the missing access keys but the way that the > service (at least > DHL) is written, it will log an error and I believe > even display that > shipping properties need to be configured. For > someone starting out, > this is already explained in the guide and easy to > configure. > > If we don't set the serviceName correctly, most new > users will have no > means to set the entity attribute. It is not a > visible field in the > EditProductStoreShipSetup form. > > My recommendation is to set the attribute for all of > the carriers. > USPS is prepopulated correctly. I don't > see/understand why we > wouldn't do the same for DHL and UPS. > > I've included the patch in the jira issue: > https://issues.apache.org/jira/browse/OFBIZ-328 > > Thanks, John > |
Hi
Actually, you do need a USPS account for some features used in the OFBiz api... Again, the production setup guide has additional details. On Mon, 2006-09-25 at 13:02 -0700, Chris Howe wrote: > I could be wrong and I'm sure someone will point this > out if I am, but I believe the USPS services do not > require (or even take) account information like FedEx, > UPS and DHL would. ie there is no setup for USPS. > This would be why it is setup in the demo data and the > others are not. > > --- John Martin <[hidden email]> wrote: > > > Hi Dave, > > > > I'm not quite sure what you mean. If you mean that > > setting the > > serviceName to call the API's wouldn't work > > properly. That is correct > > do to the missing access keys but the way that the > > service (at least > > DHL) is written, it will log an error and I believe > > even display that > > shipping properties need to be configured. For > > someone starting out, > > this is already explained in the guide and easy to > > configure. > > > > If we don't set the serviceName correctly, most new > > users will have no > > means to set the entity attribute. It is not a > > visible field in the > > EditProductStoreShipSetup form. > > > > My recommendation is to set the attribute for all of > > the carriers. > > USPS is prepopulated correctly. I don't > > see/understand why we > > wouldn't do the same for DHL and UPS. > > > > I've included the patch in the jira issue: > > https://issues.apache.org/jira/browse/OFBIZ-328 > > > > Thanks, John > > > Daniel *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*- Have a GREAT Day! Daniel Kunkel [hidden email] BioWaves, LLC http://www.BioWaves.com 14150 NE 20th St. Suite F1 Bellevue, WA 98007 800-734-3588 425-895-0050 http://www.Apartment-Pets.com http://www.SatelliteRadioZone.com http://www.Cards-Visa.com http://www.ColorGlasses.com *-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*-.,,.-*"*- |
In reply to this post by John Martin
John, I believe what David was saying was that the reason that the
service name is not in there by default is that, then, in the default instance, the DHL service would be invoked without proper information. I ran into the same problem with UPS - and asked the same question, but it was decided that the demo data would contain information that would show how these processes work, but would not work for each of the different carrier options out of the box. It should be spelled out clearly in the production setup guide - and if it's not - then we should correct it there. Any additional thoughts? Cheers, Tim -- Tim Ruppert HotWax Media http://www.hotwaxmedia.com o:801.649.6594 f:801.649.6595 John Martin wrote: > Hi Dave, > > I'm not quite sure what you mean. If you mean that setting the > serviceName to call the API's wouldn't work properly. That is correct > do to the missing access keys but the way that the service (at least > DHL) is written, it will log an error and I believe even display that > shipping properties need to be configured. For someone starting out, > this is already explained in the guide and easy to configure. > > If we don't set the serviceName correctly, most new users will have no > means to set the entity attribute. It is not a visible field in the > EditProductStoreShipSetup form. > > My recommendation is to set the attribute for all of the carriers. > USPS is prepopulated correctly. I don't see/understand why we > wouldn't do the same for DHL and UPS. > > I've included the patch in the jira issue: > https://issues.apache.org/jira/browse/OFBIZ-328 > > Thanks, John |
Yes, the USPS ones do have the service names and I don't really like it because each time you use them you get an error message. In a way it advertises the possibility of the feature, as John pointed out, but that really shouldn't be done through error messages, that should be done through documentation. My vote would be to remove all of the service names, and just make sure they are all adequately documented in the Basic Production Setup Guide on docs.ofbiz.org. -David On Sep 26, 2006, at 12:44 AM, Tim Ruppert wrote: > John, I believe what David was saying was that the reason that the > service name is not in there by default is that, then, in the > default instance, the DHL service would be invoked without proper > information. > I ran into the same problem with UPS - and asked the same question, > but it was decided that the demo data would contain information > that would show how these processes work, but would not work for > each of the different carrier options out of the box. It should be > spelled out clearly in the production setup guide - and if it's not > - then we should correct it there. > > Any additional thoughts? > > Cheers, > Tim > > -- > Tim Ruppert > HotWax Media > http://www.hotwaxmedia.com > > o:801.649.6594 > f:801.649.6595 > > John Martin wrote: >> Hi Dave, >> >> I'm not quite sure what you mean. If you mean that setting the >> serviceName to call the API's wouldn't work properly. That is >> correct >> do to the missing access keys but the way that the service (at least >> DHL) is written, it will log an error and I believe even display that >> shipping properties need to be configured. For someone starting out, >> this is already explained in the guide and easy to configure. >> >> If we don't set the serviceName correctly, most new users will >> have no >> means to set the entity attribute. It is not a visible field in the >> EditProductStoreShipSetup form. >> >> My recommendation is to set the attribute for all of the carriers. >> USPS is prepopulated correctly. I don't see/understand why we >> wouldn't do the same for DHL and UPS. >> >> I've included the patch in the jira issue: >> https://issues.apache.org/jira/browse/OFBIZ-328 >> >> Thanks, John |
+1(but only because I've already learned my lesson ;) )
David E Jones wrote: > > Yes, the USPS ones do have the service names and I don't really like > it because each time you use them you get an error message. In a way > it advertises the possibility of the feature, as John pointed out, but > that really shouldn't be done through error messages, that should be > done through documentation. > > My vote would be to remove all of the service names, and just make > sure they are all adequately documented in the Basic Production Setup > Guide on docs.ofbiz.org. > > -David > > > On Sep 26, 2006, at 12:44 AM, Tim Ruppert wrote: > >> John, I believe what David was saying was that the reason that the >> service name is not in there by default is that, then, in the default >> instance, the DHL service would be invoked without proper information. >> I ran into the same problem with UPS - and asked the same question, >> but it was decided that the demo data would contain information that >> would show how these processes work, but would not work for each of >> the different carrier options out of the box. It should be spelled >> out clearly in the production setup guide - and if it's not - then we >> should correct it there. >> >> Any additional thoughts? >> >> Cheers, >> Tim >> >> John Martin wrote: >>> Hi Dave, >>> >>> I'm not quite sure what you mean. If you mean that setting the >>> serviceName to call the API's wouldn't work properly. That is correct >>> do to the missing access keys but the way that the service (at least >>> DHL) is written, it will log an error and I believe even display that >>> shipping properties need to be configured. For someone starting out, >>> this is already explained in the guide and easy to configure. >>> >>> If we don't set the serviceName correctly, most new users will have no >>> means to set the entity attribute. It is not a visible field in the >>> EditProductStoreShipSetup form. >>> >>> My recommendation is to set the attribute for all of the carriers. >>> USPS is prepopulated correctly. I don't see/understand why we >>> wouldn't do the same for DHL and UPS. >>> >>> I've included the patch in the jira issue: >>> https://issues.apache.org/jira/browse/OFBIZ-328 >>> >>> Thanks, John |
In reply to this post by David E Jones-2
Couldn't we simply enter an enabled flag in the entity that associates
these services to the product store? Obviously it should still be properly documented, but it would make life a lot easier for someone looking at it for the first time. - Andrew On Tue, 2006-09-26 at 07:56 +0100, David E Jones wrote: > Yes, the USPS ones do have the service names and I don't really like > it because each time you use them you get an error message. In a way > it advertises the possibility of the feature, as John pointed out, > but that really shouldn't be done through error messages, that should > be done through documentation. > > My vote would be to remove all of the service names, and just make > sure they are all adequately documented in the Basic Production Setup > Guide on docs.ofbiz.org. > > -David > > > On Sep 26, 2006, at 12:44 AM, Tim Ruppert wrote: > > > John, I believe what David was saying was that the reason that the > > service name is not in there by default is that, then, in the > > default instance, the DHL service would be invoked without proper > > information. > > I ran into the same problem with UPS - and asked the same question, > > but it was decided that the demo data would contain information > > that would show how these processes work, but would not work for > > each of the different carrier options out of the box. It should be > > spelled out clearly in the production setup guide - and if it's not > > - then we should correct it there. > > > > Any additional thoughts? > > > > Cheers, > > Tim > > > > -- > > Tim Ruppert > > HotWax Media > > http://www.hotwaxmedia.com > > > > o:801.649.6594 > > f:801.649.6595 > > > > John Martin wrote: > >> Hi Dave, > >> > >> I'm not quite sure what you mean. If you mean that setting the > >> serviceName to call the API's wouldn't work properly. That is > >> correct > >> do to the missing access keys but the way that the service (at least > >> DHL) is written, it will log an error and I believe even display that > >> shipping properties need to be configured. For someone starting out, > >> this is already explained in the guide and easy to configure. > >> > >> If we don't set the serviceName correctly, most new users will > >> have no > >> means to set the entity attribute. It is not a visible field in the > >> EditProductStoreShipSetup form. > >> > >> My recommendation is to set the attribute for all of the carriers. > >> USPS is prepopulated correctly. I don't see/understand why we > >> wouldn't do the same for DHL and UPS. > >> > >> I've included the patch in the jira issue: > >> https://issues.apache.org/jira/browse/OFBIZ-328 > >> > >> Thanks, John > Kind Regards Andrew Sykes <[hidden email]> Sykes Development Ltd http://www.sykesdevelopment.com |
Free forum by Nabble | Edit this page |