- need to mark the end of execution (similar to a transaction boundary)
- serializer does not support nested workflows
- dataflow events as well as process events are sent multiple times - dataflow now sent only once when the WorkflowFacade is created.
- some process events are empty [check?]
- how to support multiple runs of the same workflow -- the workflow ID should be different, otherwise the process events of the new run overlap with those of the older run. However, you don't want to have a 1-1 rel. b/w static structure and execution. Ideally you want to refer to an existing structure for multiple runs.
- what happens now is that T2 sends the dataflow instance, whereas we want a separation b/w the dataflow definition and its instance
- I think this means that we need some versioning info on the dataflow. Maybe the first time a dataflow is run it is assigned a unique id and this is the definition identifier, each run is then given a unique id and also has the definition id.
Test workflows:
functional testing:
- implicit iterations -- but no dot or cross product, initially simple (only one input)
- lists_iterate.xml
- "some branching"
operational testing. Goals:
- generate large numbers of events for each run
- large branching workflows -- what are we testing here??
Dispatch Layer:
- The dataflow events bubble back up to the provenance layer and are then sent to the provenance connector for storage. However, this means that duplicate events will be sent across since the all the dataflow events in the provenance connector are sent each time. There is now a fix which gets the connector to only send the last event from the list. This may need changing for some better logic at some point.
- When a dataflow run "ends" there doesn't seem to be any way of knowing this. This means that we can't send a "DataflowEnded" message to the provenance connector.