Custom panel on shipping method selection - for postage terminal selection

[erob...@gmail.com]

Hi again,

I would like to integrate REST API of postage service, which returns list of postage terminals for each city.

I think postage option "terminal_postage" would be added to shipping methods using admin. Then I need to add these custom drop down selections filled with data from REST API and save user selection to database and then somehow to pass this selection into admin app.

Are the any guidelines how I can do such extensions? 

Please help

[Yes Cart]

Hi,

The answer is: it depends on whether you postage API is dynamic or not.

If your postage service APIs are fairly static (i.e. flat rate) then it is best to add a cron job in admin that calls postage service APIs querying available terminals in all cities that you wish to support and pre-populate the available shipping methods (i.e. CarrierSla) and corresponding prices for them. Then ShippingServiceFacade.findCarriers() will return all terminals in all cities on the checkout's shipping page. If you need some dynamic selection (e.g. offer only places applicable to their shipping address) then you can do so using custom javascript by hiding the options or modifying the page template (e.g. ShippingView in community version).

If your postage service APIs is dynamic (i.e. determine available locations by some criteria from cart contents) then you probably a better approach would be integrating with postage API in the frontend (i.e. invoking API during checkout). For this you probably looking at creating a REST API client service (e.g. service using RESTTemplate bean), updating ShippingServiceFacadeImpl and inject this REST service, so that you can use it in findCarriers method to add extra options dynamically (potentially you will need to create adhoc CarrierSla records whilst doing so, make sure that you set type to E - CarrierSla.EXTERNAL and set bean name into script field). This will make it work in terms of allowing the selection of the right option. Lastly you also need to implement your own DeliveryCostCalculationStrategy that will dynamically calculate the cost. Strategy bean name needs to match what you specified in the external script field in CarrierSla. Inside the strategy you either can perform your own calculation or invoke more postage API to calculate it for you.

Hopefully this gives you a good start.

Regards,

YC team

[erob...@gmail.com]

Thanks for these details, what is the right way to add custom cron job in admin? Which xml should I extend?

So basically, if let say there are 100 cities and each city has 20 terminal, I should create 2000 CarrierSla entities data? Adn then populate these into a drop down selection in ShippingView?

Or I should extend CarrierSlaEntity and introcude new slaType = terminal and additional map of lists with terminals data in single CarrierSLa entry?

[Yes Cart]

Hi,

Yes you had it right that you would need to configure 2000 CarrierSla and that would populate the default dropdown. However it does sound a bit much, so we would recommend to change the ShippingView or even ShippingServiceFacade.findCarriers().

For ShippingView you can introduce additional step to dill down selection. Say add two options first "home delivery" or "terminal", then if the pick terminal ask the city, then third step to pick the terminal in that city. Alternatively you can do all of this in custom javascript by introducing artificial control that will select the right option behind the scenes.

For ShippingServiceFacade.findCarriers() you can add logic to pre filter cities depending on the address selection in cart that will reduce the size of the select on the page.

Ultimately it is about presentation of the selection on shipping step in the checkout.

For cron jobs see org.yes.cart.bulkjob.cron.CronJob and its uses. You will need to setup a cron job and a trigger beans and then extend the managerCronScheduleTriggers to include that trigger (see "ftCronExtension" for example on how to add to ArrayListBean without updating core files)

Regards,

YC team

[erob...@gmail.com]

These tips are very useful.

I faced another issue, that CarrierSlaEntity can not store any details about address of terminal, so I see two options.

First, example of terminal entry:

"id","name","city","address","postalCode","boxes__001","boxes__002","boxes__003","boxes__004","latitude","longitude","workingHours","servicingHours","comment","boxes__005"

"4101","Maxima XX","Alytus","Sakalo g. 1","33133","Small","Medium","Large","XLarge","55.222323","25.435055","I-VII: 00-24 h","I - V iki , VI iki ","Terminalas yra lauke, prie parduotuvės.",""

Option 1: Extend CarrierSlaEntity with additional fields like terminalName, terminalCity, terminalAddress, terminalPostalCode, terminalComments

PROS: This way I would be easily put this data on cron job and retrieve it in Shipping view to group by city, etc.

CONS: lots of extending to do on persistence and services

Option 2: concat all required data (terminalName, terminalCity, terminalAddress, terminalPostalCode, terminalComments) to CarrierSla GUID field and then parse it when loading Shipping view

PROS: No extension requirements

CONS: once fields has loads of information to be parsed, no localization ability.

Any ideas you have? Maybe you plan to implement such feature in your next Yes Cart versions?

[Yes Cart]

Hi,

Extending the model is better approach (option 1). If you do not want to create all those extra fields you can create a text field and then package up all the extra meta data. For example see CustomerOrderEntity.storedAttributes - this one has a simple class that packages up the attributes into one text field. Or you could use Jackson object mapper to serialize the extra properties as JSON into one text field.

Some more options for you:

Option 3: would be to use AddressEntity to store your details. It also has 10 custom fields where you can put anything that does not fit. Use one of the custom fields as a reference back to CarrierSlaEntity. Also if you do that ensure you add the index in DB on that column.

Option 4: would be to create a separate TerminalService that loads all data in memory from the import file. If you are getting data from API you can generate the file from API response, say CSV first and then use TerminalService to load it on context start (i.e. initialising bean). You could also make it ApplicationEventListener so that you can create internal Spring event to reload that in memory state. Pros: This way you can avoid persistence alltogether. Cons: is that you will not have this data stored anywhere.

We are aware of this use case with terminals, which some of our clients use. In most cases the implementation is very specific to a particular business and how they work with terminals/pick up points/lockers etc. Because there is no unified use case it is impossible to come up with something generic. Although we are monitoring this use case and are discussing potential implementations or foundation services. Unfortunately there is no concrete plan to implement something like this at the moment.

Regards,

YC team