[
https://issues.apache.org/jira/browse/OFBIZ-6713?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15001185#comment-15001185
]
Pierre Smits commented on OFBIZ-6713:
-------------------------------------
When looking at the code in ShipmentServices, this is the section (in the
quickScheduleShipmentRouteSegment function) that will be affected:
{code}
// get the shipment label. This is carrier specific.
// TODO: This may not need to be done asynchronously. The reason it's
done that way right now is that calling it synchronously means that
// if we can't confirm a single shipment, then all shipment route
segments in a multi-form are rolled back.
try {
Map<String, Object> input = UtilMisc.toMap("shipmentId",
shipmentId, "shipmentRouteSegmentId", shipmentRouteSegmentId, "userLogin",
userLogin);
// for DHL, we just need to confirm the shipment to get the label.
Other carriers may have more elaborate requirements.
if (carrierPartyId.equals("DHL")) {
dispatcher.runAsync("dhlShipmentConfirm", input);
} else {
Debug.logError(carrierPartyId + " is not supported at this
time. Sorry.", module);
}
{code}
As you can see only a service for DHL is mentioned. And if we add (or change
to) another shipment service provider, this section must be corrected each
time.
In order to circumvent that, I thought that it would be better to use data
associated with the carrierPartyId that will lead to the appropriate OFBiz
service and also have a check whether that service is enabled.
Now the thing is that only the carrierPartyId is known. And the associated
service, that needs to be executed, can be anything. But there is a 1 on 1
relationship between carrierPartyId and the code of the service for a given
purpose.
In order to make this more configurable/less requiring code changes I came up
with the following solution of using configuration property definitions s in
either a .properties file or in SystemProperties records, e.g.
{code}
<SystemProperty
systemPropertyId="carrierPartyId"
systemPropertyValue="dhl"
description="Component associated carrier (partyId)"
systemResourceId="dhl"
/>
<SystemProperty
systemPropertyId="confirmService.name"
systemPropertyValue="dhlShipmentConfirm"
description="Name of the OFBiz specific confirm service."
systemResourceId="dhl"
/>
<SystemProperty
systemPropertyId="confirmService.enabled"
systemPropertyValue="True"
description="Indicator whether the OFBiz confirm service is enabled.
Options: False, True. Default value: False"
systemResourceId="dhl"
/>
{code}
The above indicates that the service name (the systemPropertyValue of
systemPropertyId="confirmService.name"), and whether it is available and
enabled, can be retrieved from the carrierPartyId as the systemPropertyId and
the systemResourceId, and that subsequently can be executed through the:
{code}
dispatcher.runAsync( systemPropertyValue, input)
{code}
But there might be also other options available to explore. But what could
those be?
What are the insights you can share?
> Have ShipmentServices.java work with configurable aspects regarding
> integration 3rd party shipment providers
> ------------------------------------------------------------------------------------------------------------
>
> Key: OFBIZ-6713
> URL: https://issues.apache.org/jira/browse/OFBIZ-6713
> Project: OFBiz
> Issue Type: Improvement
> Components: product
> Affects Versions: Trunk
> Reporter: Pierre Smits
>
> Current in ShipmentServices.java there are hard coded references to services
> associated with 3rd party shipment providers. In order to open it up more to
> more shipment fulfilment providers , this should be more flexible.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
