Submit and vote on feature ideas.

Welcome to the new Parasoft forums! We hope you will enjoy the site and try out some of the new features, like sharing an idea you may have for one of our products or following a category.

Coding Concrete/Collection Type Schemas for JSON Payloads

goofy78270
goofy78270 Posts: 133
edited June 2019 in SOAtest

When I import my YAML, I can see the Concrete/Collection Schema Types, but I am unable to create these manually, at least that I have seen. Is this even possible?

Is this ability even supported by Parasoft as I could find no documentation on this feature. By ability, I am referring to the ability to not only setup, but to loop through possible schemas and sub-schemas (if applicable) as shown below.

I tried to convert the payload in the yaml to literal and script, in an effort to retain the schemas, but was unable to.

Comments

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    When I import my YAML, I can see the Concrete/Collection Schema Types, but I am unable to create these manually, at least that I have seen. Is this even possible?

    I'm not sure I understand what you mean by "unable to create these manually". Are you saying that the Form JSON view isn't behaving the way you expect or are you just asking about how to avoid manually selecting concrete schema types?

    By ability, I am referring to the ability to not only setup, but to loop through possible schemas and sub-schemas (if applicable) as shown below.

    I'm not sure what you mean by "loop through". SOAtest does not automatically create multiple copies of the same test with different payload configurations. If you want to test sending different payloads for the same operation then you should make multiple copies of your test and configure the payload in each one as desired, selecting a different concrete schema type in each one if that is what you desire.

  • goofy78270
    goofy78270 Posts: 133

    Are you saying that the Form JSON view isn't behaving the way you expect or are you just asking about how to avoid manually selecting concrete schema types?

    yes. I am looking to manually set the different schemas up in other test in which the developer did not code a swagger (so no import available) to test.

    I'm not sure what you mean by "loop through". SOAtest does not automatically create multiple copies of the same test with different payload configurations.

    through script, i am looking to set each schema, from an table or external data source, and then populate data based on the schema, rather than separate entries for each possible field and schema.

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited July 2019

    I believe you would need a separate test where each one has a different concrete type selected in the Form JSON view.

  • goofy78270
    goofy78270 Posts: 133

    ok, but, to my first question, is it possible to set up schemas manually, or can they only be imported with a yaml?

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited July 2019

    I'm happy to help but I believe there is some misunderstanding. I'd like to clarify some things a bit more then attempt to answer your question once more.

    Your OpenAPI document (yaml file) is the thing that says what schema is used for each operation in your service API. Therefore, if you pick a different operation on the Rest Client's Resource tab then the Form JSON view will reflect the schema for that operation and not some other operation. Secondly, based on your screenshots, you have an operation selected where the OpenAPI document says says the request payload is of schema type "CreateIdentityInput". The Form JSON view must have found multiple child types that extend "CreateIdentityInput" and is asking you which one of those (concrete) child types you want to send. My main point is that as a user, you pick the schema "manually" by first choosing the operation on the Resource tab and then configuring the request body for that schema on the Payload tab which in some cases requires choosing between multiple matching child types.

    ok, but, to my first question, is it possible to set up schemas manually, or can they only be imported with a yaml?

    Your question has not been clear to me from the start but I'm doing my best to interpret what I think you are asking. The REST Client can consume JSON schema types from an OpenAPI/Swagger or RAML document. Your yaml file sounds like it is an OpenAPI (Swagger) document that already contains the schemas for each operation in your service. It sounds like you already have what you need!

  • goofy78270
    goofy78270 Posts: 133

    sorry for the clarity issues. let me try to clarify. I am looking for a way to set up schemas from scratch, for a request for those instances where a yaml is not available.

    for example, I am given an endpoint of http://test.com/schematest. I know there are certain schemas allowed, but since I do not have a yaml to import these schemas , I have no way to access them.

    How can I create a schema(s) for an endpoint, through parasoft itself, and NOT through the import of a yaml?

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited July 2019

    I would be interested in knowing how you imagine creating schemas "through parasoft itself" and what that might look like. A JSON schema is just a JSON file. I personally create JSON schema files using a JSON editor or just a plain text editor. A YAML file is also fine because YAML is a superset of JSON (any JSON file can be encoded as YAML). Whether you want to write your JSON Schema as JSON file or a YAML file is your choice.

    Once you have your schemas "written from scatch" using your desired JSON or text editor, you can import them but they would need to be embedded within an OpenAPI document. The OpenAPI document can be in JSON format or YAML format.

    The Swagger project has various tooling for OpenAPI. They even have a web based editor at https://editor.swagger.io/ if you find that convenient to use. It sounds like you would use an editor like this to describe your "http://test.com/schematest" endpoint including the schema for the request and/or response for that endpoint.

  • goofy78270
    goofy78270 Posts: 133

    so basically I would have to create a yaml/json file from scratch if one is not provided, but the possible schemas are.

    this is similar to setting options for a field within the Parasoft UI as this does not appear to be available, but can be set using an imported source yaml/json file.

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    I do not understand what you are stating here. How were your "possible schemas" provided? If they are not in a YAML file then how were they provided to you? Please be specific.

  • goofy78270
    goofy78270 Posts: 133

    for scenarios where a yaml was not provided, the schema was detailed in a requirements doc/acceptance criteria. the yaml was not created due to this specific endpoint not being setup in the typical swagger interface we use, hence the desire to manually create the schema(s) within SoaTest.

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    Thanks for clarification. In this case you effectively have to translate your human readable spec document to a machine consumable OpenAPI document.

    OpenAPI is based on JSON Schema which are both standards. The UI we have in the REST Client supports these standards, analogous to other tools in SOAtest that support XML Schema and WSDL. I'm not sure how else you envision SOAtest consuming your schemas if not in a formal document like OpenAPI.

  • goofy78270
    goofy78270 Posts: 133

    I was looking for a more intuitive option like a right click option on the JSON element and then an insert option to add schema (this would simply be a named instance of a sub schema for the payload).

    Same type of right click option for creating an option list of valid entries for a field rather than having to import these through an openAPI doc would be great as well.

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭
    edited July 2019

    Your request is not clear to me. How do you imagine referencing schema types from another document without providing that document in some way? You mention "named instance of a sub schema for the payload" but there has to be a document that says what that is. The document format we support is OpenAPI. Are you asking about supporting some format other than OpenAPI? Please be specific.

  • goofy78270
    goofy78270 Posts: 133

    just like today, a user can manually create a payload with the options above. I would guess this somehow is captured as a reference. Could a user have the option to also create a schema (or list) type, and then once a schema is defined (named) they would edit the schema just like a normal payload? This would essentially be a nesting of payload configurations.

    Since I am unsure how Parasoft saves the payload configuration, I am unable to offer any specifics on the how to implement, but hopefully the above is a good start on the idea.

  • benken_parasoft
    benken_parasoft Posts: 1,228 ✭✭✭

    It sounds like you would like to define your JSON schemas using a UI as opposed to coding them in an editor. I'm not sure there are any current plans for Parasoft to implement a user interface for designing JSON schemas. In contrast, I know there are other tools on the web for doing this including the one from the Swagger project that I mentioned earlier.

  • goofy78270
    goofy78270 Posts: 133

    Correct, just like today, a user can manually create a payload with the options above. I would guess this somehow is captured as a reference. It would be nice if a user could have the option to also create a schema (or list) type, and then once a schema is defined (named) they would edit the schema just like a normal payload? This would essentially be a nesting of payload configurations.

    Since I am unsure how Parasoft saves the payload configuration, I am unable to offer any specifics on the how to implement, but hopefully the above is a good start on the idea.