Thanks everyone for your inputs.

Here is a case, please check these services
'createUpdateCustomerAndShippingAddress',
'createUpdateBillingAddressAndPaymentMethod'.
If we are calling these already available services without contactNumber,
as per current flow they will nullify existing contactNumber available, as
'createUpdatePartyTelecomNumber' is being called inside them and if some
contact details are found for specific purpose, which might be not passed
in context, its gets nullified and customer important data is lost.

Either we should fix this issue here, considering it from a generic
problem, I would recommend to change the serviceDef and make it work like
real situations, not likely to work as per data model flexibilities.

Please share you thoughts on this.
--
Best Regards,
Suraj Khurana
TECHNICAL CONSULTANT
mobile: +91 9669750002
email: suraj.khur...@hotwax.co
*www.hotwax.co <http://www.hotwax.co/>*


On Mon, Dec 16, 2019 at 11:35 AM Rishi Solanki <rishisolan...@gmail.com>
wrote:

> After Michael and Jacques input, I would say no need to change the existing
> behavior and in case required then it can be simply taking care by
> overriding the service definition in custom project.
> So my vote change now, no need to change ootb behavior.
>
> Best Regards,
> --
> Rishi Solanki
> *CTO, Mindpath Technology*
> Intelligent Solutions
> cell: +91-98932-87847
> http://www.mindpathtech.com
>
>
> On Thu, Dec 12, 2019 at 9:21 PM Michael Brohl <michael.br...@ecomify.de>
> wrote:
>
> > Hi Suraj,
> >
> > I don't see a reason why we should make this field mandatory. It's one
> > of a few other fields in the table.
> >
> > It *could* be of value to remove the contactNumber, in case this part of
> > the number is wrong and should not be displayed as long as it is fixed.
> > Or the telecom number ist created and will be updated with the contact
> > number later.
> >
> > The service is used in several other services, that could be a problem
> too.
> >
> > I would not change this until there is a real problem with it being
> empty.
> >
> > Regards,
> >
> > Michael
> >
> >
> > Am 12.12.19 um 09:22 schrieb Jacques Le Roux:
> > > Hi,
> > >
> > > I tend to agree, I see not reason to have it optional. Now I don't
> > > know what it implies in term of related changes, notably for custom
> > > projects...
> > >
> > > All in all I don't see a lot of positive doing so. Did you cross a
> > > specific issue Suraj?
> > >
> > > Jacques
> > >
> > > Le 03/12/2019 à 16:42, Rishi Solanki a écrit :
> > >> Hi Suraj,
> > >> It seems writing this service just to wrap the create and update
> > >> logic in
> > >> one service. So it uses the same IN parameters and constraints as
> inner
> > >> services have. IMO, we can change the wrapper service behavior based
> on
> > >> business requirements and override it.
> > >>
> > >> +1 for changing it.
> > >>
> > >> Best Regards,
> > >> --
> > >> Rishi Solanki
> > >> *CTO, Mindpath Technology*
> > >> Intelligent Solutions
> > >> cell: +91-98932-87847
> > >>
> > >> On Tue, Dec 3, 2019 at 8:17 PM Suraj Khurana <suraj.khur...@hotwax.co
> >
> > >> wrote:
> > >>
> > >>> Hello team,
> > >>>
> > >>> There is a service named 'createUpdatePartyTelecomNumber' in which
> > >>> contactNumber field is optional on service definition.
> > >>>  From DB fields perspective it seems good to have it optional,
> > >>> ideally I
> > >>> think it should not. Whether you are creating or updating any party
> > >>> telecom
> > >>> details, contactNumber should be mandatory because that's the main
> > >>> thing to
> > >>> be created/updated.
> > >>>
> > >>> Please share your thoughts, am I missing something?
> > >>>
> > >>> --
> > >>> Best Regards,
> > >>> Suraj Khurana
> > >>> Technical Consultant
> > >>> *HotWax Systems*
> > >>> *Enterprise open source experts*
> > >>> cell: 96697-50002
> > >>> http://www.hotwaxsystems.com
> > >>>
> >
> >
>

Reply via email to