Dear Suraj,
Calling service without contactNumber should not null the value in db using
these services. In case parameters send the null value then only service
will do that, if you do not want to null the value then do not pass it.
Below is example to clarify what I am suggesting;
CASE1: Pass map below value set null in db.
{"contanctMechId": "10000", countryCode: "1", contactNumber: null}
CASE2: Pass map below to remain contactNumber as is in db.
{"contanctMechId": "10000", countryCode: "1"}
I guess somehow contactNumber passed as null in Map which causes this
problem.
Best Regards,
--
Rishi Solanki
*CTO, Mindpath Technology*
Intelligent Solutions
cell: +91-98932-87847
http://www.mindpathtech.com
On Mon, Dec 16, 2019 at 2:28 PM Suraj Khurana <suraj.khur...@hotwax.co>
wrote:
> 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
> > > >>>
> > >
> > >
> >
>
