Java SDK

Hello, I am working on a new Zuora integration project and looking at the Java SDKs provided they look to be abandoned and not maintained by Zuora (last update 2yrs ago). The quickstart project doesnt look to compile either and issues reported have not been addressed.

2. When I do a POST action/query it responds with a "records" arrays. In Swagger this is a zObejct. However that zObject is empty with no properties so it is unable to deserialize the reponse. I think the swagger yaml you publish needs to be updated.

Re: Java SDK

For #1, could you give a specific example of something that's not being created that you were expecting to be created? I'm not exactly sure what you are referring to, sorry.

For #2, We've been looking into this recently to see if there's any way we can change our Swagger spec to work around the issue. It will take some more time to investigate - will let you know if we find a solution.

This makes zuoraTrackId a required param so I must provide it even though it is optional in the spec.

Not so bad in this case but when there are tens of optional fields and I'm forced to provide all of them then its practically not very usable. Maybe I am missing some configuration for codegen as I would expect optional fields in spec are not required.

Re: Java SDK

Hi rahulaga, thanks for clarifying.

I see what you mean about all the parameters. I think you can set parameters to null if you don't want to use them. But still, that is quite inconvenient. This at least seems to be a known problem with swagger-codegen: https://stackoverflow.com/questions/43044439.

I've done some more investigation into the issue you're seeing with zObject. The problem here is that what we've called zObject in our Swagger spec does not have a fixed set of fields; the names and types of the fields that could be returned in the API response depend on the type of object that you're querying.

I don't believe that we can fully capture this behavior in Swagger, other than to specify that zObject has some unnamed fields of unknown type (this is done via an additionalProperties declaration is Swagger). In theory, that would cause the ZObject class in Java to extend HashMap, which would then enable you to access the particular fields of each ZObject instance.

Unfortunately, it looks like this functionality is currently missing from swagger-codegen. See here: https://github.com/swagger-api/swagger-codegen/issues/7586. In any case, we'll update our Swagger file to support this functionality from our side, so that we are prepared for when swagger-codegen supports it.

For now, my only suggestion is that you manually modify the ZObject class in ZObject.java and insert HashMap<String, Object> in the appropriate place. For comparision, take a look at how the CalloutMergeFields class extends HashMap<String, String>.

Re: Java SDK

Thanks David. I would be hesitant to modify autogenerated code as then it would need to part of my source control and not built on the build machine.

It seems like using Swagger codegen is not really an option then and I just need to manually use a http client and create my own POJOs for serialization/deserialization. It just adds a lot of boilerplate overhead and maintenence effort. It would be nice if Zuora provided a supported SDK.

Re: Java SDK

Hi rahulaga,

I hear what you're saying - I can understand why you wouldn't want to modify the autogenerated code.

I've just done some further investigation on this and I found that it's possible to modify the Swagger spec so that swagger-codegen inserts HashMap<String, Object> in ZObject.java; no need to manually modify the autogenerated code.

However, the Swagger change would be a workaround that would misrepresent our API (and could easily cause issues elsewhere) so I'm reluctant to make that change in our offical Swagger spec. But you would of course be free to modify your copy of the Swagger spec, and the necessary modification is very suitable to be scripted.

Here's what your script would need to do:

Load our Swagger spec using a YAML parser, so that you can manipulate the spec as a native object.

Set definitions.zObject to this object:

{
"type": "object"
"additionalProperties": {
"type": "object"
}
}

Note that I'm using JavaScript notation for this example.

Output the modified spec in JSON format.

Feed the JSON file to swagger-codegen.

Is this process something that you'd be able to include in your workflow?