Table of Contents

DataSource API: In Streams

you are here (click to zoom) - discover the stack

All DataSources can have In Streams, even Root DataSources. This is because an In is often used to provide the DataSource with configuration information.

In addition to that, many DataSources expect Data which will be processed. For example, the Shuffle needs one In-Stream containing data to shuffle, while the ValueFilter expects two streams: a Default to filter on and an optional Fallback stream to return in case the filter didn't return anything.

Important

Here we only explain aspects which are relevant to your code. Make sure you are familiar with the general concept of In-Streams.

To help the UI explicitly show these predefined In-Streams, we must list them in the VisualQuery decorator attribute in the In property.

Example from the ValueFilter DataSource

[VisualQuery(NameId = "...",
  Type = DataSourceType.Filter, 
  In = new[] { Constants.DefaultStreamName, Constants.FallbackStreamName },
  DynamicIn = false,
  DynamicOut = false,
  ConfigurationType = "...",
  HelpLink = "...")]

Nice to Know

  1. If the In is not specified in the VisualQuery Attribute, then the UI will show no special In-markers
    ...except in Dynamic DataSources where the default is to always have In-Streams.
  2. By convention, the default In-stream is called Default
  3. To mark an In-Stream as required, add a * at the end, like Default*
  4. In-Streams have data which can be used, but they are not accessed until you really need them
  5. If your code really needs an In (like you require the Default stream) best use the best-practice for error-handling
  6. The property DynamicIn would mark DataSources which can work with a variable amount of In-Streams, like StreamMerge

History

  1. Introduced ca. in 2sxc 6
  2. Best practices for getting in-streams in Code were changed in v15 (breaking change)
Edit this page