E9.2 XRCS_getMathNumericFromElement gives error when Mathnumeric value is ZERO in XML being read

[PawPatrol]

XRCS_getMathNumericFromElement in C Business function fails to read Mathnumeric field of value 0 in XML.
XML response with ZERO in mathnumeric field mnExpirationMonth is shown below-
Mar 30 16:55:51.913568 jdecallsbf.c476 - jdeCallBusinessService - bssvPayload contents after to call to Business Function:
Mar 30 16:55:51.913592 jdecallsbf.c491 - <?xml version='1.0' encoding='UTF-8'?>
<retrieve-payment-instrument-vO>
<mn-expiration-month> <currency-code/> <currency-decimals>0</currency-decimals> <value>0</value> </mn-expiration-month>
<mn-expiration-year> <currency-code/> <currency-decimals>0</currency-decimals> <value>0</value> </mn-expiration-year>
<sz-address-line1/>
<sz-address-line2/>
<sz-administrative-area/>
<sz-card-type/>
<sz-country/>
<sz-email-address/>
<sz-first-name/>
<sz-instrument-identifier/>
<sz-last-name/>
<sz-locality/>
<sz-masked-credit-card-number/>
<sz-merchant-iD>XX</sz-merchant-iD>
<sz-payment-instrument>99999999999999999999</sz-payment-instrument>
<sz-phone-number/> <sz-postal-code/>
<sz-return-code>404</sz-return-code>
<sz-return-message>Endpoint URL not found</sz-return-message>
</retrieve-payment-instrument-vO>

The error encountered by API XRCS_getMathNumericFromElement is given below-
Mar 30 16:55:51.913616 b5503xxx.c561 - B5503XXX: After Call to SOAP API via BSSV JC553XXX-ModifXXXProcessor.retrievePaymentInstrumentSOAPCall
Mar 30 16:55:51.913632 b5503xxx.c580 - B5503XXX: Call to Webservice ModifyXXXProcessor.retrievePaymentInstrument returned NO ERROR
Mar 30 16:55:51.914592 XercesWrapper.cpp4810 - XRCS_getMathNumericFromElement: valueElemNodeList->getLength is less than or equal to 0, returning error
Mar 30 16:55:51.914728 b5503xxx.c646 - XRCS_getMathNumericFromElement failed
Mar 30 16:55:51.914784 XercesWrapper.cpp346 - Entering XRCS_freeParser

XML Read of Mathnumeric value of ZERO fails. Is XRCS_getMathNumericFromElement not capable of reading ZERO value of MathNumeric?

 

[PawPatrol]

Reply from Oracle -
"It seems the API is working as designed, not allowing a zero value.

Here are some Options:
1. Using the custom BSFN, trap for the error and avoid the zero value being sent to the API. [ Not applicable to me because my ZERO value is a response from API call ]
2. I can enter an enhancement request to have the API allow for a zero value.
3. Upgrade to the latest Tools Release (TR) as 9.2.7.x does not use XRCS."

 

[ccornagg]

Thank you for sharing present issue with 0 value using XRCS_getMathNumericFromElement

I never used such API: when I need to retrieve a math numeric value from an XML file I'm using XRCS_getElementsByTagName followed by XRCS_getElementText

Afterwards, I'm used to convert value by using BSFN ConvertStringToMathNumeric

I'm really courious to know what is the suggested approach with TR 9.2.7.x
What does it mean "9.2.7.x does not use XRCS" ? we will need to rewrite all BSFNs adopting such an API ?

Thanks,

Carlo

 

[BOster]

This doesn't answer your exact question, more of a tip.

If this is a custom BSSV, i.e. you have control over the BSSV/Java code, I found it easier to just pass everything as strings in the XML payload back to the calling BSFN. It made it exponentially easier to parse for the most part. It has been a while since I have done any BSSV development but there may have been occasions where I used data types other than strings (dates????), but for the most part I just used string data types and then converted the strings to MATH_NUMERIC, etc.

BTW, this was a tip that was given to me by the developer that taught me BSSVs. He had done considerable work with BSSVs and the two tips that he gave me that I remember and I found to be true were:

1. For consumer BSSVs, format everything as strings in the return XML payload (tip above).
2. Use BSSVs as light wrappers to BSFNs. Especially true for published BSSVs. In other words, put most of your logic in the BSFN and only use BSSVs as a thin interop wrapper. I use this same philosophy with Orchestrator BTW.