InfoSource
A structure consisting of InfoObjects without persistence for connecting two transformations.
You always use an InfoSource when you want to perform two (or more) transformations consecutively in the data flow - without additional storage of the data.
If you do not need two consecutive transformations, you can model the data flow without an InfoSource. A transformation is used to write data from the source to the target.
It might be necessary to use one or more InfoSources however due to semantic reasons or the level of complexity. For example, you can specify the format and assignment to InfoObjects in the first transformation. The actual business rules can be performed in the next transformation. If the rules are very complex and interrelated, it might be advisable to use more than one InfoSource.
More information: Recommendations on Using InfoSources.
InfoSource with Key
You can mark the InfoObjects of the InfoSource as keys. This function is provided for special situations. You should check whether the result really is the one you want.
The way keys are used in InfoSources depends on integration into the corresponding load scenario. If you set the Aggregation flag in the definition of the InfoSource, the incoming data will be aggregated according to this key.
This is generally not necessary however, as the transformation in the path with the actual InfoProvider as its target compresses the data by data package anyway in accordance with the keys.
If you flag InfoObjects of the InfoSource as keys, it is very important for this key definition to be compatible with the load scenario that this InfoSource is used in. If the granularity of the key between the InfoSource and the target InfoProvider is not identical, incorrect data might arise. With aggregation SUM, this does not matter. With overwriting however, it is important that overwriting takes place for the correct key combinations.
The InfoSource key must therefore have at least the same granularity as the connected InfoProvider. It is important here to be aware of complex transformations that could change the values in the key fields.
In complex transformation scenarios, deriving a compatible key definition from the InfoSource might be different, or even impossible.
DataStore Object-Like InfoSource
With a DataStore object as the target of the transformation, you can define the InfoSource as a DataStore Object-Like InfoSource. This option is automatically selectable once the InfoSource contains InfoObject 0RECORDMODE.
If this option is selcted, the corresponding transformation in the aggregration behaves in the same way as a DataStore object, in accordance with the keys in the InfoSource. If you are using an InfoSource with a key for loading to a DataStore object, you have to select this option in order to guarantee consistent processing of before, reverse and delete images during aggregation.
The output from the InfoSource is then the same as if the data were written to the table of new data for a DataStore object (classic). In the case of a reverse image, a record is created with RECORDMODE = R, which results in the record being deleted when the request is activated. If a prior record has already written an after image with the same key in the same data package however, this will be deleted from the data package, and just the reverse image will be passed on to the transformation.
Integration
The following graphic shows how the InfoSource is integrated into the dataflow:
Create the data transfer process from the DataSource to the InfoProvider. Since the InfoSozrce is not a persistent data store, it cannot be used as a target for a data transfer process. Create each transformation on the InfoProvider (as a target) with the InfoSource (as a source) and on the InfoSource (as a target) with the DataSource (as a source).