- UNIFYBroker Forum
-
Ideas
Allow for modular adapter transformations and logging providers
Currently we have the ability to use a provided interface to implement a custom connector that can synchronize data in a specified manner.
Understanding that we have the powershell logging and adapter transformation ability, I feel that it would be beneficial to give people the ability to write custom transformations and custom logging providers that can be loaded into IDB in the same way that custom connectors can be.
This would provide the ability for extended transformations that may be complex to be packaged and used as necessary, avoiding messy powershell scripts. It would also abstract the logging capabilities from the base IDB install, which means that any changes in provider functionality do not need a new release to be distributed (IE splunk changing its data endpoint).
Answer
Transformations are already pluggable, they are done in a similar manner to connectors. The difference being that the transformation generator is added into to adapter engine; and the UI uses ExtensibleTransformationController instead of ExtensibleConnectorController. There aren't instructions because no-one has been interested in this before, and we added PowerShell as the extensibility point.
The log writers are technically pluggable, in the service. However, they cannot be added into the UI - meaning they can't be configured. As with the transformation, we have added PowerShell as the extensibility point. I imagine the demand for extensibility in the logging is non-existent due to the PowerShell writer. Any log writers that would be of value would be incorporated into the product. Any breaking changes (as with your Splunk example) would be fixed up in the product, as with any breaking change.
Customer support service by UserEcho
Transformations are already pluggable, they are done in a similar manner to connectors. The difference being that the transformation generator is added into to adapter engine; and the UI uses ExtensibleTransformationController instead of ExtensibleConnectorController. There aren't instructions because no-one has been interested in this before, and we added PowerShell as the extensibility point.
The log writers are technically pluggable, in the service. However, they cannot be added into the UI - meaning they can't be configured. As with the transformation, we have added PowerShell as the extensibility point. I imagine the demand for extensibility in the logging is non-existent due to the PowerShell writer. Any log writers that would be of value would be incorporated into the product. Any breaking changes (as with your Splunk example) would be fixed up in the product, as with any breaking change.