A subsequent query fails. Is it because test input needs to be provided to the Microservice processor? If so, is there a trick to copy&paste as it doesn’t seem to work for me.
As far as I know, the test input will only be used when you execute the workflow directly and not through a microservice.
In my opinion it helps to have the “expected structure” of the input data there but this is not a must as long as you execute said workflow through a microservice.
2 Likes
As Pedro already mentioned, the test input data (!) only plays a role when executing the Workflow manually “inside” ONE DATA. When called via the Microservice API, the data here gets replaced with the Microservice input from the request.
Please note, that since you have not activated “Ignore Schema Mismatch”, your input data must comply with the schema specified by your test input (in your case, it must contain two columns “Col1” and “Col2” both of type String - and nothing else). By activating the toggle above it, your input can be more arbitrary but you lose the extra safety of specifying the expected schema. And of course, the subsequent workflow must be able to cope with your arbitrary input data.
A rule of thumb is to be “ready for change” here by not using explicit column names where possible. This can be bone by using the “Extended mathematical Operations” Processor in combination with an “Exclude Columns” Processor to add a column to the input instead of having to write a select statement with explicitly naming columns which might not be present at runtime. Both processors mentioned can cope with changing inputs and will not raise errors when their input schema changes (unless you’re using a certain column for computing new columns of course).
However, given this freedom, it is highly recommended to at least try to have a static schema.
If you need more help with your failing subsequent query at hand, just paste the error!
Oh, and when using the workflow as an integrated WF inside another one (which technically differs from its dedicated use as an API-triggered Microservice), things also change a little. If this is your use case, the schema validation does not play such an important role anymore.
1 Like