Form Input XML and Literal XML

LegacyForumLegacyForum Posts: 1,669 ✭✭
edited December 2016 in SOAtest
I seem to be having an issue switching between request input types using the SOAPClient in SOATest 6.1. I pasted some XML into the Literal XML window. When I switch to Form XML view, it asks if I want to override values in Form XML view with values from Literal XML. That is good.

However, it does not do this when switching from Form Input back to Literal XML view; no option is given to override the Form Input values with the literal values. I tried deleting all the literal XML but when I switch views from Form Input to Literal XML I deleted comes back.

I also notice that when switching from Form Input to Form XML, it asks if you want to override the values. After saying yes, the values are not all moved over. For example, the "Use Data Source: exclude with empty string:" values are cleared. Also some of the values entered on the Form Input screen are not copied over.

Are these known problems?

Which view is the best (most stable/predictable) one to use when working with data sources?

Thanks

gozer




Tagged:

Comments

  • LegacyForumLegacyForum Posts: 1,669 ✭✭
    These are expected behavior.

    One can switch views between Literal XML and Form XML and carry over values if desired. However, Form Input view is a special view. It is tightly coupled with either a WSDL or a schema - meaning the way we build the Form Input must absolutely adhere to the definition described in the WSDL or schema. Literal XML and Form XML does not have this 'intelligence' and tight integration and is therefore more flexible for overriding or carrying over values.

    However, one can build a Form Input view from Literal XML view IFF the Form Input view is "empty" to begin with. For example, if you add an empty SOAP Client or Messaging Client and paste in some XML into the Literal XML view followed by switching to Form Input view, it will build the Form Input view. But once it has done so, you cannot override the Form Input view anymore. It will stay the way it is. You can refresh it if it's tied to a WSDL or schema, and it will re-build the Form Input view to reflect the new changes.

    We recommend using Form Input view if you have a readily available WSDL or schema (most users use this view). The Form Input view has a lot of features and functionality built in to it and it adheres to the WSDL or schema which provides more robust testing.

    As a secondary choice, we recommend Form XML view in the case you need more flexibility (e.g. your testing conflicts with the WSDL or schema definition).

    Both works flawlessly with data sources.

    Literal XML view is something users use to do some quick testing, but obviously do not provide a robust testing need.

    I seem to be having an issue switching between request input types using the SOAPClient in SOATest 6.1. I pasted some XML into the Literal XML window. When I switch to Form XML view, it asks if I want to override values in Form XML view with values from Literal XML. That is good.

    However, it does not do this when switching from Form Input back to Literal XML view; no option is given to override the Form Input values with the literal values. I tried deleting all the literal XML but when I switch views from Form Input to Literal XML I deleted comes back.

    I also notice that when switching from Form Input to Form XML, it asks if you want to override the values. After saying yes, the values are not all moved over. For example, the "Use Data Source: exclude with empty string:" values are cleared. Also some of the values entered on the Form Input screen are not copied over.

    Are these known problems?

    Which view is the best (most stable/predictable) one to use when working with data sources?

    Thanks

    gozer

  • LegacyForumLegacyForum Posts: 1,669 ✭✭
    Thanks for the quick response. I like Form Input view and we do have readily available WSDL files to back them up.

    Suppose we start with Literal XML to create the initial Form Input. We then use the Form Input mode to replace XML request with data source parameters. If I understand your explanation, the test now has 2 sets of data: the original Literal XML and the update Form Input. How does SOATest know which to use in the test?

    Cheers,

    gozer
  • LegacyForumLegacyForum Posts: 1,669 ✭✭
    One more thought. We use the same SOAP header for all 100+ services.

    Is there a way to use a common SOAP header with data pulled from the data source associated with the specific test?

    I have 1 test setup with the header grabbing its data from a data source (created in Form Input). I do not see a way to copy the SOAP header from one test to another. Should I create a "Header Test" and use that as a tempelte to cut and paste the entire test each time I need to test a new web services? Is there a better way to do this in SOATest 6.1?

    Thanks,

    gozer

  • LegacyForumLegacyForum Posts: 1,669 ✭✭

    Suppose we start with Literal XML to create the initial Form Input. We then use the Form Input mode to replace XML request with data source parameters. If I understand your explanation, the test now has 2 sets of data: the original Literal XML and the update Form Input. How does SOATest know which to use in the test?

    Whichever view is currently selected will be used by SOAtest. So if you've changed from Literal XML to Form Input view, then it will use the request represented by Form Input view.

    One more thought. We use the same SOAP header for all 100+ services.

    Is there a way to use a common SOAP header with data pulled from the data source associated with the specific test?

    Yes you can use a common SOAP header that pulls data from a data source for that particular test.

    I have 1 test setup with the header grabbing its data from a data source (created in Form Input). I do not see a way to copy the SOAP header from one test to another. Should I create a "Header Test" and use that as a tempelte to cut and paste the entire test each time I need to test a new web services? Is there a better way to do this in SOATest 6.1?

    There's a few ways of going about this. You can create a Global SOAP Header (right click a test suite and in the right click menu navigate to Add New > Global Property... > Global Property > Soap Headers. You can then reference to this global soap header from any of your SOAP Clients when using Form Input view. You can also create a set-up method tool test that builds the SOAP Header and pipe it to a Writable Data Source. You can then parameterize your SOAP Client with the Writable Data Source.
Sign In or Register to comment.