Integration and Testing

[bkiefer]

We are unable to retrieve shipping or billing information for one of our transactions due to a defect in the Java Reporting API.

The XML that we are receiving is missing the "customer" element, and as a result it is not falling into the 

if(customer_list != null && customer_list.getLength() == 1) 

block of code of the net.authorize.reporting.Results class so that the shipTo and billTo elements can be processed.

According to the authorize.net xml schema, the billto and shipto elements are not children of a customer element, so the java code should not require the customer element to be present before processing these records.

I will take a look at hacking together a solution that will get me by. Please let me know when I can expect a fix.

Quick follow up question. Is anyone else using the Java Reporting API? I've submitted three defects for it in the past two months, and none of them have been fixed yet. Is everyone working off of their own forked version of the code? Just trying to find out if there is a better way of getting these fixes pushed out to our customers.

Thank you for your help.

[bkiefer · Accepted solution]

Awesome. Glad to hear it. Congrats on getting out to github and publishing to Maven Central. I'll plug in the new version tonight and make sure my build is happy.

If all is well, I'll get this accepted for you shortly.

[RaynorC1emen7]

I would just use the Transaction Details API documentation to create your own code.

[bkiefer]

Sorry, maybe the terminology I used is incorrect. The the java reporting api I am referring to is the transaction details api. Thanks for the help though.

Ben

[RaynorC1emen7]

What you referring to is the SDKs, not the actual Transaction Details API. You can access that API thru either XML or soap interface and any programming language you want.

[bkiefer]

Ok, now I understand what you are suggesting. You'd like me to write my own java wrapper for the transaction details api, rather than using the one provided by authorize.net.

I appreciate the recommendation (seriously), and it's good to know what other people are doing. I'm not sure that I'm at the point of re-engineering a library because of a defect. I may get there soon though. Is this the approach that others have taken?

I'd rather see us move this code out to github (since it is pretty much open source anyway) and get the community submitting patches that can be released quickly.

Thank you again. For now, I'll wait for a fix to be released and keep running against my forked version.

[RichardH Administrator]

Hello @bkiefer 

I've reported your issue to the product team for analysis.

I'd recommend subscribing to this topic so that you'll be alerted via email if there are updates. To subscribe, click Topic Options at the top of this thread and then select Subscribe. You'll then receive an email once anyone replies to your post.

Thanks,

Richard

[RichardH Administrator]

Hello,

This issue is now resolved and an updated SDK is available from GitHub: https://github.com/AuthorizeNet/sdk-java/

Richard

[bkiefer · Accepted solution]

Awesome. Glad to hear it. Congrats on getting out to github and publishing to Maven Central. I'll plug in the new version tonight and make sure my build is happy.

If all is well, I'll get this accepted for you shortly.