JSON Importer?

[Paolo F Cantoni]

I know EA can generate JSON, but is there a way to import JSON directly into EA?

Can it be done indirectly (e.g. JASON -> XSD -> EA)?  If so, what tools are recommended?

TIA,
Paolo

[Geert Bellekens]

You could write one yourself.
We've done some work on parsing source files and translating them to EA elements recently (all open source) for DDL (part of of the EA Database Transformer and Cobol copybooks (part of the EA Mapping addin

It should be pretty easy to extend that for the JSON syntax.
See
- https://github.com/GeertBellekens/cobol-object-mapper
- https://github.com/GeertBellekens/DDL-Parser

Both are based on the generic Human Parser Generator

Geert

PS. Or yo can of course outsource the development to my company, I'd be happy to provide you with a quote for a JSON parser 

[Eve]

No, I'm not aware of anything to import JSON into EA.

Given your comment about transforming to XSD and then importing, can I assume that you are in fact referring to a JSON schema?

Not sure about JASON, can't find anything that seems relevant on that. I know our schema composer generates JSON Schema files. So at least that would be a candidate for importing.

[Paolo F Cantoni]

No, I'm not aware of anything to import JSON into EA.

Given your comment about transforming to XSD and then importing, can I assume that you are in fact referring to a JSON schema?

Not sure about JASON, can't find anything that seems relevant on that. I know our schema composer generates JSON Schema files. So at least that would be a candidate for importing.

Yes, Simon,

I WAS referring to a JSON schema (I believe). As you might tell, my knowledge of JSON is limited.  We've been provided with some REST APIs with JSON definitions and are wanting to import them into EA.

Paolo

[Eve]

Ah, the standard requirements management issue. Getting to know what users need without them knowing themselves.

Stepping beyond the JSON, what you're probably after is a model of the REST api and not just the schema of each request and response. If it's well designed, all of those requests and responses probably take the form of subsets of a core data model for the service. In that case the ideal would be to import schema composer profiles, the base data model, and a list of each request path and the possible response types (including http status codes)

 It's a request I have seen before, but there's nothing built in to EA to do it.

PS. JSON is like this... XML is too complicated. Let's make a new format that's easier to read and doesn't have all those nasty schemas etc. A few months later... How can we specify what we expect in a JSON message? Let's create a way of specifying that. A few years later... JSON is too complicated. 

[Paolo F Cantoni]

[SNIP]

PS. JSON is like this... XML is too complicated. Let's make a new format that's easier to read and doesn't have all those nasty schemas etc. A few months later... How can we specify what we expect in a JSON message? Let's create a way of specifying that. A few years later... JSON is too complicated. 

Yes, I'd already gathered that! 

Paolo

[Paolo F Cantoni]

Stepping beyond the JSON, what you're probably after is a model of the REST api and not just the schema of each request and response. If it's well designed, all of those requests and responses probably take the form of subsets of a core data model for the service. In that case the ideal would be to import schema composer profiles, the base data model, and a list of each request path and the possible response types (including http status codes)

 It's a request I have seen before, but there's nothing built into EA to do it.

These are 3rd party product developers.  Data model?  What's a data model?  They can't even give me a CSV of the REST APIs.  All they can give me is a Swagger JSON output file.

Any other options to get that into EA?

Paolo

[Glassboy]

PS. JSON is like this... XML is too complicated. Let's make a new format that's easier to read and doesn't have all those nasty schemas etc. A few months later... How can we specify what we expect in a JSON message? Let's create a way of specifying that. A few years later... JSON is too complicated. 

The phrase I have heard most often is "we had xml serialization issues, so we switched to json".

[Eve]

All they can give me is a Swagger JSON output file.

Yep. Had several requests for import of swagger files. Seems to be pretty common for developers of REST APIs.

PS. Incidentally, swagger isn't in JSON although it often embeds it, the base format is in fact YAML.

[Glassboy]

All they can give me is a Swagger JSON output file.

Yep. Had several requests for import of swagger files. Seems to be pretty common for developers of REST APIs.

PS. Incidentally, swagger isn't in JSON although it often embeds it, the base format is in fact YAML.

And YAML is a human readable format. (or should be)

[Paolo F Cantoni]

All they can give me is a Swagger JSON output file.

Yep. Had several requests for import of swagger files. Seems to be pretty common for developers of REST APIs.

PS. Incidentally, swagger isn't in JSON although it often embeds it, the base format is in fact YAML.

As I said, my knowledge of JSON is extensive (ly lacking).

Should I submit a formal request, since it does seem to be increasingly common or is it already in the pipeline due to previous requests?

Paolo

[MatthiasVDE]

Paolo, what's the status about this?

I'm dealing with the same problem 

[Paolo F Cantoni]

Hi Matthias,

No real progress that I'm aware of.  It would not hurt for you to put in a formal feature request also.

Paolo

[PhilippeWolkowicz]

is there anything new regarding this subject? Did somebody work on a solution?

[qwerty]

@Philippe You should stick with Geerts suggestion: write your own. I guess it would not take me longer than 15 minutes with a basic Python script.

q.