Currently all pipelines of an application service use the same targetType. For services which gather both data / events and metrics, or raw / objects and events, etc. etc.
Relevant Package [REQUIRED]
Services which gather both raw, events and/or metrics. E.g a user interface application which make use of both real-time data. (instead of using polling).
Preferable the objects which are generated and/or parsed in other services are forwarded with minimal overhead, thus the raw targetType is preferred.
A combination of events and metric are perhaps more straightforward example.
Description [REQUIRED]
Add an extra parameter to AddFunctionsPipelineForTopics(..) and SetDefaultFunctionsPipeline(..). This could also be in the configuration file as part of the Trigger subject.
The service.runtime code should use the targetType stored at the pipeline instead of the global location in the service.runtime
Describe the solution you'd like
Describe alternatives you've considered
Using Event wrappers, which gives a lot of unneeded overhead and the need to create profiles for all kinds of objects
🚀 Feature Request
Currently all pipelines of an application service use the same targetType. For services which gather both data / events and metrics, or raw / objects and events, etc. etc.
Relevant Package [REQUIRED]
Services which gather both raw, events and/or metrics. E.g a user interface application which make use of both real-time data. (instead of using polling). Preferable the objects which are generated and/or parsed in other services are forwarded with minimal overhead, thus the raw targetType is preferred. A combination of events and metric are perhaps more straightforward example.
Description [REQUIRED]
Add an extra parameter to AddFunctionsPipelineForTopics(..) and SetDefaultFunctionsPipeline(..). This could also be in the configuration file as part of the Trigger subject. The service.runtime code should use the targetType stored at the pipeline instead of the global location in the service.runtime
Describe the solution you'd like
Describe alternatives you've considered
Using Event wrappers, which gives a lot of unneeded overhead and the need to create profiles for all kinds of objects